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 namedbeta.jar
, but not the other way around - extensions in an archive named
alpha.jar
can observe AnnotatedTypes from an archived namedbravo.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 inseam-faces.jar
, becauseseam-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.
