Red Hat

In Relation To Weld

In Relation To Weld

Fresh blood, voila Weld 1.1.6.Final

Posted by    |       |    Tagged as Weld

I'm happy to announce a new Weld 1.1.6.Final release. It's probably the biggest bug squashing fest since I took over the project.

Big thanks to Marko for stepping up and doing most of the work.

Here is the impressive list of handled issues:

[WELD-580] - Around-Invoke Interceptors with wrong signature should cause DefinitionException
[WELD-627] - Clarify the implementation and usage of WeldClass.getWeldMethods, WelldClass.getDeclaredWeldMethods
[WELD-665] - Servlet injection not working on EAP 5.1
[WELD-680] - Weld tests fail on IBM JDK
[WELD-687] - Refactoring InstantiatorFactory to allow per-deployment configuration
[WELD-820] - When invoking a method that is not intercepted, invocations on this are intercepted/decorated
[WELD-853] - @AroundInvoke annotations added by SPI are ignored
[WELD-909] - Dual faces mapping and cid parameter for conversational redirect
[WELD-910] - Wrong example code - refering non-existent Weld#shutdown()
[WELD-911] - Shared dependent instance injection with circular reference through decorator
[WELD-926] - Weld Servlet still uses old Google Collections instead of Guava
[WELD-930] - Producer is made an alternative if the declaring bean class is an alternative
[WELD-937] - Documentation issue - Instantiating abstract class
[WELD-954] - URIs escaped twice in URLScanner
[WELD-967] - @ThreadScope documentation bug
[WELD-977] - Specialized bean does not disable producer method of its parent
[WELD-986] - Interceptors and decorators may not declare observer methods
[WELD-989] - #{conversation.id} instead of #{javax.enterprise.context.conversation.id} mentioned in the reference guide
[WELD-997] - Custom implementation of Interceptor never invoked
[WELD-999] - Interceptor binding transitivity broken
[WELD-1007] - Weld SE startup fails.
[WELD-1016] - Weld creates multiple interceptor instances per target instance
[WELD-1024] - Missing check that specializing bean has all the bean types of specialized bean
[WELD-1026] - @New session beans created eagerly
[WELD-1028] - CLONE - URLScanner can not handle paths containing spaces
[WELD-1036] - ArrayIndexOutOfBoundsException destroying Stateful SessionBean
[WELD-1044] - ConversationPropagationFilter active for non-JSF requests
[WELD-1048] - Decorated dependent bean not passivation capable
[WELD-1056] - Weld-servlet brings transitive dependency on weld-build-config
[WELD-1062] - Superclass of a modified AnnotatedType is ignored
[WELD-1067] - Thread safety issue in BeansClosure
[WELD-1068] - Weld conversation crash when used in portlet
[WELD-1075] - Ambiguous dependencies when only one correct dependency exists
[WELD-1077] - java.lang.VerifyError when applying an interceptor on a method in a class with final equals
[WELD-1083] - Weld only detects conflicting interceptor bindings on classes, but not on methods
[WELD-1091] - Test failures on JDK7

[WELD-1055] - Exception when deploying EJB with duplicated Interceptors-annontation is not informative enough

[WELD-731] - Bind BeanManager to JNDI when naming context is read/write (as in JBoss AS/EAP 5)
[WELD-894] - Around-Invoke interceptors should not wrap RuntimeException into WeldException
[WELD-1000] - Pass extension instances to bootstrap
[WELD-1043] - Convert Weld example ftests to Ajocado

[WELD-27] - Consider using JBoss maven plugin, not ant for example builds
[WELD-398] - Unable to run translator example with settings for cluster
[WELD-494] - Add Arquillian test to the dist examples
[WELD-655] - maven-jetty-plugin not configured correctly
[WELD-1005] - Upgrade surefire plugin to 2.10
[WELD-1064] - Upgrade dependency jboss-interceptors-api from 1.0.0.Beta1 to 1.0.0.Final
[WELD-1084] - Introduce class InterceptorBindingType
[WELD-1092] - Configure m2e to ignore Checkstyle Plugin

This is (probably) the last 1.1.x release, as it's high time to finally get Mathieu's OSGi integration in (which requires API changes, hence bumping the minor version).

Give it a spin. Feedback welcome as always.

Weld 2.0.0.Alpha1 released!

Posted by    |       |    Tagged as Weld

