We've been starting to think about what we want to include in Weld 1.1. Of course, you can expect the usual bug fixes, as well as a few new features -- I'll outline those for you here.

Container integration improvements

A number of refinements are planned to the existing requirements -- the biggest change will be exposing our reflection abstraction API to the container. The Weld Reflection API extends the Annotated interface hierarchy from the CDI SPI, adding in additional methods to support discovery of meta-annotated classes, methods, fields, constructors and parameters, as well as some methods to complete the reflection API. You can find the API in SVN (you can glean the intention from the API, but be aware we do intend to clean it up before exposing it to the world!).

This will allow the container to replace our built in implementation (based on JDK Reflection) allowing extensive optimisations. For example, the container must scan classes for annotations for multiple components (such as JPA, EJB 3, JAX-RS, CDI, JSF, Servlet 3) - each implementation performing its own scan is clearly both a waste of time and memory (if the implementation caches this information). Further, a container might choose to use Javassist rather than JDK Reflection to provide faster scanning.

CDI API

A CDI maintenance release is planned, and if finalised in time, we plan to include this update in Weld 1.1.

You can expect this release around September. If the CDI MR is not final, we will provide the latest revision of the changes in our non-portable API, allowing you to experiment with them in advance!

Anything else you think should be included? If so, get in touch!

Pete Muir 2010-05-08T15:11:44Z

At the last Seam meeting we ran over the the time line for Seam 3.0 release. We are aiming to have development finished by mid June, spend a month polishing up the documentation and examples, and have a release candidate ready for you to try out in mid July.

Seam 3.0 will contain:

• Drools 5 integration
• Additional JSF 2 support
• Internationalization support
• Seam Security
• XML Bean Config
• The Seam Application Framework
• jBPM 3 support
• Additional support for JAX-RS
• Additional support for Servlet
• Seam managed transactions and seam persistence contexts
• Support for transactions in Servlet Containers
• Javascript Remoting

and, if available in time:

• JMS events bridge
• Support for Errai/GWT
• Scheduling support, including asynchronous events

Looking ahead, we're aiming to release Seam 3.1 around Christmas, which will likely add support for:

• Seam 2 Backwards Compatibility
• Spring Integration
• Reporting (Excel and PDF support)
• Support for JBoss ESB
• Provisionally, support for jBPM 5

Some of these modules have releases already (and you can expect to see more very soon), and we'll continue in this vein - so you may well find that there is some support before the Seam release is complete!

We'd also like to hear what you think - do you think we should delay the 3.0 release to get more in? What would you include in the 3.0 release if you had the choice?

Pete Muir 2010-04-22T15:58:07Z

It looks like I'll be doing a series of presentations in Brazil next month - the rough schedule is:

• May 8th - JBossInBossa conference in Sao Paulo
• May 12th - JUG in Brasilia (tentative)
• May 13th - JUG in Rio de Janeiro (tentative)

Currently only the Sao Paulo event is confirmed, so if you can make that, I would strongly recommend you attend!

We would like to know what you want to hear about:

• Seam 3 Overview and Roadmap
• An overview of Java EE 6
• CDI Technical Deep dive
• Test Driven Development with Java EE 6
• JSF 2 overview, highlighting a few features

Vote now!

Pete Muir 2010-04-14T17:33:43Z

The RichFaces team is very happy to announce the 3.3.3 Final release!! The 3.3.3 release is an important milestone for RichFaces. Not only does this release build on the stability you expect from RichFaces, but it also brings basic JSF 2.0 support to the 3.3.X branch.

In this release we have resolved several critical issues, and stabilized the JSF 2.0 support. The details can be found:

• RichFaces 3.3.3 and JSF 2.0 Wiki
• JSF 2.0 Roadmap for RichFaces Blog
• Release Notes for 3.3.3 Final

You can download the latest stable artifacts from the download page or if you are using maven, you can update your dependencies following the RichFaces Maven wiki page.

