4 Replies Latest reply on Feb 11, 2006 11:54 AM by Jens Elkner

    Sahoo 'using java Persistence JEE 5' blog

    darren hartford Expert


      http://weblogs.java.net/blog/ss141213/archive/2005/12/using_java_pers.html

      For this to work in jboss, so far these changes need to be made:

      *needed to add a META-INF/application.xml (it IS required for jboss)

      *The persistence.xml gives an error on deployment of -

      Caused by: java.lang.RuntimeException: You have not defined a jta-data-source for a JTA enabled persistence context name
      d: pu1


      I haven't gone any further as I'm curious if someone else has already done this and provide the change-list, or if the Jboss guys have any recommendations/comments regarding this example?

      Thanks,
      -D

        • 1. Re: Sahoo 'using java Persistence JEE 5' blog
          Bill Burke Master

          We do not support the Java EE 5 EAR format yet in JBoss 4.0.x. So, you have to declare standalone persistence archives within application.xml as an ejb module if you want them to be deployed.

          We are allowed to require a jta-data-source.

          • 2. Re: Sahoo 'using java Persistence JEE 5' blog
            Jens Elkner Apprentice

            Hmmm, is this (*.ear/lib/availableToAll.jar) on your roadmap for 4.x ?

            • 3. Re: Sahoo 'using java Persistence JEE 5' blog
              Bill Burke Master

              Not yet. Why is it such a big deal?

              • 4. Re: Sahoo 'using java Persistence JEE 5' blog
                Jens Elkner Apprentice

                E.g. because my EJBs use util classes, which are required on the rich client (and in the feature possibly on the web app as well). Right now, I've to add the util classes to the ejb.jar - otherwise I get ClassNotFoundExeptions when invoking the beans.

                OK, perhaps it might work to add a class-path entry into the metainfo and add all the extension description stuff (simply adding it to the application.xml as module does not work), but why should it be so complicated? It is much easier, when the stuff in lib gets picked up automatically,
                anlog as more or less good startup files for rich clients already do, which avoid s a lot of typing, possible typos, maintainance overhead (e.g. when the version and thus name of a jar changes,
                etc.) .

                Just in case, here an example, what I mean wrt. to automatic pickup for RCs:

                # add in the dependency .jar files
                DIRLIBS=${BASE_DIR}/lib/*.jar
                LOCAL_CLASSPATH=""
                for i in $DIRLIBS ; do
                 # if the directory is empty, then it will return the input string
                 # this is stupid, so case for it
                 if [ "$i" != "${DIRLIBS}" ] ; then
                 if [ -z "LOCAL_CLASSPATH" ]; then
                 LOCAL_CLASSPATH=$i
                 else
                 LOCAL_CLASSPATH="$i":$LOCAL_CLASSPATH
                 fi
                 fi
                done


                So I can just add/remove/replace any lib without the need to adjust anything wrt. "deployment"/startup ...