I am very proud to announce the very first alpha release of Weld 2. Weld is the reference implementation of Contexts and Dependency Injection for Java EE (CDI). In the 2.x series of Weld releases, we will be focusing on JSR-346 which is the next version (1.1) of the CDI specification.

The Alpha1 release is a feature-complete implementation of the Early Draft of CDI 1.1. Pete blogged about the news in the early draft some time ago. The following list just highlights some of the new features I consider the most important:

The main reason for building a reference implementation is to prove a specification and reveal potential problem early. While implementing the Early Draft of JSR-346, several issues emerged that were previously unseen. If you are interested in these issues or have an idea of how to address them, feel free to share you opinions in the issue comments or the JSR-346 mailing list. Also, if you want to contribute to Weld 2, now is the right time. Since we are hosted on github forking and playing with Weld is extremely easy.

In addition to our efforts on the Weld side, Martin Kouba has been working on the Technology Compatibility Kit (TCK) for JSR-346. The Alpha1 version of the CDI 1.1 TCK is released along with the Weld release. Martin did a great job and delivered a solid test coverage of the new features. He also migrated the entire testsuite to Arquillian, which enabled us to develop new tests faster while at the same time using more extensive scenarios (such as multiple web applications inside of an enterprise archive).

Weld and CDI TCK artifacts can be obtained from Maven or from a distribution bundle (see the links below). We tried our best to make it easy for you to test-drive the new features. Therefore, we also provide a special build of JBoss AS 7.1.0.CR1 enhanced with Weld 2 :-)

For the next release (Alpha 2), our plan is to look into improving non-functional characteristics of Weld such as memory footprint and start-up time.

[ Distribution (Weld, CDI TCK) ] [ JBoss AS 7.1.0.CR1b with Weld 2.0.0.Alpha1 ] [ Issue tracker (Weld, CDI TCK) ] [ CDI 1.1 EDR1 Javadoc ]

Minor bug release fix - Weld 1.1.5.Final

Posted by    |       |    Tagged as Weld

I've just release a new Weld 1.1.5.Final.

It doesn't have many fixes, but a super pesky one with protection domains, which bugged us a lot for our EAP6 testing.

While I also finally managed to upgrade SLF4J:

Now let me finally get Mathieu's OSGi integration into upstream ...

A new @Special(izes) Weld 1.1.4.Final release

Posted by    |       |    Tagged as Weld

I'm happy to say we finally fixed the pesky @Specializes bug

  • WELD-912 - Specializing beans in different bean archives does not work

And some other issues also proved to be far more interesting from what one would expect while reading the initial problem.

  • WELD-617 - Can not find beans when deploying compressed Archive to Tomcat
  • WELD-802 - Specialization of Beans registered through portable extension does not work.
  • WELD-892 - Calling session-scoped components from session initialized observer goes into infinite loop
  • WELD-904 - Observer method inheritance broken
  • WELD-1010 - @PreDestroy method invoked twice

Full release notes can be found here: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310891&version=12318550

I've already uploaded the .zip to Sourceforge and of course pushed artifacts into our JBoss Maven repo.

And a little bird told me this version is gonna be used in the upcoming JBossAS7.1.0.Beta1 release. ;-)

SP1 for Weld 1.1.3.Final

Posted by    |       |    Tagged as Weld

With Maven Surefire playing tricks on us, we unfortunately missed a few regressions with the latest 1.1.3.Final release.

Luckily Jozef spotted this early enough (too bad it wasn't before we actually did the release ;-), hopefully before you guys became grey of worry. :-)

So, the new Weld 1.1.3.SP1 is already in our JBoss Maven repo and on SourceForge as .zip.

Weld 1.1.3.Final is out!

Posted by    |       |    Tagged as Weld

I'm happy to announce new Weld 1.1.3.Final release.

With this release we finally moved Weld Core Arquillian tests by default to JBoss AS7, making the build easier and faster -- thanks Stuart.

But this of course doesn't mean we forgot about other containers;

  • it's still fully tested against latest GlassFish (thanks GF guys!),
  • added new web container tests (Tomcat 7; thanks Matija) and
  • reduced Jetty config a bit (thanks Geoffrey).

Other interesting issues or features include:

  • better conversation handling - thanks Lincoln and George; btw, LB3 I expect more patches from now on ;-)

Weld' github master will now be the basis of future 1.2 releases, moving current to branch 1.1.