As always, thanks to the development, QE, and doc teams. I wanted to say a special thanks to Andrei Markhel for tackling the majority of the issues in the 3.3.3 release, and our QE guys in Brno, Czech Republic ( Lukas and Pavol ) who did a great job testing this release. I am proud of everyone involved in this release.

JSF 2.0 Support

The RichFaces 3.3.3 and JSF 2.0 and JSF 2.0 Roadmap for RichFaces articles detail the integration requirements and plans for RichFaces and JSF 2.0. Instead of going over everything said there again I'll just take a couple of small quotes from the roadmap regarding the 3.3.3 release and JSF 2.0:

The goal of JSF 2.0 support in the 3.3.3 release is to run your existing RichFaces 3.3.X applications in a JSF 2.0/EE6 environment with little or no changes. This is an important migration step for any large application, or infrastructure. We have always meant the 3.3.3 release to be a stepping stone for JSF 2 support. We needed to make a trade off between retro-fitting 3.3.X completely for JSF 2.0 ( a major undertaking ), or have limited JSF 2.0 support in 3.3.X and push forward with RichFaces 4.0 where we can really get the most out of JSF 2.0. This is one of the reasons that we are working so hard to get RichFaces 4.0 out. Onward to RichFaces 4.0

This is the latest and last release of the 3.3.X branch, from here on out the whole team will be focused on pushing RichFaces 4.0 releases out. This is really going to be an exciting and busy time for the project. Keep an eye on this space for more in the near future!!

I would like to encourage anyone interested in Richfaces 4.0 and JSF 2.0 to look at the work already done, take part in our team meetings, and see where you can contribute. Once 4.0.0.Alpha2 release is out I'll be posting some blogs and how to articles on getting involved!

As one of the original JBoss leaders says - Onward…

[Project Site] [Stable Downloads] [Release Notes] [Jira] [User Forums] [Design Forums] [RichFaces Twitter]

Jay Balunas 2010-04-13T13:23:24Z

The schedules for JBoss World and JUDCon have now been finalised. I'll be talking about how the Java EE 6 programming model at JUDCon; I'll present the model and also look at directions the platform is likely to take. At JBoss World Dan and I will lay out the roadmap for Seam 3 and show you how it harnesses the innovations of Java EE 6 to provide a loosely coupled collection of portable extensions for Servlet containers and Java SE as well as Java EE 6. We also have a BOF covering Seam and RichFaces (hosted by Dan, Jay and myself, with as many guests as we coerce into coming!) - so start thinking up those tough questions :-D

JBoss World is in Boston this year, and runs for four days between 22 and 25th June. It's co-located with Red Hat Summit again this year, and there are about 50 sessions on JBoss technologies. There are a host of other sessions from fellow in.relation.to bloggers, including Dan, Jay, Jason, Emmanuel and Max.

JUDCon is a new conference aiming to connect JBoss Users and Developers, with highly technical presentations. The first JUDCon is happening in the same venue as JBoss World in Boston, and runs the day before JBoss World starts - admission is free (but register now as attendance is limited)! It's up to all of us (Red Hat engineers assigned to JBoss projects, community contributors and users) to make this conference a run-away success, so I encourage you to attend, or, better yet, to submit a presentation on your favourite piece of JBoss technology.

Look forward to seeing you there!

Pete Muir 2010-04-12T15:38:49Z

Following on from the success of the RichFaces Design Meetings held weekly on IRC, we're going to do the same for Seam 3. We'll be holding a regular 45 minute meeting every Thursday at 13:45 in #seam-dev on irc.freenode.net. At this meeting we will cover a mix of technical architecture and project planning - if you are interested in working on a Seam module, or just want to know more about the progress of Seam 3, this is a good opportunity to drop by!

I'm also back recently from an extended holiday to Nepal, which is a good enough excuse for me to include a photo of the high point of the trip (and at 5500m of my life!).

Pete Muir 2010-04-09T07:33:48Z

