Red Hat

In Relation To CDI

In Relation To CDI

Securing Your Applications with PicketLink and DeltaSpike

Posted by Shane Bryzak    |    Jul 7, 2014    |    Tagged as CDI PicketLink

If you’re looking for a simple way to secure your Java EE application’s classes and methods, then PicketLink in conjunction with DeltaSpike provides an elegant and flexible solution thanks to DeltaSpike’s support for typesafe security annotations. This powerful combination means you can easily apply security to your application in three simple steps, which we’ll be examining in more detail in this article.

Before we get started though, let’s take a closer look at each of these individual projects.

PicketLink

PicketLink (http://www.picketlink.org) is an application security framework for Java EE. It provides features such as Identity Management (IDM), credential management, authentication API, permissions and permission management, plus much more. At the time of writing, the latest available version of PicketLink is 2.6.0.Final.

Apache DeltaSpike

Apache DeltaSpike (http://deltaspike.apache.org) is a collection of portable extensions for Java EE, built on top of the CDI (Contexts and Dependency Injection) standard. It enhances the Java EE platform by providing a set of useful features for application developers. The latest release of Deltaspike is 1.0.

Setting up the Maven Dependencies

This step is required to add the PicketLink libraries to your application. Start by defining a property value for the version of PicketLink that you’ll be using - the latest version at time of writing is 2.6.0.Final. Add the following property declaration to the <properties> section of your project’s pom.xml:

  <properties>
    <!-- PicketLink dependency versions -->
    <version.picketlink.javaee.bom>2.6.0.Final</version.picketlink.javaee.bom>
  </properties>

Then add the PicketLink BOM to the <dependencyManagement> section:

  <dependencyManagement>
    <dependencies>
      <!-- Dependency Management for PicketLink and Apache Deltaspike. -->
      <dependency>
        <groupId>org.picketlink</groupId>
        <artifactId>picketlink-javaee-6.0</artifactId>
        <version>${version.picketlink.javaee.bom}</version>
        <scope>import</scope>
        <type>pom</type>
      </dependency>
    </dependencies>
  </dependencyManagement>

Finally, add the PicketLink dependency to the <dependencies> section:

    <dependency>
      <groupId>org.picketlink</groupId>
      <artifactId>picketlink</artifactId>
      <scope>compile</scope>
    </dependency>

We’re done! The next step is to enable the DeltaSpike security interceptor.

Enabling the Security Interceptor

For the security interceptor to perform authorization checks for the classes or methods that we wish to secure with our security binding annotations, we must first enable it in our application’s beans.xml file. In a web application this file can be found in the WEB-INF directory. Add the <interceptors> section as shown in the following example:

<beans xmlns="http://java.sun.com/xml/ns/javaee"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="
      http://java.sun.com/xml/ns/javaee 
      http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">
    <interceptors>
        <class>org.apache.deltaspike.security.impl.extension.SecurityInterceptor</class>
    </interceptors>
</beans>

Step 1: Create the Security Annotation

This first step is extremely simple - all we need to do is create an annotation and meta-annotate it with @SecurityBindingType. As an example let’s create a security annotation that we can use to restrict access only to users that are currently logged in:

@Retention(value = RetentionPolicy.RUNTIME)
@Target({ ElementType.TYPE, ElementType.METHOD })
@Documented
@SecurityBindingType
public @interface LoggedIn { }

Make sure that the @Target is set to both TYPE and METHOD - this will ensure that the annotation can be used to secure either all the methods of a class (when applied to the class itself) or to secure individual methods. The @SecurityBindingType annotation can be found in the org.apache.deltaspike.security.api.authorization package.

Step 2: Create the Authorizer method

This step is where we’ll be implementing the business logic for our security annotation. Each security binding annotation requires a corresponding authorizer method. This method must match the security binding annotation and any of its member values (excluding those annotated with @NonBinding, mirroring the behaviour of CDI itself). There must be exactly one authorizer method per unique security binding annotation usage.

The authorizer method can be placed in a bean class of your choosing, and there are no restrictions on the scope of the bean (in the following example we’ll use an @ApplicationScoped bean). Besides the security binding annotations, the authorizer method must also be annotated with @Secures, to denote that the method is being used to secure that security binding type:

@ApplicationScoped
public class Authorizer {
    @Secures
    @LoggedIn
    public boolean isLoggedIn(InvocationContext invocationContext, Identity identity) {
        return identity.isLoggedIn();
    }
}

The parameters of the authorizer method are treated as injection points (except for parameters of type InvocationContext which may be used to inspect metadata pertaining to the method from which the security check is being invoked). In the above example, we inject the Identity bean which represents the currently authenticated user - the Identity bean provides a method called isLoggedIn() that allows us to check if the current user is logged in.

Step 3: Apply the annotation to your methods

By the time we reach this step all of the hard work has been already done. The only remaining task is to apply the new security binding annotation to the methods and/or classes that you wish to secure. Let’s start off with a really simple example:

@RequestScoped
public class PostController {
    @LoggedIn
    public void getNewPosts() {
        // business logic here
    }
}

In this code we’ve applied our @LoggedIn security binding annotation to the getNewPosts() method of a request-scoped bean called PostController. When the user invokes this method, the security interceptor will intercept the method call and invoke the authorizer method to determine if the currently authenticated user is logged in. If the authorizer method returns true then the method invocation will then proceed as normal, otherwise an AuthorizationException will be thrown. If we would like to apply the same security restriction to all of the methods of a bean, we can put the annotation on the bean class instead:

@LoggedIn
@RequestScoped
public class PostController {
    public void getNewPosts() {
        // business logic here
    }
}

A Complete Example

You can find a complete example of using PicketLink with DeltaSpike in the following quickstart project:

https://github.com/jboss-developer/jboss-picketlink-quickstarts/tree/master/picketlink-deltaspike-authorization

Summary

In this article we examined how we can get the most out of DeltaSpike’s security annotation feature by combining it with a powerful security framework such as PicketLink. By following three simple steps we learned how to define a new security annotation, implement its business logic and then apply it to the methods and classes which we wish to protect.

CDI 1.1 available :-)

Posted by Pete Muir    |    May 31, 2013    |    Tagged as CDI

I'm pleased to say that CDI 1.1 is available and included in Java EE 7. If you want to learn more, read on, and join a webcast 12th June about all the technologies in Java EE 7. Both webcasts are followed by a Q&A session, when CDI experts will be on hand to answer your questions. The webcast is at [9 am PT / 12 pm ET / 5 pm London] or [9 pm PT / 12 am ET (Thursday) / 2 pm Sydney (Thursday)]

So, what's new in CDI 1.1?

Try it out and find out more

PicketLink 2.5.0.Beta3 Release and Version Change

Posted by Shane Bryzak    |    May 22, 2013    |    Tagged as CDI PicketLink Seam

I'm pleased to announce the release of PicketLink 2.5.0.Beta3. This release is actually the successor to 3.0.0.Beta2 - we've changed the version number to help avoid confusion going forward, if you want the nitty gritty details about this decision then you can find out more below.

In case you don't know what it is, PicketLink is a security framework for Java EE applications. If you are already familiar with Seam Security, then you might consider PicketLink to be its spiritual successor. For more info about its features check out this overview.

As always, here's the direct links to the various resources for this release:

PicketLink 2.5.0.Beta3 Distribution Zip

Reference Documentation

API Documentation

Source on GitHub

Report Issues

Mailing List

Mailing List Archives

Forums

For those of you that use Maven, we've made a slight change to the artifact ids - from now on a typical application will only need to declare the following dependencies:

<dependency>
  <groupId>org.picketlink</groupId>
  <artifactId>picketlink-api</artifactId>
  <version>2.5.0.Beta3</version>
</dependency>

<dependency>
  <groupId>org.picketlink</groupId>
  <artifactId>picketlink-impl</artifactId>
  <version>2.5.0.Beta3</version>
  <scope>runtime</scope>
</dependency>

<!-- Optional database schema when using Identity Management with JPA based Identity Store -->
<dependency>
  <groupId>org.picketlink</groupId>
  <artifactId>picketlink-idm-schema</artifactId>
  <version>2.5.0.Beta3</version>
  <scope>runtime</scope>
</dependency>

For this release, the reference documentation has received some special attention and so should be significantly more informative than previous betas. With that being said, the team is constantly improving the docs and will continue to add more content right up to the final release. There are also numerous quickstarts planned to help you get up and running quickly with the many security features provided by PicketLink - I'll be posting some more info about some of these shortly so keep an eye on this space.

There have also been a substantial number of bug fixes, new features and improvements made since the last beta release, the details of which you'll find in the release notes below.

As always, the PicketLink team is available to chat with at various times of the day on the #picketlink IRC channel at freenode.net; also feel free to drop them a line at the PicketLink Forums if you need help using PicketLink in your own application.

Version Change

If you've been following any PicketLink-related news lately, you'll know that the PicketLink team has been working hard towards releasing PicketLink 3 in the very near future. It has recently come to the team's attention though that there is some confusion surrounding the versioning of PicketLink, which is due to a couple of reasons; firstly, there is an existing committment to support PicketLink Federation 2.1 in EAP (the supported version of JBoss Application Server, recently renamed to WildFly). Secondly, there was never an actual 2.x release of PicketLink IDM (it was only ever officially released as version 1.x). Because of this, and since the PicketLink Federation that was planned to be released as 3.0 is actually backwards compatible with 2.1, the team has decided to rename the 3.0 release to 2.5. So what does this mean exactly? Well, besides the change in version number, not much at all really - PicketLink 2.5 will still include all of the next generation security features that the PicketLink team have been working on over the past months. We apologise for any inconvenience that this change might have caused, however the team felt it was best to resolve this confusion now, before the final release.

Release Notes

Bug

  • PLINK-116 - Change scope for JBoss Logging dependency in picketlink-common module to provided
  • PLINK-119 - DefaultIdentity is considering the User.id when comparing with the DefaultLoginCredentials.userId
  • PLINK-131 - Signed logout request does not contain the "Destination" attribute
  • PLINK-132 - PicketLink based SP's need to support different login and logout URLs
  • PLINK-136 - The IDM subsystem is always initialized even when a custom Authenticator is provided
  • PLINK-137 - Change the scope for CDI dependencies in picketlink-api and picketlink-impl to provided

Enhancement

  • PLINK-126 - Introduce individual annotations for JPA schema entities and properties
  • PLINK-135 - Add type parameters to CredentialHandler

Feature Request

  • PLINK-113 - Users should be able to use a IdentityManager for any of the configured realms.
  • PLINK-117 - The API documentation should aggregate the javadocs for the modules
  • PLINK-118 - Update documentation with the File and LDAP stores configuration
  • PLINK-120 - Login logic is not considering when the user is disabled/locked
  • PLINK-121 - Throw a specific exception when the user tries to authenticate twice using the same credentials
  • PLINK-124 - Add credential storage retrieval methods to IdentityManager
  • PLINK-127 - CredentialHandler implementations should check if the Agent is disabled
  • PLINK-128 - Refactor the Configuration API to provide a Fluent API using the build pattern
  • PLINK-142 - Provide more examples about how to mix identity stores

Task

  • PLINK-92 - Container Bindings Project
  • PLINK-122 - Provide test cases for the base module
  • PLINK-125 - Umbrella task for 2.5.0.Beta3 documentation issues
  • PLINK-129 - Import the container bindings modules from PicketLink v2
  • PLINK-133 - Use getAgent() instead of getUser() throughout authentication API
  • PLINK-138 - Change project version from 3.0.0 to 2.5.0

PicketLink 3.0 Alpha1 Released

Posted by Shane Bryzak    |    Mar 3, 2013    |    Tagged as CDI PicketLink Seam

I'm very pleased to announce the first alpha release of PicketLink 3.0. This release is the culmination of many months of effort by the JBoss Security team, with many contributions made from other project teams at JBoss and members of the community. I'd like to thank everyone involved with this release, from those who participated in the many design discussions on the security mailing list over the last few months, to those who contributed code and have started integrating PicketLink into their own projects.

For those who don't know, PicketLink is a CDI-based application security framework for Java EE, much in the same spirit of Seam Security. In fact, PicketLink 3.0 can be considered to be the spiritual successor to Seam Security, as it is more or less based on a similar core design albeit with a much more powerful and flexible identity model and feature set.

Before I go any further, here's the links to the goodies:

PicketLink 3.0.0.Alpha1 Distribution Zip

Reference Documentation * PLEASE NOTE that the reference documentation is still being written, so please be patient with us!

API Documentation

Source Code on GitHub

Report Issues

PicketLink forums

Mailing List

Mailing List Archives

For those of you that use Maven, here's the artifact id's to add to your pom.xml:

<dependency>
  <groupId>org.picketlink</groupId>
  <artifactId>picketlink-core-api</artifactId>
  <version>3.0.0.Alpha1</version>
</dependency>

<dependency>
  <groupId>org.picketlink</groupId>
  <artifactId>picketlink-core-impl</artifactId>
  <version>3.0.0.Alpha1</version>
  <scope>runtime</scope>
</dependency>

<dependency>
  <groupId>org.picketlink</groupId>
  <artifactId>picketlink-idm-api</artifactId>
  <version>3.0.0.Alpha1</version>
</dependency>

<dependency>
  <groupId>org.picketlink</groupId>
  <artifactId>picketlink-idm-impl</artifactId>
  <version>3.0.0.Alpha1</version>
  <scope>runtime</scope>
</dependency>

<!-- Optional database schema when using Identity Management with JPA based Identity Store -->
<dependency>
  <groupId>org.picketlink</groupId>
  <artifactId>picketlink-idm-schema</artifactId>
  <version>3.0.0.Alpha1</version>
  <scope>runtime</scope>
</dependency>

Currently the Maven artifacts are located in the JBoss Maven Repository, however they are planned to be synchronized to Maven Central shortly.

This initial Alpha release primarily concentrates on authentication, authorization and identity management features. Let's take a look at a couple of these features in a little more detail, starting with simple programmatic authentication.

Programmatic authentication

This simple form of authentication should be familiar to many Seam users. To control the authentication process yourself, simply provide a bean in your application that implements the following Authenticator interface:

package org.picketlink.authentication;

import org.picketlink.idm.model.User;

public interface Authenticator {
    public enum AuthenticationStatus {
        SUCCESS, 
        FAILURE, 
        DEFERRED
    }

    void authenticate();

    void postAuthenticate();

    AuthenticationStatus getStatus();

    User getUser();
}

To make things easier, we've provided an abstract base class that's already implemented everything for you except for the authenticate() method. There's only two things you need to do yourself in the authenticate() method; 1) set the authentication status to reflect whether authentication was successful, and 2) set the User object if authentication was successful. In this example, we're going to inject DefaultLoginCredentials (a simple holder bean provided by PicketLink which can be used for traditional username/password authentication) and allow authentication if the provided username is 'jsmith' and the password is '1234':

public class MyAuthenticator extends BaseAuthenticator {
    @Inject DefaultLoginCredentials credentials;

    public void authenticate() {
        if ("jsmith".equals(credentials.getUserId()) && "1234".equals(credentials.getPassword())) {
          setUser(new SimpleUser(credentials.getUserId()));
          setStatus(AuthenticationStatus.SUCCESS);
        } else {
          setStatus(AuthenticationStatus.FAILURE);
        }
    }
}

To actually perform the authentication, simply have your application set the username and password credentials on the DefaultLoginCredentials bean, then invoke the Identity.login() method - you can either do this directly from your view layer, or define a business method in your project that injects the Identity bean and then invokes its login() method. Your Authenticator bean will be found automatically by the authentication process and its authenticate() method invoked to determine whether authentication was successful. An example might look something like this:

public @RequestScoped class LoginAction {

  @Inject DefaultLoginCredentials credentials;
  @Inject Identity identity;
  
  public void login(String username, String password) {
    credentials.setUserId(username);
    credentials.setPassword(password);
    identity.login();
  }
}

Once authenticated, the Identity bean (which by default is session-scoped) can be injected into your application's beans so that you can access the currently authenticated User.

Identity Management

PicketLink's Identity Management (IDM) module provides a formal API for managing the Users, Roles and Groups of your application. Support is provided out of the box for LDAP, Database (via JPA) or File-based identity stores, and an extensible SPI allows for the implementation of additional identity storage backends. The IDM features provided by PicketLink are far too extensive to cover in a single blog post, so let's take a look at a simple example using the JPA identity store. To make things easier we provide a default database schema, included in the picketlink-idm-schema jar file. To make use of this schema, simply add the schema jar file to your project and then add a persistence-unit entry to your project's persistence.xml file, like so:

<persistence-unit name="picketlink-default"
                      transaction-type="JTA">
    <description>PicketLink Persistence Unit</description>
    <provider>org.hibernate.ejb.HibernatePersistence</provider>
    <jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source>

    <class>org.picketlink.idm.jpa.schema.IdentityObject</class>
    <class>org.picketlink.idm.jpa.schema.PartitionObject</class>
    <class>org.picketlink.idm.jpa.schema.RelationshipObject</class>
    <class>org.picketlink.idm.jpa.schema.RelationshipIdentityObject</class>
    <class>org.picketlink.idm.jpa.schema.RelationshipObjectAttribute</class>
    <class>org.picketlink.idm.jpa.schema.IdentityObjectAttribute</class>
    <class>org.picketlink.idm.jpa.schema.CredentialObject</class>
    <class>org.picketlink.idm.jpa.schema.CredentialObjectAttribute</class>

    <exclude-unlisted-classes>false</exclude-unlisted-classes>
    <properties>
        <property name="hibernate.hbm2ddl.auto" value="create-drop" />
        <property name="hibernate.show_sql" value="true" />
        <property name="hibernate.format_sql" value="true" />
        <property name="hibernate.transaction.flush_before_completion"
                  value="true" />
    </properties>
</persistence-unit>

The one other thing you must provide is an EntityManager for PicketLink to use, we can do this by writing a CDI producer field - here's an example (make sure the unitName matches the one you've configured in persistence.xml):

