I chatted with Ivan on IRC about this and I think we have a simple plan that might work for now. I'm reluctant to propose a large scale solution that involves much code changes for several reasons including that I hope we can use the aries jpa support instead of our gbeans soon.
It looks like right now the PersistenceUnitBuilder is adding two gbeans, one to the server and one to the app client, for this persistence.xml in lib/shared.jar. I'm not sure this is a good idea, but I'm also not sure how to change it easily Here's what I think the simplest solution for right now is: 1. Modify the peristenceRefBuilder to make an AbstractNameQuery that will find either one of these gbeans (the names are very similar) 2. make a PersistenceUnitReference that doesn't set the configId in the ConfigurationAwareReference constructor. 3. change ConfigurationAwareReference so it works even with no configId. I think this will still uniquely identify the persistence unit globally since the app name is already part of the abstract name. In the future we might want to look into something like: - only deploy the gbean once for the module it is actually it - scan the app and global contexts for COnfigurationAwareReferences and if the gbeans for them are not in the app client, copy them from the server config to the app client config. On the other hand, I hope that we can avoid this by not using gbeans at all. thanks david jencks On Jul 6, 2011, at 7:41 AM, Ivan wrote: > Hi, I am looking at a sample about using app scope jndi entry in client > application. The sample is an ear package, the structure is like : > a.ear > /lib/lib.jar > client.jar > ejb.jar > > In the lib.jar, there is a persistence.xml file in the meta-inf folder, and > in the application.xml, there is an entry like > > <persistence-unit-ref> > <persistence-unit-ref-name>java:app/env/pu</persistence-unit-ref-name> > </persistence-unit-ref> > > In the deployment process, EARConfigBuilder will use those naming builder to > create a PersistenceUnitReference in the java:app scope, and the reference > points to the abstractName of the PU found in the lib.jar. So far, it is > fine.But for the application client module, as app scope jndi is shareable > with the server side. It has the same PURference, but unfortunately, it > points to an unexisted PU GBean name. For fixing this, one way is to update > the PUReference in the app scope map for the application client module, we > might construct the AbstractName on the fly, might be we just need to update > the configuration name and some other properties. Another possible solution > is that, while processing the naming in other modules, if we found the jndi > reference is of app and global scope, let's keep them in a temporary > structure. Later, when processing the jndi entry for application client, we > adds all those entry to the application-client.xml file. So that application > client will use each naming builder to create the correct jndi reference for > themselves. That means, for application client modules, it will not share the > same map with other modules. This solution also have some issues, if we have > more than one application client, and each of them configures some global and > app jndi entry, those entries might lost for other modules, including those > web modules, ejb modules, and other client modules in the same ear package. > > Any idea for this ? Thanks. > -- > Ivan
