Develop Reference

Upgrading gwt from 2.1.1 to 2.8.0: ServiceConfigurationError: org.apache.juli.logging.Log: Provider org.eclipse.jetty.apache.jsp.JuliLog not a subtype

After upgrading gwt from version 2.1.1 to 2.8.0, I got the error message
2017-04-20 12:59:19.551:WARN:oejuc.AbstractLifeCycle:main: FAILED c.g.g.d.s.j.WebAppContextWithReload#341fbaf1{/,file:/C:/Users/xxx/.IntelliJIdea2017.1/system/gwt/xxx.97baa614/xxx.fdf824a8/run/www/,STARTING}{C:\Users\xxx\.IntelliJIdea2017.1\system\gwt\xxx.97baa614\xx.fdf824a8\run\www}: java.util.ServiceConfigurationError: org.apache.juli.logging.Log: Provider org.eclipse.jetty.apache.jsp.JuliLog not a subtype
java.util.ServiceConfigurationError: org.apache.juli.logging.Log: Provider org.eclipse.jetty.apache.jsp.JuliLog not a subtype
I found some other posts with similar messages, like this or this, but the situation seems to be different:
I do not use Maven or Ant, just pure IntelliJ, I have no reference to any Tomcat library, and I am not aware of any JSP in our application.
I found through debugging that first the class loader com.google.gwt.dev.shell.jetty.Jettylauncher$WebAppContextWithReload$WebAppClassLoaderExtension loads class org.eclipse.jetty.apache.jsp.JuliLog including interface org.apache.juli.logging.Log.
Then, later interface org.apache.juli.logging.Log is loaded by sun.misc.Launcher$AppClassLoader triggered indirectly by
org.eclipse.jetty.webapp.WebAppContext.startContext()
which calls method initialize of an
org.eclipse.jetty.jsp.JettyJspServlet
instance.
I have no idea why a JspServlet needs to be initialized at all, as no JSPs are used in the application, as far as I see, just a few Servlets. And it seems all the classes involved in this conflict are contained in the single jar gwt-dev.jar, so I see no possibility to influence any class loading behavior via class path settings.
Any idea how I could resolve this?

I also got this error upgrading from gwt from version 2.4 to 2.8.2.
Jake W's answer helped me.
To solve this, I ran a maven dependency tree on my project to figure out what was referencing jetty's apache-jsp.
To run the dependency tree, in Eclipse I created a new run configuration -> maven build -> with the goals "dependency:tree -Doutput=/dependency/file.txt". Once it's run, the console output will show where it saves the output. It should be the same location that you referenced with the -Doutput option.
Look for something like this in the output file:
- org.eclipse.jetty:apache-jsp:jar:9.2.14.v20151106:compile
And then look up in the tree to see where it's being pulled in from. In my case it came from this:
+- com.google.gwt:gwt-dev:jar:2.8.2:compile
+- net.sourceforge.htmlunit:htmlunit:jar:2.19:compile
\- org.eclipse.jetty:apache-jsp:jar:9.2.14.v20151106:compile
Once you know where it's coming from, (assuming you're using maven) you can add an exclusion in your pom.xml file for it:
</dependencies>
<dependency>
<groupId>com.google.gwt</groupId>
<artifactId>gwt-dev</artifactId>
<version>${gwt.version}</version>
<exclusions>
<exclusion>
<groupId>org.eclipse.jetty</groupId>
<artifactId>apache-jsp</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
This worked for me. Thanks :)

I saw this error when I recently upgraded to GWT 2.8.0. Please try to exclude jetty-apache-Jsp related dependencies from your project.
You may see other jetty related issues as well, so please also make sure you are using exactly the same jetty version as GWT 2.8.0 is using.
I'm on mobile at the moment, unable to add more details, but I hope that can be a useful direction to go. Please add your comments if you still see issues, I will then have a look and update the answer when I'm on my laptop.

I have just ran into this exception after adding gwt-test-utils:0.53 dependency (with GWT 2.8.1)

I am using ant and all information found regarding this error indicated there was 2 versions of Juli Logging in the classpath, but every search came up with only gwt-dev.jar. Production builds worked fine, but dev mode did not which needs gwt-dev.jar.
Part of the build process has the jars copied from a local lib directory to war/WEB-INF/lib to pack into the war. The ant script points to the local lib directory for debugging, not the ones meant for the war file. Despite the war location not being listed in the ant file as a class path, it was still loading it.
Ultimately, gwt-dev.jar was conflicting with the copied version of itself.

