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.


Back to top