Red Hat



In Relation To Dan Allen

In Relation To Dan Allen

Seam Community Heros announced at JUDCon

Posted by Dan Allen    |       |    Tagged as Seam

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).

Is Seam 3 going to be portable or what?

Posted by Dan Allen    |       |    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.

Gel with CDI and Java EE at the Boston JBUG

Posted by Dan Allen    |       |    Tagged as CDI Events

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 !

Seam 3 Modules "Stocking Stuffer" Release

Posted by Dan Allen    |       |    Tagged as Seam

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 :)

Weld Extensions becomes Seam Solder; 3.0.0.Beta1 now available!

Posted by Dan Allen    |       |    Tagged as Seam Weld

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!).

Infinispan and Seam are doing it again. We're hosting a community social in the midst of Europe's premier Java conference, Devoxx (in Antwerp, Belgium). This year we'll be joined by Arquillian to keep things under control (you don't want to make Ike mad).

If you plan to be at Devoxx - or just happen to be nearby - and fancy an evening of in-depth conversation about three JBoss open source projects set to rock the enterprise, come on by and partake in some of the finest beer in the world with the project core developers. Demos, design discussions, architectural questions are all fair game. Join our pilgrimage to Kulminator at 20:00 on Monday the 15th of November (near the Groenplaats Station).

Seam, Infinispan and Arquillian Social
Date: Monday, November 15 @ 20:00
Destination: Kulminator

They say open source is free as in speech. Well, our open source social is free as in beer. Yep, we're sponsoring beer! And free swag too (the early bird gets the swag).

Getting back to business, we've got your Devoxx JBoss planner if you want to learn more about the exciting stuff going on in the JBoss Community.

Title Time Location Speaker(s)
Seam 3: State of the Union Mon, Nov 15 @ 09:00 Room 8 Pete Muir, Dan Allen
Java enterprise testing made easy with Arquillian Mon, Nov 15 @ 13:30 BOF 1 Aslak Knutsen, Dan Allen, Pete Muir
Beautiful Java EE: URL-rewriting for the next generation web-user Mon, Nov 15 @ 16:45 Room 5 Lincoln Baxter, III
Seam Gathering Mon, Nov 15 @ 19:00 BOF 2 Pete Muir, Dan Allen, Lincoln Baxter III
Seam in Action - Book signing Tues, Nov 16 @ 12:30 Bookstore Dan Allen
JBoss Tools, the Deployment Ninja! Tues, Nov 16 @ 13:00 Room 4 Max Andersen
What's new in Hibernate: A JPA 2 perspective Tues, Nov 16 @ 13:30 Room 8 Emmanuel Bernard
Hacking Infinispan: the new open source data grid meets NoSQL Wed, Nov 17 @ 14:00 Room 9 Manik Surtani
The roots of Java EE 6: JSR-299 (CDI) and Weld extensions Fri, Nov 19 @ 11:50 Room 8 Dan Allen

We also strongly recommend that you attend the Java EE 6 Tutorial. Reloaded! by Antonio Goncalves and Alexis Moussine-Pouchkine to soak up essential foundation knowledge of Java EE 6, in particular CDI.

In addition to my Devoxx talks, I'll be flying ✈ Munich on Wednesday (if you can believe it) to present on Seam 3 Faces and PrettyFaces at W-JAX. I'll be back at Devoxx on Thursday.

If you want to know where else we might turn up at Devoxx, or want to know how else to spend your off hours, check out the eating and drinking in Antwerp guide that our community member Peter Hilton put together.

Hope to see you there! If you are stuck at home this time around, fork a Seam 3 module on github and start hacking away!

Adam Bien: Java Developer of the Year (2010)

Posted by Dan Allen    |       |    Tagged as CDI Java EE

I'd like extend my congratulations to fellow Java EE community member and blogger Adam Bien for being awarded Java Developer of the Year for 2010 by the editors of Oracle Magazine (image from November/December 2010 issue right). This is one award announced by Oracle this year that I can totally get behind and say is truly deserved.

If you speak with Adam even for any length of time, you immediately recognize that he strikes an ideal balance between being practical and flexible. He's quoted in the announcement as stating:

You have to be open to changes and suggestions

Java EE 6 brought a lot of changes in the platform, including JSR-299, and it's great to see Adam embrace the changes, apply them in practice and communicate (and challenge) the benefits through blog entries, books, articles, podcast interviews, presentations and status updates. The message he consistently delivers is:

Most developers are stunned to discover that Java EE 6 became even lighter than POJOs.

Can you ask for a more well-rounded champion for the platform? The best part is, I know Adam bases his support on technical merit and utility. To me, that's what makes his message carry so much weight.

Bien works with many companies as a Java architecture consultant for enterprise applications, helping organizations design and implement high-performance Java solutions and troubleshooting mission-critical problems. He's also the author of eight books and more than 100 articles on Java, architectures, and best practices.

So he works and gives back to the community. Hero.

Keep up the great work Adam and all Java EE rock stars who contribute practical experience to the community! You keep us away from Ivory Towers.