Issue in getImageWritersByFormatName for Tiff. Getting image writer

I am trying to convert PDF to tif images. I use following code to get the image writers by format.
Iterator<ImageWriter> writers = ImageIO.getImageWritersByFormatName("TIFF");
if (writers == null || !writers.hasNext()) {
throw new ImageWritingException();
}
This works fine when I run the application standalone in Eclipse. But when I deploy the application to tomcat server in linux, writers==null is false but !writers.hasNext is true resulting to throw Exception.
I use maven to build the project to war.
I have following dependencies in the pom file.
<dependency>
<groupId>org.icepdf</groupId>
<artifactId>icepdf-core</artifactId>
</dependency>
<dependency>
<groupId>com.sun.media</groupId>
<artifactId>jai_imageio</artifactId>
</dependency>
<dependency>
<groupId>com.sun.media</groupId>
<artifactId>jai-codec</artifactId>
</dependency>
<dependency>
<groupId>javax.media</groupId>
<artifactId>jai_core</artifactId>
</dependency>
What can be the difference between two environments? How can I fix this issue?

I met the same issue and found the root cause.
Let me summarize first, the issue does not occur in eclipse on dev machine, and it occurs on Tomcat server.
The root cause is that the imageio uses SPI, and there is a basic implementation in JDK (please refer to rt.jar, we can find it with two plugins for bmp and jpeg.) while the plugins we wants are in jai_imageio.jar.
With default configuration, Tomcat scans the one in rt.jar for plugins during initialization for ImageIO. Later when the application runs, the jai_imageio.jar won't be scanned.
As a result the plugins in jai_imageio.jar are not available. When running in dev machine, jai_imageio.jar is scanned.
There are several solutions as listed below, i would recommend the first one as it fits the design intention of ImageIO.
without changing the tomcat default configuration, re-scan the jar.
static {
ImageIO.scanForPlugins();
}
changing the tomcat configuration, so tomcat won't initialize ImageIO.
edit file /conf/server.xml，add appContextProtection="false" like following:
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" appContextProtection="false" />
With suchconfiguration, tomcat won't call ImageIO.getCacheDirectory in JreMemoryLeakPreventionListener, so ImageIO is not initialized until our codes runs.

Tiff support is provided by the Java Advanced Imaging plugin jai_core.jar.
In order to work correctly, the jar file needs to be added to the JVM's ext directory, otherwise it won't register properly

Got my writer like this :
TIFFImageWriterSpi tiffSpi = new TIFFImageWriterSpi();
ImageWriter imageWriter = tiffSpi.createWriterInstance();

SLF4J and LogBack configuration in GWT (Eclipse and Jetty)

I've made an app init function that I'm using both in Java and GWT applications. I have external logback.xml file that I'm setting the path to the "logback.configurationFile" System property. In pure Java projects, all works as expected, but not in GWT projects.
I've implemented my ServletContextListener and in method contextInitialized I'm setting the System property. Logback does not read it, but falls back to basic (red letters in console).
So, I tried to follow instructions from logback configuration
LoggerContext context = (LoggerContext) LoggerFactory.getILoggerFactory();
to reconfigure Logback, but that throws
java.lang.ClassCastException: org.slf4j.impl.SimpleLoggerFactory cannot be cast to ch.qos.logback.classic.LoggerContext
I also tried to put logback.xml in folders: src, war, war/WEB_INF, but it doesn't read it.
I'm switching to slf4j because previous log4j started to throw many "class not found" exceptions (something with commons-logging)
The question is:
What is wrong?
or
How can I get sfl4j (logback) to read the external configuration XML file?
or
How can I get sfl4j (logback) to read any configuration XML file?
Help appreciated
EDIT: Tried to use log4j adapter with slf4j, and it doesn't work either.
EDIT2: I reverted back to pure log4j that didn't work before. However, I added log4j.jar directly in "Installed JRE" in Eclipse in the main system JRE and now the pure log4j works. What seems to me is that there is quite a difference between the OpenJDK and the Sun's JDK, and that is causing problems. I'll try to fix this slf4j issue in a few days. Maybe there is also a need for some jar on some weird place.
EDIT3: slf4j now works with log4j, but I have to manually configure it. Doesn't matter where I put log4j.xml, it doesn't read it. Looks like classloader problem with Sun's JDK. I'll try with Logback soon. It might be similar problem.