public class Resources {
    @SuppressWarnings("unused")
    @Produces
    @PicketLink
    @PersistenceContext(unitName = "picketlink-default")
    private EntityManager picketLinkEntityManager;
}

Once we've done that, we're ready to go! No further configuration is necessary, PicketLink provides an IDM-based Authenticator implementation that is automatically configured if the appropriate entity classes are provided.

The first thing we might want to do is to create some default users for our application. We can do this by providing a @Startup bean - here's an example in which we create a user called 'admin', to which we grant the 'administrator' application role:

@Singleton
@Startup
public class CreateDefaultUser {
    @Inject IdentityManager identityManager;

    @PostConstruct
    public void create() {
        User admin = new SimpleUser("admin");
        admin.setEmail("admin@acme.com");

        this.identityManager.add(admin);
        this.identityManager.updateCredential(admin, new Password("secret"));

        Role roleAdmin = new SimpleRole("administrator");
        this.identityManager.add(roleAdmin);

        identityManager.grantRole(admin, roleAdmin);
    }
}

The IdentityManager bean is the gateway to all of PicketLink's IDM features. It allows you to create, update and delete Users, Groups, Roles and their relationships, plus manage and validate user credentials and attributes. It can be injected into any of your project's beans any time you wish to perform Identity Management related operations.

