2 Replies Latest reply on Jun 27, 2011 9:48 AM by Ryan J

    @Resource, container bootstrapping and java.endorsed.dirs.

    Ryan J Newbie

      When using the @Resource annotation there is a difference between the library distributed with Java SE and the library included in the endorsed .jars for Java EE 6.  Java EE 6 has a newer version and supports the 'lookup' attribute.

       

      Does anyone have any advice on how to deal with the version conflict that can occur depending on how the container is bootstrapped?

       

      I'm using Glassfish Embedded 3.1 and Arquillian Alpha5.  How does Arquillian handle java.endorsed.dirs when bootstrapping the embedded container?  I have a couple related questions on StackOverflow:

       

      http://stackoverflow.com/questions/6422577/trouble-injecting-resources-with-java-ee-6-and-glassfish-3-1-using-resource

      http://stackoverflow.com/questions/6439368/any-best-practices-for-dealing-with-java-ee-and-java-endorsed-dirs

       

      I would really like to hear some opinions.  For Glassfish it looks like GLASSFISH_HOME/glassfish/modules/javax.annotation.jar is the only endorsed library.  Am I worrying about something that is a non-issue?

        • 1. Re: @Resource, container bootstrapping and java.endorsed.dirs.
          Aslak Knutsen Master

          When bootstrapping Embedded containers, they are started in the same JVM as Arquillian/JUnit. So the question is, how can you bootstrap that JVM.

           

          In the case of Maven, it's Maven Surefire that is the runner, so you have to control java.endorsed.dirs via the surefire argLine configuration.

          • 2. Re: @Resource, container bootstrapping and java.endorsed.dirs.
            Ryan J Newbie

            Thanks for the reply.  I still have a few issues with the way this works.  I understand Arquillian probably can't do anything about it, but would still value your opinion.

             

            When using Arquillian, I take responsibility for starting the JVM via Maven Surefire.  That means I'm also the only on that can set java.endorsed.dirs since it must be set when the JVM is started, right?  I found an old bug report that describes the problem a bit better.

             

            Now, the problem I have is that for me, the user, there isn't a decent source for the endorsed .jars that need to be included.  Maybe I'm confused because it doesn't seem right that I should have to deal with such a messy situation if I stick to the Java EE spec.  I shouldn't need to figure out where every container stores its endorsed .jars and if / how they get loaded when I'm using the embedded versions of those containers.

             

            Am I misunderstanding how java.endorsed.dirs works and how it relates to Java EE containers?  To me it seems like a recipe for JAR hell, yet I can't find anyone else having problems.  My questions are already the first hits on Google.  Sometimes I think I'm on a sadistic version of the Truman Show and that I'm the only one on the planet using Java EE.  Lol.