geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: How to build app and global scope jndi namespace for client application ?
Date Thu, 07 Jul 2011 07:20:08 GMT
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

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
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.

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

View raw message