Yes you can lookup a datasource. Make sure the JNDI name is correct. If you can view your datasource from the jndi view, you should be able to look it up.
I think obtaining the datasource only makes sense on the server. Since server manages the connection pool and transactions. If you are doing this on the client outside of jboss, you may want to re-consider your design.
If you are still stuck, post your code and someone may be able to help you.
You can't lookup a JBoss datasource outside JBoss. The JNDI lookup is only possible within the container (java:/ prefix).
mlange ... is there any way out of this?
actually my issue is that I need to keep passwords secured and out of the reach of the general developers.
web applications should not have this issue for my side. It is because some of our background processes runs as java clients and we would like to take out the connection portion and pass the handling of the connection pool to the J2EE server.
Do advice me on the best approach.
is there such a thing as a JNDI datasource on the global namespace? How do I set it up for that and would that help for the java client?
ok .. don't bother answering the questions above ... this is what I conclude :
1) It is virtually impossible to get a JNDI Datasource.
2) It is impractical also due to the J2EE implementation. EJBs would be the way to go if we need data. Since data access will fall within the Business Layer, it should be handled by EJBs and since it is handled by EJBs, it will be possible for even Java Clients to access these EJBs to request for data.
Now, can anyone post me links to where I can learn EJBs within 24 hours. Even if I have to read a thousand pages just to get it, I am geared to go. Just need the compass to be pointed in the correct direction.
ps: someone should put this up in the wiki (the JNDI Datasource issue)
Yea... that doesn't help much. I saw the following in Chapter 31...
Specify the logical name of the database.
private String dbName
The java:comp/env portion of the logical name is the environment naming context of the component. The jdbc/SavingsAccountDB string is the resource reference name (sometimes referred to as the coded name). In deploytool, you specify the resource reference name and then map it to the JNDI name of the DataSource object.
Obtain the DataSource object associated with the logical name.
InitialContext ic = new InitialContext();
DataSource ds = (DataSource) ic.lookup(dbName);
Given the logical name for the resource, the lookup method returns the DataSource object that is bound to the JNDI name in the directory.
Get the Connection object from the DataSource object.
Connection con = ds.getConnection();
Still, that doesn't address the fact that JBoss doesn't bind the JDBC info in JNDI where it can be accessed directly. I know that directly accessing the DB is discouraged, which I agree with, but I have rare case where it is needed. To do this, I've been directly reading the datasource info in the DS XML file, but I would have preferred to lookup the info directly in JNDI.
JBoss specifically puts the DataSource bindings in the java:/ namespace of JNDI to make it inaccessible to external VMs, since by definition, they cannot use any objects bound in that space.
In the case of EJBs, you have two options. You can reference the java:/ namespace directly to retrieve the DataSource, or you can create a link that will make it appear as though your DataSource is in your EJB's java:comp/env/jdbc/ namespace. The later is probably preferred since the spec says that an EJB has no access to JNDI outside of its own java:comp/env/ environment.
The easiest way to get this reference in the deployment descriptor, and the easiest way in general to write EJBs is to use XDoclet. Skip the 94 page tutorial and just go by the examples in XDoclet or XPetStore.
XDoclet : http://xdoclet.sourceforge.net
And you will need Ant as well.
Cheers and good luck.