Help

Tags
Inactive Bloggers

As promised, we're happy to announce another early release of a Seam 3 module, Seam XML 3.0.0 Alpha 1. The Seam XML module, contributed and led by Stuart Douglas, is a CDI portable extension that allows you to add, modify and extend CDI-discovered beans using XML as an alternative to annotations.

But not just any XML. It's a typesafe XML format heavily based on an early revision of the JSR-299 (then Web Beans) specification.

Try it on for size

Let's assume you have defined the following ProducerBean class:

package org.jboss.seam.xml.test.injection;

public class ProducerBean {
   private String message = "Hello, annotation fans!";
}

and the following qualifier annotation:

package org.jboss.seam.xml.test.injection;

@Qualifier
@Retention(RUNTIME)
@Target({TYPE, METHOD, FIELD, PARAMETER})
public @interface ProducerQualifer {}

You want to expose the message field of ProducerBean using a CDI producer. You could take an annotation approach:

package org.jboss.seam.xml.test.injection;

public class ProducerBean {
   @Produces
   @ProducerQualifier
   private String message = "Hello, annotation fans!";
}

But what if the class isn't under your control, or you are more of a fan of XML tag soup? You can apply the same bean metadata using XML:

<test:ProducerBean>
   <test:message>
      <s:Produces/>
      <test:ProducerQualifier/>
      <s:value>Hello, XML fans!</s:value>
   </test:message>
</test:ProducerBean>

That snippet may take a while for your mind to parse, but observe closely how the XML tags map to the annotated version of the ProducerBean class. Notice we've also overridden the value of the message field in XML to say Hello, XML fans! rather than Hello, annotation fans! Assigning field values in XML is a very useful feature which cannot (easily) be addressed with annotations alone.

What's with all the namespace prefixes? The namespace prefix s is for the Seam XML schema and test represents the Java package of the bean class being configured. Here's the complete configuration file with the XML root and namespace declarations included. Also notice that an additional bean is being configured, ReceiverBean, this one through metadata extension.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://java.sun.com/xml/ns/javaee"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:s="urn:java:seam:core"
   xmlns:test="urn:java:org.jboss.seam.xml.test.injection">

   <test:ProducerBean>
      <s:override/>
      <test:message>
         <s:Produces/>
         <test:ProducerQualifier/>
         <s:value>Hello, XML fans!</s:value>
      </test:message>
   </test:ProducerBean>

   <test:RecieverBean>
      <s:extends/>
      <test:anotherField>
         <test:ProducerQualifier/>
         <s:Inject/>
      </test:anotherField>
   </test:RecieverBean>

</beans>

To give you the complete picture, this example wires up two beans, a bean with a producer field that produces Hello, XML fans! and a bean that injects the produced value. The ProducerBean overrides the existing bean, while RecieverBean extends the existing bean, so annotations physically present on the class will be merged with those defined in the XML file. For more information please consult the docs and exmaple that are bundled with the distribution.

Rev up your XML editor!

Now that you've seen a glimpse of what this module offers, it's time to go get it. Here are the links you need to get started.

As with all Seam 3 modules releases, the Seam XML module is published to the central Maven 2 repository. Here's the dependency declaration you need to add to your POM to include this module in your project (note the hyphen in the version):

<dependency>
   <groupId>org.jboss.seam.xml</groupId>
   <artifactId>seam-xml-core</artifactId>
   <version>3.0.0-Alpha1</version>
</dependency>

As this is an early release, there is no guarentee that the syntax is set in stone. It all depends on your feedback, which we are very interested in receiving!

Please join us!

We are hoping that all JSR-299 implementations can join us in our effort to get XML configuration into the next version of the spec. You can help by adopting this XML schema and helping us to define, refine and improve on it.

A tremendous thanks to Stuart Douglas for putting this module together. The XML configuration lays a key foundation for the entire Seam 3 project! Also thanks to Shane Bryzak for preparing the release.