Despite all that I have written, explained and presented about Seam, I often find myself struggling to sum it up in a few short breaths. Fortunately, Matt Campbell does an superb job of defining the essence of what Seam provides eloquently and concisely in his blog series An Honest Look at Seam. (And I'm not just saying that because he credits Seam in Action as being his guide in his exploration of Seam).

• An Honest Look at Seam - Part 1: How Seam builds on Spring
• An Honest Look at Seam - Part 2: The Conversation
• An Honest Look at Seam - Part 3: Learning Seam

In part 1, Matt explains how the attention to scoping of components is what sets Seam apart from Spring and makes it more suited for the web environment. In my talks on Java EE 6, I often say that JSR-299 (CDI) considers the scope of a bean (where it's stored) to be just as important as the component instance itself. Speaking of Java EE 6, Matt does some comparisons of his own between Seam and CDI.

Having established the importance of context, Matt opens part 2 introducing the conversation scope. He quickly delves into the symbiotic relationship between this scope, the persistence context and the multi-request use case (which is just about any use case on the web). He raises the ever important issue of manual flush mode in Hibernate and how it enables use of an optimistic transaction.

Matt takes a break from the theory in part 3 to address the developer's first experience with Seam. He calms the anxiety a typical newcomer might have the first time the developer observes seam-gen churn out application. While some may appreciate the huge boast that a fully-functional application provides, the shear number of artifacts is daunting for those expecting "Hello World". But as Matt clarifies,

There is a lot to Seam, but not becuase Seam itself is vastly huge and complex, but because Seam integrates so many things together.

So take your time and explore it all. Use what parts you need and skip the parts you don't.

In the future, rather than struggling to find the words to describe Seam on a trip in an elevator, I'm just going to hand the interested listener a card with the URL to these blogs on it ;)

It's important to zero in on what Seam 2 provides, especially as we look ahead to Java EE 6 and the development of the Seam 3 portable extension library. So regardless of where you are in your adoption of Seam 2 or Java EE 6, take a moment to read through these entries.

Dan Allen 2010-03-30T06:05:48Z

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.

• Download
• Reference Guide
• Issue Tracker

As with all the Seam 3 modules, the Seam XML module will soon be published to the central Maven 2 repository. We'll let you know when that becomes available.

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!

Dan Allen 2010-03-19T04:47:39Z

I'm often asked to identify what projects I'm working on at Red Hat, or what group I'm a part of. My response reads like a laundry list:

• Seam
• Weld
• CDI TCK
• Arquillian

...and sometimes I'm really not sure if I can classify myself as a member of a certain project (e.g., RichFaces). Other developers that hang around here likely have a similar story. Eventually, we just settle on the response, I'm part of the in.relation.to crowd.

However, for people that don't know this blog, or its history, this description makes no sense whatsoever. Which made me come to the realization that we lack a true identity within the JBoss Community. I believe this detracts from the spirit of integration and coordination between projects. As my first order as Community Liaison, I set out to fix that.

Seam is often described as the glue that brings together a myriad of standard and third-party Java EE technologies. The glue that brings us together is that we are all working on creating tools and frameworks for the application developer (some use the term enterprise web developer). This purpose not only unites those of us creating these technologies, but also unites us with the folks that consume these technologies. So, to align the name of our group with the common organizational group name of our community members, we have chosen this name for our group:

Application Developer Projects Group (or the more casual name, App Dev Group)

This group is a loose knit collection of projects which people often view as their development stack:

• Seam
• JBoss Tools
• Weld (CDI)
• RichFaces (JSF)
• Hibernate Validator (Bean Validation)
• Hibernate (JPA)
• Hibernate Search
• ...perhaps others

We also recently formed the JBoss Testing Group that encompasses Arquillian, ShrinkWrap, JSFUnit, and other testing tools. Some of us are a part of that group too, myself included.

When we address this audience, or seek to describe where we fit in the JBoss community, we can really establish the connectedness by using the term App Dev, or Application Developer Projects, to show we are thinking about the concerns across technologies. So there you have it, our group name.

Dan Allen 2010-03-16T18:11:16Z

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.

Pete Muir 2010-03-10T20:30:21Z

I want to spend a moment introducing you to a new initiative we're undertaking for the Seam and Weld projects. We have decided to consolidate the community management 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 manager 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 manager 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.

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.

Pete Muir 2010-03-10T20:30:21Z

I'm happy to announce the first alpha release of Arquillian, a framework for running tests in the container. If you want to read more about Arquillian's mission, and how it fits into our vision for testing at JBoss, read Pete's blog.

It is one thing to unit test your code outside of the container, but what happens when you run it inside? Does it still behave the same? How about testing against container managed resources? This is where Arquillian comes into it's own.

With Arquillian it's just as easy to write integration tests as unit tests. In fact, to minimize the burden on you, Arquillian integrates with familiar testing frameworks, allowing reuse of tools such as the JUnit/TestNG support in your favorite IDE, Maven Surefire, Ant - in fact any tool which supports TestNG or JUnit!

To show you just how simple, here is a example test case using JUnit:

@RunWith(org.jboss.arquillian.junit.Arquillian.class) public class TemperatureConverterTestCase { @Deployment public static JavaArchive createTestArchive() { return Archives.create("test.jar", JavaArchive.class) .addClasses(TemperatureConverter.class, TemperatureConverterBean.class); } }

By using JUnit's @RunWith annotation you tell JUnit to use Arquillian as the test controller. Arquillian will then look for a static method marked with the @Deployment annotation, which creates your micro deployment. In the example above we simply deploy a session bean.

Arquillian hooks into your testing frameworks life cycle and reacts to events. On the before suite and after suite events the container is started/stopped, while on the before class and after class events your micro deployment is deployed to the container and then undeployed.

The test case is started in the local JVM, and then Arquillian overrides the normal test execution and moves it over so that it is executed in the container. By the time the test framework calls your @Test annotated method, the test is running inside the container, giving us the possibility to work with container managed resources.

@RunWith(org.jboss.arquillian.junit.Arquillian.class) public class TemperatureConverterTestCase { @Deployment public static JavaArchive createTestArchive() { return Archives.create("test.jar", JavaArchive.class) .addClasses(TemperatureConverter.class, TemperatureConverterBean.class); } @EJB private TemperatureConverter converter; @Test public void shouldConvertToCelsius() { Assert.assertEquals(converter.convertToCelsius(32d), 0d); Assert.assertEquals(converter.convertToCelsius(212d), 100d); } @Test public void shouldConvertToFarenheit() { Assert.assertEquals(converter.convertToFarenheit(0d), 32d); Assert.assertEquals(converter.convertToFarenheit(100d), 212d); } }

Note how we can use @EJB to inject the session bean from our deployment into the test case for use in our test method - neat!

The Arquillian TestEnricher SPI supports all the injection annotations from Java EE 6 - @EJB, @Resource and @Inject.

This example test case could run in GlassFish, JBoss AS or OpenEJB as there are no container specific code/configuration at all. The choice is yours. You could even test on multiple platforms!

I want to learn more, where should I go from here?

You can follow up with some in depth usage scenarios and tests described in these articles:

• Dan Allen - Using Arquillian to test a possible bug in Weld
• Jordan Ganoff - Seam 3 JMS Module Testing with Arquillian
• German Escobar - Testing a JMX Portable Extension for CDI

We also have reference documentation which walks you through the examples from Arquillian, and shows you how to create your own Arquillian test suite. You might also find the javadoc useful. You can also check out the forums and more articles can be found on our community site. If your interested in chatting to us, please drop by #jbosstesting on irc.freenode.net

So, what's next?

Some of the things you can expect from Arquillian are:

• Local run mode -- Sometimes, you don't want to run the test case inside the container itself. A local run mode will be added; a mode where your test controls the deployment but is not deployed as a part of it. This will give you the chance to run a test against, for example, JSF pages or RMI (testing for those nasty Non-Serializable / SessionClosed exceptions).

• Multiple deployments controlled by same test -- Sometimes your micro deployment is not enough to test on it's own and you want to package other components as part of the same deployment. For example, you need to test the interaction between two Web applications.

• Support for method argument injection -- In the first alpha we only support field injection. In alpha 2 we will be extending the TestEnricher SPI to include support for method argument injection:

@Test public void shouldWithdrawFromAccount(@EJB AccountManager manager) throws Exception { ... }

• Test method interceptors -- Another planned enricher SPI is a test method interceptor. With this we can add support for transactions:

@Test @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW) public void shouldWithdrawFromAccount(@EJB AccountManager manager) throws Exception { ... }

• Convention over configuration -- The micro deployments should be as easy as possible to create, so adding support for common conventions should help speed up the test development. For example we can automatically add all classes in the same package as the test class to the deployment

• Arquillian controlled resources -- Sometimes the container requires container specific configuration e.g, java.naming.\* parameters needed to create a InitialContext. If the test case has to explicitly deal with this, it places the burden for container portability back on the test case author. Arquillian will provide an extension point to add Arquillian created/managed resources:

// auto creation of InitialContext based on running container, remote or local. @ArquillinResource private InitialContext context; // auto creation of URL to a specific deployed Servlet, including http port/ip etc. @ArquillinResource(MyServlet.class) private URL myServletURL; // the bundle context of a deployed osgi bundle @ArquillinResource private BundleContext context;

• Add support for more containers -- We will plan to support more containers! Currently we have planned: GlassFish 3 (as a remote container), Jetty, Tomcat, Resin, Felix OSGI.

• Third party integrations -- In the spirit of ease of development, we integrate with existing test frameworks as much as possible, but we are always keen to learn of new frameworks we can integrate with. We already plan to support Selenium for example.

• Support for Other build tools -- Arquillian Alpha1 comes with Maven support. In upcoming releases, we will distribute builds targeted toward other build tools like Ant.

Where can I see Arquillian in use?

Arquillian is a new framework, but it will be used to test all the Seam 3 modules, and will be our recommended solution for testing your Seam application. We'll also replace the current core of the JSR-299 CDI TCK with Arquillian, likely for the 1.1 version of the TCK

If you have any thoughts on these ideas, or would like to suggest some new avenues we should explore, please contact us on the Arquillian Dev forum.

And, what is open source with out the community!

A big thanks to the Arquillian and ShrinkWrap community for helping out on this release by being early adopters, joining in on community meetings, general discussions and writing blogs, articles and patches. In alphabetical order: Dan Allen, Steven Boscarine, German Escobar, Jordan Ganoff, Ken Gullaksen, Pete Muir, Jason Porter, Andrew Lee Rubinger

[JIRA] | [SPI Javadoc API Javadoc] | [Reference Guide] | [Release Notes] [Maven Artifacts]

Aslak Knutsen 2010-03-10T19:30:35Z

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 out! 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 the same blog you can find examples of using Arquillian, as well as some sample uses.

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 from 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 boostrap 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 seen, but are worried that Arquillian requires build script wizardry to use, let us suprise you again! Being able to run any of these tests from within the IDE is a key goal of Arqullian -- and the key to a rapid development cycle. Arquillian requires no build wizardry!

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

Pete Muir 2010-03-10T19:26:12Z

If you've ever programmed in PHP, Ruby, Perl, Groovy, and probably others, then you know how nice it is to have a central, official space for reference documentation and inline community feedback.

This is something that has sorely been missing from the JEE community, and something that has caused many disparate websites to attempt putting forward a weak effort in providing useful documentation -- you leave the community part aside to think that this is a good thing for any open-source technology.

A successful open-source community documentation initiative has:

• Comprehensive documentation provided on a central, official website (http://seamframework.org)
• Inline comments and user feedback.
• The most common paths on the website are the most visible, intuitive paths.
• Fluent navigation and document hierarchies. (The URL matches the Breadcrumbs matches the content. If users get lost, users give up.)
• Accurate and relevant official information, well vetted information.

I'm sure there is more, but that's what I have at the top of my head.

Making progress happen:

In kick-starting my (hopefully long) tenure with Red Hat, I'm focusing on improving community documentation for the Seam Framework, and for Java EE as a whole. I've started by updated the Seam Framework website to more clearly display the links to Seam and Weld JIRAs; you previously had to do a little digging.

All of my efforts can be tracked here: https://jira.jboss.org/jira/browse/JBSEAM-4585

Please, I ask if you find any outstanding problems, or points of pain with the Seam or Weld documentation, to add it to this Jira. If you can't, then comment here and I'll see that it's addressed.

SeamFramework.org needs work, and I do think that the community really belongs on jboss.org, in order to fully get credit for their hard work and great achievements. Jboss.org also provides much of the functionality that I'm looking for in a community management tool, but we'll see what everyone wants ;)

Happy communities make happy software!

Lincoln Baxter III 2010-03-04T19:09:35Z

Now that RichFaces 3.3.3 is nearing its final release I wanted to take some time and discuss our plans for RichFaces and JSF 2.0 support in more detail.

RichFaces 3.3.3+

The goal of JSF 2.0 support in the 3.3.3 release is to run your existing RichFaces 3.3.X applications in a JSF 2.0/EE6 environment with little or no changes. This is an important migration step for any large application, and infrastructure.

We have always meant the 3.3.3 release to be a stepping stone for JSF 2 support. We needed to make a trade off between retro-fitting 3.3.X completely for JSF 2.0 ( a major undertaking ), or have limited JSF 2.0 support in 3.3.X and push forward with RichFaces 4.0 where we can really get the most out of JSF 2.0. This is one of the reasons that we are working so hard to get RichFaces 4.0 out.

In addition to the information in our release announcements ( 3.3.3.BETA1 and 3.3.3.CR1 ) and our wiki page Richfaces 3.3.3 and JSF 2.0, a few people have also posted blogs and articles that I think explain the plans for RichFaces support of JSF 2.0 well. DZone posted RichFaces 3.3.3 Begins Support for JSF 2.0 and Max Katz has posted RichFaces 3.3.3 RC1 and JSF 2.

RichFaces 4.0.0

RichFaces 4.0 is where we can really innovate and extend features to get the most out of JSF 2.0. RichFaces did this for JSF 1.2 and we plan to push the specification to the limits, and prototype the future of JSF!

This is going to include:

• New Custom behaviors
• Dynamic resource extensions
• Simplified component development kit (CDK)
• Customizable request queues
• Updated skinning
• Consolidated component set ( with all functionality you expect )
• Performance tuning and review
• Semantic HTML markup changes to make styling easier
• Interoperability with other component libraries
• Module build system for easy contributions

Plus, all the flexibility and stability needed for large scale development. This does mean that taking advantage of some JSF 2.0 features with RichFaces will need to wait for 4.0. The good news is that we are well on our way to our next 4.0 release, and we will have several time-boxed milestone releases to jump start your development.

We are also going to have detailed migration instructions, scripts, examples and a migration bridge to assist users in moving their existing applications to RichFaces 4.0. The details of this are not completely worked out yet, but our goal is make it as easy as possible for users of 3.3.X to migration to 4.0.

I would like to encourage anyone with an opinion or an idea to contribute to the process. Take a look at our releases, post to our forums, check out our meetings and get involved!

[Project Page] [JIRA] [User Forums] [Design Forums] [RichFaces Twitter]

Jay Balunas 2010-02-26T15:27:35Z

The JSF 2 series on DZone we've been working on continues with an introduction to JSF 2 client behaviors by guest author Andy Schwartz. Andy is a member of the JSR-314 Expert Group (EG) and architect on the ADF Faces project team at Oracle Corporation.

In this installment, Andy introduces you to client behaviors for UI components, an API which he led, in collaboration with Alex Smirmov (Exadel), Roger Kitain (Sun/Oracle) and Ted Goddard (ICEsoft), to provide a general extension point for adding client-side functionality (i.e., JavaScript) to existing UI components. This new API quickly received support and input from the entire EG and proved to be a solid foundation on which the declarative Ajax control (i.e., <f:ajax>) could be based.

One of the goals of providing an extensible API is to encourage JSF users to leverage this for their own needs. While we only have a single standard behavior (<f:ajax>) today, we expect to see many third party behavior implementations in the near future. Some of these behaviors may be candidates for inclusion in future versions of the JSF specification – perhaps even yours!

We'd like to thank Andy for contributing his time and dedication in writing this article! Although Andy represents a different company than the other authors in this series, we come together as colleagues on the JSR-314 EG. The strong partnerships that are built between companies through their participation in JSRs are what make the JCP an asset to the Java EE community and allow the technologies to take such large leaps, in this case JSF. You can thank him too by rating the article.

Dan Allen 2010-02-26T08:30:09Z

UPDATE: The artifacts are now published to the Maven Central Repository (apologies, I forgot to hit the promote button).

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 ]

