Classpath problem

[Carlo Bertuccini]

Hi all,

I'm trying to connect to HornetQ from my vertx app.

The problem is that if I package the necessary Jars within my app (or I put jars in a library folder adding this one to the CP) I get a ClassNotFoundException.

The only solution I found till now is to include these jars in vert.x lib folder (ugly!) -- why do I get this error with these libraries? (I've used different jars in my app but no one ever raised this exception). Any better solution to fix it?

TIA.

Regards,

Carlo

[Tim Fox]

Can you post an example which demonstrates the issue, showing where you're putting everything, and how you're running it?

I'd also recommend (if you're not already) packaging your app as a module - this makes classpaths much easier to manage.

[Carlo Bertuccini]

Here is what I did ....

I've used the maven assembly plugin to package one "big jar" with its dependencies. I run it using

vertx run mypack.DeployerVerticle -cp "C:/temp/vertx-services-vertxpack.jar" -conf "C:/Progetti/pgit-vertx/trunk/target/configuration.json"

if I remove the dependencies from the "big jar" and I put them in a folder added to -cp I raise the same exception.

This happens only if I try to use JMS/HornetQ, with other dependencies I don't have any problem.

If I put the "big jar" in the lib of vertx everything run smooth.

Exception in Java verticle script

javax.naming.NoInitialContextException: Cannot instantiate class: org.jnp.interfaces.NamingContextFactory [Root exception is java.lang.ClassNotFoundException: o

rg.jnp.interfaces.NamingContextFactory]

        at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:674)

        at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307)

        at javax.naming.InitialContext.init(InitialContext.java:242)

        at javax.naming.InitialContext.<init>(InitialContext.java:216)

        at it.seat.fe.pgol.vxservices.MessagesConsumerVerticle.startVerticle(MessagesConsumerVerticle.java:46)

        at it.seat.fe.pgol.vxservices.ConfiguredVerticle.start(ConfiguredVerticle.java:16)

        at org.vertx.java.deploy.impl.VerticleManager$9.run(VerticleManager.java:642)

        at org.vertx.java.core.impl.Context$2.run(Context.java:118)

        at org.vertx.java.core.impl.Context$1.run(Context.java:108)

        at org.vertx.java.core.impl.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:90)

        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)

        at java.lang.Thread.run(Thread.java:722)

Caused by: java.lang.ClassNotFoundException: org.jnp.interfaces.NamingContextFactory

        at java.net.URLClassLoader$1.run(URLClassLoader.java:366)

        at java.net.URLClassLoader$1.run(URLClassLoader.java:355)

        at java.security.AccessController.doPrivileged(Native Method)

        at java.net.URLClassLoader.findClass(URLClassLoader.java:354)

        at java.lang.ClassLoader.loadClass(ClassLoader.java:423)

        at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)

        at java.lang.ClassLoader.loadClass(ClassLoader.java:356)

        at java.lang.Class.forName0(Native Method)

        at java.lang.Class.forName(Class.java:264)

        at com.sun.naming.internal.VersionHelper12.loadClass(VersionHelper12.java:63)

        at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:671)

        ... 12 more

I'd also recommend (if you're not already) packaging your app as a module - this makes classpaths much easier to manage.

My app is not packaged as module ... can you please tell me how it will be "easier to manage"?

Thanks,

Carlo

[Tim Fox]

On 23/10/12 15:59, Carlo Bertuccini wrote:
> Here is what I did ....
>
> I've used the maven assembly plugin to package one "big jar" with its
> dependencies.

What's in the big jar? Make sure you don't have any of the Vert.x jars
in there.

Packaging an app as a module is the "Vert.x way" of doing things. In a
module, you can put your dependencies in the lib dir of the module, and
you can run it without having to hand craft any classpath. See the
modules manual for more info.
>
> Thanks,
> Carlo
> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/vertx/-/LFvSSOPnhnwJ.
> To post to this group, send an email to ve...@googlegroups.com.
> To unsubscribe from this group, send email to
> vertx+un...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/vertx?hl=en-GB.


