Referencing EJB on remote server AND using deployment descriptor

Question

We're using Weblogic 6.1sp2 under Windows 2000.
We have a web application on server A and several EJBs running on server B -
some of these may in the future be moved to different servers.
We would like to ensure that this only requires reconfiguring the deployment
descriptors.
In our web app, we access the EJB's like this:
AccountHome accHome = (AccountHome) (new
InitialContext()).lookup("java:comp/env/ejb/AccountHome")
- we then map ejb/AccountHome to the JNDI name in the weblogic.xml file in
the web app - the JNDI name will usually (but not always) be the class name
of the implementing class, e.g. system.billing.accounting.AccountHome
However, to make this work when the EJB is on server B, we must put a
jndi.properties file in the server A classpath containing
java.naming.provider.url=t3://server_b:7001/
to point to server B.
Now, this makes ALL JNDI lookups on server A go to server B - this is not
what we want. Especially not in the case where some EJB's move to server C -
B and C may be in separate clusters and will not be clustering the JNDI
tree. Also, other web applications on the server will need to go to
different servers.
Alternatively, we could specify a property set in the InitialContext
constructor with a provider url. But in that case, the mapping from
web.xml/weblogic.xml is apparently not applied - or rather, if we look up
"java:comp/env/ejb/AccountHome", weblogic maps it to
"system.billing.accounting.AccountHome" and then tries to look it up on the
local machine, server A.
If we look up "system.billing.accounting.AccountHome", it does correctly
look it up on the server specified in the provider url and finds the entry.
However, this would mean that we would have to specify the exact jndi name.
In addition, we would have to hard-code the server name for each lookup.
An alternative would be to "copy" the JNDI entries from server B to server A
(or to some other shared, global JNDI registry). But these would need to be
kept in sync - especially since server B is really a cluster, where
different servers may come online at different times and register their EJBs
as clusterable, so the stubs would need to be continously updated.
My best idea is to bypass the whole web.xml/weblogic.xml mapping scheme and
just add our own config file with stuff like
<mappings>
<map entry="java:comp/env/ejb/AccountHome">
<jndi-properties>
java.naming.provider.url=t3://server_b:7001/
java.naming.security.principal=jndiuser
java.naming.security.credentials=mysecretpassword
</jndi.properties>
<jndi-name>sysmte.billing.accounting.AccountHome</jndi-name>
</map>
</mappings>
We then need to wrap all the lookups in our own lookup mechanism which first
checks the config file to find any mappings.
However, this seems like reinventing the wheel and will also confuse most
deployment tools etc.
Does anybody have any suggestions where we
1. Don't put a jndi.properties file in the server classpath
2. Lookup ejb's using "java:comp/env/ejb/SomeEJB" - not the JNDI name.
3. Don't hardcode the server names in the application - but potentially
in the deployment descriptor.
4. Can look up different EJB's on different machines
Niels Harremoës

Answer 1

There is an article on dev2dev that may explain what you are seeing...
http://dev2dev.bea.com/articlesnews/discussion/thread.jsp?thread=142
HTH
dwfa
"Niels Ull Harremoës" <[email protected]> wrote in message
news:[email protected]...
It turns out that we can make it work by entering the url of the server in
the weblogic.xml entry - e.g. instead of having
<reference-descriptor>
<ejb-reference-description>
<ejb-ref-name>ejb/AccountHome</ejb-ref-name>
<jndi-name>system.billing.accounting.AccountHome</jndi-name>
</ejb-reference-description>
</reference-descriptor>
we enter
<reference-descriptor>
<ejb-reference-description>
<ejb-ref-name>ejb/AccountHome</ejb-ref-name>
<jndi-name>t3://server_b:7001/system.billing.accounting.AccountHome</jndi-na
me>
</ejb-reference-description>
</reference-descriptor>
However, we are unsure on whether this will establish a new JNDIconnection
to server_b on every lookup? And it's not documented anywhere?
Does anybody have any other suggestions?
"Niels Ull Harremoës" <[email protected]> wrote in message
news:[email protected]...
We're using Weblogic 6.1sp2 under Windows 2000.
We have a web application on server A and several EJBs running on serverB -
some of these may in the future be moved to different servers.
We would like to ensure that this only requires reconfiguring thedeployment
descriptors.
In our web app, we access the EJB's like this:
AccountHome accHome = (AccountHome) (new
InitialContext()).lookup("java:comp/env/ejb/AccountHome")
- we then map ejb/AccountHome to the JNDI name in the weblogic.xml file
in
the web app - the JNDI name will usually (but not always) be the classname
of the implementing class, e.g. system.billing.accounting.AccountHome
However, to make this work when the EJB is on server B, we must put a
jndi.properties file in the server A classpath containing
java.naming.provider.url=t3://server_b:7001/
to point to server B.
Now, this makes ALL JNDI lookups on server A go to server B - this is
not
what we want. Especially not in the case where some EJB's move to serverC -
B and C may be in separate clusters and will not be clustering the JNDI
tree. Also, other web applications on the server will need to go to
different servers.
Alternatively, we could specify a property set in the InitialContext
constructor with a provider url. But in that case, the mapping from
web.xml/weblogic.xml is apparently not applied - or rather, if we look
up
"java:comp/env/ejb/AccountHome", weblogic maps it to
"system.billing.accounting.AccountHome" and then tries to look it up onthe
local machine, server A.
If we look up "system.billing.accounting.AccountHome", it does correctly
look it up on the server specified in the provider url and finds theentry.
However, this would mean that we would have to specify the exact jndiname.
In addition, we would have to hard-code the server name for each lookup.
An alternative would be to "copy" the JNDI entries from server B to
server
A
(or to some other shared, global JNDI registry). But these would need tobe
kept in sync - especially since server B is really a cluster, where
different servers may come online at different times and register theirEJBs
as clusterable, so the stubs would need to be continously updated.
My best idea is to bypass the whole web.xml/weblogic.xml mapping schemeand
just add our own config file with stuff like
<mappings>
<map entry="java:comp/env/ejb/AccountHome">
<jndi-properties>
java.naming.provider.url=t3://server_b:7001/
java.naming.security.principal=jndiuser
java.naming.security.credentials=mysecretpassword
</jndi.properties>
<jndi-name>sysmte.billing.accounting.AccountHome</jndi-name>
</map>
</mappings>
We then need to wrap all the lookups in our own lookup mechanism whichfirst
checks the config file to find any mappings.
However, this seems like reinventing the wheel and will also confuse
most
deployment tools etc.
Does anybody have any suggestions where we
1. Don't put a jndi.properties file in the server classpath
2. Lookup ejb's using "java:comp/env/ejb/SomeEJB" - not the JNDIname.
3. Don't hardcode the server names in the application - butpotentially
in the deployment descriptor.
4. Can look up different EJB's on different machines
Niels Harremoës