I have logback working in my gwt,eclipse, jetty projects. works quite well. Kind of worked out of the box. I am using maven. What I did is:
add slf4j-api and logback as a dependencies.
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.6.4</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.0.0</version>
</dependency>
in my code I get a logger by using:
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
protected Logger log = LoggerFactory.getLogger(this.getClass());
The logback.xml is in my src/main/resources folder. This way it will be placed in target/myproject/WEB-INF/classes after beeing compiled.
Hope this will help you.

There are a number of possible configurations with jetty, slf4j, and logback.
It really depends on what you are trying to accomplish.
1) Having the webapp itself do its own logging to logback.
2) Having a global log at the server level that logs the server events and webapp events to logback.
3) Having a global logback configuration at the server level that creates a log file for the server and individual log files for each webapp.
To accomplish #1, you just have to put the slf4j and logback files in your webapp's WEB-INF/lib directory and deploy the webapp. (be sure you put the configuration files in the webapps WEB-INF/classes or WEB-INF/ directory)
To accomplish #2 and #3 you need to let jetty know that slf4j and logback should be exposed to all webapps, and that all webapps, regardless of the existence of their own (potential) slf4j and logback jars, they are to always use the jar files from the server.
This is done by manipulating the WebAppContext's list of systemClasses and serverClasses via the default web
Slf4j is permitted through the webapp classloader barrier on Jetty, but logback is not.
This can be defined statically in the context/*.xml deployable, or dynamically via a DeploymentManager binding. see the jetty-webapp-logging module on jetty.codehaus.org for details on how to accomplish this (I would link you do this, but codehaus is undergoing a server migration ATM)
So, i gist'd the relevant file here - https://gist.github.com/1409147
package org.mortbay.jetty.webapp.logging;
import org.eclipse.jetty.deploy.App;
import org.eclipse.jetty.deploy.AppLifeCycle;
import org.eclipse.jetty.deploy.graph.Node;
import org.eclipse.jetty.server.handler.ContextHandler;
import org.eclipse.jetty.webapp.WebAppContext;
public class CentralizedWebAppLoggingBinding implements AppLifeCycle.Binding
{
#Override
public String[] getBindingTargets()
{
return new String[]
{ "deploying" };
}
#Override
public void processBinding(Node node, App app) throws Exception
{
ContextHandler handler = app.getContextHandler();
if (handler == null)
{
throw new NullPointerException("No Handler created for App: " + app);
}
if (handler instanceof WebAppContext)
{
WebAppContext webapp = (WebAppContext)handler;
webapp.addSystemClass("org.apache.log4j.");
webapp.addSystemClass("org.slf4j.");
webapp.addSystemClass("org.apache.commons.logging.");
}
}
}
To accomplish #3 you'll need to setup a slf4j MDC handler and sift logging in logback that uses the MDC information to route the appropriate logging event to the logfile of your choice.
I blogged about this at http://webtide.intalio.com/2011/08/sifting-logs-in-jetty-with-logback/ and have example projects for basic logback, sifted logback, and even how to use the logback-access module for NCSA access logging at https://github.com/jetty-project/jetty-and-logback-example

Logback looks for its configuration files in the classpath, not in the file system.
To get to a configuration file in the file system, use file inclusion as described at http://logback.qos.ch/manual/joran.html#fileInclusion. Note that the filename can refer to an environment variable if it makes it easier to point to the file system location of the file.

I am also faced the same problem, found slf4j-simple.jar in the pom/class path. Once it was removed, working fine.

Strange jboss console error

I'm creating additional module to already multi-module maven project. And for this one I want everything to be like in other modules(meaning dependencies) just to test hello world, then I'll go do some more complex stuff. And it does print hello world as it should when deployed onto jboss server, but I get some strange error on console, had anyone had similar experience? and how can I fix it? Here it is :
15:48:35,789 ERROR [STDERR] log4j:ERROR A "org.jboss.logging.appender.FileAppender" object is not assignable to a "org.apache.log4j.Appender" variable.
15:48:35,789 ERROR [STDERR] log4j:ERROR The class "org.apache.log4j.Appender" was loaded by
15:48:35,790 ERROR [STDERR] log4j:ERROR [BaseClassLoader#9a8d9b{vfszip:/C:/jboss-5.1.0.GA/server/default/deploy/new-module-0.0.1-SNAPSHOT.war/}] whereas object of type
15:48:35,790 ERROR [STDERR] log4j:ERROR "org.jboss.logging.appender.FileAppender" was loaded by [org.jboss.bootstrap.NoAnnotationURLClassLoader#506411].
15:48:35,790 ERROR [STDERR] log4j:ERROR Could not instantiate appender named "FILE".
Here is the part of Appender xml
http://pastebin.com/X7Dgdrki

First check your <server>/conf/jboss-log4j.xml for the configuration of the appender named FILE (and post it here if you can - that may give us more clues).
Further investigation reveals that org.jboss.logging.appender.FileAppender actually implements the interface org.apache.log4j.Appender. So this is apparently a classloader conflict. The same class definition (in this case org.apache.log4j.Appender), when loaded by two different classloaders, counts as two distinct classes for the JVM.
Is log4j.jar included in your war, or in your server/lib directory? If so, you could try removing it and see whether it resolves the issue.
Update: Actually the easiest possible solution is to simply change the type of the appender to org.apache.log4j.FileAppender in jboss-log4j.xml.
Regarding log4j.jar, what I mean is that if it is present in your war, it (and a copy of org.apache.log4j.Appender) gets loaded by the war classloader (BaseClassLoader#9a8d9b in your error message). And this causes the classloader conflict. So if you do not deploy log4j.jar with your war, the error may go away. This is related to Maven only in that the dependency is configured in your pom. For this little experiment, you can simply remove the log4j.jar from your war by hand; if this solves the issue, configure the log4j dependency in your pom as "provided", e.g.:
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.12</version>
<scope>provided</scope>
</dependency>
If log4j.jar is not in your war, it might still be in the server/default/lib directory - please check that and if it is there, try to remove it.

We recently came across this problem. We tried the suggestions above and they did not work. So we handled the problem by replacing all log4j imports with a abstract logging interface (we chose org.apache.commons.logging for this) and removing the log4j from the depdenancies. Then what happens is the actual underlying logging implementation supports whatever JBoss has set. And if we want to move back to Tomcat (without JBoss) we can just add the log4j jar or whatever logger implementation back into the war.

Disabling logging for jetty run from maven

I downloaded a big framework which I need to built from source. The project uses a maven build structure, and includes a demo application which can be viewed with an embedded jetty. Maven plugins handle all this stuff.
However when I run the demo application (with mvn jetty:run), I can't really use it because for some reason logging on the DEBUG level is turned on and the application spends most of its time logging a lot of statements. Responsiveness is reduced to almost nothing.
The framework (geomajas 1.5.0) seems to use SLF4J, but I can't figure out where it is configured or where it can be turned off.
Any ideas welcome... thanks!
Update:
Apparently they use logback. I found the configuration file (logback.xml), in which I edited out the DEBUG levels and replaced them with ERROR
To make sure the changes would propagate, I cleaned the project and rebuilt it. But the issue remains!
I manually looked at the logback.xml files in the target folder, and they've updated. But I still see the log records!
Update 2
I'm on Windows 7 btw.

The simplest and most straight forward way to disable logging would be indeed to use the NOP binding. To do so, edit geomajas/geomajas-dojo-example/pom.xml and change the logging dependencies into:
<!-- logging dependencies, delegate all to slf4j and use logback -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.5.8</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-nop</artifactId>
<version>1.5.8</version>
</dependency>
And run mvn jetty:run.

looking at this slf4j manual/overview http://www.slf4j.org/manual.html it looks like you could turn off all logging by using the slf4j NOP jar (slf4j-nop-1.5.10.jar). So you'd probably need to find and replace the current slf4j implementation jar in your projects WEB-INF/lib folder with the NOP jar.
Though most likely it's using a log4j implementation, if that's the case you'd need to find the log4j.xml or log4j.properties and edit/remove them. They could be tricky to find though - first look in WEB-INF/classes and then in some sort of config directory would be a good start.
EDIT {
A bit ugly but if you just want to get it up and running as fast as possible you could redirect stdout and stderr to /dev/null which should make it a bit faster as it won't be writing to disk or console:
mvn jetty:run > dev/null 2>&1
}
HTH

Try to find out a log4j configuration (if it is used for logging) - that might be log4j.xml (or log4j.properties) file. If you remove this file from classpath there will be no logging at all. If you want to reduce level of logs try to comment out some logger sections in this file, like e.g.
<!--<logger name="org.hibernate">
<level value="debug"/>
<appender-ref ref="hibernate-file"/>
</logger>-->
For this example there will be no logs for classes from org.hibernate package.

Geomajas uses logback for the sample applications. You can configure the logging using the logback.xml file in src/main/resources.
Switching everything off can be done using a config file like:
<configuration>
<root>
<level value="OFF"/>
</root>
</configuration>
Kind regards,
Joachim