Weld Extensions is set of portable services and utility classes for CDI which make up a good base layer for extension and application development. You can read more about the sort of portable extensions we are planning in this interview I gave.

Injectable Logger

Weld extensions includes an injectable logger, based on slf4j. By default, the fully qualified class name will be used as the category:

class Sparrow {
   @Inject
   private Logger log;

   ...
}

Alternatively you can specify a category:

class Finch
{
   @Inject @Category("Finch")
   private Logger log;
   
   ...
}

Managed Resource Streams

Weld extensions also contains managed resource streams (the stream is automatically closed for you when the bean goes out of scope) for resources loaded from the classpath:

@RequestScoped
class ResourceClient {
   
   @Inject @Resource("/META-INF/config.xml") 
   InputStream inputStream;

   public void parse() {
      // TODO Parse the inputStream!
   }
}

Here the stream will be closed for you when the request ends. Of course, you often don't know the file name you want to parse at development time, so you can also specify the name at runtime:

@SessionScoped
class ResourceClient {
   
   @Inject ResourceProvider resourceProvider;

   public void parse(String fileName) {
      InputStream is = resourceProvider.loadResourceAsStream(fileName);
      // TODO parse the XML!
   }
}

Here, the stream will be closed for you when the session is destroyed.

At the moment, only loading resources from the classpath is supported, but we'll add support for loading resources from the servlet context soon. As you can see, this can greatly simplyfy using input streams!

Extensions to the core CDI programming model

Gavin has blogged about a number of improvements to the CDI programming model, some of which are available in this release. Included are:

• Bean declaration at the constructor level
• The exact qualifier
• Compound name defaulting
• Generic beans

The extensions package is currently available in Maven, and we welcome feedback, either in the Weld forum or in JIRA. Thanks for this release go to David Allen for the injectable logger and to Gavin King and Stuart Douglas for the extensions to the core CDI programming model.

I want to spend a moment introducing you to a team restructuring we're undertaking for the Seam and Weld projects. We have decided to consolidate the community-focused roles that various people have held in the past to a single person. Whilst I (as project lead) am often focused on architecture, making sure releases happen on time, and coordinating the various contributors, the community liaison is more focused on making sure the project is both easy to consume by the community and easy to contribute ideas and code into.

Briefly, the community liaison for Weld and Seam will be responsible for taking an overview of the electronic and in-person resources. This could include maintaining a directory of blogs about Seam and Weld or identifying that there are a lot of new users struggling with a particular area through to ensuring that we have a good spread of content types (e.g. screencasts, conference appearances, reference docs etc.). You can read more about the role in the job description on seamframework.org.

Please do not confuse the community liaison for Weld and Seam with the Community Leader of JBoss.org, Mark Newton. As head of JBoss.org, Mark oversees all of the JBoss.org websites, projects and community members. The role described in this blog is more fine-grained, focused specifically on the interaction between the Seam and Weld teams and its community members and contributors.

We're currently planning this to be a rotating position that a full time project member occupies. Dan Allen will be the first in the hot seat.

Recently, we've been working hard on a solution to improve the testability of Java EE, and particularly JBoss AS. I'm pleased to say that a critical piece of puzzle, Arqullian, is now available. Congratulations to Aslak and the Arquillian team for releasing the first alpha of Arquillian! You can read more about Arquillian's mission, and our plans for Java EE testing below; alternatively, there are some quick links at the bottom if you want to dive right in.

The mission of the Arquillian project is to provide a simple test harness that developers can use to produce a broad range of integration tests for their Java applications (most likely enterprise applications). A test case may be executed within the container, deployed alongside the code under test, or by coordinating with the container, acting as a client to the deployed code. Arquillian defines two styles of container, remote and embedded. A remote container resides in a separate JVM from the test runner. Its lifecycle may be managed by Arquillian, or Arquillian may bind to a container that is already started. An embedded container resides in the same JVM and is mostly likely managed by Arquillian. Containers can be further classified by their capabilities. Examples include a fully compliant Java EE application server (e.g., GlassFish, JBoss AS, Embedded GlassFish), a Servlet container (e.g., Tomcat, Jetty) and a bean container (e.g., Weld SE). Arquillian ensures that the container used for testing is pluggable, so the developer is not locked into a proprietary testing environment. Arquillian seeks to minimize the burden on the developer to carry out integration testing by handling all aspects of test execution, including:

• managing the lifecycle of the container (start/stop),
• bundling the test class with dependent classes and resources into a deployable archive,
• enhancing the test class (e.g., resolving @Inject, @EJB and @Resource injections),
• deploying the archive to test (deploy/undeploy) and
• capturing results and failures.

To avoid introducing unnecessary complexity into the developer's build environment, Arquillian integrates transparently with familiar testing frameworks (e.g., JUnit 4, TestNG 5), allowing tests to be launched using existing IDE, Ant and Maven test plugins without any add-ons.

The Arquillian Mission Statement

The first alpha release of Arquillian gives us support for JBoss AS (remote deployments), GlassFish (embedded deployments), Weld SE (embedded deployments) and OpenEJB (embedded deployments). You can also inject beans and component (using @Resource or @Inject) into test cases.

