JDOM WebSphere and the dreaded classpath

[oxymoron]

Hi folks, I would like to use JDOM in a plugin I'm writing for a websphere application. We're using WebSphere 6.0.2.7 and the application running on top of it is called xPression. xPression (a print/reporting server) can have user exits (basically a plugin) written in java a class which can be dynamically be loaded and used by the application.

I have written a user exit class that loads up an xml document in JDOM and then uses XPath to return specific bits of data from the xml. This is all works on the local machine in NetBeans with the jdom and necessary jars added to the project library.

When running on the server, I run into the problem where it cannot load the default SAXParser as it doesn't implement XMLParser. It appears that in my WebSphere classpath another (older) SAXParser is present. I have confirmed this by using a bit of code I found on the web which returns the url for a class - in this case, SAXParser is being loaded from the \java\jre\lib\xml.jar somewhere under the websphere home directory and not from the later version I placed on the server. I've added the jdom and its necessary lib jars to the end of websphere class path - I don't want to contaminate the server with newer versions of code as this will probably break xpression.

So... my question is around jars and manifest class path. What I am hoping is that I can add a manifest class path to the jdom jar which will override the websphere class path, therefore loading the correct version of SAXPath and other required jdom libs. This seems to be possible for jar apps but I'm not sure about class libraries in websphere?

Or perhaps someone can suggest another way I can override the WS classpath just for jdom?

In fact, can anyone suggest a way of being able to use XPath on my WS version without using an external java lib at all? Any help would be appreciated.

Cheers

Sam

[Sean Sullivan-3]

I was able to use jdom.jar in a web application in Websphere 6.0

@see http://www.jdom.org/pipermail/jdom-interest/2005-May/014856.html

Sean

On Thu, Jan 22, 2009 at 9:41 AM, oxymoron <sam_north@...> wrote:

>
> Hi folks, I would like to use JDOM in a plugin I'm writing for a websphere
> application. We're using WebSphere 6.0.2.7 and the application running on
> top of it is called xPression. xPression (a print/reporting server) can have
> user exits (basically a plugin) written in java a class which can be
> dynamically be loaded and used by the application.
>
> I have written a user exit class that loads up an xml document in JDOM and
> then uses XPath to return specific bits of data from the xml. This is all
> works on the local machine in NetBeans with the jdom and necessary jars
> added to the project library.
>
> When running on the server, I run into the problem where it cannot load the
> default SAXParser as it doesn't implement XMLParser. It appears that in my
> WebSphere classpath another (older) SAXParser is present. I have confirmed
> this by using a bit of code I found on the web which returns the url for a
> class - in this case, SAXParser is being loaded from the
> \java\jre\lib\xml.jar somewhere under the websphere home directory and not
> from the later version I placed on the server. I've added the jdom and its
> necessary lib jars to the end of websphere class path - I don't want to
> contaminate the server with newer versions of code as this will probably
> break xpression.
>
> So... my question is around jars and manifest class path. What I am hoping
> is that I can add a manifest class path to the jdom jar which will override
> the websphere class path, therefore loading the correct version of SAXPath
> and other required jdom libs. This seems to be possible for jar apps but I'm
> not sure about class libraries in websphere?
>
> Or perhaps someone can suggest another way I can override the WS classpath
> just for jdom?
>
> In fact, can anyone suggest a way of being able to use XPath on my WS
> version without using an external java lib at all? Any help would be
> appreciated.
>
> Cheers
>
> Sam
> --
> View this message in context: http://www.nabble.com/JDOM-WebSphere-and-the-dreaded-classpath-tp21589217p21589217.html
> Sent from the JDOM - General mailing list archive at Nabble.com.
>
> _______________________________________________
> To control your jdom-interest membership:
> http://www.jdom.org/mailman/options/jdom-interest/youraddr@...
>

_______________________________________________
To control your jdom-interest membership:
http://www.jdom.org/mailman/options/jdom-interest/youraddr@...

[oxymoron]

Unfortunately I can't take the existing IBM JDom out of the classpath as it is being used by the xPression application and I can't run the risk of breaking it. I would just use IBM's JDOM but the version supplied does not support XPath. What I require is a way of overriding the classpath just for my user exit code...

Sean Sullivan-3 wrote:

I was able to use jdom.jar in a web application in Websphere 6.0