--
Tim Fox

Vert.x - effortless polyglot asynchronous application development
http://vertx.io
twitter:@timfox

[Carlo Bertuccini]

What's in the big jar? Make sure you don't have any of the Vert.x jars in there. 

The big jar is a jar that embed the dependency necessary for my application to run.

The vert.x jars aren't in since I declared them as provided

However it could be not a problem of "vert.x" 

https://community.jboss.org/thread/121035?_sscc=t

Packaging an app as a module is the "Vert.x way" of doing things. In a
module, you can put your dependencies in the lib dir of the module, and
you can run it without having to hand craft any classpath. See the
modules manual for more info.

Thanks for the info and for vert.x

Regards,

Carlo 

[Tim Fox]

On 24/10/12 07:13, Carlo Bertuccini wrote:
>
> What's in the big jar? Make sure you don't have any of the Vert.x
> jars in there.
>
>
> The big jar is a jar that embed the dependency necessary for my
> application to run.

Sure, I understand that, but I want to know the exact jars (and other
files). I know a little bit about JMS and HornetQ as well, thought I
might be able to help you, but I can't unless you help me too :)

> The vert.x jars aren't in since I declared them as provided
>
> However it could be not a problem of "vert.x"
> https://community.jboss.org/thread/121035?_sscc=t
>
> Packaging an app as a module is the "Vert.x way" of doing things.
> In a
> module, you can put your dependencies in the lib dir of the
> module, and
> you can run it without having to hand craft any classpath. See the
> modules manual for more info.
>
>
> Thanks for the info and for vert.x
>
> Regards,
> Carlo

> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/vertx/-/_GBYR2-_M3UJ.

[Pid]

On 24/10/2012 09:40, Tim Fox wrote:
> On 24/10/12 07:13, Carlo Bertuccini wrote:
>>
>> What's in the big jar? Make sure you don't have any of the Vert.x
>> jars in there.
>>
>> The big jar is a jar that embed the dependency necessary for my
>> application to run.
>
> Sure, I understand that, but I want to know the exact jars (and other
> files). I know a little bit about JMS and HornetQ as well, thought I
> might be able to help you, but I can't unless you help me too :)

[chortle]


p

>> The vert.x jars aren't in since I declared them as provided
>>
>> However it could be not a problem of "vert.x"
>> https://community.jboss.org/thread/121035?_sscc=t
>>
>> Packaging an app as a module is the "Vert.x way" of doing things.
>> In a
>> module, you can put your dependencies in the lib dir of the
>> module, and
>> you can run it without having to hand craft any classpath. See the
>> modules manual for more info.
>>
>>
>> Thanks for the info and for vert.x
>>
>> Regards,
>> Carlo
>> --
>> You received this message because you are subscribed to the Google
>> Groups "vert.x" group.
>> To view this discussion on the web, visit
>> https://groups.google.com/d/msg/vertx/-/_GBYR2-_M3UJ.
>> To post to this group, send an email to ve...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> vertx+un...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/vertx?hl=en-GB.
>
>


--

[key:62590808]

[Carlo Bertuccini]

Sure, I understand that, but I want to know the exact jars (and other
files). I know a little bit about JMS and HornetQ as well, thought I
might be able to help you, but I can't unless you help me too :)

Ok I will try to help you :-)

I've heard you know something about JMS/HornetQ :-)