(since there already is an abandoned 1.1 branch, we'll first move that one to 1.1-legacy)


I also have a few exciting announcements - in case you missed them:


Onward to Weld 1.2 and 2.0!!

p.s.: let us know if there are any new issues with the latest release ;-)

Weld 1.1.2.Final released!

Posted by    |       |    Tagged as Weld

I'm happy to say we (finally) released Weld 1.1.2.Final.

It includes a bunch of implemented tasks and fixed issues:

Big thanks to Stuart for stepping up and fixing some pesky bugs and providing cool thread local performance boost.

We'll make sure this version is included in our super cool JBossAS7, as well as upcoming JBossAS6.1 and latest GlassFish.

Please give it a spin and let us know. The same means as usual: forum, JIRA, github + pull-requests.

Weld 1.1.1.Final

Posted by    |       |    Tagged as Weld

I'm glad to announce we've finally released Weld 1.1.1.Final.

The release includes a couple of nasty bug fixes, which specially gave Seam3 and GlassFish users a lot of trouble:

Another performance improvement:

And re-factored web containers integration, which now includes Jetty7+ support:

The non-maven distribution can be found at SF.net:

Thanks to everyone involved -- Stuart, Pete, Martin, Nicklas, ... Seam3 guys, ... to name a few. :-)

Is Seam 3 going to be portable or what?

Posted by    |       |    Tagged as Seam Weld

The short answer is: Yes.

In this entry, I'll clarify our portability goal, then address the problems many you have encountered using Seam 3 on GlassFish (and JBoss AS). Hopefully I'll manage to your frustrations with confidence :)

Portability is a goal

Seam 3 is not just for JBoss AS. One of our main goals for Seam 3 is to deliver on the portability contract that CDI espouses, while at the same time providing strong integration with the container (CDI, Java EE, etc). It's a portable extension library built on top of CDI. Therefore, you should expect to be able to use it with any compliant CDI runtime.

We remain committed to this goal because it gives you, the developer, choice. That's something we strongly believe in. There are other benefits as well. It allows Seam to reach a wider community of developers and it challenges us to make Seam more robust.

Obviously, some modules will intentionally offer non-portable behavior. Those features are there for when your requirements call for them and will be appropriately called out in the documentation. In general, though, we want you to feel free to use Seam in whatever CDI environment that works best for you.

With that goal, there's no doubt we've set a high bar for this project. It won't always come easy, especially in the beginning. There have been some bumps along the way. We've also made some mistakes. Both are to be expected for an emerging technology. We are tracking down and squashing the bugs. And any limitations we've hit are already being addressed in CDI 1.1.

What's the issue?

Several of the modules in the Seam 3.0.0 candidate releases have been causing deployment errors in GlassFish 3.1 (and even JBoss AS). We are working on the problems, some of which originate in the CDI implementation or application server. We don't want to throw around blame, we want to resolve the issues.

CDI is one of the most well-defined specifications in the Java EE platform and has an extensive test suite, leaving virtually no room for implementations to step out of line. Yet, inconsistencies still slip through. As we work on Seam 3, and push the limits of what we can do with CDI, we bring these inconsistencies to the surface.

Fortunately, you just heard from Pete that we've already submitted the JSR proposal for CDI 1.1, which will focus on a small number of much requested features, along with bug fixes and clarifications. In the short term, the fastest, most productive way to get these problems resolved is to help each other understand the correct behavior and make sure all the implementations support it properly. The mess only appears when we start pointing fingers.

Regardless of where the problems occur, we help get them resolved as quickly as possible, primarily by writing compatibility tests (found in the Solder module) using Arquillian that communicate the expected behavior. We then use these tests as the basis for assumptions that support or supplement rules defined in the CDI specification. We also continue beef up our test suite and leverage Arquillian to run it against additional containers.

As time goes by, portability will not just be a goal, but something you can count on.

Paving the way to portability

Part of making Seam 3 portable involves making sure that the application servers are playing by the same rules. They haven't been in all cases. (Recently we've been struggling with some issues in GlassFish 3.1). These problems, which I describe below, have meant deployment errors in Seam 3. We haven't been ignoring the issues. We've be actively working to pave out those rough spots, which is good for both Seam 3 and Java EE in general.

I'll try to clearly explain the issues you likely encountered getting Seam to run on either GlassFish or JBoss AS and what we've done (or are still in the process of doing) to solve them before the final release. I'm sharing this information with you to keep you in the loop. At this point, we've worked through or around most of them.