@see http://www.jdom.org/pipermail/jdom-interest/2005-May/014856.html

Sean

On Thu, Jan 22, 2009 at 9:41 AM, oxymoron <[e-mail]> wrote:
>
> Hi folks, I would like to use JDOM in a plugin I'm writing for a websphere
> application. We're using WebSphere 6.0.2.7 and the application running on
> top of it is called xPression. xPression (a print/reporting server) can have
> user exits (basically a plugin) written in java a class which can be
> dynamically be loaded and used by the application.
>
> I have written a user exit class that loads up an xml document in JDOM and
> then uses XPath to return specific bits of data from the xml. This is all
> works on the local machine in NetBeans with the jdom and necessary jars
> added to the project library.
>
> When running on the server, I run into the problem where it cannot load the
> default SAXParser as it doesn't implement XMLParser. It appears that in my
> WebSphere classpath another (older) SAXParser is present. I have confirmed
> this by using a bit of code I found on the web which returns the url for a
> class - in this case, SAXParser is being loaded from the
> \java\jre\lib\xml.jar somewhere under the websphere home directory and not
> from the later version I placed on the server. I've added the jdom and its
> necessary lib jars to the end of websphere class path - I don't want to
> contaminate the server with newer versions of code as this will probably
> break xpression.
>
> So... my question is around jars and manifest class path. What I am hoping
> is that I can add a manifest class path to the jdom jar which will override
> the websphere class path, therefore loading the correct version of SAXPath
> and other required jdom libs. This seems to be possible for jar apps but I'm
> not sure about class libraries in websphere?
>
> Or perhaps someone can suggest another way I can override the WS classpath
> just for jdom?
>
> In fact, can anyone suggest a way of being able to use XPath on my WS
> version without using an external java lib at all? Any help would be
> appreciated.
>
> Cheers
>
> Sam
> --
> View this message in context: http://www.nabble.com/JDOM-WebSphere-and-the-dreaded-classpath-tp21589217p21589217.html
> Sent from the JDOM - General mailing list archive at Nabble.com.
>
> _______________________________________________
> To control your jdom-interest membership:
> http://www.jdom.org/mailman/options/jdom-interest/[e-mail]
>
_______________________________________________
To control your jdom-interest membership:
http://www.jdom.org/mailman/options/jdom-interest/[e-mail]

[oxymoron]

Well after a couple of weeks of trying different things and getting knowhere, I now have a solution that seems to work...

I moved my user exit classes in to the application's .ear folder. xPression uses JDOM throughout so I knew it must have been possible. It would seem that the .ear has it own "classpath" as such as even though the jdom.jar and associated libs are in there, they are not specified in the classpath or its manifest... I don't think the situation was helped by the fact that xPression loads the user exit class dynamically. Very weird stuff but I can now run xpath queries despite being limited to jdom 1.0.

Cheers

Sam

oxymoron wrote:

Hi folks, I would like to use JDOM in a plugin I'm writing for a websphere application. We're using WebSphere 6.0.2.7 and the application running on top of it is called xPression. xPression (a print/reporting server) can have user exits (basically a plugin) written in java a class which can be dynamically be loaded and used by the application.

I have written a user exit class that loads up an xml document in JDOM and then uses XPath to return specific bits of data from the xml. This is all works on the local machine in NetBeans with the jdom and necessary jars added to the project library.

When running on the server, I run into the problem where it cannot load the default SAXParser as it doesn't implement XMLParser. It appears that in my WebSphere classpath another (older) SAXParser is present. I have confirmed this by using a bit of code I found on the web which returns the url for a class - in this case, SAXParser is being loaded from the \java\jre\lib\xml.jar somewhere under the websphere home directory and not from the later version I placed on the server. I've added the jdom and its necessary lib jars to the end of websphere class path - I don't want to contaminate the server with newer versions of code as this will probably break xpression.

So... my question is around jars and manifest class path. What I am hoping is that I can add a manifest class path to the jdom jar which will override the websphere class path, therefore loading the correct version of SAXPath and other required jdom libs. This seems to be possible for jar apps but I'm not sure about class libraries in websphere?

Or perhaps someone can suggest another way I can override the WS classpath just for jdom?

In fact, can anyone suggest a way of being able to use XPath on my WS version without using an external java lib at all? Any help would be appreciated.

Cheers

Sam