public class MyApplicationBean {

    @Inject IdentityManager identityManager;   

}

To create a new User, Group or Role, you simply create a new instance of the object (PicketLink provides default implementations called SimpleUser, SimpleGroup and SimpleRole) and pass it to IdentityManager.add():

  User bob = new SimpleUser("bob");
  identityManager.add(bob);
  
  Group managers = new SimpleGroup("managers");
  identityManager.add(managers);
  
  Role admin = new SimpleRole("admin");
  identityManager.add(admin);

To update something, you can first look it up using the appropriate method (such as getUser(), getGroup(), etc), make your changes and then pass the object to the update() method:

  User bob = identityManager.getUser("bob");
  bob.setEmail("bob@acme.com");
  identityManager.update(bob);

To remove something, you pass it to the remove() method:

  User bob = identityManager.getUser("bob");
  identityManager.remove(bob);

Relationships are used to model typed groupings of two or more identities. PicketLink provides a few built-in relationships, and provides support for custom user-defined relationships also. The built-in relationship types are provided to address the most common identity use cases, and the IdentityManager interface declares a number of convenience methods for working with these built-in relationships. Let's take a brief look at a few examples.

Firstly, the Grant relationship is used to represent an application role. This is a role that is typically granted to a user to give them some kind of application-wide privilege. The IdentityManager.grantRole() method is used to grant an application role:

  // Grant user "bob" the "admin" role
  User bob = identityManager.getUser("bob");
  Role admin = identityManager.getRole("admin");
  identityManager.grantRole(bob, admin);

