I have multiple WARs that rely on the same depenency jar, which contains
EJBs, including the @LocalBean, @Local, and @Remote classes. One WAR is the
host for the EJB, the others use the remote interface via JNDI.
Using the default JNDI naming scheme, this cause conflicts when initializing
the server, as it tries to create the JNDI name for the bean each time the
dependency is located.
I can repackage the dependency, to put the Remote interfaces in its own jar,
so the actual bean classes aren't detected and initialized when the server
starts. I'm not a fan of this as it involves splitting up an otherwise
logically coherent unit, and adds a separate dependency to manage for host
WAR.
Currently, I use the nested JNDI naming scheme ("{module}/{beanName}"). This
prevents conflicts when initalizing the server/servlets, but I have to
access the bean from the server-wide URL ( "http://host/tomee/ejb/"; ), and
then provide the nested namespace/bean name ( "webapp/ejbName" ).
What I'd rather have:
provider-url : "http://host/webapp/ejb/";
jndi name : Bean.class.getSimpleName()
The idea being that each WAR has its own OpenEjb configuration, and nested
access URL. I can't find any examples like this, so I don't know if it's
possible to configure it using the provided facilities. At the least, a
filter which converts all calls to a url-filter into JNDI calls in the
applications namespace would do the job.
I'd also be interested in simply inserting a config file or option into my
WARs which prevents them from initializing the JNDI for that app, to prevent
conflicts.
Can anybody offer some suggestions? Is it possible to have separate openejb
instances per application, or is it always a global server thing? What kind
of options do I have to tweak openEJB at the web-app, as opposed to the
server level?
--
View this message in context:
http://openejb.979440.n4.nabble.com/Working-around-JNDI-conflicts-tp4657328.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
