Help

Dan Allen is the author of Seam in Action, the comprehensive guide to the Seam framework. After completing his book, Dan now works at JBoss by Red Hat as a Principal Software Engineer to work full-time on on Seam, Weld, and Arquillian. Dan is a passionate open source advocate who enjoys speaking about, hacking on, and discussing Java EE frameworks and technologies.

Location: Laurel, MD
Occupation: Senior Software Engineer
Archive
My Book
Seam in Action
August 2008
Manning Publications
624 pages (English), PDF
03. May 2011, 16:01 CET, by Dan Allen

At the start of the hackfest at JUDCon, I took the stage to recognize (after a long introduction and too much story telling) the following community members as Seam Community Heros (some additions here for those not in attendance). These community members have been instrumental in shaping the Seam 3 project and advancing it to its first release.

  • Jordan Ganoff - First Seam community module lead (JMS); encouraged migration to github; first module to identify significant enhancements needed for CDI in the area of events; smoothly transitioned module to John Ament's lead
  • Brian Leathem - Took over the lead role of the Seam Faces project, gave it direction and has absolutely been a bug crushing and feature crafting machine; also wrote the Seam contributor guide
  • Jason Porter - Designed and leads the Seam Catch module; keeps the Seam community engaged, particularly in IRC, and continuously helps improve it's efficiency; Jason joined Red Hat shortly after the Seam 3 release
  • John Ament - Stepped in as module lead of Seam JMS, taking it from 7 to over 40 classes; he found a way to move past some of roadblocks that were preventing the module from advancing; he also works on Seam JCR
  • Ken Finnigan - Leads the Seam International module; worked with James Perkins and David Lloyd to transition the typed-logger in Solder from slideware to working code; his teamwork was critical in making this feature a success
  • James Perkins - Wrote the annotation processor for JBoss Logging and worked with Ken Finnigan to make its design flexible enough to accommodate the Solder annotations
  • Stuart Douglas - Almost singlehandedly saved the Seam 3 project during its infancy by contributing a stunning amount of code, including Seam Config, significant parts of Seam Solder and Seam Persistence; drastically improved the performance of Weld's extension processing; joined Red Hat at the start of the year to work on AS 7
  • Cody Lerum - Has been plugging away at the Seam Mail module since last summer; was a big fan of the e-mail support in Seam 2 and picked up ownership of the Seam Mail module for Seam 3 pretty much on his own, designed a fluent API set to modernize the mail experience in Java EE

Each person has (or will) receive a t-shirt with the Seam Community Hero graphic on the back and a github octopint. My wife totally surprised me by designing this custom artwork for the t-shirt in your honor. She got the idea after listening to me recount many stories about the work you done. I'd like to thank her for this contribution (and for being awesome). She is certainly an honorary Seam community member.

I'd also like to thank our QA team, namely Jozef Hartinger and Martin Gencer, for doing a fantastic job of identifying and resolving issues for the Seam 3 release and beyond. Of course, we value each and every one of our community contributors and their participation. I look forward to recognizing additional individuals for this award as the project continues. (And my wife just offered to design a new graphic for the next ceremony).

17. Mar 2011, 19:16 CET, by Dan Allen

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.

Are you in Boston? Want to learn more about CDI or just meetup? I'll be in town presenting at the Boston JBUG on Tuesday, March 8th about how CDI makes Java EE gel. Join us!

Java EE 6 offers significant and compelling improvements over previous revisions of the platform. Java EE is now portable and lightweight. But what if these improvements still come up short for your needs? Will you have to wait for Java EE 7 to get the features necessary for you to move forward? How do third-party technologies fit into this picture?

Regardless of how sweeping the change, before long, you'll expect more out of the platform. Java EE 6 makes room for growth.

This talk explores the new programming model that was introduced as the foundation of Java EE 6, Contexts and Dependency Injection (CDI). You discover that with this programming model, it's possible to enhance, extend and customize the platform to suit your needs. You learn how you can achieve loose coupling without sacrificing strong typing and how to create portable extensions that integrate natively with the container by leveraging the extension SPI. In essence, we can backport features of Java EE 7 and beyond, effectively making them available today. You have to look no further than Seam 3.

Sign-up sheet (for pizza) See you at Boston U !

28. Dec 2010, 14:37 CET, by Dan Allen

We're excited to announce that a majority of the Seam3 modules (listed below) have been migrated to Seam Solder!

The Seam elves were busy right up until the eve of Christmas working together to prepare a simultaneous release of 8 modules along with two project POMs to stuff in your stockings. The primary purpose of the release was to align with the recent release of Seam Solder 3.0.0.Beta1, though minor feature requests and bug fixes were squeezed in as well. You'll have to check your stocking to find out surprises await you.

Here's the list of modules that were released, linked to the corresponding module pages (where you can find all the key links):

This is the first time we have attempted a simultaneous module release. This is not the first stack release of Seam, but it's an important step towards that goal. We took this opportunity to touch base with the module leads, clean up and align the module builds and survey what remains to be done. We also gained some key insight into what it's going to take to put a Seam 3 distribution release together.

