aspose file tools*
The moose likes JBoss/WildFly and the fly likes How standalone program interact with JBOSS Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Products » JBoss/WildFly
Bookmark "How standalone program interact with JBOSS" Watch "How standalone program interact with JBOSS" New topic
Author

How standalone program interact with JBOSS

Cherry Gupta
Greenhorn

Joined: Feb 09, 2010
Posts: 17
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:



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
author
Bartender

Joined: May 14, 2008
Posts: 5845
    
    7

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


JBoss In Action
Cherry Gupta
Greenhorn

Joined: Feb 09, 2010
Posts: 17
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
Greenhorn

Joined: Jul 10, 2008
Posts: 10
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
author
Bartender

Joined: May 14, 2008
Posts: 5845
    
    7

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



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

Cherry Gupta
Greenhorn

Joined: Feb 09, 2010
Posts: 17
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
Marshal

Joined: Jul 20, 2005
Posts: 10290
    
168

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.

[My Blog] [JavaRanch Journal]
G Par
Greenhorn

Joined: Jul 11, 2011
Posts: 9
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
author
Bartender

Joined: May 14, 2008
Posts: 5845
    
    7

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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: How standalone program interact with JBOSS