We'll be adding supported containers in future releases - if you want to see your favorite container on the list, join our community and we can show you how to add support for it. We also plan to add more convention over configuration, meaning you'll only need to specify a single deployment and reuse it in all your test cases. Aslak has written more about future ideas in a follow-up blog entry. He also provides some examples of how to use Arquillian.

We're strong believers in writing tests, and writing tests which actually test your business logic in the environment it will finally run in, rather than introducing mocked out objects (which may behave differently). While unit testing is important to ensure the correctness of your logic, it does not ensure the correctness of two objects which interact with each other.

With the help of the ShrinkWrap project, Arquillian gives you the ability to create micro deployments around your tests. Micro-deployments are contained sub-sections of your application logic. This gives you the ability to do lower level integration testing on a lower level then normal integration. It is up to you at what level you want to test!

We also know you need a convenient way to run your test quickly, and that is why we are getting JBoss Embedded AS in shape. Embedded AS offers the potential to bootstrap JBoss AS inside the same JVM when you run your test, making it super easy to debug the test. Unfortunately, Embedded AS support didn't make this release (we made a decision to release what we have now, rather than delay), but we will push this out to you as soon as it's ready.

Testing your components and services gets you a long way, but you'll nearly always want to test your presentation tier as well. And that's where frameworks like JSFUnit and Selenium come in - they allow you to exercise the work flows your user will use. Support for both these frameworks is planned, as well as for Mock JSF Objects.

If you like what you've heard so far, but are worried that Arquillian requires build script wizardry to use, let us surprise you again! Being able to run any of these tests from within the IDE is a key goal of Arquillian -- and the key to a rapid development cycle. Arquillian requires no build wizardry! So check out the documentation and give it a try today!

[ JIRA ] | [ SPI Javadoc, API Javadoc ] | [ Reference Guide ] | [ Release Notes ]

I'm pleased to say that we have completed the 1.0.1 release of Weld, the reference implementation of JSR-299: Contexts and Dependency Injection for Java EE. It's based on the CDI 1.0 API. So go get it!. You can find direct download links at the bottom of this post or you can pull the artifacts from the Maven Central Repository.

With that out of the way, let's look at what's new and noteworthy in this release.

Release notes

In this release we've focused on bug fixing, as well as scalability improvements. Extensive profiling of memory usage has resulted in some good improvements (more to come), and we've added clustering tests to the project for JBoss AS 6.

Thanks go to the whole Weld team!

Google App Engine

If you're a fan of Google App Engine (GAE), or just looking to experiment with it (using CDI, of course!), we have really exciting news for you! Weld now has basic support for running on Google's scalable infrastructure. And just to prove it to you, we gave the Weld numberguess example its own appspot, where it's currently running the latest version of Weld.

If you want to get your own CDI + JSF 2 application running on Google App Engine, Shane Bryzak has done a fantastic job of showing you how to navigate the minefield to arrive at a successful GAE deployment. He takes you through App Engine signup, installation of the App Engine SDK plugin in Eclipse, the required CDI and JSF configurations and libraries and, finally, deployment.

Weld SE

Weld 1.0.1 brings improvements to the Java SE support, most notably allowing programmatic instantiation of the container (i.e., new Weld()). I'll let the following code do the talking:

Weld weld = new Weld().initialize();
weld.instance().select(Foo.class).get();
weld.event().select(Bar.class).fire(new Bar());
weld.shutdown();

CDI TCK

The CDI TCK (1.0.1) is also available, and includes quite a few fixes to the tests which both the GlassFish and the OpenWebBeans teams reported. Thanks to both groups for their work on this!

What's around the corner?

In the 1.0.2 release you can expect more work on memory usage, performance profiling as well as bug fixes. We'll also be working on improving support for Jetty and Tomcat. You can expect to see 1.0.2 in around 3 months time.

However our main focus is now on developing Seam 3, a collection of portable extensions for CDI and Java EE 6!

JBoss AS 6 Milestone 2

It's important for you to know that this version of Weld is not in JBoss AS 6 Milestone 2. To use Weld 1.0.1 with JBoss AS, you can update JBoss AS 6 M2:

JBOSS_HOME=/path/to/jboss-as-6 mvn -f jboss-as/pom.xml

About Weld

Weld is used in GlassFish V3 and the JBoss AS 6 series. Weld also has support for Servlet containers such as Tomcat and Jetty. While JSF support is built in, you also have the option to use Wicket as your view layer or even Swing and JavaFX through the Java SE support. If you are an OSGi fan, there's a bundle for that too.

If you are just getting started, there are a few examples in the distribution to guide you (look for instructions in the reference guide, and each example has a readme.txt). If you are looking for help, try our user forums, or perhaps join us on IRC.

[ Distribution (Weld, CDI TCK) ] | [ Release Notes (Weld 1.0.1-Final, CDI TCK 1.0.1-Final) ] | [ Reference Guide (Weld, CDI TCK ] | [ Issue Tracker ] | [ CDI Javadoc ]

Norman Richards has been busy working on a reference card for JSR-299: Contexts and Dependency Injection recently. DZone just published it so go and check it out!

Great work Norman :-)