Thank you for the reply,

>> this is the enhancement strategy I have to adopt for reasons beyond the 
scope of this post 
> I don't want to get this post off track, but I am interested in hearing
> what 
the problems were that you encountered with build time enhancement. 
Our application uses legacy libraries which are also used by legacy
applications. The legacy application employs a particular enhancement
strategy which utilizes a custom built java agent. This agent looks for xml
files with a particular name (which are actually invalid persitence xml
files carrying only class elements) at a particular location in the
classpath and merges all of these to form a valid persitence.xml and places
it under META-INF and than lets jpa enhancer to do loadtime enhancement. We
could probably continue to use this custom agent but I am searching for more
elegant way to achieve this. 

>Now down to my recommendation. This advise assumes that you're using the
-javaagent for enhancement.? 
Yes I am using openjpa javaagent.

>You could create a "root" persistence unit in the default
location(META-INF/persistence. xml) that will be used only for enhancement.
If you do not list any persistent types in the  list, we will enhance all
Entities that are encountered at load time. I think this approach should
work for you... just as long as you don't have different openjpa.DetachState
settings across your persistence units. 

-javaagent:[path-to-openjpa-jar].jar=p=META-INF/persistence.xml#enhance-pu 

Thanks I will try this approach and come back with feedback.

Paul


--
View this message in context: 
http://openjpa.208410.n2.nabble.com/Merging-modular-persistence-units-tp6218352p6222043.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

Reply via email to