Fat.jar starter in 2.1.2 (Issues in Starting up)

[neoeahit]

Recently upgraded to vertx 2.1.2 and we have been experiencing issues starting up the fat.jar

Error:

java.lang.NullPointerException: moduleID

at org.vertx.java.platform.impl.FatJarStarter.go(FatJarStarter.java:108)

It seems like an issue with the classloader/classpath

Please advice.

[Tim Fox]

Do you have a reproducer?

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alexander Lehmann]

That looks like a format error in the MANIFEST.MF file, if you unzip the jar, what does the file contain?

the file has to contain an entry Vertx-Module-ID:, if that is missing, the null pointer will happen.

Maybe there was a mistake in the build process.

[Vipul]

The setup was identical with vertex version 2.1.1. This used to work fine for us and we were able to use the fatjar.

We had just upgraded the version to 2.1.2 and started having this issue.

--
You received this message because you are subscribed to a topic in the Google Groups "vert.x" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vertx/jOsiGoF-FuU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vertx+un...@googlegroups.com.

[Alexander Lehmann]

That doesn't answer my question, please open the jar file and post the contents of the file META-INF/MANIFEST.MF

[Trevor S]

https://github.com/eclipse/vert.x/commit/b4ecab9d766e7c8a7a3a36867f3af5a8706f87ce#commitcomment-7429788

i made some comments on this issue at the commit above.    its unizipping the wrong jar - its unzipping a jar from my jdk's ext dir.

[Tim Fox]

We still need a reproducer, otherwise I have no idea how to replicate this issue.

[Bernd Donath]

Hi Tim,

I can reproduces this issue by executing

java -javaagent:C:\CC\FusionReactor\instance\CloudCollector\fusionreactor.jar=name=CloudCollector,address=8100 -Dlog4j.configuration=file:log4j.properties -jar cloudcollector-1.0.0-SNAPSHOT-fat.jar -conf conf.json

which results in the error

INFO FusionReactor FW: fusionreactor-core: Starting OSGi Plugin Manager

INFO FusionReactor FW: Bootstrap: Runlevel 10 achieved.

Failed to run fat jar

java.lang.NullPointerException: moduleID

        at org.vertx.java.platform.impl.FatJarStarter.go(FatJarStarter.java:108)

        at org.vertx.java.platform.impl.FatJarStarter.main(FatJarStarter.java:59)

INFO FusionReactor Framework Host Manager - Initialized

INFO FusionReactor FW: Framework stopping.

INFO FusionReactor FusionReactorOSGiServletForward: Destroyed filter

INFO FusionReactor FusionReactorOSGiServlet: Destroyed filter

FINEST FusionReactor ODL: Deactivating bundle...

FINEST FusionReactor ODL: Bundle deactivated.

2014-10-31 11:12:38.060:INFO:oejsh.ContextHandler:stopped o.e.j.s.ServletContextHandler{/,null}

If I exclude our agent and use 

java -jar cloudcollector-1.0.0-SNAPSHOT-fat.jar -conf conf.json

everything works as expected. This did work with version 2.1.1 but stopped since we upgraded to 2.1.4.

Hope that helps.

Regards

Bernd

[Alexander Lehmann]

I think it may be necessary to iterate through the jar files in the classpath to find the one that contains the actual verticle it should try to start, the agent probably changes the classpath in a way which vert.x is not expecting.

[Alexander Lehmann]

Ok, i can reproduce that now, I have created a BZ issue for the bug and I will put up my example project later.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=449637

[Trevor S]

The Fatjarstarter in 2.1.2 unzips the wrong jar. If u have other jars in java's extension dir, one of thos may be unzipped, not your fatjar.

We've had to patch 2.1.2 Fatjarstarter.java to use its old logic cron 2..1.1 instead.

[Trevor S]

I don know how to get a jar in java's ext dir loaded by the class loader, that will show the issue and the code in fatjarstarter choosing to unzip the wrong jar. Our "Java eng team" distributed our jdks here at work.

So this is likely only an issue in companies and teams loading jars into the jvm via ext

Not sure why this code was changed at all btw. It was fine.

[Alexander Lehmann]

There are probably cases where the classpath doesn't start with the farjar, so using the first entry isn't working either.
In your usecase, using the first jar in the classpath works, but it has to be implemented in a way that works with all cases.

I have created a fix and proposed a PR for the issue, but this is not yet included in the snapshot.

[Tim Fox]

On 05/11/14 12:28, Alexander Lehmann wrote:

There are probably cases where the classpath doesn't start with the farjar,

I think that's only the case when someone has messed with the classpath somehow, e.g. they have specified an agent or have specified extra classpath when running it on the command line.

--

[Trevor S]

yes, in my case its 2 agents they run in the jvms we have to use.

[Alexander Lehmann]

the 2.1.5-SNAPSHOT now contains my fix for the agent issue, if you want to give it a try.