Jboss library conflicts

[sebastiaan...@gmail.com]

I hava a short question about the libraries that come with PWM. When deploying PWM inside JBOSS 5.1.-GA, you'll endup with a library conflict on:

- /lib/jaxb-impl.jar
- /lib/endorsed/jaxb-api.jar

This is because PWM comes with:

- jaxb-api-2.2.4.jar
- jaxb-impl-2.2.4-1.jar

Before spending a lot of time on setting up a custom class loader in JBOSS to circumvent this, I was wondering why PWM comes with those libraries and is it safe to delete them from WEB_INF/lib and use the JBOSS provided libraries?

[Menno Pieters]

They come with PWM because PWM uses them and the preferred application server (Tomcat) does not include these libraries.

Does JBoss refuse to start PWM with these libraries? If not, just leave them in there. If so, check which is the most up to date and choose that one. It's been a long time since I've used JBoss, but I know that some application servers (like Websphere) have options to determine which libraries (either application server's or application's) take preference.

Regards,

Menno

--
You received this message because you are subscribed to the Google Groups "pwm-general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pwm-general...@googlegroups.com.
To post to this group, send email to pwm-g...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pwm-general/30064437-3549-4b3d-bf7a-2496012ed515%40googlegroups.com?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.

[sebastiaan...@gmail.com]

Yup, JBoss refuses to start PWM with these conflicts, so I need to resolve that first. Jboss has a way to provide a custom class loader and domain isolation to to determine which libraries are loaded first, but it requires at least a PhD to get it going ;)

I guess the most easies way is to delete the jar files from PWM, because PWM will be deployed in a shared JBoss application cluster where other applications are already deployed. Simply deleting the JBoss libraries is therefore not an option for me.

JBoss 5.0.1-GA ships with version 2.1.9 for both libraries, which are older than the PWM provided libraries. Also I'm stuck too this JBoss version due to other dependencies (i.e. Novell User Application).

Probably a tough question, but what is the minimum version of jaxb-api and jaxb-impl for PWM?

[Jason Rivard]

Dropping those libraries seems to let PWM run fine in tomcat, so that may be an option.  More testing needed.  

However I tried in JBoss 6.1 and dropping those libraries has no effect, the web services do not function.   Most of these libraries are there in theory to support Jersey.  I mostly didn't know what I was doing when I added them so if they are unnessary or there is a better way to do it we can change it.  

Menno is right though, it has to work in Tomcat above all.  JBoss support is secondary.

[sebastiaan...@gmail.com]

Thanks for sharing your experiences, I appreciate it.

About JBoss 6.1: probably a typo:

"However I tried in JBoss 6.1 and dropping those libraries has no effect, the web services do not function."

You mean "has effect", right?

I'll do some testing and will share my results. In the worst case, I'll dive into custom class loading ;)

[Jason Rivard]

Nope, it had no effect.  I still had the same errors about invalid classes and jersey not finding resources.  I think it's different issues from JBoss5 where you are seeing some difference.  It seems every major release of JBoss they change the classloader strategy and apps break in entirely new ways :)

To view this discussion on the web visit https://groups.google.com/d/msgid/pwm-general/454099cd-bd57-4999-b83d-a89cdb6f71d0%40googlegroups.com?hl=en-US.

[sebastiaan...@gmail.com]

I did some tests this morning an I ended up with the same problem as you described: Jersey can not find the necessary resources

