Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] Loading multiple persistence.xml files

Hey, Tom.

The number of mapping files is unlimited.  We've effectively recreated an OSGi style environment where components are made available at load time and the number of components is far ranging.  It's a JavaSE setup, so I may give the classloader thing a shot and see how it goes.  I'll try to post back with any results I'm able to put together.

FYI, this is the site that gave me the classloader idea.
http://netbeans.dzone.com/news/netbeans-and-jpa-with-multiple

-Carl


On Wed, Dec 17, 2008 at 11:47, Tom Ware <tom.ware@xxxxxxxxxx> wrote:
Hi Carl,

 Is the number of mapping files you get known or constrained?  If so, it may be possible to build jar files containing your domain classes and orm.xml files and point to them in the persistence.xml file using <jar-file>.

 As for the "classloader trick"...  Although I have not heard of it, it is plausible that it might work.  If you are in a JavaSE-type deployment, EclipseLink processes the persistence.xml and as long as it is available to System.getResources("META-INF/persistence.xml") when we bootstrap, I can't see why it wouldn't work.  There is even some API that allows you to tell us what classloader to use.  The only issue I can think of in this type of deployment is that the dynamic weaving we can do for performance might not work.

 JavaEE-type deployments would likely depend on what application server you are running since the app-server controls the processing of persistence.xml.

-Tom

Carl Hall wrote:
That works out fine.  Our system pulls in jars that are self contained projects.  I don't have a way to know what mapping files are available without querying the classloader.

e.g.
Sakai ClassLoader sees:
 project1.jar!META-INF/persistence.xml   <-- defines "default" UoW
 project1.jar!META-INF/orm.xml
 project2.jar!META-INF/persistence.xml   <-- also defines "default" UoW
 project2.jar!META-INF/orm.xml
etc.

The classloader "trick" I've seen is to query for all these files then inject into getResources() such that either, on-the-fly, 1) create a persistence.xml that contains a mapping entry for each orm.xml found or 2) merge all orm.xml files into 1 file and return a reference.


On Wed, Dec 17, 2008 at 11:07, Tom Ware <tom.ware@xxxxxxxxxx <mailto:tom.ware@xxxxxxxxxx>> wrote:

   Hi Carl,

    What issues are you seeing when you specify several orm files
   within the same persistence unit definition in one persistence.xml file?

   e.g.

   <persistence xmlns="http://java.sun.com/xml/ns/persistence"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
   persistence_1_0.xsd" version="1.0">

      <persistence-unit name="default" transaction-type="RESOURCE_LOCAL">
          <provider>
              org.eclipse.persistence.jpa.PersistenceProvider
          </provider>

            <mapping-file>META-INF/advanced-entity-mappings.xml</mapping-file>
            <mapping-file>META-INF/inheritance-entity-mappings.xml</mapping-file-->
            <mapping-file>META-INF/inherited-entity-mappings.xml</mapping-file>
            <mapping-file>META-INF/relationships-entity-mappings.xml</mapping-file>


   etc....


   -Tom

   Carl Hall wrote:

       Hi, Tom.

       You've nailed it.  Each persistence.xml is trying to create the
       same persistence unit ("default").  Is there a nice way to load
       1 persistence unit from multiple orm.xml files?  I've seen some
       classloader tricks to accomplish this but don't want to head
       down that rabbit hole unless necessary.

       Thanks,
       Carl


       On Wed, Dec 17, 2008 at 10:55, Tom Ware <tom.ware@xxxxxxxxxx
       <mailto:tom.ware@xxxxxxxxxx> <mailto:tom.ware@xxxxxxxxxx

       <mailto:tom.ware@xxxxxxxxxx>>> wrote:

          Hi Carl,

           Are you using separate EntityManagers for each persistence unit?

           An EntityManager represents one persistence unit - when the
          EntityManagerFactory is created, you get it by persistence unit
          name.  Any EntityManager created by that factory will
       represent that
          persistence unit.

           The name of a persistence unit is specified in the
       persistence.xml
          and only one persistence.xml may be used to define a given
          persistence units.  It is an error to have multiple
       persistence.xml
          that define the same persistence unit and the behavior is
       undefined
          - I am not surprised that if you are doing this, you get the last
          one loaded.

           To access different persistence units, create an
       EntityManager for
          each.

          -Tom

          Carl Hall wrote:

              I have a setup where multiple project come into a shared
              classloader.  Each project can have its own model files and
              thusly its own persistence.xml and orm.xml files.  When I
       create
              an EntityManager, I see in the logs that each persistence.xml
              file is found (3) and each orm.xml file loads with the
       expected
              entities.  When I try to query or persist using this
              EntityManager, only the entities from the lastly loaded
              persistence.xml is found.  Am I loading this correctly?  Am I
              trying to access things incorrectly?


                    ------------------------------------------------------------------------

              _______________________________________________
              eclipselink-dev mailing list
              eclipselink-dev@xxxxxxxxxxx
       <mailto:eclipselink-dev@xxxxxxxxxxx>
       <mailto:eclipselink-dev@xxxxxxxxxxx
       <mailto:eclipselink-dev@xxxxxxxxxxx>>

              https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

          _______________________________________________
          eclipselink-dev mailing list
          eclipselink-dev@xxxxxxxxxxx
       <mailto:eclipselink-dev@xxxxxxxxxxx>
       <mailto:eclipselink-dev@xxxxxxxxxxx
       <mailto:eclipselink-dev@xxxxxxxxxxx>>

          https://dev.eclipse.org/mailman/listinfo/eclipselink-dev



       ------------------------------------------------------------------------

       _______________________________________________
       eclipselink-dev mailing list
       eclipselink-dev@xxxxxxxxxxx <mailto:eclipselink-dev@xxxxxxxxxxx>
       https://dev.eclipse.org/mailman/listinfo/eclipselink-dev

   _______________________________________________
   eclipselink-dev mailing list
   eclipselink-dev@xxxxxxxxxxx <mailto:eclipselink-dev@xxxxxxxxxxx>
   https://dev.eclipse.org/mailman/listinfo/eclipselink-dev



------------------------------------------------------------------------

_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev


Back to the top