Question

I want to write an application which has 2 EJBs. This application can run in both OpenEJB and WebLogic 10.3. Both of the EJB are EJB 3.0.

I know how to implement in both OpenEJB and WebLogic, but the problem is I want to use the same code to deploy to both environments. I think the problem is that how to do JNDI lookup, because WebLogic’s Context.INITIAL_CONTEXT_FACTORY is weblogic.jndi.WLInitialContextFactory but OpenEJB is not.

Current idea is the 1st EJB use a service locator to lookup the 2nd EJB and the service locator will read different INI in 2 environments. Is there any other suggestion? Is there a solution I can just use annotation, no need to use external INI files.

The 2 EJBs live in one container, but it’s possible one will be move to other container in the future.

Update on 2011/10/06

By David’s suggestion, I put some change. The code is a POJO, not JUnit code. It doesn’t use @LocalClient and initialContext.bind(“inject”, this); (I put the 2 code in my JUnit code)

1. Put resources\META-INF\application-client.xml (only contain )

2. Put resources\jndi.properties

   jdbc/OrderDB = new://Resource?type=DataSource
   jdbc/OrderDB.JdbcDriver = oracle.jdbc.OracleDriver
   jdbc/OrderDB.JdbcUrl = jdbc:oracle:thin:@*.*.*.*:1521:test
   jdbc/OrderDB.JtaManaged = false
   jdbc/OrderDB.UserName = test
   jdbc/OrderDB.Password = test
   

3. Lookup code

   InitialContext ctx= new InitialContext();
   ctx.lookup("jdbc/" + name);
   

The following is the log, OpenEJB creates the JNDI for the database. I also use Eclipse debug mode to see the content of “ctx” and find “jdbc/OrderDB” in MyProps

INFO - Configuring Service(id=jdbc/OrderDB, type=Resource, provider-id=Default JDBC Database)

But finally I still cannot lookup it. I also try to use ctx.lookup(name), ctx.lookup(“java:comp/env/jdbc/” + name) and the result is the same.

javax.naming.NameNotFoundException: Name "jdbc/OrderDB" not found.

Update on 2011/10/12

Base on David’s comment, before Java EE6, I think the only solution is to use a service locator and some configuration to use different JNDI between WebLogic and OpenEJB. The following is the test result.

DB: WebLogic: OrderDB, OpenEJB: openejb:Resource/jdbc/OrderDB

Transaction manager: WebLogic: javax.transaction.TransactionManager, OpenEJB: java:comp/TransactionManager

EJB: Both of them just lookup the EJB name without any prefix

Answer 1

The question in the update is a very different question, so posting a different answer.

No Global JNDI prior to Java EE 6

The long and short of it is that prior to Java EE 6, there is no global JNDI. So it is quite literally the case that the question “what is the JNDI name of x” is an unanswerable question. Each EJB has its own private JNDI namespace and “POJOs” don’t have any namespace at all, they use the JNDI namespace of whatever EJB invoked it. So to make “java:comp/env/myDataSource” appear as global as possible, you have to declare that reference for every single EJB in the application.

The amount of configuration work this creates for users is quite devastating. In Java EE 6 there is finally Global JNDI and three new standard namespaces, java:module, java:app and java:global. Any Global JNDI functionality existing prior to Java EE 6 is vendor-specific and non-portable.

The vendor-specific and non-portable way to do a Global JNDI lookup in OpenEJB for the given name would be to lookup openejb:Resource/jdbc/OrderDB

Calling a spade a spade

In OpenEJB we deliberately do not support non-standard lookups like jdbc/OrderDB or java:jdbc/OrderDB as some vendors do. The required prefix for global names in OpenEJB is openejb:.

JNDI is complex and confusing enough and making non-portable names look like portable names doesn’t do users any favors. If a certain style of naming is not portable and going to create vendor lock-in, it should look like it. So with the openejb: prefix, you can access anything you need globally but it is at least clear that what you are doing is not portable and should not be expected to work in other platforms without some modification.