Retrive datasource from remote VMs

[madghigno]

I have the following problem:

I have two servers, one runs JBoss 3.2.5 and one Tomcat 4.1.30.

I configured the datasource in JBoss copying the oracle-ds.xml into the deploy directory and adapting it to my oracle instance.
The drivers (classes12.zip) are in the lib directory.

Now, I want to get a datasource from the tomcat machine via JNDI

 try {
 Properties pf = new Properties();
 File jndiPF = new File("jndi.properties");

 InputStream is = (InputStream)new FileInputStream(jndiPF);

 pf.load(is);
 System.out.println("Property file loaded");
 System.out.println("Working on: " + pf.getProperty("java.naming.provider.url"));

 Context ctx = new InitialContext(pf);
 System.out.println("Context created");

 NamingEnumeration ne = ctx.list("java:" + args[0]);

 while (ne.hasMore()) {
 Object el = ne.next();
 System.out.println(" - " + el.toString());
 }

 DataSource ds = (DataSource)ctx.lookup("java:/jdbc/OracleDS");
 System.out.println("Datasource retrived");


 } catch (Exception e) {
 System.out.println("Error: " + e.getMessage());
 }

 }

the jndi.properties file is the following

java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory

java.naming.provider.url=jnp\://appsEJB01\:1099

java.namin.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
#The jnp socket factory class
jnp.socketFactory=org.jnp.interfaces.TimedSocketFactory
#The TimedSocketFacory connection time out in milliseconds (0 == blocking)
jnp.timeout=0
#The TimedSocketFactory read timeout in milliseconds (0 == blocking)
jnp.sotimeout=0

the loop on the initial context (java:/) show the following entries:

- HAILConnectionFactory: javax.naming.LinkRef
- jmx: org.jnp.interfaces.NamingContext
- HTTPXAConnectionFactory: org.jboss.mq.SpyXAConnectionFactory
- ConnectionFactory: org.jboss.mq.SpyConnectionFactory
- UserTransactionSessionFactory: $Proxy12
- HTTPConnectionFactory: org.jboss.mq.SpyConnectionFactory
- XAConnectionFactory: org.jboss.mq.SpyXAConnectionFactory
- invokers: org.jnp.interfaces.NamingContext
- UserTransaction: org.jboss.tm.usertx.client.ClientUserTransaction
- UILXAConnectionFactory: javax.naming.LinkRef
- HAILXAConnectionFactory: javax.naming.LinkRef
- UIL2XAConnectionFactory: javax.naming.LinkRef
- queue: org.jnp.interfaces.NamingContext
- topic: org.jnp.interfaces.NamingContext
- console: org.jnp.interfaces.NamingContext
- UIL2ConnectionFactory: javax.naming.LinkRef
- UILConnectionFactory: javax.naming.LinkRef
- UUIDKeyGeneratorFactory: org.jboss.ejb.plugins.keygenerator.uuid.UUIDKeyGeneratorFactory

but when I try to get the datasource I configured it says:

jdbc not bound


Looking in the FAQs (Creating a JDBC datasource) I found this phrase:

. . . DataSource wrappers are bound under the java:/ prefix since they are not usable outside of the server VM.


so if the JNDI datasources are available only if my code is running in the same VM I have to work only with the embedded version of tomcat ? why have I to specify a provider URL if it work only on the same host ? I'm missing something ?

How can I configure a pool available via JNDI from remote VMs ?

thanks in advance
MG

[darranl]

why have I to specify a provider URL - JNDI can be used remotely, it is only access to items bound under the java: namespace that can't be used remotely.

I think I remember reading something on here that said that access to datasources remotely was being added to a later verion of JBoss. (Possibly the 4.0 branch).

[madghigno]

This is a great problem for me, I can't scale EJBcontainers and Servlet containers on multiple hosts in this way.

I think I have to choose another EJB container, I can't wait version 4, unfortunately :(

MG

[adrian.brock]

You want to stop and think about what you are doing before
you start configuring such an anti-pattern.
I can't belive people still do this. Just because something
is technically possible, doesn't mean you should do it.

Colocate
Why serialize everything between the servlet and ejb container?
This has been discussed so many times before...

All I can say is we don't license by the number of cpus the ejb
container is deployed on (a major consideration when using
other containers where this is the case), there is no need to
minimize the ejb container machines.
This is usually the real reason people advocate separating servlet
and ejb constainers.

Pool available via jndi
Ridiculous. Let's create a pool to efficiently use resources,
but then use each connection from the pool remotely, negating
any benefit. The connections will also be held for longer
(network latency) and you have to trust the client to use the
connection efficiently (i.e. not to hog the resources).

Create the pool where it is used, i.e. in the servlet container.

Security
The only reason not to colocate is because you want the servlet
container in the demilitarised zone.
If that is true, why have you punctured a hole straight through
to your db? And why do you have business logic inside the servlet
in the demilitarized zone anyway?

[madghigno]

Adrian,
first of all, thank you for your quick reply
you are right about the pool available via jndi, and I know that, but the problem is that I have to integrate systems from different providers that have no enough skills to rebuild things in the right way now.

I'll configure JNDI locally on every servlet container. I hope to re-colocate all the pieces in the right place in a second time

Thanks again
MG

[madghigno]

about the demilitarised zone, the servlet containers and the EJB containers are behind the DMZ.
Only the web server is in the DMZ. Communication between the Web server and tomcats is made via jk connector

bye
MG