We're updating the issue view to help you get more done. 

Deployment on glassfish

Description

This is actually a problem on glassfish side (in my opinion)
see http://docs.oracle.com/cd/E19798-01/821-1752/6nmndgmhp/index.html
Under Delegation:
The Java Servlet specification recommends that a web module's class loader look in the local class loader before delegating to its parent. You can make this class loader follow the delegation inversion model in the Servlet specification by setting delegate="false" in the class-loader element of the sun-web.xml file. It is safe to do this only for a web module that does not interact with any other modules.

So the openRDF war files will deploy fine on a vanilla install of glassfish. But, when you have an existing installation that has your own or other apps running, you might run into classpath problems as the openRDF wars does not act as a self contained unit as expected.

In my case, we want to use the java.util.logger impl for slf4j (for our apps). But as soon as I add it to the glassfish lib folder, openRDF fail (open rdf for some reason explicitly cast to logback impl):

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

We have 50+ apps, so I do not want add the lib in each war file, but rather in the glassfish lib.

Because of the delegation (as mentioned above) in glassfish, the classloader loads the slf4j impl from the lib folder first before the one in the war is loaded.

As I understand the intention of the openRDF wars is to have a self contained unit, so it should not be a problem to add a sun-web.xml in the WEB-INF folder of both war files (openrdf and workbench) to correct the delegation ?

Here the sun-web.xml
<?xml version="1.0" encoding="UTF-8"?>
<sun-web-app>
<class-loader delegate="false"/>
</sun-web-app>

This fix the issue for me, but now I have to "patch" the war files on every upgrade. I would assume other people might experience similar issues ?

It still warns in the log that there are multiple slf4j implementations, but it seems to pick the correct one now.

As I see it there are two solutions.
1) openRDF remove dependency on a specific slf4J implementation and allow the deplorer to choose one (that is the idea of slf4j)
2) openRDF include the sun-web.xml in the distribution.

Anyway. Please let me know what you think.

Thanks !

Phillip Kruger
http://thumbtribe.mobi/info

Environment

Linux, Glassfish (3.1.1 and 3.1.2.2)

Status

Assignee

JeenB

Reporter

Phillip Kruger

Labels

Fix versions

Priority

Minor