2013-05-29 09:57:40,296 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/pwm].[Jersey REST Service]] (http-0.0.0.0-8180-7) Servlet.service() for servlet Jersey REST Service threw exception
java.lang.ClassNotFoundException: org.codehaus.jackson.xc.JaxbAnnotationIntrospector from BaseClassLoader@a224a4{VFSClassLoaderPolicy@113af36{name=vfsfile:/opt/novell/idm/jboss/server/IDMProv/deploy/pwm.war/ domain=ClassLoaderDomain@343190{name=vfsfile:/opt/novell/idm/jboss/server/IDMProv/deploy/pwm.war/ parentPolicy=AFTER_BUT_JAVA_BEFORE parent=ClassLoaderDomain@1283052{DefaultDomain}} roots=[MemoryContextHandler@22291092[path= context=vfsmemory://3o6d166y-6b7l1r-hha7twur-1-hha7z00u-zy real=vfsmemory://3o6d166y-6b7l1r-hha7twur-1-hha7z00u-zy]
...


I tested with two scenarios:

- removing the conflicting libraries from the pwm.war
- defining a JBoss custom class loader to isolate the pwm.war

Both options result into the same issue. I hope somebody else is running PWM inside JBoss and could give some advice on how to get it running.

[sebastiaan...@gmail.com]

Did some further digging: it seems like PWM is missing the optional XC Jackson lib. It seems taht only the first connection to REST results in the ClassNotFoundException.

See http://stackoverflow.com/questions/10860142/appengine-java-jersey-jackson-jaxbannotationintrospector-noclassdeffounderror

After adding http://repo1.maven.org/maven2/org/codehaus/jackson/jackson-xc/1.9.2/jackson-xc-1.9.2.jar to WEB-INF lib, REST seems to be working correctly :)

I'll update this thread if I come up with some new findings.

[matt...@gmail.com]

Just as a general addition to the thread, this application seems to work much better on JBoss 7.1. This probably shouldn't be too surprising, since 7 comes with a much better class loading system.

Thought I would throw it out there for anyone who is curious!

[Jason Rivard]

My testing isn't going so well.  I'm not sure what version im actually using though, this is very confusing: The download page is titled, JBoss Application Server 7, the Version line says Version 6.1.0 Final, EAP build from AS7, and IntelliJ detects it as "JBoss 7.2.0-Final-redhat-8", and the folder explodes to "jboss-eap-6.1".  Is this 7 or 6.1?  As far as I can tell its the latest version on the jboss website.

Anyway, with this version, PWM seems to run except the webservices don't work.  You'll see lots of exceptions and classloader errors in the log.  Interactive changepassword, health, and helpdesk screens will all be broken.

I tried adding the library "jackson-xc-1.9.2" Sebastiaan mentioned in his post but it made no difference for me.  What version of JBoss did that work for you on Sebastiaan ?

Matt if this is the same version your using what did you do get it to work?

[matt...@gmail.com]

The JBoss versioning is a little crazy it seems. EAP 6.1 is actually based on JBoss 7.1, so you are running an environment that is similar as far as this application would be concerned.

I did jump the gun a little bit in what I was saying. I did get the application to deploy, but as you said, it still has some issues. I think I have gotten past most of it with some tweaking to JBoss and the application. The main point of my changes was to get JBoss to allow the application to use its own jax library rather than its own. Here is what I did:

Added "jboss-deployment-structure.xml" to the WEB-INF folder with the following content:

<jboss-deployment-structure>
<deployment>
<!-- Exclusions allow you to prevent the server from automatically adding some dependencies -->
<exclusions>
<module name="org.jboss.as.jaxrs" />
<module name="org.jboss.resteasy" />
<module name="org.jboss.resteasy.resteasy-atom-provider" />
<module name="org.jboss.resteasy.resteasy-cdi" />
<module name="org.jboss.resteasy.resteasy-jaxrs" />
<module name="org.jboss.resteasy.resteasy-jaxb-provider" />
<module name="org.jboss.resteasy.resteasy-jackson-provider" />
<module name="org.jboss.resteasy.resteasy-jsapi" />
<module name="org.jboss.resteasy.resteasy-multipart-provider" />
<module name="org.jboss.resteasy.async-http-servlet-30" />
</exclusions>
</deployment>
</jboss-deployment-structure>

Added the following to web.xml:

<context-param>
<param-name>resteasy.scan</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<param-name>resteasy.scan.providers</param-name>
<param-value>false</param-value>
</context-param>
<context-param>
<param-name>resteasy.scan.resources</param-name>
<param-value>false</param-value>
</context-param>

Commented the following in web.xml:

<!-- <init-param> -->
<!-- <param-name>com.sun.jersey.config.property.packages</param-name> -->
<!-- <param-value>password.pwm.ws.server.rest</param-value> -->
<!-- </init-param> -->

Commented the following in the JBoss standalone.xml:

<subsystem xmlns="urn:jboss:domain:jaxrs:1.0"/>

So far, the REST endpoints seem to be working, though I have more testing to do.

[matt...@gmail.com]

I should add that I don't know if all of those changes are necessary, so we can probably look at figuring out what exactly is needed.

[Jason Rivard]

Soungs great!  Although modifying the JBoss standalone.xml sounds pretty undesirable, I wonder if there is a way to avoid that.

On Mon, Jun 3, 2013 at 6:39 PM, <matt...@gmail.com> wrote:

I should add that I don't know if all of those changes are necessary, so we can probably look at figuring out what exactly is needed.

--
You received this message because you are subscribed to the Google Groups "pwm-general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pwm-general...@googlegroups.com.
To post to this group, send email to pwm-g...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pwm-general/6a8dc76d-761c-435a-acca-935c098c96f9%40googlegroups.com?hl=en-US.

[sebastiaan...@gmail.com]

So far, I took a different approach with 5.1.0 GA. I did two things to get the frontend working:

- added a JBoss custom class loader to isolate the the PWM app from the JBoss share/ endorsed libraries:

<?xml version="1.0" encoding="UTF-8"?>
<classloading xmlns="urn:jboss:classloading:1.0"
parent-first="false"
domain="DefaultDomain"
top-level-classloader="true"
parent-domain="Ignored"
export-all="NON_EMPTY"
import-all="true">
</classloading>


- added the lib jackson-xc-1.9.2, to prevent a ClassNotFoundException for the first REST call.

Those two changes give a working frontend, but the backend is still a mess:

- editing an existing configuration invalidates the configuration
- creating a new configuration invalidates the configuration
- I'm seeing a wide spectrum of different Exceptions

[matt...@gmail.com]

On Monday, June 3, 2013 5:00:37 PM UTC-6, Jason Rivard wrote:
> Soungs great!  Although modifying the JBoss standalone.xml sounds pretty undesirable, I wonder if there is a way to avoid that.
>

It looks like I didn't need to edit the standalone.xml after all. The combination of module exclusions in the deployment descriptor and changes to the web.xml seems to have done the trick.

Going to the /public/rest/health URL works this way, and I'll know more once it's all configured.

I will note that this is for SSPR, the NetIQ version, but I don't see anything in PWM that would be different in this regard.