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 ]
...and JBoss Tools 3.1 nightly provides support for CDI/Weld (@Named code completion, openon, find references, refactoring and some validation for certain constructs)
--max
Great news, and great work, guys :-)
<h:link outcome="/addProduct.xhtml value="Add Product">
<f:param name="cid" value="#{conversation.id}"/>
</h:link>
Now that JSF2 has Ajax support could you clarify if conversation propagation happens when f:ajax triggers a post ? I assume one would have to add the conversation id in the ajax post request. Correct me if I am wrong :)
However that can't be done in an elegant way since f:ajax can't support nested f:param.
I discovered this bug in JSF2
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1532
and my suggestion was to add f:param support for f:ajax.
Hence a spec change was proposed for JSF2 with
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=742
This may be important for a full integrated JSF2 & WELD combo .
I am trying to update my JBoss server with the given command: mvn -f jboss-as/pom.xml from the root of Weld 1.0.1-CR2 distribution. When I deploy the numberguess example I got:
ClassNotFoundException: org.jboss.metadata.ejb.jboss.JBossSessionBean31MetaData
Could anyone help me with this problem ?
What version of JBoss AS?
If a conversation is present, then yes, a postback should automatically propagate the conversation, regardless of whether the request is Ajax or not. The whole idea is that the view need not be aware it's participating in a long-running conversation, unless it to a different view. If the conversation doesn't propagate on a postback (Ajax or not), then that is a bug in Weld.
A postback should also propagate any view parameters, again including Ajax requests.
In short, JSF postbacks maintain the state of the view. The conversation and the view parameters are both part of the view's state. If any of the assertions I have made prove to be false, I encourage you to follow up with issue reports.
That being said, having <f:param> on <f:ajax> could still be useful for passing additional parameters, or overriding ones that exist.
Click HELP for text formatting instructions. Then edit this text and check the preview.
I've filed an issue ( WELD-439 ) to create an example that demonstrates conversations and conversation propagation.
Yes, good idea. I'm rewriting the conversation manager against an API proposal currently so I'm going to expand the test suite and examples in this area. Perhaps an ELIZA for schizophrenics ;-)
BTW. I haven't checked but isn't AJAX requests going through the same ViewHandler as a normal JSF requests so the conversation id would be added in the same mechanism?
Hello Pete,
The version I've tried to update is 6.0.0.M1:
1) I run mvn -f jboss-as/pom.xml from the root of Weld 1.0.1-CR2 distribution
2) I deploy numberguess example from CR2 distribution
3) I start the server and I got ClassNotFoundException: org.jboss.metadata.ejb.jboss.JBossSessionBean31MetaData
I don't know is it something that I am missing out or other people have the same problem as well?
If something went wrong with the update can I use jboss-6.0.x.zip built on 12-Feb-2010 15:01:41 available in Hudson. Is this build CR2 ready?
You need to use 6.0.0.M2 (currently only available as a snapshot) as described in the blog post.
Now it works fine. Thanks a lot!
Just as an aside, the weld updater doesn't update the server - just the and ones.
Are there any plans on providing eclipse/netbeans/IDEA plugins. Some features that might be useful (This would provide true since we do not have to wait till deploy/run time to determine errors)
1.
Eg:
public class Hello { .. @Inject @Formal Greeting greeting; ...
}
In the above case, assuming Greeting is an interface, the plugin validator could throw an error if a. there is no implementation OR b. there is more than one implementation of Greeting that matches the type and qualifiers above (i.e of type Greeting annotated with the qualifier: Formal).
2. Also, are there any plans on providing a feature similar to the plugin in eclipse. In the above example, if I moused over to greeting and selected , it should automatically open the class that implements Greeting and is annotated with the Formal qualifier
JBoss Tools nightly builds have had CDI support for a while ;)
We do have some validation now but this one is not there yet - on the roadmap though ;)
Ctrl Click on @Inject or the field name will give you Open Declaration AND Open Injected Class - and Open Injected Class will right now show all possible matches - the thing that we need to do for the validator above. So we are close ;)
--max