maven-tomcat-plugin and the 'system' classpath

[bimargulies]

I've hit what seems to be a problem with classpath management with the maven-tomcat-plugin.

I have a webapp that includes xercesImpl 2.9.1.

It includes some code that builds a DOM tree with XML Schema validation turned on.

This all works fine when the code is run in a POJO unit test.

Run from inside the webapp by tomcat:run, it fails. The failure mode seems to result from the use of a strange hybrid of building JDK JAXP classes and the xerces classes.

I eventually got my code to work by introducing the JAXP 1.4 APIs to the webapp and then calling the newInstance(...) methods that allow me to very explicitly specify Xerces.

My theory here is that the 'system' classpath of tomcat in the plugin is maven's classpath, not the project's classpath or a clean classpath. There's some loopy old version of xml-apis or something else on that classpath causing all this chaos.

I suggest that the plugin should load tomcat, insofar as possible, in a clean classloader, or even a classloader with the same things in it as show up by default in the lib directory of the relevant version of tomcat.

[Olivier Lamy]

Hi,
Yes the plugin classLoader is used to start tomcat because tomcat
dependencies comes from the plugin dependencies.
What we could do is to create a classLoader with all tomcat deps (ones
with groupId : org.apache.tomcat ) and start tomcat with.
But as I don't have any sample project it's difficult to work on this.
Can you record an issue in http://jira.codehaus.org/browse/MTOMCAT ?
(and include a test project which reproduce the issue)


Thanks,
--
Olivier

2009/10/29 Benson Margulies <bimargulies@...>:

> I've hit what seems to be a problem with classpath management with the
> maven-tomcat-plugin.
>
> I have a webapp that includes xercesImpl 2.9.1.
>
> It includes some code that builds a DOM tree with XML Schema validation
> turned on.
>
> This all works fine when the code is run in a POJO unit test.
>
> Run from inside the webapp by tomcat:run, it fails. The failure mode seems
> to result from the use of a strange hybrid of building JDK JAXP classes and
> the xerces classes.
>
> I eventually got my code to work by introducing the JAXP 1.4 APIs to the
> webapp and then calling the newInstance(...) methods that allow me to very
> explicitly specify Xerces.
>
> My theory here is that the 'system' classpath of tomcat in the plugin is
> maven's classpath, not the project's classpath or a clean classpath. There's
> some loopy old version of xml-apis or something else on that classpath
> causing all this chaos.
>
> I suggest that the plugin should load tomcat, insofar as possible, in a
> clean classloader, or even a classloader with the same things in it as show
> up by default in the lib directory of the relevant version of tomcat.
>
>
>

--
Olivier

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[bimargulies]

Can do.

On Fri, Oct 30, 2009 at 5:49 PM, Olivier Lamy <olamy@...> wrote:

Hi,
Yes the plugin classLoader is used to start tomcat because tomcat
dependencies comes from the plugin dependencies.
What we could do is to create a classLoader with all tomcat deps (ones
with groupId : org.apache.tomcat ) and start tomcat with.
But as I don't have any sample project it's difficult to work on this.
Can you record an issue in http://jira.codehaus.org/browse/MTOMCAT ?
(and include a test project which reproduce the issue)


Thanks,
--
Olivier

2009/10/29 Benson Margulies <bimargulies@...>:

> I've hit what seems to be a problem with classpath management with the
> maven-tomcat-plugin.
>
> I have a webapp that includes xercesImpl 2.9.1.
>
> It includes some code that builds a DOM tree with XML Schema validation
> turned on.
>
> This all works fine when the code is run in a POJO unit test.
>
> Run from inside the webapp by tomcat:run, it fails. The failure mode seems
> to result from the use of a strange hybrid of building JDK JAXP classes and
> the xerces classes.
>
> I eventually got my code to work by introducing the JAXP 1.4 APIs to the
> webapp and then calling the newInstance(...) methods that allow me to very
> explicitly specify Xerces.
>
> My theory here is that the 'system' classpath of tomcat in the plugin is
> maven's classpath, not the project's classpath or a clean classpath. There's
> some loopy old version of xml-apis or something else on that classpath
> causing all this chaos.
>
> I suggest that the plugin should load tomcat, insofar as possible, in a
> clean classloader, or even a classloader with the same things in it as show
> up by default in the lib directory of the relevant version of tomcat.
>
>
>