Pete Muir 2010-02-24T10:44:32Z

I'd like to introduce to you the newest member of the Seam engineering team, Lincoln Baxter III, Lincoln has contributed (very vocally) to JSF 2 and developed a number of Open Source Java projects (such as PrettyFaces, PrettyTime and Scrum Shark). I'll take this opportunity to help you get to know him a little and share with you an abbreviated story of how he arrived at Red Hat.

Lincoln's interaction with the Seam development team started with one of those Can someone please take a look a this? e-mails from Gavin. It was Lincoln introducing his PrettyFaces extension for JSF.

I'm the author of the PrettyFaces extension. (...An explanation of how it works and what problems it solves in Seam...) My source is available here and is licensed under the GPL3. Most of what I think you'd be interested in will be in the PrettyViewHandler class, which is ... simple. Have at it. http://ocpsoft.com/prettyfaces

At around the same time Norman was developing a URL rewriting solution for Seam, so we didn't end up giving Lincoln much of a chance on this go around ;)

When Lincoln really started to catch our eye was when he posted on his blog that JavaServer Faces 2.0 is in Good Hands. In the blog entry, he highlights the impact Red Hat was having (namely Pete and myself) on the progress of the JSF 2 specification. He credited us as the first to really listen to the community and drive the spec the direction that made the community feel assured and engaged. In short, he identified Red Hat as having leadership, and emphasized how important that quality is to him.