To test whether a user has an application role we use the hasRole() method:

  User bob = identityManager.getUser("bob");
  Role admin = identityManager.getRole("admin");
  boolean bobIsAdmin = identityManager.hasRole(bob, admin);

To revoke an application role, we use revokeRole():

  User bob = identityManager.getUser("bob");
  Role admin = identityManager.getRole("admin");
  identityManager.revokeRole(bob, admin);

Next, the GroupMembership relationship is used to represent a user's membership within a group. The addToGroup() method is used to add a user to a particular group:

  // Add user "bob" to the "managers" group
  User bob = identityManager.getUser("bob");
  Group managers = identityManager.getGroup("managers");
  identityManager.addToGroup(bob, managers);

To test whether a user is a member of a group, we use the isMember() method:

  User bob = identityManager.getUser("bob");
  Group managers = identityManager.getGroup("managers");
  boolean isBobAManager = identityManager.isMember(bob, managers);

Lastly, to remove a member of a group we can use the removeFromGroup() method:

  User bob = identityManager.getUser("bob");
  Group managers = identityManager.getGroup("managers");
  identityManager.removeFromGroup(bob, managers);

The last built-in relationship type is the group role. This is used when we wish to grant a user a particular role for a group, but not make them a member of the group themselves. To grant a group role, we use the grantGroupRole() method:

  // Make user "bob" an admin of the "managers" group
  User bob = identityManager.getUser("bob");
  Role admin = identityManager.getRole("admin");
  Group managers = identityManager.getGroup("managers");
  identityManager.grantGroupRole(bob, admin, managers);