--
Olivier

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[bimargulies]

In trying to set up a test case, I seem to have hit MTOMCAT-6. dependency:tree shows no sign of the wrong servlet apis. I've got the geronimo servet api artifact in my project.

On Fri, Oct 30, 2009 at 5:49 PM, Olivier Lamy <olamy@...> wrote:

Hi,
Yes the plugin classLoader is used to start tomcat because tomcat
dependencies comes from the plugin dependencies.
What we could do is to create a classLoader with all tomcat deps (ones
with groupId : org.apache.tomcat ) and start tomcat with.
But as I don't have any sample project it's difficult to work on this.
Can you record an issue in http://jira.codehaus.org/browse/MTOMCAT ?
(and include a test project which reproduce the issue)


Thanks,
--
Olivier

2009/10/29 Benson Margulies <bimargulies@...>:

> I've hit what seems to be a problem with classpath management with the
> maven-tomcat-plugin.
>
> I have a webapp that includes xercesImpl 2.9.1.
>
> It includes some code that builds a DOM tree with XML Schema validation
> turned on.
>
> This all works fine when the code is run in a POJO unit test.
>
> Run from inside the webapp by tomcat:run, it fails. The failure mode seems
> to result from the use of a strange hybrid of building JDK JAXP classes and
> the xerces classes.
>
> I eventually got my code to work by introducing the JAXP 1.4 APIs to the
> webapp and then calling the newInstance(...) methods that allow me to very
> explicitly specify Xerces.
>
> My theory here is that the 'system' classpath of tomcat in the plugin is
> maven's classpath, not the project's classpath or a clean classpath. There's
> some loopy old version of xml-apis or something else on that classpath
> causing all this chaos.
>
> I suggest that the plugin should load tomcat, insofar as possible, in a
> clean classloader, or even a classloader with the same things in it as show
> up by default in the lib directory of the relevant version of tomcat.
>
>
>

--
Olivier

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

[bimargulies]

Never mind that. MTOMCAT-39 is your test case.

On Fri, Oct 30, 2009 at 7:03 PM, Benson Margulies <bimargulies@...> wrote:

In trying to set up a test case, I seem to have hit MTOMCAT-6. dependency:tree shows no sign of the wrong servlet apis. I've got the geronimo servet api artifact in my project.

On Fri, Oct 30, 2009 at 5:49 PM, Olivier Lamy <olamy@...> wrote:

Hi,
Yes the plugin classLoader is used to start tomcat because tomcat
dependencies comes from the plugin dependencies.
What we could do is to create a classLoader with all tomcat deps (ones
with groupId : org.apache.tomcat ) and start tomcat with.
But as I don't have any sample project it's difficult to work on this.
Can you record an issue in http://jira.codehaus.org/browse/MTOMCAT ?
(and include a test project which reproduce the issue)


Thanks,
--
Olivier

2009/10/29 Benson Margulies <bimargulies@...>:

> I've hit what seems to be a problem with classpath management with the
> maven-tomcat-plugin.
>
> I have a webapp that includes xercesImpl 2.9.1.
>
> It includes some code that builds a DOM tree with XML Schema validation
> turned on.
>
> This all works fine when the code is run in a POJO unit test.
>
> Run from inside the webapp by tomcat:run, it fails. The failure mode seems
> to result from the use of a strange hybrid of building JDK JAXP classes and
> the xerces classes.
>
> I eventually got my code to work by introducing the JAXP 1.4 APIs to the
> webapp and then calling the newInstance(...) methods that allow me to very
> explicitly specify Xerces.
>
> My theory here is that the 'system' classpath of tomcat in the plugin is
> maven's classpath, not the project's classpath or a clean classpath. There's
> some loopy old version of xml-apis or something else on that classpath
> causing all this chaos.
>
> I suggest that the plugin should load tomcat, insofar as possible, in a
> clean classloader, or even a classloader with the same things in it as show
> up by default in the lib directory of the relevant version of tomcat.
>
>
>

--
Olivier

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email