Topic
  • 3 replies
  • Latest Post - ‏2013-09-06T12:50:28Z by ChrisVignola
mgn2009
mgn2009
15 Posts

Pinned topic WAS administrative client program on WLP

‏2013-08-28T10:40:50Z |

I'm trying to develop a WAS administrative client program and deploy it on WLP. A web application will use the com.ibm.websphere.management.AdminClient class to interact with WAS Job Manager and Dmgr.

A simple standalone java program works correctly (e.g. the one described here in the InfoCenter). However, there are many conflicts when I try to integrate it with the web application and deploy on WLP. I used the com.ibm.ws.admin.client_8.5.0.jar library and the following features:

<featureManager>

    <feature>jsp-2.2</feature>

    <feature>localConnector-1.0</feature>

    <feature>jpa-2.0</feature>

    <feature>cdi-1.0</feature>

    <feature>ejbLite-3.1</feature>

    <feature>jaxrs-1.1</feature>

    <feature>appSecurity-2.0</feature>

    <feature>wab-1.0</feature>

</featureManager>

The class not found exceptions refer to the classes and libraries located under java_1.7_64(IBM)\jre\lib\:

rt.jar -> e.g. HostnameVerifier.class

ibmjgssfw.jar

ibmorbapi.jar

xml.jar ->  e.g. DocumentBuilderFactoryImpl.class, Node.class

I already tried to:

 - change the classloader delegation to parentLast  and I got these additional warnings:

 [WARNING ] CWNEN0070W: The javax.ws.rs.PathParam annotation class will not be recognized because it was loaded from the file ...

 - define a shared library with those jar files,

- or place them under WEB-INF\lib.

In the end, I got the following exception:

 java.lang.ClassCastException: org.apache.xerces.jaxp.DocumentBuilderFactoryImpl incompatible with javax.xml.parsers.DocumentBuilderFactory

Which libraries should I use to connect to the from WLP to WAS Dmgr with com.ibm.websphere.management.AdminClient?  

  • ChrisVignola
    ChrisVignola
    3 Posts

    Re: WAS administrative client program on WLP

    ‏2013-08-30T03:43:14Z  

    Wow!  That's a great scenario - but can you believe we've never actually tried it ourselves?!   I know, I know ...  the incredulity is staggering :)   Anyway, we've re-created your setup and are studying what's going amiss with the class loaders.  We hope to have an answer for you soon.   

  • mgn2009
    mgn2009
    15 Posts

    Re: WAS administrative client program on WLP

    ‏2013-08-30T13:07:34Z  

    Wow!  That's a great scenario - but can you believe we've never actually tried it ourselves?!   I know, I know ...  the incredulity is staggering :)   Anyway, we've re-created your setup and are studying what's going amiss with the class loaders.  We hope to have an answer for you soon.   

    Thanks for your comment.
    In the end, I created an OSGi application instead of JEE and then placed the com.ibm.ws.admin.client_8.5.0.jar library under WEB-INF/lib. The application needs to import the following packages: 
    javax.management,
    javax.naming,
    javax.net.ssl,
    javax.security.auth.callback,
    javax.security.auth.login,
    javax.xml.parsers,
    org.ietf.jgss,
    org.omg.CORBA,
    org.w3c.dom,
    org.xml.sax,
    org.xml.sax.ext,
    org.xml.sax.helpers
  • ChrisVignola
    ChrisVignola
    3 Posts

    Re: WAS administrative client program on WLP

    ‏2013-09-06T12:50:28Z  
    • mgn2009
    • ‏2013-08-30T13:07:34Z
    Thanks for your comment.
    In the end, I created an OSGi application instead of JEE and then placed the com.ibm.ws.admin.client_8.5.0.jar library under WEB-INF/lib. The application needs to import the following packages: 
    javax.management,
    javax.naming,
    javax.net.ssl,
    javax.security.auth.callback,
    javax.security.auth.login,
    javax.xml.parsers,
    org.ietf.jgss,
    org.omg.CORBA,
    org.w3c.dom,
    org.xml.sax,
    org.xml.sax.ext,
    org.xml.sax.helpers

    Well, you're still out ahead of us :)   We tried a JEE application and ran into the same sort of issues that you did.  We tried the admin jar under WEB-INF/lib,  under wlp/lib,  and via a shared library.  We also tried some variations with classloader order.   All cases resulted in one set of class loading issues or another.  The bottom line is we have some duplicate/conflicting classes exposed between the admin jar and in the Liberty runtime, and we cannot eliminate them for a JEE application without reegineering the admn jar.  We then thought like you did:   create an OSGi application.   We were just about to start that then came back to look at your post.   We thought we would have to convert the admin jar to an OSGi bundle to eliminate the class loading conflicts.  Based on your results it appears that may not be necessary.  We are glad you found a way to do this on your own and thanks for sharing.  We are going to try out the OSGi application ourselves and then decide if it's something we formally support.  Thanks again.