There are plans for a Weld 1.1.1 release, which specifically fixes these problems at the source. Brian Leathem has provided instructions for updating Weld in GlassFish 3.1 when it comes time.

Alpha-bravo library visibility

Affects: GlassFish 3.1 (fixed in Weld 1.1.1-SNAPSHOT)
Issue report: GLASSFISH-15735
Test case: JarToJarReverseAlphaVisibilityTest

Explanation:

  • in certain cases, types (classes) in one bean archive (jar) aren't visible to beans and extensions in another jar in a web module
  • visibility is dependent on the alphabetic order of the archive names
  • an archive named alpha.jar can see types in an archive named beta.jar, but not the other way around
  • extensions in an archive named alpha.jar can observe AnnotatedTypes from an archived named bravo.jar, but not the other way around

Consequence:

  • typed loggers and message bundles weren't being processed by Solder for any library (e.g., seam-servlet.jar) with a name that comes before seam-solder.jar in alphabetical order
  • the built-in Messages bean from seam-international.jar cannot be injected into bean in seam-faces.jar, because seam-faces.jar comes first in alphabetical order

Resolution:

  • went through modules and found a way to work around this issue on a case-by-case basis
  • worse case scenario, you can combine all the Seam bits into a single JAR

Library-to-application visibililty

Affects: GlassFish 3.1 (unresolved)
Issue report: GLASSFISH-15721
Test case: VisibilityOfBeanInWebModuleFromBeanManagerInBeanLibraryTest

Explanation:

  • beans in WEB-INF/classes are not visibile to a BeanManager in a bean archive (jar) in the same web module

Consequence:

  • several Solder features aren't available on GlassFish (EL evaluator, default beans, generic beans, unwraps, service handler)

Resolution:

  • we've ensured Solder doesn't cause deployment issues
  • we need this issue to be resolved to unlock all Solder features

Missing typed logger and message bundle implementation classes

Affects: Seam <= 3.0.0.CR2 (fixed in Seam 3.0.0.CR3)
Issue report: SEAMSERVLET-30, SOLDER-62

Explanation:

  • currently two modules (Seam Solder and Servlet) use the typed logger and message bundle feature provided by Solder
  • the implementation class must be generated, either by a proxy or by an annotation processor
  • generation of proxies requires a system property to be set (jboss.i18n.generate-proxies)
  • the annotation processor wasn't finished prior to Seam 3.0.0.CR2

Consequence:

  • you were getting unsatisfied dependency errors with ServletLog and/or AnnotatedMessages at deployment

Resolution:

  • the annotation processor is available and we are now generating the concrete implementation classes (thanks to James and Ken)
  • we've added documentation to Seam Solder to educate you how to use this feature, and the options you have

Dangling web fragment reference

Affects: Seam <= 3.0.0.CR2 on GlassFish and Tomcat (fixed in Seam 3.0.0.CR3)
Issue report: SEAMSERVLET-29, GLASSFISH-16201

Explanation:

  • Seam Servlet had a web-fragment.xml with an ordering clause that referenced a web fragment named WeldServlet
  • the motivation was to ensure the the Weld bootstraps before Seam Servlet listeners are invoked

Consequence:

  • there were deployment problem on GlassFish and Tomcat 7

Resolution:

  • it turns out we don't need the reference anyway since Weld Servlet does not yet use a web fragment (premature optimization)
  • the reference has been removed for now

Intermittent interceptors

Affects: GlassFish 3.1 (unresolved)

Explanation:

  • interceptors listed in beans.xml don't always get enabled (seemly random per deployment)

Consequence:

  • in the Seam booking example, the conversation for booking does not activate if the interceptor for @Begin/@End does not activate

Resolution:

  • at the moment, the only resolution is to redeploy the application

Overzealous class scanner

Affects: GlassFish 3.0.1 (fixed in GlassFish 3.1)

Explanation:

  • the class scanner fails whenever it finds a class with a field that references a class not on the classpath; happens before class is even considered as a bean

Consequence:

  • can't have optional beans that are enabled based on what's available
  • Seam Faces breaks because it has optional dependency on Seam Persistence
  • Seam Solder breaks because it has optional dependency on logging providers
  • Seam Persistence breaks has optional dependency on Hibernate