But we couldn't fill his entire vision. Lincoln has the false hope that Sun was putting effort into creating resources to help make the platform easy for newcomers to start using, in particular JSF, and that the JCP truly embraced openness. I had to let him down gently that both assumptions were a long way from reality. I would learn from Lincoln's next move how much he really cared about making these perceptions a reality and whether he could affect change.

The fact that I'm writing this introduction gives away the answer.

A couple mornings later, the JSR-314 EG woke up and there was a new guy posting to a mailinglist...a mailinglist that was very difficult to get on (for a myriad of technical and political reasons). Lincoln found a way through. How? He became an individual JCP member, far from a simple task. He pleaded to Ed Burns to let him join the list and to be allowed to post. Gradually, people began to view him as an EG member and soon after, everyone just accepted that he was an official member of the group. In fact, we would probably still be trying to find our own arse without him :)

Since then, Lincoln has been a part of just about everything that has happened with the JSF EG. With a promise to Kito Mann and Jay Zimmerman that Lincoln would be among the best speakers at JSFSummit (despite having no speaking credentials), I got him into the conference to speak about his project, PrettyFaces. There he attended the JSF EG meeting, launched http://javaserverfaces.org--which he managed to convince Kito Mann to donate to the group--and sure enough, he gave the best talk of the conference (as decided by the attendees) in front of 12 EG members!