To test whether a user has a particular group role, we use the hasGroupRole() method:

  User bob = identityManager.getUser("bob");
  Role admin = identityManager.getRole("admin");
  Group managers = identityManager.getGroup("managers");
  boolean isBobManagersAdmin = identityManager.hasGroupRole(bob, admin, managers);

Finally, to remove a group role we use the revokeGroupRole() method:

  User bob = identityManager.getUser("bob");
  Role admin = identityManager.getRole("admin");
  Group managers = identityManager.getGroup("managers");
  identityManager.revokeGroupRole(bob, admin, managers);

What's Next

We're aiming to have a beta release ready by mid-March, for which we're planning to have more polished code, more unit tests, better documentation and hopefully an actual example and/or quickstart that you can play around with yourself. For those adventurous enough to take the alpha release for a spin, we would love to hear some feedback from you about what you found easy, what you found hard and what we can do to make things better. For future releases of PicketLink we'll be focusing on adding some really cool features, such as support for OAuth, OpenID, SAML, Rule-based permissions with Drools, a RESTFul API and much more. You can also look forward to some more blog posts that delve further into some of the more complex PicketLink features such as ACL style permissions, identity and relationship queries, plus multi-domain support. If you'd like to leave us some feedback or have questions, please comment below or on the PicketLink forums, or if you'd like to contribute to the development discussion please join the security-dev mailing list, or alternatively catch us on the #picketlink irc channel on FreeNode.

Thanks and enjoy!

CDI 1.1 Public review draft

Posted by Pete Muir    |    Nov 13, 2012    |    Tagged as CDI

Last week the JCP posted the CDI 1.1 public review draft. This draft continues to incrementally improve the 1.0 spec. We haven't added any major new features, instead we're concentrating on honing 1.0 :-)

  • The CDI class, which provides programmatic access to CDI facilities from outside a managed bean
  • Ability to veto beans declaratively using @Vetoed
  • Conversations in Servlet requests
  • Application lifecycle events in Java EE
  • Injection of Bean metadata into bean instances
  • Programmatic access to a container provided Producer, InjectionTarget, AnnotatedType
  • Ability to override attributes of a Bean via BeanAttributes
  • Ability to process modules via ProcessModule
  • Ability to wrap the InjectionPoint
  • Honor WEB-INF/classes/META-INF/beans.xml to activate WEB-INF/classes in a bean archive
  • Global ordering and enablement of interceptors and decorators
  • Global selection of alternatives
  • @New deprecated
  • Clarify interceptors and decorators must be implemented using proxying
  • Allow multiple annotated types per Java class
  • Allow Extensions to specify the annotations that they are interested in

There are a number of open issues about which we would appreciate your feedback:

Bean visibility

The CDI 1.0 specification clearly states that only beans whose bean class is accessible (using standard classloader visibility rules) can be injected into another bean. For example, if you have a bean A in WAR, assuming standard Java EE classloader structure, it wouldn't be available for injection in bean B, in an EJB module. This generally makes sense, as the type is not visible either.

CDI also offers two options to replace bean implementations transparently, without explicitly selecting that implementation (either by type or using a qualifier) - alternatives and specialization. In this case, it is less clear that the bean class of the specializing bean, or the bean class selected alternative, must be visible.

The CDI EG is still debating this issue, including whether to offer a backwards incompatible mode here.

@ApplicationScoped beans shared between all EAR modules

CDI implementations have not consistently shared @ApplicationScoped beans across all modules of an EAR. This issue heavily relates to Bean visibility. The CDI 1.1 specification will clearly state how @ApplicationScoped are shared.

Startup event

A commonly requested feature is for the application to be able to do some work once the application has started but before it starts servicing requests originating remotely. Currently CDI 1.1 defines a @Initialized(ApplicationScoped.class) which is called when the application context starts, but we are investigating whether this can be extended to provide a more general startup event.

If we define such an event, we need to allow custom contexts to activate themselves whilst it is executing, however this is likely beyond the scope of CDI 1.1 and will likely be addressed in CDI 2.0.

@WithAnnotations

CDI 1.1 adds @WithAnnotations which allows an extension observing ProcessAnnotatedType to filter which types it sees. We would like to provide such functionality for all container lifecycle event observers, but there are some interesting things to consider, including whether it would be better to filter on qualifiers for later events. CDI 1.1 may or may not add such support, and we are looking for feedback on this.

Allowing arrays as qualifier members

CDI 1.0 requires array valued members of qualifiers to be annotated with @Nonbinding, excluding them from the resolution process. The JDK defines that annotation equality for array valued members should use Arrays.equals(), which requires two identical arrays (equal values, in the same order) in order to return true.

We feel that to make array valued members of qualifiers useful, we need to offer a pluggable strategy for checking equality of arrays, as often it would be desirable to consider two arrays with the same values, in any order, as equal. We intend to add this for CDI 1.1.

Restricting what CDI scans

CDI 1.0 will scan all classes in a jar with beans.xml. We plan to add a syntax to beans.xml that will the application developer to exclude classes using a variety of filtering options (e.g. by package). Weld offers such a syntax, and will be used as a starting point for CDI http://docs.jboss.org/weld/reference/1.1.5.Final/en-US/html/configure.html#d0e5769.

Observer resolution