Stay tuned for alpha releases of additional Seam modules in the near future, such as Seam International (i18n), which will give you enhanced language support for Java EE 6 applications, and Seam Faces, an appetizing collection of extensions and enhancements for JSF 2. Keep in mind that everything is on the drafting table right now. Join us!

Emmanuel and I sat down with Pete and Dan at Devoxx to talk about CDI and Weld.

Dan and Pete present what is CDI and what is Weld.

We discuss how CDI portable extensions allows you to extend and build on top instead of around the standard platform.

And of course you get to hear how Dan and Pete ended up working within the JBoss Community.

Get it all and more from Episode 6 at The Asylum.

11. Nov 2009, 07:10 CET, by Gavin King

Today, Red Hat submitted the final draft of JSR-299[1], which now goes under the moniker CDI (Contexts and Dependency Injection), along with the Reference Implementation and TCK. Check out the spec[1] and Javadoc.

This specification defines a powerful set of complementary services that help improve the structure of application code.
  • A well-defined lifecycle for stateful objects bound to lifecycle contexts, where the set of contexts is extensible
  • A sophisticated, typesafe dependency injection mechanism, including the ability to select dependencies at either development or deployment time, without verbose configuration
  • Support for Java EE modularity and the Java EE component architecture - the modular structure of a Java EE application is taken into account when resolving dependencies between Java EE components
  • Integration with the Unified Expression Language (EL), allowing any contextual object to be used directly within a JSF or JSP page
  • The ability to decorate injected objects
  • The ability to associate interceptors to objects via typesafe interceptor bindings
  • An event notification model
  • A web conversation context in addition to the three standard web contexts defined by the Java Servlets specification
  • An SPI allowing portable extensions to integrate cleanly with the container

I would like to take this opportunity to thank the Expert Group and everyone else who contributed ideas and criticism to this specification. Folks outside the JCP probably can't really imagine the incredible investment of time and emotional energy that it takes to create a spec like this. I would really, really like to single out a couple of individual members of the EG for their great ideas and totally uncompensated work, but I guess there's no way to do that without leaving someone feeling unrecognized.

On a more personal note, I believe (and hope) that we've done right by the community, and created something beautiful.

Tomorrow we'll be releasing Weld 1.0.

09. Nov 2009, 22:34 CET, by Gavin King

I put a whole bunch of work into the Javadoc for CDI recently. You can see it here. There's a good overview of the spec in the package doc for javax.enterprise.inject.

Oh, I also did the Javadoc for javax.interceptor, but that's not available anywhere yet.

09. Nov 2009, 14:11 CET, by Gavin King

I just noticed that CDI makes it possible to write properties files in Java, instead of plain text. I'm not sure if this is useful, but it is cute.

We define our properties in a class. Of course, since the properties are going to be deployment-specific, we should declare the class @Alternative. (Unless it holds the default values, I suppose.)

@Alternative 
class TestSettings {
   @Produces @Named String adminUser = "admin";
   @Produces @Named String adminPassword = "nimda";
   @Produces @Named int maxRetries = 100;
}

Now, we can inject these properties. Into fields:

@Inject @Named int maxRetries;

Or even into constructors or methods:

@Inject 
Connection(@Named("adminUser") String user, 
           @Named("adminPassword") String pass) { 
   ... 
}

To select the right settings class for a deployment, we list it in beans.xml:

<beans>
   <alternatives>
      <class>settings.TestSettings</class>
   </alternatives>
</beans>

You could even write a really simple portable extension that would weave in the necessary @Alternative, @Produces and @Named annotations to the following class:

@Properties 
class TestSettings {
   String adminUser = "admin";
   String adminPassword = "nimda";
   int maxRetries = 100;
}

(If you want to know how to do this, go read up on the ProcessAnnotatedType event that is part of the CDI portable extension SPI.)

Well, I suppose it would be more typesafe to create a Settings interface with getter methods for all the properties, and inject that. Still, for an accidental feature, this is kinda cool.

UPDATE: hrrrm ... this feature makes somewhat more sense, when you realize that TestSettings is also a perfect place to declare all your deployment specific resources.

Showing 1 to 5 of 58 blog entries tagged 'Web Beans'