How standalone program interact with JBOSS

[Cherry Gupta]

Hi,

I m trying to connect to datasource from my standalone program to JBOSS. But I m getting the below error:

javax.naming.NameNotFoundException: commsDSLocal not bound
at org.jnp.server.NamingServer.getBinding(NamingServer.java:771)
at org.jnp.server.NamingServer.getBinding(NamingServer.java:779)
at org.jnp.server.NamingServer.getObject(NamingServer.java:785)
at org.jnp.server.NamingServer.lookup(NamingServer.java:443)

my standalone program is:

class DatasourceTest
{
	public void dsInfo() throws NamingException, SQLException
	{
		System.out.println("Inside dsInfo()");
		Connection con=null;
		try
		{				
			Hashtable map=new Hashtable();
			System.out.println("Map");
			map.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
			map.put(Context.PROVIDER_URL, "jnp://localhost:1099");
			map.put(Context.URL_PKG_PREFIXES, "org.jboss.naming:org.jnp.interfaces");
			Context ctx = new InitialContext(map);
			DataSource ds1=(DataSource)ctx.lookup("java:commsDSLocal");
			System.out.println("Datsource is "+ds1);
		}
		catch(Exception e)
		{
			e.printStackTrace();
		}
		finally
		{
			if(con!=null)
			con.close();
		}
	}
}

public class Datasource_demo {
	public static void main(String[] args) throws NamingException, SQLException 
	{
		DatasourceTest dt = new DatasourceTest();
		dt.dsInfo();
	}
}

I have configured commDSLocal in -ds.xml file in JBOSS and started the JBOSS server but still I m getting this issue.

Please help to resolve the issue.

Thanks in advance!!!

Regards,
Cherry

[Peter Johnson]

What is "commDSLocal"?

First, you need to turn off use-java-context in the *-ds.xml file, and then you need to drop "java:" from the name you arel ooking up. The java: context is valid only for apps running within JBoss AS itself.

For more details, see "Configuring a DataSource for remote usage" at http://community.jboss.org/wiki/ConfigDataSources

[Cherry Gupta]

Thanks Peter for replying.

Now NameNotFoundException has gone.

But now I m getting different exception:

java.lang.ClassCastException: javax.naming.Reference cannot be cast to javax.sql.DataSource
at test.DatasourceTest.lookup(Datasource_demo.java:46)
at test.Datasource_demo.main(Datasource_demo.java:80)

I m getting this error when I m trying to convert from Object to DataSource class at below line.
DataSource o=(DataSource)ctx.lookup(name);

Please help!!!


Regards,
Cherry

[Manjunatha Murthy]

Check the jars that you are using. If the JBOSS client jars are from a different version of JBOSS server this type of error comes. I had encountered similar error when my JBOSS server was 5.0.1 and my client jars from 5.1.0

[Peter Johnson]

And after you try Manjunatha's suggestion, also try printing out the classname for the object looked up:

Object obj = ctx.lookup(name);
System.out.println(obj.getClass().getName());

Also, use JNDIView to see exactly which name is registered in JNDI. See: http://community.jboss.org/wiki/DisplayTheJDNITreeWithTheJMXConsole

[Cherry Gupta]

Hi,

I have checked the jars and they are of same version only.

the result of the below statement is javax.naming.Reference:
System.out.println(obj.getClass().getName());

means its returning javax.naming.Reference

but then how I convert javax.naming.Reference to javax.sql.DataSource?

[Jaikiran Pai]

Cherry Gupta wrote:Hi,

I have checked the jars and they are of same version only.

How did you check that? How exactly are you setting the classpath of the client application? What jars does it contain? Does it point to JBOSS_HOME/client/jbossall-client.jar? Post the command you use to set the classpath.

[G Par]

Hey Guys,
I am a newbie in the whole java distributed world, so please bear with my ignorance. I had the exact same problem mentioned above (ClassCastException) and I was literrally scouring the web for the last 8 hours for a solution. Dozens of blogs say the same thing, that it has to do with the libraries in your path, but do not say exactly what libraries. Plus most of them are from old Jboss 5.0. I had this problem with Jboss 6 which deals with whole different set of libraries. So I had to do lot of trial and error. Just keep adding missing Jars (aout 20 of them) one at a time and removing ones that caused conflict and see if it hits. Finally after wasting many hours some random combination of libraries did hit which made me happy, but also sad. Here's why.. Are problems in distributed java just like this?, obscure and without much documented or logical approach? I mean, where in Jboss documentation is it mentioned that to do a remote call to jboss you need x, y and z jars and why are those needed ? Is it all just hit, miss and google? Is that how people solve problems in java? I am getting a bit demotivated by this. Would love to hear from veterans on this.

Thanks
Girish

[Peter Johnson]

In ages past (oh, a year ago or so) the typical remote client would include client/jboss-all.jar in the classpath. That usually covered everything that the client needed. In 4.2.x and earlier, tat JAR contained all the classes; starting with 5.0.0 that JAR contained no classes and instead referenced the other JAR files in the client directory.

But including all those classes all the time was not always a good idea, especially if you are trying to trim down the amount of space your client takes. Nowadays, JBoss Tattletale can be used to determine the JAR file dependencies so that you will know exactly which JAR files need to be included in your client. Tatttletale beats the old "run it until it complains about a missing class and then hunt up its JAR file" strategy.