CDI 1.0 requires the type used for observer resolution to be based on the runtime type of the event object. Unfortunately, the JDK erases generic type information about objects that we need to allow firing of many events with parameterized types. CDI 1.0 also completely ignores the generic type of the injected event object, which does typically contain the needed type information. We therefore intend to change the event observer resolution rules to allow the generic type of the event object to be taken into account if the runtime event object does not contain sufficient information.

Note that this may seem like a backwards incompatible change, however CDI 1.0 is essentially unimplementable today - examples in the spec do not work as described.

Coming soon! New AeroGear Site & Other Updates

Posted by Jay Balunas    |    Jul 18, 2012    |    Tagged as AeroGear CDI

It's been a little while since I wrote about AeroGear (and we're still hiring by the way!) so I wanted to take a minute and give a bit of an update and preview some things we are working on.

JBoss World

For those of you that did not get a chance to make it to JBoss World it was a great conference for mobile, and AeroGear was everywhere! It all started at the opening keynote demo showcasing jBPM, mobile, and other JBoss technology. The AeroGear team worked with the rest of the demo team to create a JBoss toy store application, both in mobile web and native versions using Apache Cordova. We also deployed the application using AppBlade, a partner of ours that allows for enterprise provisioning of native mobile applications. You can check out this video by Burr Sutter for a technical run through of the various parts. You can also download the source, and try it all out for yourself here.

There were several other sessions, BOF's and labs related to mobile development and AeroGear. In one of the AeroGear sessions I discussed where the project is, and what our upcoming plans are. I wanted to share these more broadly, and from that this blog was born!

New Project Site

One of the first things I mentioned is that the AeroGear project site needed a revamp! It was authored using a content management system (CMS), and as such could not really showcase some of the advanced functionality that we wanted to use. We also wanted to update our roadmap and wiki pages with the items below, and have them be easier to maintain.

So we're moving our project site to use Awestruct, a great tool for developing project sites that look great and let you have more control. In this we are following the footsteps of TorqueBox, Immutant, Arquillian, and JBoss Developer Framework. This means our site will be developed on github, and hosted on JBoss.org just as before, only better :-)

For our docs and wiki we're going to be moving to AsciiDoc, which is a lot like markdown, but even more powerful and supported by github! This is another great option for open source projects that want their documents to be functional, beautiful and pull request-able.

We'll be getting these updates in place as soon as possible, hopefully in the next week or two!

Native Client Libraries

As I mention in the current What is AeroGear page, we started out focused on education and examples for how to create mobile applications with existing JBoss technology. We're now moving into that 3rd column - innovation!

We're currently defining and beginning development of a set of native client libraries for JavaScript (yes, I consider this native :-), Objective-C, and Android Java to make accessing and extending the power of JBoss and JavaEE to mobile clients easy and immediately recognizable to developers on those platforms.

In my presentation I talked about what these libraries would address:

  • Persistence (secure content access via REST & Websockets, including bean validation and more)
  • Security (authentication, authorization, content encryption, and IDM)
  • Messaging & Connectivity (Integrated CDI eventing, JMS, native/non-native push, Websockets)
  • Data Sync & Offline support (Auto sync of various content across clients/servers, collision handling, and local cache)

We'll be focusing first on persistence and security as the foundation for these libraries, and initially develop the JavaScript APIs, with the Objective-C and Android libraries following (maybe even Windows Phone someday). We are still strong believers in Hybrid application frameworks like Apache Cordova, and also plan to create plugins and advanced examples for these.

Providing a server-side foundation for some of this functionality is also a new, early stage light-weight MVC that QMX developed called AeroGear Controller. While our client libraries will not depend on this entirely, some of the advanced functionality may require it, a lot of that is still TBD. To join in, check out QMX's blog aerogear controller 1.0.0.Alpha is out!

Keep An Eye Open!