A more concise way to generate the JPA 2 metamodel in Maven

Posted by Dan Allen    |       |    Tagged as Discussions JPA

The JPA 2 metamodel is the cornerstone of type-safe criteria queries in JPA 2. The generated classes allow you to refer to entity properties using static field references, instead of strings. (A metamodel class is the fully-qualified class name of the entity class it matches followed by an underscore (_)).

It sounds promising, but many people using Maven are getting tripped up trying to get the metamodel generated and compiled. The Hibernate JPA 2 Metamodel Generator guide offers a couple of solutions. I've figured out another, which seems more elegant.

Just to refresh your memory of the problem:

  1. Maven compiles the classes during the compile phase
  2. The Java 6 compiler allows annotation processors to hook into it
  3. Annotation processors are permitted to generate Java source files (which is the case with the JPA 2 metamodel)
  4. Maven does not execute a secondary compile step to compile Java source files generated by the annotation processor

I figured out that it's possible to use the Maven compiler plugin to run only the annotation processors during the generate-sources phase! This effectively becomes a code generation step. Then comes the only downside. If you can believe it, Maven does not have a built-in way to compile generated sources. So we have to add one more plugin (build-helper-maven-plugin) that simply adds an additional source folder (I really can't believe the compiler plugin doesn't offer this feature). During the compile phase, we can disable the annotation processors to speed up compilation and avoid generating the metamodel a second time.

Here's the configuration for your copy-paste pleasure. Add it to the <plugins> section of your POM.

