Problems with vert.x and many Logback appenders loaded by different classloaders

[Kaj Magnus Lindberg]

Hi,

We're having problems with Logback and Vert.x: apparently different instances of the Logback appender are created for each verticle, presumably beacus each verticle uses its own class loaders. This apparently results in problems with files being overwritten when the appenders roll over the files.

There might be a solution to that problem:  This Vert.x Goolge Groups email from december 2012 suggests that the logging framework JARs be loaded by the system classloader, so that only 1 instance of the log framework is create. (instead of one per vertex?). Quotes:

   "...Put your logging JARs on the system classpath..."

   "...This provides log4j and slf4j on the system classpath, so there will only be a single instance of the logger..."

Questions:

- How do I place the logging JARs on the system classpath? How do we make Vert.x load the logging framework only once? (We're using Vert.x version 2.0.0-final, Gradle, and logback-classic-1.0.13.)

- Do you think we're on the right track? Does it seem reasonable that conflicts between [different rolling-file-appenders loaded by different classloaders] cause problems when log files are rolled over?

Extra info 1:

When we've started Vert.x (`./gradlew runMod`), Vert.x does open the log file in many different file handles:

$ lsof log-file.log 

COMMAND  PID      USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME

java    4572 kajmagnus  206w   REG    8,1    11626 396901 log-file.log

java    4572 kajmagnus  210w   REG    8,1    11626 396901 log-file.log

java    4572 kajmagnus  212w   REG    8,1    11626 396901 log-file.log

java    4572 kajmagnus  215w   REG    8,1    11626 396901 log-file.log

java    4572 kajmagnus  222w   REG    8,1    11626 396901 log-file.log

java    4572 kajmagnus  224w   REG    8,1    11626 396901 log-file.log

java    4572 kajmagnus  226w   REG    8,1    11626 396901 log-file.log

Extra info 2:

When we configured Logback to use prudent mode (which avoids conflicts between different processes writing to the same log file), our problems were solved. However the prudent mode affects performance.

Best regards,

KajMagnus

[bytor99999]

To put log back into Vert.x go to the install directory of Vert.x, that is where you unzipped it. In that folder is a lib directory. In that dir put the log back jar files.

That would be 

logback core and logback classic 1.0.12 jar files and also put an slf4j1.7.2  jar file too in that directory. That is what we do and it works.

Mark

[Kaj Magnus Lindberg]

Thanks Mark! We're using the Vertex Gradle Template though, so we don't have any Vert.x installation directory (as far as I can tell). Do you (or someone else) know what to do then?

(About the Vertx Gradle Template: http://vertx.io/gradle_dev.html. We've already added Logback and SLF4J to the dependencies section of build.gradle mentioned on that page.)

Best regards, KajMagnus

--
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/Mh7nIHru1Zk/unsubscribe.
To unsubscribe from this group and all of its topics, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[bytor99999]

Well you do have a Vert.x installation somewhere. Didn't you download a zip file and unzip it? We do. 

If not, maybe you have to do it via the download way to get it to work. You can still use Gradle.

Mark

[Kaj Magnus Lindberg]

We downloaded no zip. Instead we cloned a Git repo, https://github.com/vert-x/vertx-gradle-template, which contains some Gradle config files, but no Vert.x installation and no Vert.x related JAR files at all actually. What happens is (I think) that Gradle fetches Vert.x JARs from some online repositories, and puts them in Gradle's local repository, and starts Vert.x via those JARs somehow. Apparently there's no "real" Vert.x installation anywhere — when I searched for the "vertx-core" JAR file, I found it only in Gradle's local repository (which isn't a Vert.x installation but rather something like a Maven or Ivy repo):

~$ find . -name '*vertx-core*'

./.gradle/caches/artifacts-23/module-metadata/io.vertx/vertx-core

./.gradle/caches/artifacts-23/filestore/io.vertx/vertx-core

./.gradle/caches/artifacts-23/filestore/io.vertx/vertx-core/2.0.0-final/source/f5bdac7f28b948ee762eb6bbf760fa233e9ec578/vertx-core-2.0.0-final-sources.jar

./.gradle/caches/artifacts-23/filestore/io.vertx/vertx-core/2.0.0-final/jar/7b19f7e13bbb57cf3fd996008a11b56f1a5e9221/vertx-core-2.0.0-final.jar

./.gradle/caches/artifacts-23/filestore/io.vertx/vertx-core/2.0.0-final/pom/497faa4b1868ab3da6c84e911821710598751991/vertx-core-2.0.0-final.pom

./.gradle/caches/artifacts-24/module-metadata/io.vertx/vertx-core

./.gradle/caches/artifacts-24/filestore/io.vertx/vertx-core

./.gradle/caches/artifacts-24/filestore/io.vertx/vertx-core/2.0.0-final/source/f5bdac7f28b948ee762eb6bbf760fa233e9ec578/vertx-core-2.0.0-final-sources.jar

./.gradle/caches/artifacts-24/filestore/io.vertx/vertx-core/2.0.0-final/jar/7b19f7e13bbb57cf3fd996008a11b56f1a5e9221/vertx-core-2.0.0-final.jar

./.gradle/caches/artifacts-24/filestore/io.vertx/vertx-core/2.0.0-final/pom/497faa4b1868ab3da6c84e911821710598751991/vertx-core-2.0.0-final.pom

./.IdeaIC12/system/jars/vertx-core-2.0.0-final-sources.jar.b1c0531d

./.IdeaIC12/system/jars/vertx-core-2.0.0-final.jar.afc6d5e

./.IdeaIC12/system/jars/vertx-core-2.0.0-final.jar.517fd79d

./.IdeaIC12/system/jars/vertx-core-2.0.0-final-sources.jar.be8e5b7e

So, as far as I can tell, there's nowhere to place the Logback JARs (or at least I cannot figure out where).

Perhaps we need to do as you mentioned and do a "real" installation of Vert.x instead.

Doesn't anyone use the Gradle-Vertx project with Logback? Are we the only ones?

Thanks anyway Mark for the help, and best regards,

KajMagnus

[Dean Pehrsson-Chapman]

I think you're on the right track, multiple classloaders with the same log config would cause this issue.

The solution I want to trial when I have a chance is to create a separate module for the logging (and perhaps any other infrastucture functions) and 'include' in my verticles.  If I'm reading the docs right, this included module will have its own classloader which can be accessed from including verticles, but they won't load any new logging instances.

http://vertx.io/mods_manual.html#includes

[Mumuney Abdlquadri]

I am wondering how you running vertx with installation...

--
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.

[Dean Pehrsson-Chapman]

Me?  All embedded, all the time, but I think the 'include' mechanism should work regardless. 

[Tim Fox]

I'm a bit confused about what you're trying to do.. Are you trying to use logback for the built in container logging (i.e. what you use when you container.log()), or do you want to ignore that and just do your own logging using the logback API in your verticle code?

[Kaj Magnus Lindberg]

Hi Tim,

We don't use container.log() actually. Instead we're doing it like this:

import org.slf4j.Logger;

import org.slf4j.LoggerFactory;

    ...

    private static final Logger logger = LoggerFactory.getLogger(SomeClass.class);

    ...

    // this code is run by a Verticle

    logger.info("Something happened today again, look: {}", something);

And as dependencies we've added Logback — in build.gradle:

dependencies {

    configurations {

        ...

        compile group: 'ch.qos.logback', name : 'logback-classic', version : '1.0.13'

        compile group: 'org.slf4j', name : 'slf4j-api', version : '1.7.5'

        compile group: 'org.slf4j', name : 'jcl-over-slf4j', version : '1.7.5'

        compile group: 'org.slf4j', name : 'log4j-over-slf4j', version : '1.7.5'

So yes I think that means that we're doing our own logging, using the SLF4J API in our verticle code.

Best regards,

KajMagnus

[Tim Fox]

Right, so each verticle type will get its own logger as it has its own classloader.

If you want multiple verticles to share the same logger you can put the logger classes in a non runnable module and include that from the modules that want to use it. (see modules manual)

On 13/12/13 15:59, Kaj Magnus Lindberg wrote:

Hi Tim,

We don't use container.log() actually. Instead we're doing it like this:

import org.slf4j.Logger;

import org.slf4j.LoggerFactory;

� � ...

� � private static final Logger logger = LoggerFactory.getLogger(SomeClass.class);

� � ...

� � // this code is run by a Verticle

� ��logger.info("Something happened today again, look: {}", something);

And as dependencies we've added Logback � in build.gradle:

dependencies {

� � configurations {

� � � � ...

� � � � compile group: 'ch.qos.logback', name : 'logback-classic', version : '1.0.13'

� � � � compile group: 'org.slf4j', name : 'slf4j-api', version : '1.7.5'

� � � � compile group: 'org.slf4j', name : 'jcl-over-slf4j', version : '1.7.5'

� � � � compile group: 'org.slf4j', name : 'log4j-over-slf4j', version : '1.7.5'

So yes I think that means that we're doing our own logging, using the SLF4J API in our verticle code.

Best regards,

KajMagnus

On Friday, December 13, 2013 2:57:07 PM UTC, Tim Fox wrote:

I'm a bit confused about what you're trying to do.. Are you trying to use logback for the built in container logging (i.e. what you use when you container.log()), or do you want to ignore that and just do your own logging using the logback API in your verticle code?

On 12/12/13 11:09, Kaj Magnus Lindberg wrote:

Hi,

We're having problems with Logback and Vert.x: apparently different instances of the Logback appender are created for each verticle, presumably beacus each verticle uses its own class loaders. This apparently results in problems with files being overwritten when the appenders roll over the files.

There might be a solution to that problem: �This Vert.x Goolge Groups email from december 2012 suggests that the logging framework JARs be loaded by the system classloader, so that only 1 instance of the log framework is create. (instead of one per vertex?).�Quotes:

�� "...Put your logging JARs on the system classpath..."

� �"...This provides log4j and slf4j on the system classpath, so there will only be a single instance of the logger..."

Questions:

- How do I place the logging JARs on the system classpath? How do we make Vert.x load the logging framework only once? (We're using Vert.x version 2.0.0-final, Gradle, and logback-classic-1.0.13.)

- Do you think we're on the right track? Does it seem reasonable that conflicts between [different rolling-file-appenders loaded by different classloaders] cause problems when log files are rolled over?

Extra info 1:

When we've started Vert.x (`./gradlew runMod`), Vert.x does open the log file in many different file handles:

$ lsof log-file.log�

COMMAND �PID � � �USER � FD � TYPE DEVICE SIZE/OFF � NODE NAME

java � �4572 kajmagnus �206w � REG � �8,1 � �11626 396901 log-file.log

java � �4572 kajmagnus �210w � REG � �8,1 � �11626 396901 log-file.log

java � �4572 kajmagnus �212w � REG � �8,1 � �11626 396901 log-file.log

java � �4572 kajmagnus �215w � REG � �8,1 � �11626 396901 log-file.log

java � �4572 kajmagnus �222w � REG � �8,1 � �11626 396901 log-file.log

java � �4572 kajmagnus �224w � REG � �8,1 � �11626 396901 log-file.log

java � �4572 kajmagnus �226w � REG � �8,1 � �11626 396901 log-file.log

Extra info 2:

When we configured Logback to use prudent mode (which avoids conflicts between different processes writing to the same log file), our problems were solved. However the prudent mode affects performance.

Best regards,

KajMagnus

--
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/groups/opt_out.

[Kaj Magnus Lindberg]

Hi Tim and Dean Pehrsson-Chapman,

We've placed the Logback related code in a separate module that we include from our main module. And this does indeed avoid the problem that the logging code was otherwise loaded many times by different classloaders. Thanks for suggesting this solution :-)

There were two things to think about: (that might be interesting to other people doing the same thing)

1.

The including module (i.e. our main module) still needed the Logback library in order to *compile*, so we specified that the Logback code was a 'provided' dependency of our main module: (since the Logback code is provided by the module we created)

in build.gradle: (well perhaps we didn't need exactly all these dependencies)

        provided group: 'ch.qos.logback', name : 'logback-classic', version : '1.0.13'

        provided group: 'org.slf4j', name : 'slf4j-api', version : '1.7.5'

        provided group: 'org.slf4j', name : 'jcl-over-slf4j', version : '1.7.5'

        provided group: 'org.slf4j', name : 'log4j-over-slf4j', version : '1.7.5'

2.

A problem when loading Logback in an included module was that the logback config files weren't available at the time the module with logging code and Logback was loaded. Therefore this error happened:

     *   SLF4J: The following loggers will not work because they were created

     *   SLF4J: during the default configuration phase of the underlying logging system.

     *   SLF4J: See also http://www.slf4j.org/codes.html#substituteLogger

     *   SLF4J: ...

     *   SLF4J: ... all our loggers listed here ...

     *   SLF4J: ...

Fortunately the error message includes a helpful link (see above) so I found this page:

   http://logback.qos.ch/manual/configuration.html#joranDirectly

that clarifies how to configure Logback dynamically after it's been loaded and started already.

Best regards,

KajMagnus

[Georg Grütter]

I ran into the same problem and was able to only partially solve it with the suggestions in this thread. I have factored out the logging specific dependencies as well as a base class responsible for instantiating the logger to a dedicated module. That module contains all required libs in its lib directory

logback-classic-1.0.13.jar
logback-core-1.0.13.jar
slf4j-api-1.7.6.jar

and it seems to be properly included by the module, in which I try to load a custom logback configuration file.  That's when I get the following exception

java.lang.ClassCastException: org.slf4j.helpers.NOPLoggerFactory cannot be cast to ch.qos.logback.classic.LoggerContext

which tells me, that SLF4J was not bound to logback. From my understanding of SLF4J and Vert.x class loading, having the three jar files listed above in the class path should do the trick, right? 

I compile and execute my modules using maven (mvn vertx:runMod). Am I missing anything? How did you set up your module and did you run into similar problems, Kaj?

Thanks in advance and cheers,

Georg

[Tim Fox]

On 13/12/13 13:07, Kaj Magnus Lindberg wrote:

We downloaded no zip. Instead we cloned a Git repo, https://github.com/vert-x/vertx-gradle-template, which contains some Gradle config files, but no Vert.x installation and no Vert.x related JAR files at all actually. What happens is (I think) that Gradle fetches Vert.x JARs from some online repositories, and puts them in Gradle's local repository, and starts Vert.x via those JARs somehow.

Correct

Apparently there's no "real" Vert.x installation anywhere — when I searched for the "vertx-core" JAR file, I found it only in Gradle's local repository (which isn't a Vert.x installation but rather something like a Maven or Ivy repo):

~$ find . -name '*vertx-core*'

./.gradle/caches/artifacts-23/module-metadata/io.vertx/vertx-core

./.gradle/caches/artifacts-23/filestore/io.vertx/vertx-core

./.gradle/caches/artifacts-23/filestore/io.vertx/vertx-core/2.0.0-final/source/f5bdac7f28b948ee762eb6bbf760fa233e9ec578/vertx-core-2.0.0-final-sources.jar

./.gradle/caches/artifacts-23/filestore/io.vertx/vertx-core/2.0.0-final/jar/7b19f7e13bbb57cf3fd996008a11b56f1a5e9221/vertx-core-2.0.0-final.jar

./.gradle/caches/artifacts-23/filestore/io.vertx/vertx-core/2.0.0-final/pom/497faa4b1868ab3da6c84e911821710598751991/vertx-core-2.0.0-final.pom

./.gradle/caches/artifacts-24/module-metadata/io.vertx/vertx-core

./.gradle/caches/artifacts-24/filestore/io.vertx/vertx-core

./.gradle/caches/artifacts-24/filestore/io.vertx/vertx-core/2.0.0-final/source/f5bdac7f28b948ee762eb6bbf760fa233e9ec578/vertx-core-2.0.0-final-sources.jar

./.gradle/caches/artifacts-24/filestore/io.vertx/vertx-core/2.0.0-final/jar/7b19f7e13bbb57cf3fd996008a11b56f1a5e9221/vertx-core-2.0.0-final.jar

./.gradle/caches/artifacts-24/filestore/io.vertx/vertx-core/2.0.0-final/pom/497faa4b1868ab3da6c84e911821710598751991/vertx-core-2.0.0-final.pom

./.IdeaIC12/system/jars/vertx-core-2.0.0-final-sources.jar.b1c0531d

./.IdeaIC12/system/jars/vertx-core-2.0.0-final.jar.afc6d5e

./.IdeaIC12/system/jars/vertx-core-2.0.0-final.jar.517fd79d

./.IdeaIC12/system/jars/vertx-core-2.0.0-final-sources.jar.be8e5b7e

So, as far as I can tell, there's nowhere to place the Logback JARs (or at least I cannot figure out where).

If you've created your project from the Gradle template you'll find a directory called platform_lib:

https://github.com/vert-x/vertx-gradle-template/tree/master/src/main/platform_lib

Any stuff there will be added to the Vert.x classpath

(There's a README there too)

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.

[jo...@insightfullogic.com]

I am not sure how this has worked.

The included modules classloader does not appear to be used to load classes by the individual verticals classloader. Looking at the code of ModuleClassLoader it only uses the included modules classloader to reference resources but not to load classes. This means that when in a vertical you put `LoggerFactory.getLogger(FooVerticle.class)` the LoggerFactory is loaded by the verticals classloader and not the classloader of the included module, as are all its dependant classes, and logback reinitialises again as it cannot see the previously initialised static instances.

I cant see how this approach could work at the moment.

Thanks

John

[Tim Fox]

On 27/02/14 14:57, jo...@insightfullogic.com wrote:

I am not sure how this has worked.

The included modules classloader does not appear to be used to load classes by the individual verticals classloader. Looking at the code of ModuleClassLoader it only uses the included modules classloader to reference resources but not to load classes.

That's not correct, it's certainly used for classes too.

This means that when in a vertical you put `LoggerFactory.getLogger(FooVerticle.class)` the LoggerFactory is loaded by the verticals classloader and not the classloader of the included module, as are all its dependant classes, and logback reinitialises again as it cannot see the previously initialised static instances.

I cant see how this approach could work at the moment.

If you can push an example that doesn't work to github somewhere, I can take a look soon and see what the problem is.

[John Oliver]

Yes, I have tracked down the issue, due to some bad packaging I had the logback dependencies on the classpath of the vertical. So when it was asked to load the class it did so from its own classloader as opposed to delegating to the included module.

As before this was fixed by setting all the scopes to provided so that they are not bundled up.

Thanks

John

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/Mh7nIHru1Zk/unsubscribe.
To unsubscribe from this group and all of its topics, send an email to vertx+un...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

-- 
John Oliver

[Georg Grütter]

Would you mind sharing infos on your setup, John? It still doesn't work for me and I have all logback related dependencies with scope provided, except in the included module.

Thanks in advance,

Georg

[John Oliver]

Hay, I built a non-runnable module, it is at https://github.com/johnoliver/vertx-logback so you can take a look yourself.

for the sake of ease I will call this `vertx-logback`

All it does is take in a URL to the logback.xml file and configures logback from it.

Then in the mod.json of the module in which I want logging I have:

```
"includes": "com.insightfullogic~vertx-logback~1.0.0",
```

This imports `vertx-logback` which has the logback jar in it.

Since I want `vertx-logback`s classloader to load the logback classes they cannot be available in the modules dependencies/libs otherwise it will load it and not `vertx-logback`. So I add to the modules pom.xml:

```

        <dependency>

            <groupId>com.insightfullogic</groupId>

            <artifactId>vertx-logback</artifactId>

            <version>1.0.0</version>

            <scope>provided</scope>

        </dependency>

        <dependency>

            <groupId>ch.qos.logback</groupId>

            <artifactId>logback-classic</artifactId>

            <version>1.0.13</version>

            <scope>provided</scope>

        </dependency>

        <dependency>

            <groupId>ch.qos.logback</groupId>

            <artifactId>logback-core</artifactId>

            <version>1.0.13</version>

            <scope>provided</scope>

        </dependency>

```

This ensures those libraries are not bundled up into the libs dir.

Finally when the module starts I need to call logback with the right configuration file. So in my modules main class I have:


```
public class Starter extends Verticle {

    static {
        configureLogback();
    }
   
    private static void configureLogback() {
            URL config = Starter.class.getClassLoader().getResource("logback.xml");
            ConfigureLogback.configureLogging(config);
    }

```

So when the class is first loaded by Vert.x, it gets the config file then calls ConfigureLogback that is in `vertx-logback`, in order to set it up. After that everything just worked.

Let me know if you have any issues. Also `vertx-logback` can probably be improved, if anyone has any ideas let me know, or give it a pull request. I can also release it up to maven central if there is any interest.

Thanks

John

--

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/Mh7nIHru1Zk/unsubscribe.
To unsubscribe from this group and all of its topics, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

-- 
John Oliver

[Georg Grütter]

Thanks a lot for the detailed info, John. It's much appreciated. I'm still trying to get your module to work with my project and still failing. I'll strip down everything and post anything I learned here. Might take me a couple of days, though.

[Jeremy Truelove]

So I cloned your project and built it and installed it locally in my maven repo, I put a logback.xml in my platform_lib directory which should get it on the classpath if I'm remembering correctly but I get this exception 

SEVERE: Failed in deploying module

java.lang.NoClassDefFoundError: ch/qos/logback/core/joran/spi/JoranException

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

at java.lang.Class.privateGetDeclaredConstructors(Class.java:2658)

at java.lang.Class.getConstructor0(Class.java:2964)

at java.lang.Class.newInstance(Class.java:403)

at org.vertx.java.platform.impl.java.JavaVerticleFactory.createVerticle(JavaVerticleFactory.java:57)

at org.vertx.java.platform.impl.DefaultPlatformManager$21.run(DefaultPlatformManager.java:1740)

at org.vertx.java.core.impl.DefaultContext$3.run(DefaultContext.java:175)

at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:370)

at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:353)

at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)

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

Caused by: java.lang.ClassNotFoundException: ch.qos.logback.core.joran.spi.JoranException

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

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

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

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

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

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

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

... 11 more

Aug 14, 2014 11:15:03 AM org.vertx.java.core.logging.impl.JULLogDelegate error

SEVERE: Failed in deploying module

java.lang.NoClassDefFoundError: ch/qos/logback/core/joran/spi/JoranException

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

at java.lang.Class.privateGetDeclaredConstructors(Class.java:2658)

at java.lang.Class.getConstructor0(Class.java:2964)

at java.lang.Class.newInstance(Class.java:403)

at org.vertx.java.platform.impl.java.JavaVerticleFactory.createVerticle(JavaVerticleFactory.java:57)

at org.vertx.java.platform.impl.DefaultPlatformManager$21.run(DefaultPlatformManager.java:1740)

at org.vertx.java.core.impl.DefaultContext$3.run(DefaultContext.java:175)

at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:370)

at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:353)

at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)

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

Caused by: java.lang.ClassNotFoundException: ch.qos.logback.core.joran.spi.JoranException

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

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

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

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

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

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

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

... 11 more

I have this in my build.gradle file in the dependencies section

 provided "com.insightfullogic:vertx-logback:1.0.1-SNAPSHOT"

  provided "ch.qos.logback:logback-classic:1.0.13"

  provided "ch.qos.logback:logback-core:1.0.13"

and this in my modules mod.json file

 "includes": "com.insightfullogic~vertx-logback~1.0.1-SNAPSHOT"

Am I missing something else? I'm running my module from intellij. This code from your example is in my vertical file

static {

        configureLogback();

    }

    private static void configureLogback() {

        URL config = Starter.class.getClassLoader().getResource("logback.xml");

        try {

            ConfigureLogback.configureLogging(config);

        }

        catch (JoranException ex) {

            System.out.println(ex);

[Dean Pehrsson-Chapman]

It is on the platform classpath,  but is logback?  Logback needs to be available to the platform,  not the module.

To unsubscribe from this group and all its topics, send an email to vertx+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jeremy Truelove]

Yeah so logback jars weren't on the classpath, I thought that perhaps the vertx-logback jar was including them internally but when I checked it wasn't. So I pointed intellij at the lib folder under the mods folder of vertx-logback. What is the standard way to do this, I was assuming (probably incorrectly) that when I included this module in my module it would do the right thing as far as pulling in the dependencies? Is it just assumed you'll have a bash script that launches the vertx process and makes the classpath correctly?

[Alexander Lehmann]

the vertx script does not use the platform_lib directory I think, so you have to put the logging jars into $VERTX_HOME/lib and the config into $VERTX_HOME/conf

[John Oliver]

Did you put the vertx-logback-1.0.0-SNAPSHOT-mod.zip file in your repo? And does vertx access that repo? This includes the logback dependency so I believe should make it available to the verticle.

Thanks

John

[Jeremy Truelove]

The zip is in the repo. In the vertx home dir the conf/repos.txt contains the line 'mavenLocal:~/.m2/repository' which should make it look at my local repo where I installed it. I'm running it in intellij with the main class pointed at the vertx starter class and the following program arguments

runmod [myPackage]~[myModule]~1.0.0-final -cp out/production/[myModule]

should I be including the mods dir in the classpath there as well? I tried the following which didn't work either

runmod [myPackage]~[myModule]~1.0.0-final -cp "out/production/[myModule]:mods/com.insightfullogic~vertx-logback~1.0.1-SNAPSHOT:mods/com.insightfullogic~vertx-logback~1.0.1-SNAPSHOT/lib"

--

[Tim Fox]

What are you trying to achieve here? Run a module from intelliJ?

If so there is a gradle template or Maven plugin for this...

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.

[Jeremy Truelove]

Yeah I used the gradle template for this, and as I've made the changes to add in the other vertx-logback module I re-ran './gradlew idea' as the instructions mention. Everything builds fine and I have my module using his vertx-logback module but the only way to get it running in intellij is manually add the libs to the classpath for logback and the vertx-logback jar. When I specify them with the -cp flag to the run arguments in the run config it doesn't work.

However when I run these same arguments from the command line it does work. ie:

vertx runmod [myPackage]~[myModule]~1.0.0-final -cp "out/production/[myModule]:mods/com.insightfullogic~vertx-logback~1.0.1-SNAPSHOT:mods/com.insightfullogic~vertx-logback~1.0.1-SNAPSHOT/lib"

I was just planning on documenting the setup and submitting a pull requests for his project with an updated README so others could easily use it too and maybe get it published up on maven central.

[Maciej Żerkowski]

And if you use fat jar - all Vertx stuff embedded within the jar and would like to use Logback - how to do this?

I have fat jar with couple of modules, some of them are mine, some not. I have also the Logback non running module - only dependencies:
    compile "org.slf4j:slf4j-api:1.7.6"
    compile "ch.qos.logback:logback-classic:1.1.2"
    compile "org.slf4j:jcl-over-slf4j:1.7.6"
    compile "ch.qos.logback:logback-access:1.1.2"
and logback.xml in this module.
And this module is included in all the modules I wrote. And it works fine - logging from these modules. But what about other modules (not written by me and just added as compile within dependency closure) that for example use BusModeBase.logger for logging purposes - how to force them to use Logback?

BTW: Do I have to include this logback module in each of the modules that are still in the same jar?

[Nick Scavelli]

I believe you would just setup logback for vertx (not a module) and all modules using the vertx logger would use logback.xml.

[Maciej Żerkowski]

And how to do that - setup logback for vertx?
There is no vert.x installation in the system - just this jar.

[krana...@gmail.com]

Could you solve this issue setting up logback for vertx having just a fat-jar? 

I'm having the same scenario right now and don't know how to solve it. 

[Maciej Żerkowski]

That worked for me:
>java -Dorg.vertx.logger-delegate-factory-class-name=org.vertx.java.core.logging.impl.SLF4JLogDelegateFactory -jar xxx-web-mod-1.0.0-fat.jar -conf conf.json

I have also logback related jars in src/resources/platform_lib folder.