So keep your eyes open for more from us in the near future, and jump into our IRC channel (#aerogear @ irc.freenode.net), forums, or mailing lists if you are interested in lending a hand or seeing whats going on!

[AeroGear Project] [GitHub] [Twitter] [User Forums] [Dev Mailing List]

Seam.Next Announcement

Posted by Shane Bryzak    |    Nov 30, 2011    |    Tagged as CDI Seam

I’m very happy to announce the details for the first phase of our Seam.Next plan. I’d like to thank everyone for waiting patiently while we worked on this, and for providing feedback either directly via e-mail or IRC, or through the Seam forums. I’d also like to thank the module leads, key community members and other people that were involved in helping to shape this plan, it was very much a collaborative effort and we are very excited about the ideas and goals that were discussed and direction going forward.

Before I get into the nitty gritty of the details, I’d first like to describe the motivations for wanting to make such significant changes, and talk about the overall goals that drive us. I think the best starting point for describing this is Seam 2.

Seam 2

Looking back at how we did things in Seam 2, I think it’s safe to say that many of the aspects of the framework were quite successful. I think that one of the most defining factors of its success was the integration - Seam 2 provided the core framework features (Dependency Injection, Contexts, Events, etc) and enough useful features built on top of that core framework to make application development quite a productive activity.

It also provided integration with a number of third party technologies, such as Drools, jBPM, Wicket, Spring and others. On top of that, it provided excellent documentation that tied the whole lot together, and did a pretty good job of bringing new developers up to speed, and not to mention decent tooling in the form of seam-gen and JBoss Tools.

All in all, Seam 2 has proven to be a mature, well rounded framework that solved many of the problems that developers face when building modern web applications.

Along Came CDI

CDI changed everything. By standardizing many of the core framework features of Seam and making them part of the Java EE platform, with an added focus on type-safety and extensibility, there is no longer a requirement to BYO framework - any compliant Java EE 6 container provides a comprehensive programming model out of the box, without having to supplement it with additional libraries to provide core services.

This was a great step forward - writing your application against a standard is a good thing. It helps you to avoid vendor lock-in, and means that as a developer your knowledge is portable. It also puts you into a great position for tapping into a growing ecosystem of extensions and tooling.

CDI Everywhere

Since CDI was released, one of the principles underlying all our work is that of CDI Everywhere. By enabling CDI support in as many places as possible, our goal is to make developer productivity stronger than ever. To that end, we have been encouraging and assisting other project teams to provide CDI integration directly from their own projects. We believe this is one of the key ingredients in strengthening the CDI ecosystem, and providing an environment where the developer can concentrate more on solving business problems and less on fighting with his tools.

This of course means that you no longer require an integration framework like Seam to provide support for a number of CDI-enabled technologies, such as Drools and jBPM (CDI support coming soon), GWT, Wicket and many others. Furthermore, since the tooling we provided for Seam 2 (i.e. seam-gen and JBoss Tools) was based on its proprietary core framework, any new tooling going forward should naturally be focused on the now standards-based component model provided by CDI. This is the reason why Forge is now a standalone, top level project in its own right, with a focus on building Java EE applications.

Seam 3

Looking at the previous diagram, we can now see that as a result of standardization, quite a few of the bits that made up Seam have moved outside the scope of the original project. This has meant a change in focus for Seam. Instead of providing a fully integrated framework stack, Seam 3 has taken the remaining bits and turned them into a collection of portable extensions for CDI. Essentially, what we did was implement many of the most useful features that were present in Seam 2, as well as adding a number of new features, in a modular structure so that Java EE developers can easily add support for these features to their application by simply dropping a jar file into their project.

At this point, in hindsight we think we made a poor choice here by calling this new project Seam 3, seeing as the nature of the project has changed so drastically from the previous version. While it is most definitely a worthwhile goal to create a set of useful extensions for CDI, Seam 3 by itself is no longer the fully integrated framework stack that Seam 2 was. As a direct result of this change in focus many of you have been disappointed with the documentation and getting started experience for new users.

What do users want?

The feedback we received from the community covered a broad spectrum of concerns, however there were some common areas such as:

  • Documentation
  • Getting Started Experience
  • Tooling
  • Lack of Drools/jBPM support
  • Lack of certain features, e.g. entity framework
  • Lack of migration guide

Underlying these, we also noticed two strong messages:

  • Some developers are interested mainly in portability. They don’t want their application locked into any particular container implementation, and it’s important to them that they have the freedom to use the framework in different environments.
  • Many developers just want an end-to-end framework that works, without having to piece together all the bits themselves and work out how to integrate them. They don’t want to have to read multiple sets of documentation from different projects, and their primary requirement for an application framework is productivity, i.e. getting the job done quickly and efficiently.

So the question is, how can we return to the fully integrated framework stack and productivity that Seam 2 provided, and also provide a set of portable extensions, optionally consumed a la carte, that will run in any environment where CDI is present? We’ve been working with community leaders and module leads, and have come up with a proposal that we think will rise to the challenge of addressing these concerns.

The first step we will take is to create a community-owned set of portable CDI extensions; a de-facto set of features that developers can take and use within their own applications, in whichever container they wish to deploy to. One of the major goals of this project is to grow and unify the Java EE community. By joining forces with other CDI extension developers, such as the Apache MyFaces CODI team and the CDISource team, as well as other key members of the Java EE community, we are creating a community that is stronger than the sum of its separate parts.

This must be a real community project, without any corporate affiliation to ensure that the project remains neutral. We’ve identified Apache as being a great place to host this project, as they are a non-profit organization with no corporate agenda, and have a strong reputation in the community for producing successful open source projects. So without further ado, let me introduce the Apache DeltaSpike project.

Apache DeltaSpike

By the time you’re reading this the proposal for Apache DeltaSpike has been submitted to the Apache Incubator and begun the process toward becoming a top level Apache project. DeltaSpike is a set of portable CDI extensions, built collaboratively by the Java EE community. It will be seeded by code contributed from various Java EE open source vendors, and provide a number of essential features for building enterprise applications. Portability will be the main principal of this project, satisfying the need of many developers for a framework that will run in a number of different environments.

After its initial release, the existing Seam development team (consisting of both full time and volunteer contributors), along with the MyFaces CODI team, CDISource team and other members of the greater Java EE community will carry out ongoing development on DeltaSpike - this includes the creation of new features and innovations, bug fixes and other enhancements. While it is not my place to talk about the release schedule for DeltaSpike (this is decided by the Apache DeltaSpike Podling Project Management Committee (PPMC)), I am 100% confident that it will be a lively, active project that receives the attention and contributions that it deserves, and produce many ongoing releases.

The first release of Apache DeltaSpike will consist of a common core, a set of extensions that will provide the base on which to build other extensions. It will be tested extensively across multiple Java EE containers to ensure portability, and provide a solid foundation for the development of other features. Eventually the plan is for Apache DeltaSpike to incorporate many of the features that you can find today in Seam.

An Integrated Framework

We have also mentioned that we’d like to address the needs for developers that require an end-to-end development stack. While we’re still working out the details for this, I’d like to reassure everyone that it is a high priority for us to provide a fully integrated framework in the spirit of Seam 2 but with even better productivity. We have some great ideas in motion to provide a full integrated framework for your needs. We know you’ll be excited as we are about what’s in store, so please watch this space over the coming months for more details.

What about Seam?

For those developers who have already invested heavily in Seam, don’t worry, we’re looking after you also. We’ll be continuing development on Seam 3 for the foreseeable future, in fact Seam 3.1 which is due for release shortly contains a number of exciting new modules and other improvements. We’d like to also reiterate that we are fully committed to the Seam Community - the initiatives that we’ve described above are all for the benefit of you guys, to give you the most productive framework and tools for building your applications that run the world. We ask that you be patient with us as we roll out this vision over the coming months, and thank you for your continued support.

Seam Spring 3.1.0.Alpha1 released

Posted by Marius Bogoevici    |    Nov 22, 2011    |    Tagged as CDI Seam

It took a while to release it (due to other work that needed to be completed first), and it took me a couple of weeks to announce it (i.e. until now), but my bit of news for today is this: the first release of our CDI Spring bridge, aka Seam Spring 3.1.0.Alpha1 is out.

The details are on the module main page, and an explanation on how it works is on the documentation page.

This first release provides:

  • facilities to bootstrap Spring contexts or access outstanding Spring contexts (e.g. web contexts bootstrapped by the ContextLoaderListener)
  • facilities to import Spring beans as CDI beans (thus making them available for standard CDI injection)
  • facilities to import CDI beans an Spring beans (thus making them available for Spring injection), including dedicated namespace support

As this is an Alpha, I am looking forward for feedback, new feature suggestions (even suggestions on prioritizing certain items that we have on the roadmap). Please use it extensively, and file bug reports(they're inevitable, and the sooner, the better).

Usage examples can be found for now in the Arquillian tests of the project source code, and I will follow up with a post describing a detailed example pretty soon.

My JavaOne 2011

Posted by Aleš Justin    |    Oct 17, 2011    |    Tagged as CDI Events

It’s more than a week since I returned home from this year’s JavaOne, hence it’s probably high time I put down a few words on what was going on there.

While I missed last year’s JavaOne, the first one under new uber-lord, I was a regular there in the past. I always really liked how things looked at the Moscone center, its huge space, filled with Java aficionados and other Java related stuff. Although I wasn’t really surprised when they told me last year that the venue has moved to downtown hotel, but I was a little worried about the negative feedback wrt this move. Hence I was pleasantly surprised by the whole setup and atmosphere this year - it wasn’t bad at all! Of course there were usual quirks - schedule with no presenter names, or actually - no schedules at all to begin with, no fill-out reports at the end of the session or someone telling people they should go online to do this; but then, it was difficult to go online with semi-working wi-fi, … Anyway, overall I think it was nice to be back again.

But I wasn’t there just for fun - while we definitely had our share of partying there :-). On Monday I had a short presentation at our JBoss booth (I'll push the link once the videos are online), talking about my experience prototyping simple mobile apps against our latest JBossAS7 / OpenShift. This was sort of a lightweight introduction to my JavaOne talk - Java EE and Google AppEngine: CDI to the rescue! Monday’s talk hinted at best practices we stumbled upon while porting the server-side from GAE to OpenShift, and having properly tested UI against the server, where Tuesday’s JavaOne talk went into more details on what it takes to fully run Java EE on GAE. If you combine all of the lessons learned, you come up with my new project called CapeDwarf.

Another thing I like about such big conferences, is that there is a huge chance you’ll run into people you’ve only “met” via email - it’s always nice to put a face to the email address, and this year’s JavaOne was no exception for me in this regard. It’s actually funny how small Java world becomes during this time; e.g. while waiting to get into our famous JBoss party, I had a nice chat with another developer also waiting to get in. It turned out this dev was Greg Luck, whose EHCache I’ve been using in the past, while also contributing some small patches. While there is a lot of Oracle folks here, specially those who work on the spec related projects / products, I also finally had a chance to meet the Weld + Glassfish guys I regularly exchange emails with.

Onward to JavaOne 2012!

Contexts and Dependency Injection 1.1 early draft submitted

Posted by Pete Muir    |    Oct 6, 2011    |    Tagged as CDI

I've just submitted an early draft of the Contexts and Dependency Injection 1.1 (CDI, JSR-346) to the JCP. We (the CDI community) have completed around a third of the features we want to see in CDI 1.1, so wanted to post an early draft to get some wider feedback. Whilst the JCP sort out the paperwork, you can read the draft on jboss.org :-)

So, what's been added since CDI 1.0?

  • @Disposes methods for producer fields
  • The CDI class, which provides programmatic access to CDI facilities from outside a managed bean
  • Pass the qualifiers an event was fired with to the ObserverMethod
  • Ability to veto beans declaratively using @Veto and @Requires
  • Ability to access the BeanManager from the ServletContext
  • Conversations in Servlet requests
  • Application lifecycle events in Java EE
  • Injection of Bean metadata into bean instances
  • Programmatic access to a container provided Producer, InjectionTarget, AnnotatedType
  • Ability to override attributes of a Bean via BeanAttributes
  • Ability to process modules via ProcessModule
  • Ability to wrap the InjectionPoint
  • Ability to obtain Extension instances from BeanManager
  • Injection of the ServletContext
  • Access to beans.xml in ProcessModule
  • Injection into enums
  • Around 60 issues addressed

However, don't worry if your favorite new feature isn't listed - we're still planning to add:

  • XML configuration
  • Global ordering for interceptors, decorators and events
  • Global enablement of interceptors, decorators and alternatives
  • Multi-plexed contexts (multi-tennancy support)
  • Service Handlers
  • Split specification into core and Java EE integration
  • Bootstrap support
  • Java SE context definition
  • Transaction scope

We're also tracking the development of other features such as:

  • Declarative transactions for managed beans
  • Async invocation and timers
  • JMS / CDI integration

So, what do you think? You can comment on this blog, email the cdi-dev@lists.jboss.org list, or direct comments to me.

What do you like? What have we missed? What don't you like? The purpose of the EDR is to get your feedback - so please, get in touch!

back to top