Resolution:

  • you need to add a whole slew of needless dependencies to satisfy these class not found exceptions
  • we strongly recommend upgrading to GlassFish 3.1

Upwards

You'll be glad to know that after much deliberation, we've decided to do a CR3 and postpone the final release for one more week. Please use this opportunity to verify that the issues you've encountered are resolved so that we can deliver a quality result in Seam 3.0.0.Final.

It's been a long road to get to this point, and we really appreciate the efforts made by the whole team. I'd like to especially thank James Perkins and Ken Finnigan for there work getting the annotation process for typed loggers and message bundles designed and working. I also want to thank Jason Porter for implementing the the Arquillian GlassFish 3.1 container adapter that enabled us to run the compatibility tests on GlassFish 3.1.

This is really a community project in every sense, and we're so proud to have been a part of this great group of passionate developers.

Seam 3.0.0.Final isn't the end, it's just a stepping stone. Participation in Seam 3 is growing rapidly. Existing modules are already looking ahead to 3.1 and new modules are already scheduled. We are also getting the migration guide underway. I encourage you to join us to help make Seam 3 an awesome extension stack for enterprise Java developers.

UPDATE

I just built the latest Weld and replaced the OSGI bundle in GlassFish 3.1 and there are only two failing tests in the Solder test suite:

That means nearly all Solder features are available. Almost there.

UPDATE 2

Snapshots of the Weld OSGi bundle are now available in the JBoss Snapshot repository.

Weld 1.1.0.Final available!

Posted by    |       |    Tagged as Seam Weld

I've just published Weld 1.1.0, the reference implementation of JSR-299: Contexts and Dependency Injection for Java EE. It's based on the CDI 1.0 API. You can find direct download links at the bottom of this post or you can pull the artifacts from the JBoss Maven Repository.

This release contains all the new developments from the last six months, the highlights of which are:

  • Big improvements in memory usage, boot time and runtime performance. Our measurements showed a two fold improvement in boot time with just a few beans in the deployment, but with many beans, we were showing more than a 10 fold improvement. Memory usage showed a consistent 4 fold improvement, regardless of the number of beans deployed. We showed a 40% improvement in runtime performance, and also measured that Weld performs as well as, or better than other CDI implementations available, as well as other projects in the DI space.
  • Ability to exclude classes from scanning and deployment as beans by Weld. You can configure this in beans.xml for the bean archive you are deploying:
<beans xmlns="http://java.sun.com/xml/ns/javaee" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
        xmlns:weld="http://jboss.org/schema/weld/beans" 
        xsi:schemaLocation="
           http://java.sun.com/xml/ns/javaee http://jboss.org/schema/cdi/beans_1_0.xsd
           http://jboss.org/schema/weld/beans http://jboss.org/schema/weld/beans_1_1.xsd">
    
    <weld:scan>
        <!-- Don't include GWT support if GWT is not installed -->
        <weld:exclude name="com.acme.gwt.**">
            <weld:if-class-available name="!com.google.GWT"/>
        </weld:exclude>
    </weld:scan>

</beans>
  • The new Pastecode example, which shows off many of the new EJB 3.1 features in use with Weld
  • around 140 bug fixes
  • A new approach to managing contexts, making it easier to write view-layer integrations

We also just released 1.0.4 of the CDI TCK - you can find the links for it below :-)

Thanks go to Marius Bogoevici, Stuart Douglas, Martin Gencur, Nicklas Karlsson, Stale Pedersen, Ales Justin, David Allen, Sivakumar Thyagarajan and Jason Porter for their hard work on this release!

This also marks the last Weld release that I will be running the project for. I just want to take this opportunity to thank the Weld community for all their help over the last 2 years. Weld has an amazing community, full of very talented people, who want to get things right regardless personality and politics.

JBoss AS

Weld 1.1.0.CR2 is included in JBoss AS 6.0.0.Final, and Weld 1.1.0.Final will be included in JBoss AS 6.0.1 (it's being integrated as we speak). Weld 1.1.0.Final is also included in GlassFish V3.1

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. Alternatively, you can use Weld with Java SE.

There is great testing support via Arquillian, which allows you to test in Weld SE, a mocked out Java EE container, Tomcat or Jetty, as well as JBoss AS and GlassFish.

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, CDI TCK) ] | [ Reference Guide (Weld, CDI TCK ] | [ Issue Tracker (Weld, CDI TCK) ] | [ CDI Javadoc ]

back to top