Right after JSFSummit, I contacted my managers at Red Hat and recommended that we hire Lincoln. I argued that we don't just want this guy to join our community, we want him to be a leader in our community. We definitely didn't want him to be stuck behind a desk fixing form fields any more.

I could go on, but your break is probably over by now. Many of you will get a chance to meet with Lincoln at the next JBossWorld or interact with him in the JBoss.org community. One way or another, Lincoln is going to be one of the key leaders of our community, I guarantee it.

Good luck, Lincoln! And no pressure. Just do what you do best. Keep it simple!

Dan Allen 2010-02-19T03:37:18Z

The RichFaces team is another step closer to releasing the final 3.3.3 release! Today we are pleased to announce that RichFaces 3.3.3.CR1 is up and ready to try! This is most likely the last release before the final 3.3.3 release, which means it is also your last chance to help us help you :-)

Give this release a run-through and let us know if you have any issues. You can download the bits from the milestone download page or if you are using maven, you can update your dependencies following the RichFaces Maven wiki page.

The 3.3.3 release is a special one for RichFaces. Not only because it adds a great amount of stability, but also brings JSF 2.0 support to the 3.3.X branch. With this release you will be able to run your existing RichFaces applications with JSF 2.0. This is an important step in migrating your existing applications to JSF 2.0. If you plan on running this release on top of JSF 2.0 make sure to checkout RichFaces 3.3.3 and JSF 2.0 wiki page for all the details.

