Java EE 6 Mess, Continued

Standard

OK, found another brick wall 🙂

So if you recall, I have a Maven 2 build. I now have discreet API jars isolated for JPA 2, Servlet 3, and EJB 3.1. This allows me to build with a single dependency tree for production and still provide a suitable environment for automated testing by providing EclipseLink as a JPA2 implementation under my “test” scope.

My next challenge came when I wanted to use CDI (Contexts and Dependency Injection) to start wiring up components for use in my Facelets templates. If you recall, CDI allows you to do things like name your components and place them into specific scopes (session, request, conversation, application) so that they are lazily instantiated on demand when your web templates need their services. It also provides automatic dependency injection so when your components require other components to work, they can have themselves automatically created and injected by the container.

You’d think that because CDI largely came from Weld that the API jar would be reasonably simple to isolate. Strangely however some of the annotations I need (@Named, actually the whole javax.inject.* namespace) are completely missing from the Weld 1.0.0 and 1.0.0.SP1 distributions, and they’re buried in Glassfish in the weld-osgi-bundle.jar in between all the implementation stuff.

The JSR for CDI points to the Weld 1.0.0 distribution so I’m SNAFU’d there looking for javax.inject.*, and I’ve been unable to find another useable jar out there in the wild that contains this part of the API.

Of course, it’s fully present in the javax / javaee-web-api / 6.0 dependency which completely FAILS when used with EclipseLink JPA 2 implementation, which is why I moved away from it to begin with.

How can you expect anyone to get anything done in an environment like this?

Advertisements

9 thoughts on “Java EE 6 Mess, Continued

    • Respectfully, I don’t think you read my whole post. Those artifacts from java.net were my starting point, and failed me utterly. If however you could point me to a JPA implementation jar that actually functions with those API jars (without the java.lang.ClassFormatError: Absent Code attribute in method that is not native or abstract in class file javax/persistence/Persistence exception I mention in my original post), now that would be truly helpful for me.

  1. Sorry, I should have read your other blog as well before commenting. Yes, those API jars are intentionally kept implementation-less so they can NOT be used at runtime. We expect users to use them for compilation only. User should use classes provided by the implementation. I don’t know why this jar is used by maven during testing in spite of you specifying scope. May be you can turn on verbose flag while running maven and see what classpath is actually used.

  2. Thanks Matt, I’d found the javax.inject dependency just hadn’t blogged yet about it. Follow-up post is coming.

    Thanks Sahoo, I’ll examine the Maven build and test classpaths a little more deeply on my next round.

    If everyone hasn’t already gleaned, my goal here is to provide a lighter-weight testing environment that will fire errors back sooner than booting up a whole container a-la junitee – I realize my focus has remained somewhat narrow (only JPA 2 testing out-of-container) but I still think useful.

    I’m not quite sure even where to start to get dependency-injection functionality bootstrapped in order to test injection order, never mind transactional behaviour. By this point, I may be back to in-container testing.

  3. I’m running into the ClassFormatError too – simply by attempting to use EasyMock to mock out a stupid EntityManager. If they’re going to provide an implementation-less API jar, could they at least provide valid classfiles for the require enums so that working with the interface in any fashion doesn’t hose things? It’s not like the enums are going to vary by provider, I hope!

  4. Apparently the javax/javaee-web-api Maven artifacts aren’t the real deal — they’re ‘stubs’… basically, it means that they’re really great for easily managing your compile and provided dependencies, but not they break entirely when you need to do something like mock them out with Powermock…

    Why that is I’m not particularly clear on, but the fix seems to be in finding an actual implemention… for example, I’ve had this issue with the Servlet API in the past, and the solution was to add the following to my dependency list:

    org.glassfish.grizzly
    grizzly-servlet-webserver
    2.0.0-M2
    jar

    Not a very nice solution, I’ll be the first to admit — frankly, I’d like a better explanation as to why the javax artifacts don’t work for this… in the meantime, you can make it work with something like the above…

    M

  5. One more thing — you may need to list the implementation artifacts before the stubbed artifacts… it appears to add classpath items from top to bottom, so it will run into the worthless stubbed artifacts before the real ones, and still fail… reverse the order in the .pom file, and you’ll be good to go…

    M

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s