Often the only difference between two applications is the data used. However, if EJB is deployed with a "hard coded" jndi name, there is no way to deploy a bean twice in the same EJB container and have it refer to different database pools.

First, the mechanics:

1. Add an entry to every ejb entry in ejb-jar.xml like this

<env-entry>
    <env-entry-name>namespace</env-entry-name>
    <env-entry-type>java.lang.String</env-entry-type>
    <env-entry-value>NAMESPACE</env-entry-value>
</env-entry>

2. As part of your build process, add a script that replaces NAMESPACE with your actual namespcae, in this example "bank".

3. Use the following code to do EJBLookups:

public static EJBHome findHome(Class homeClass, String jndiName)
throws NamingException
    {
InitialContext jndiContext = new InitialContext();
Object ref = jndiContext.lookup(jndiName);
return (EJBHome) PortableRemoteObject.narrow(ref, homeClass);
    }

    public static String getApplicationName() {
        try {
InitialContext jndiContext = new InitialContext();
return (String) jndiContext.lookup("java:/comp/env/namespace");
        } catch (NamingException e) {
            return "noJndiPrefixFound";
        }
    }


4. Take whatever application server specific steps are required to modify the connection pool for your EJBs.


5. Add an application scoped variable to your web.xml that has the name space in it. Use that as part of all Session EJB lookups.

We've been battling this one at where I work for a while, and this is what we've come up with. Comments are quite welcome.

To describe the problem you wrote:
"Often the only difference between two applications is the data used. However, if EJB is deployed with a "hard coded" jndi name, there is no way to deploy a bean twice in the same EJB container and have it refer to different database pools."

I have some considerations about:
If the problem is to deploy the same bean twice in the same A/S (each one with a different jndi-name and each one referring to a different datasource), I had the same problem and the solution was to simply use the configuration mechanism provided by ejb's specs: the actual jndi-name of the bean is contained in the vendor dependent xml-file.
For example this is an excerpt from jboss.xml:
...
<ejb-name>DAOBadge</ejb-name>
<jndi-name>rap2/DAOBadge</jndi-name>
...
This is the place where you tell jboss that the bean defined as "DAOBadge" in ejb-jar.xml will be registered in jndi-tree with jndi-name "rap2/DAOBadge"
So you can deploy how many "dao-badges" as you need simply (and freely!) changin' the jndi-name.

You can't hard-code the jndi-name of a bean because of the considerations i made before, but you can hard code true jndi names of referenced ejbs or referenced resources: wrong practice! It's better to use ejb and resource references.
Doing so you only need to hard code the name of ejb or resource references but, just like the jndi-name of beans, the indirect referencing mechanism let you define the actual binding between reference and ejb/resource in the vendor dependent xml file.
here another example:
...
<ejb-ref>
  <ejb-ref-name>ejb/DAOBadge</ejb-ref-name>
  <jndi-name>rap2/DAOBadge</jndi-name>
</ejb-ref>
...
- ejb/DAOBadge is the (hard coded but ejb-local) name of the ejb reference
- rap2/DAOBadge is the globally known jndi name defined before

With this technique there is no change needed in source code or dynamic jndi-name construction.
All these operations are done by the application assembler so I think it's better to use standard j2ee configuration mechanisms, where possible (but sure: your technique works too, because the ejb-reference and resource referece are, at the end, just a special case of environment entry)

Mauro

P.S: I think this works only since ejb1.1...

But I wonder about Class conflicting, because the Bean Class is the same when you deploy it twice. The container do not know which class to be loaded!.

Any decent EJB container will deploy each bean using a different class loader...

Obviously then, you must not put your EJB jars in the classpath of the appserver - instead you must rely on the appserver's management of classloading and deployment.

Let me see if I have this correct:
BTW I am also using JBoss

1) Use the entries in Jboss.xml (the app server specific deployment file) for external (client) lookups.

2) For inside the ejb application, lookup using java:/comp/env/ejb/BeanName

Confirm or Deny anyone?

I am very new to the EJB and Application Servers world.
This is the exact problem which I am trying to find an answer for.
I have a legacy system written in C++ using COM which can connect to different databases depending on the database connection parameters. We are trying to reimplement the layer handling database operations using EJBs and Application server. But remote instances of the apps need to still retain the ability to connect to different datastores.

So basically, it is going to be the same EJBs referencing different datastores depending on client inputs. According to this guru, every remote instance of the app, has to have an instance of application server connecting to the corresponding datastore.

I have been told by an EJB guru, that this is not possible using EJBs and Application Servers.
Is it true ? Is it dependant on App Server functionality ? (We are experimenting with Orion 1.5.x).I read in the thread about JBoss allowing the same EJB app to be deployed more than once connecting to a different datastore.
 
If I were to believe the guru, this is a serious drawback in EJB/J2EE technology.

Please help with some information and clarification.

-Neeraj

Your right !

this is a serious drawback in EJB/J2EE technology...

If you would like to use the same EJB Entity to connect to more than only one database AT RUNTIME, you can't !!!

it's a big problem, and not the one...

> to more than only one database AT RUNTIME, you can't !!!

You can with Bean managed persistence. Keep in mind that CMP is for easy fixed applications, not for Database Tools.

Sure sometimes it would be nice to switch production/test database based on a flag in the data, but you can model this with 2 entity beans in that case.

The declarative component assembly has it's advantages and drawbacks.

Greetings
Bernd

Now I am using weblogic6.1 as the EJB container

I found the entity bean name can only deploy one time,despite you bind the entity bean name into several different jndi names in the "weblogic-ejb-jar.xml".

So I think if you want deploy one entity bean multi times in one container,you must declare several entity bean names for the entity bean in the "ejb-jar.xml",and then bind each entity bean name into the different jndi name in the "weblogic-ejb-jar.xml"

Hum...I'm using WL 6.1 and I've been able to deploy the same entity bean twice with seperate jndi-names. But I'm uploading these ejb's seperatly, not with them all defined in the same ejb-xml.

If this is infact the problem your having (defining them in the same ejb-jar) then why would you use the same set of jars to upload ejbs belonging to seperate applications?

Isn't the real problem that WebLogic doesn't handle the lookup correctly? Each application already has its own JNDI namespace, so there wont be any collisions. I would add that do the WebLogic Bugzilla instead of inventing patterns to go around it.

What I catched from your introduction is that you want to maintenant two environmets, (real data & test data)

Ok. Have simply your ejb servers installed twice in your machine the things would look better.