We've tackled quite a few issues, and have stabilized much of the JSF 2.0 support. You can check out the full list of jira issues resolved in the Release Notes for 3.3.3.CR1.

As always please let us know if you have any comments or feedback, and especially if you find any issues.

[Project Pages] [Milestone Downloads] [JIRA] [User Forums] [Design Forums] [RichFaces Twitter]

Jay Balunas 2010-02-17T13:06:28Z

In preparation for the release of Weld 1.0.1 on February 19th, we've pushed out a full distribution of Weld 1.0.1-CR2 for final inspection. It's based on the proposed CDI 1.0-SP1 API. Grab it, test it, play with it, give us feedback, let us know if it gets your stamp of approval. You can find direct download links at the bottom of this post or you can pull the artifacts from the Maven Central Repository.

For the Weld 1.0.1-CR1 release, we only published the Weld artifacts to the Maven Central Repository. We held off creating a full distribution until 1.0.1-CR2. Missed JBoss AS 6 M2

Before we get to the release notes, it's important for you to know that this version of Weld will not be in JBoss AS 6 M2. You'll need to grab a JBoss AS 6 snapshot if you want the out of the box experience.

You also have the option of updating your JBoss AS 6 installation using this command from the root of the Weld distribution:

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

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

Release notes

As you've come to expect out of this project team, this release (CR1 and CR2) includes major improvements in memory usage as well as numerous bug fixes (see the release notes below for details). We'll keep progress coming in these areas, as well as work on performance improvements in the Weld versions on the horizon.

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. Go check it out!

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 in part 1 of his GAE tutorial series.