As soon as we return from the holiday shutdown, we are going to release a few additional modules (JMS, Wicket, Mail), lay out a more clear plan for the project and firm up the target dates for Seam 3.

We are very pleased to see how the whole team has pulled together to get all of the releases done this week. Thanks to everyone involved, including Shane Bryzak, Stuart Douglas, Jason Porter, Jozef Hartinger, Lincoln Baxter, III, Martin Gencur and Pete Muir (for laying a solid foundation for all these POMs).

We also have a new look for module pages, which include a new styling of the Seam logo thanks to James Cobb!

Some pages still need to be converted and the emblems on several of the modules are just an idea at this point.

I don't want to make this a long entry, because I know you probably have relaxation time to get back to. Have a good holidays everyone! Enjoy time with family and friends, but if you need time away, spend some time with JIRA :)

Seam's new project lead, Shane Bryzak, announced last week on the seam-dev mailinglist that the Weld Extensions project has be brought under the Seam project banner and renamed to Seam Solder. Today we are announcing the first release of Seam Solder, 3.0.0.Beta1!

Seam Solder retains exactly the same purpose and goals as its predecessor:

a library of portable CDI utilities for use in developing applications, frameworks and other extensions based on CDI (JSR-299)

In other words, Generally Useful Stuff (tm) that you'd likely end up having to painstakingly create anyway.

Why the change?

Ever since Weld Extensions was first proposed, there's been confusion about how it differs from Weld and how it fits with the Seam project. Now, the distinction is more clear.

  • Weld: implements CDI, brings it to additional environments
  • Seam 3: extends and builds on CDI (plus other goodies)

CDI is the foundation programming model in Seam 3, but there's still room for core extensions and utilities that all Seam modules share to align and avoid code duplication. That's what Seam Solder provides.

What's the name about?

We choose solder because it's the term for an alloy that is used to join metallic parts, but not so strongly as a weld. For instance, fastening modules to a circuitboard. Although CDI extensions don't require Solder, they will greatly benefit from the extra reinforcement it supplies.

It's not just for Seam!

Solder has a life outside of Seam. If you are building on CDI, we strongly encourage you to evaluate Solder before spending time writing your own utilities. Solder will save you tons of time, and you'll get your extension working much sooner. Plus, we believe that we'll be able to implement startup optimizations for CDI in Solder that you'll immediately benefit from.

About the migration

Rather than migrating all the resources for Weld Extensions, we made a clean break (i.e., a fork). We encourage everyone using Weld Extensions to switch to Seam Solder. If you are adding new features or fixing issues, please apply them to Seam Solder unless there is some specific reason you are updating Weld Extensions. Weld Extensions is effectively closed.

Seam Solder has undergone some other changes to be consistent with the other Seam modules:

  • Uses seam-parent for dependency management and common build tasks
  • Source code divided into an API and implementation
  • Bumped major version to 3 (the major version of Weld Extensions was 1)

The switch to Solder has an important implication for the other Seam modules. We need to update each module to use Seam Solder and release a new version of that module. This step should happen quite quickly, since Seam Solder will prevent the application from deploying if Weld Extensions is detected on the classpath.

About the release

All the resources can be found on the Seam Solder project page. For your convenience, I've laid out the key resources here:

As with all Seam 3 artifacts, Solder is published to the JBoss Community repository. If you are using Maven, here's the dependency declaration you need to add to your POM to include the combined API and implementation library in your project:

<dependency>
   <groupId>org.jboss.seam.solder</groupId>
   <artifactId>seam-solder</artifactId>
   <version>3.0.0.Beta1</version>
</dependency>

Alternatively, you can use two dependency declarations so the implementation is only used at runtime:

<dependency>
   <groupId>org.jboss.seam.solder</groupId>
   <artifactId>seam-solder-api</artifactId>
   <version>3.0.0.Beta1</version>
</dependency>

<dependency>
   <groupId>org.jboss.seam.solder</groupId>
   <artifactId>seam-solder-impl</artifactId>
   <version>3.0.0.Beta1</version>
   <scope>runtime</scope>
</dependency>

This project wouldn't have been possible without the hard work of Pete Muir and Stuart Douglas. Additional thanks goes to Shane Bryzak, Nicklas Karlsson, Lincoln Baxter III and Jason Porter for their contributions.

[ Combined JAR ] | [ Distribution ] | [ JIRA ] | [ API docs ] [ Reference Guide ] | [ Release Notes ]

NOTE
It's important to note that we are still having some difficulties getting Solder to work on GlassFish. There appears to be some confusion about how extensions are supposed to be handled in non-bean archives (follow GLASSFISH-14808), a feature that Solder makes use of for performance reasons. We anticipate a resolution for GlassFish 3.1, but not likely GlassFish 3.0.1.

And beyond

For Beta 2, we're planning to tidy up the test suite, compliance, documentation and validation. Then we'll move towards a Final release. That should all happen very soon.

There's still plenty of exciting functionality planned for Seam Solder. If you want to get involved, we encourage you to look through the issue tracker and find something that interests you. If you discover the need for some common functionality when writing your own CDI extensions, consider sharing by adding a feature request (and patch!).

Showing 1 to 5 of 30 blog entries