<!-- Compiler plugin enforces Java 1.6 compatibility and controls execution of annotation processors -->
<plugin>
   <artifactId>maven-compiler-plugin</artifactId>
   <version>2.3.1</version>
   <configuration>
      <source>1.6</source>
      <target>1.6</target>
      <compilerArgument>-proc:none</compilerArgument>
   </configuration>
   <executions>
      <execution>
         <id>run-annotation-processors-only</id>
         <phase>generate-sources</phase>
         <configuration>
            <compilerArgument>-proc:only</compilerArgument>
            <!-- If your app has multiple packages, use this include filter to
                 execute the processor only on the package containing your entities -->
            <!--
            <includes>
               <include>**/model/*.java</include>
            </includes>
            -->
         </configuration>
         <goals>
            <goal>compile</goal>
         </goals>
      </execution>
   </executions>  
</plugin>         
<!-- Build helper plugin adds the sources generated by the JPA 2 annotation processor to the compile path -->
<plugin>
   <groupId>org.codehaus.mojo</groupId>
   <artifactId>build-helper-maven-plugin</artifactId>
   <version>1.5</version>
   <executions>      
      <execution> 
         <phase>process-sources</phase>
         <configuration>
            <sources>
               <source>${project.build.directory}/generated-sources/annotations</source>
            </sources>
         </configuration>
         <goals>
            <goal>add-source</goal>
         </goals>
      </execution>
   </executions>
</plugin>

The metamodel source files get generated into the target/generated-sources/annotations directory.

Note that if you have references to the metamodel across Java packages, you'll need to filter the annotation processor to only run on the package containing the entity classes.

We'll be protoyping this approach in the 1.0.1.Beta1 release of the Weld archetypes, which should be out soon.

Bonus material: Eclipse configuration

While I'm at it, I might as well show you how I enabled the JPA 2 metamodel generation in Eclipse. (Max may correct me. He's the authority on Eclipse tooling, so listen to what he says).

Start by adding the following dependency to your POM:

<dependency>
   <groupId>org.hibernate</groupId>
   <artifactId>hibernate-jpamodelgen</artifactId>
   <version>1.0.0.Final</version>
   <scope>provided</scope>
</dependency>

Then, populate the .factorypath file at the root of your project with the following contents:

<factorypath>
    <factorypathentry kind="PLUGIN" id="org.eclipse.jst.ws.annotations.core" enabled="true" runInBatchMode="false"/>
    <factorypathentry kind="VARJAR" id="M2_REPO/org/hibernate/hibernate-jpamodelgen/1.0.0.Final/hibernate-jpamodelgen-1.0.0.Final.jar" enabled="true" runInBatchMode="false"/>
    <factorypathentry kind="VARJAR" id="M2_REPO/org/hibernate/javax/persistence/hibernate-jpa-2.0-api/1.0.0.Final/hibernate-jpa-2.0-api-1.0.0.Final.jar" enabled="true" runInBatchMode="false"/>
</factorypath>

Refresh the project in Eclipse. Now right click on the project and select:

Properties > Java Compiler > Annotation Processing

Enable project specific settings and enable annotation processing. Press OK and OK again when prompted to build the project. Now, Eclipse should also generate your JPA 2 metamodel.

Happy type-safe criteria querying!

Help us select an Arquillian logo

Posted by Dan Allen    |       |    Tagged as Arquillian

Cool software projects have cool logos. We recently announced an alpha release of Arquillian, a project that's going to revolutionize Java EE integration testing. Now we need to make Arquillian cool :)

We are in the process of establishing Arquillian's visual identity, its logo. We've already been through a couple rounds of grayscale design comps with Cheyenne from the JBoss Community design team, who is designing the Arquillian logo. Throughout the process, we've asked community members to provide feedback on the comps to help steer the design process. You can follow some of the progress in this thread or the #arquillian Twitter hashtag. We're casting a wider net this time by asking readers of this blog to chime in.

The themes we are pursuing are:

  • aliens
  • remote control
  • in container

Here are the round 3 logo candidates:

r3v1
r3v2
r3v3
r3v4
r3v5
r3v6

Follow the link to the poll below to let us know which ones you like best and why.

Arquillian logo poll (Round 3)

Once we collect enough feedback, we'll send it over to Cheyenne and let you know which ones made the cut. Thanks for participating!

Seam XML 3.0.0 Alpha 1 brings XML-based configuration to fruition

Posted by Dan Allen    |       |    Tagged as CDI Seam

As promised, we're happy to announce another early release of a Seam 3 module, Seam XML 3.0.0 Alpha 1. The Seam XML module, contributed and led by Stuart Douglas, is a CDI portable extension that allows you to add, modify and extend CDI-discovered beans using XML as an alternative to annotations.

But not just any XML. It's a typesafe XML format heavily based on an early revision of the JSR-299 (then Web Beans) specification.

Try it on for size

Let's assume you have defined the following ProducerBean class:

package org.jboss.seam.xml.test.injection;

public class ProducerBean {
   private String message = "Hello, annotation fans!";
}

and the following qualifier annotation:

package org.jboss.seam.xml.test.injection;

@Qualifier
@Retention(RUNTIME)
@Target({TYPE, METHOD, FIELD, PARAMETER})
public @interface ProducerQualifer {}

You want to expose the message field of ProducerBean using a CDI producer. You could take an annotation approach:

package org.jboss.seam.xml.test.injection;

public class ProducerBean {
   @Produces
   @ProducerQualifier
   private String message = "Hello, annotation fans!";
}

But what if the class isn't under your control, or you are more of a fan of XML tag soup? You can apply the same bean metadata using XML:

<test:ProducerBean>
   <test:message>
      <s:Produces/>
      <test:ProducerQualifier/>
      <s:value>Hello, XML fans!</s:value>
   </test:message>
</test:ProducerBean>

That snippet may take a while for your mind to parse, but observe closely how the XML tags map to the annotated version of the ProducerBean class. Notice we've also overridden the value of the message field in XML to say Hello, XML fans! rather than Hello, annotation fans! Assigning field values in XML is a very useful feature which cannot (easily) be addressed with annotations alone.

What's with all the namespace prefixes? The namespace prefix s is for the Seam XML schema and test represents the Java package of the bean class being configured. Here's the complete configuration file with the XML root and namespace declarations included. Also notice that an additional bean is being configured, ReceiverBean, this one through metadata extension.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://java.sun.com/xml/ns/javaee"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:s="urn:java:seam:core"
   xmlns:test="urn:java:org.jboss.seam.xml.test.injection">

   <test:ProducerBean>
      <s:override/>
      <test:message>
         <s:Produces/>
         <test:ProducerQualifier/>
         <s:value>Hello, XML fans!</s:value>
      </test:message>
   </test:ProducerBean>

   <test:RecieverBean>
      <s:extends/>
      <test:anotherField>
         <test:ProducerQualifier/>
         <s:Inject/>
      </test:anotherField>
   </test:RecieverBean>

</beans>

To give you the complete picture, this example wires up two beans, a bean with a producer field that produces Hello, XML fans! and a bean that injects the produced value. The ProducerBean overrides the existing bean, while RecieverBean extends the existing bean, so annotations physically present on the class will be merged with those defined in the XML file. For more information please consult the docs and exmaple that are bundled with the distribution.

Rev up your XML editor!

Now that you've seen a glimpse of what this module offers, it's time to go get it. Here are the links you need to get started.

As with all Seam 3 modules releases, the Seam XML module is published to the central Maven 2 repository. Here's the dependency declaration you need to add to your POM to include this module in your project (note the hyphen in the version):

<dependency>
   <groupId>org.jboss.seam.xml</groupId>
   <artifactId>seam-xml-core</artifactId>
   <version>3.0.0-Alpha1</version>
</dependency>

As this is an early release, there is no guarentee that the syntax is set in stone. It all depends on your feedback, which we are very interested in receiving!

Please join us!

We are hoping that all JSR-299 implementations can join us in our effort to get XML configuration into the next version of the spec. You can help by adopting this XML schema and helping us to define, refine and improve on it.

A tremendous thanks to Stuart Douglas for putting this module together. The XML configuration lays a key foundation for the entire Seam 3 project! Also thanks to Shane Bryzak for preparing the release.

Stay tuned for alpha releases of additional Seam modules in the near future, such as Seam International (i18n), which will give you enhanced language support for Java EE 6 applications, and Seam Faces, an appetizing collection of extensions and enhancements for JSF 2. Keep in mind that everything is on the drafting table right now. Join us!

back to top