Props to the Weld community for working with the Weld project team to identify and patch assumptions in Weld that prevented it from running on GAE. While the basics now work, we still need help finding outstanding conflicts and getting them resolved in a way that does not compromise the compliance with JSR-299 or the integrity of Weld.

Weld SE

One area of Weld that we are particularly proud of, and which truly sets this implementation apart, is the Java SE support. The pioneering work done by Peter Royle and other community members will prove to be instrumental in shaping the future of the CDI specification as it extends outside of Java EE. Weld 1.0.1-CR2 brings improvements to the Java SE support, including documented support for interceptors and decorators and a refactoring to use the standard BeforeShutdown event. The most notable improvement is the simplification of the bootstrap API (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-CR1), which has also undergone a lot of improvements, will be included in this release. We'd like to thank the OpenWebBeans team for making the TCK more robust by identifying and helping to resolve deficiencies-ranging from broken tests to invalid interpretations of the spec.

In fact, we'd like to thank all the Weld community members who continue to find ways to improve the quality of the spec, the TCK and the implementation. Cheers!

Next steps

As mentioned above, the Weld 1.0.1 release is planned for February 19th.

Looking ahead, we plan to get to Weld 1.0.2 in 3 months time, focusing on performance, scalability and bug fixes. Developers eager to start adopting or migrating to Java EE 6 will be particularly excited to hear that we'll finally be shifting part of the team's focus to the development of Seam 3!

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.

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

Dan Allen 2010-02-09T19:21:39Z