The jars I had to put in the lib folder or I get a Class Cast Exception (jars I've added after using HQ) ...

        <dependency>

            <groupId>javax.jms</groupId>

            <artifactId>jms</artifactId>

            <version>1.1</version>

        </dependency>

        <dependency>

            <groupId>jboss</groupId>

            <artifactId>jnp-client</artifactId>

            <version>4.2.2.GA</version>

        </dependency>

        <dependency>

            <groupId>org.jboss.logging</groupId>

            <artifactId>jboss-logging</artifactId>

            <version>3.1.2.GA</version>

        </dependency>

        <dependency>

            <groupId>org.hornetq</groupId>

            <artifactId>hornetq-jms-client</artifactId>

            <version>2.2.5.Final</version>

        </dependency>

        <dependency>

            <groupId>org.hornetq</groupId>

            <artifactId>hornetq-core-client</artifactId>

            <version>2.2.5.Final</version>

        </dependency>

There are also other jars (mainly to connect to the Cassandra Database) but these works fine.

Thanks for your help

[Tim Fox]

Do you have a jndi.properties on your classpath?

http://docs.jboss.org/hornetq/2.2.5.Final/user-manual/en/html_single/index.html#d0e1227

[Carlo Bertuccini]

No. Since I was just trying I just used couple of const in my verticle ...

    private static final String JNDI_INITIAL_CONTEXT_FACTORY = "org.jnp.interfaces.NamingContextFactory";
    private static final String JNDI_URL_PKG_PREFIXES = "org.jboss.naming:org.jnp.interfaces";

[Tim Fox]

It's been a long time since I used JNDI, but iirc you need to supply a
jndi.properties on the command line, OR manually create the
InitialContextFactory.

There should be more info in the jndi documentation.

But I think this topic is less about Vert.x and more about JNDI.

> <version>4.2.2.GA <http://4.2.2.GA></version>

> </dependency>
> <dependency>
> <groupId>org.jboss.logging</groupId>
> <artifactId>jboss-logging</artifactId>

> <version>3.1.2.GA <http://3.1.2.GA></version>

> </dependency>
> <dependency>
> <groupId>org.hornetq</groupId>
> <artifactId>hornetq-jms-client</artifactId>
> <version>2.2.5.Final</version>
> </dependency>
> <dependency>
> <groupId>org.hornetq</groupId>
> <artifactId>hornetq-core-client</artifactId>
> <version>2.2.5.Final</version>
> </dependency>
>
> There are also other jars (mainly to connect to the Cassandra
> Database) but these works fine.
>
> Thanks for your help
>

> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/vertx/-/jqBb3b4sjB0J.

[Carlo Bertuccini]

It's been a long time since I used JNDI, but iirc you need to supply a 
jndi.properties on the command line, OR manually create the 
InitialContextFactory. 

In fact I've created the ICF manually in my Verticle ... however, imho, it does not explain why if I remove the dependencies from the famous "big jar" and put them in the vert.x lib it works ...

regards,

Carlo

[Doug McCall]

I've run into a similar issue - I've got a groovy vertx module that loads some existing java classes that in turn connect to qpid using jndi. If I run the main groovy entry-point for the library (not in the vertx module yet), I discovered I had to fork the process in order to allow java to access the classpath defined for groovy. Once I had that all figured out, I packaged up all of that code into a jar and dropped it into my groovy vertx module. Now, it's running into the same issue of not being able to find the qpid jndi factories on the classpath. I've got all the same jars in the vertx module lib folder as those I tested with before creating the vertx module.

I'll let you know if I discover anything useful or if I can put together a small example demonstrating the issue.

[Tim Fox]

On Wednesday, November 28, 2012 7:43:25 PM UTC, Doug McCall wrote:

I've run into a similar issue - I've got a groovy vertx module that loads some existing java classes that in turn connect to qpid using jndi. If I run the main groovy entry-point for the library (not in the vertx module yet), I discovered I had to fork the process in order to allow java to access the classpath defined for groovy. Once I had that all figured out, I packaged up all of that code into a jar and dropped it into my groovy vertx module. Now, it's running into the same issue of not being able to find the qpid jndi factories on the classpath. I've got all the same jars in the vertx module lib folder as those I tested with before creating the vertx module.

I'll let you know if I discover anything useful or if I can put together a small example demonstrating the issue.

That would be useful - if you can do that I'll take a look.