tracking down jetty/tomcat dependencies

[bimargulies]

I've got code that works fine when run as a pojo and fails when run in a
webapp, either via tomcat:run or jetty:run. I suspect, because I can't think
of anything else, that there is detritus in the 'system' classpaths of these
containers. However, mvn dependency:tree does not tell me much about the
maven-jetty-plugin. Neither does dependency:resolve-plugins.

Is there some way to get a clearer view of this question?

[javabrett]

On Fri, Oct 30, 2009 at 6:45 AM, Benson Margulies <bimargulies@...>wrote:

> I've got code that works fine when run as a pojo and fails when run in a
> webapp, either via tomcat:run or jetty:run. I suspect, because I can't
> think
> of anything else, that there is detritus in the 'system' classpaths of
> these
> containers. However, mvn dependency:tree does not tell me much about the
> maven-jetty-plugin. Neither does dependency:resolve-plugins.
>
> Is there some way to get a clearer view of this question?
>

What is the mode of failure?

Brett

[bimargulies]

I wrote it up on the mojo user list once I got a clearer picture, but here
goes again.

The code calls DocumentBuilderFactory and SchemaFactory to parse an XML file
to DOM with schema validation. Run in the plugins, it fails with an
impossible validation error (a claim that a valid attribute is invalid). The
backtrace shows a combination of xerces and JDK classes. I have xerces in
the webapp's class path.

The same code works fine, with or without xerces, run as a pojo or a junit
test.

If I try to use 100% Xerces by referring to their implementation classes
(DocumentBuilderImpl and XMLSchemaFactory) it still fails in the plugins.

The problem goes away if I use the new JAXP 1.4 APIs to force the use of
Xerces.

I reason as follows: in a live copy of tomcat or jetty, the 'system'
classpath is whatever jars are sitting in the containers system library
directory. When these plugins deploy a webapp, they don't have a system
library directory. They instead have whatever classpath maven invokes them
with, based on their declared dependencies and the transitive closure that
reaches into plexus and such. There could easily be some ancient xml-apis
jar in there, or some other source of interference, which I am not
preempting in my webapp.

If dependency:tree worked for a plugin classpath, then I might be able to
figure out the real source of the problem and fix it by tinkering with
dependencies on the plugin. But I can't figure out how to get a full tree
for maven-tomcat-plugin (e.g.).

On Thu, Oct 29, 2009 at 10:32 PM, Brett Randall <javabrett@...> wrote:

> On Fri, Oct 30, 2009 at 6:45 AM, Benson Margulies <bimargulies@...
> >wrote:
>
> > I've got code that works fine when run as a pojo and fails when run in a
> > webapp, either via tomcat:run or jetty:run. I suspect, because I can't
> > think
> > of anything else, that there is detritus in the 'system' classpaths of
> > these
> > containers. However, mvn dependency:tree does not tell me much about the
> > maven-jetty-plugin. Neither does dependency:resolve-plugins.
> >
> > Is there some way to get a clearer view of this question?
> >
>
> What is the mode of failure?
>
> Brett
>

[bimargulies]

I'm still wishing that someone could help me figure out just what is on the
classpath inside of tomcat:run.

To a first approximation, jetty:run and tomcat:run had the same problem.
However, I was a able to cure it in jetty and not in tomcat. It LOOKS as if
tomcat is depending on an old version of Xalan.


On Fri, Oct 30, 2009 at 5:16 AM, Benson Margulies <bimargulies@...>wrote:

> I wrote it up on the mojo user list once I got a clearer picture, but here
> goes again.
>
> The code calls DocumentBuilderFactory and SchemaFactory to parse an XML
> file to DOM with schema validation. Run in the plugins, it fails with an
> impossible validation error (a claim that a valid attribute is invalid). The
> backtrace shows a combination of xerces and JDK classes. I have xerces in
> the webapp's class path.
>
> The same code works fine, with or without xerces, run as a pojo or a junit
> test.
>
> If I try to use 100% Xerces by referring to their implementation classes
> (DocumentBuilderImpl and XMLSchemaFactory) it still fails in the plugins.
>
> The problem goes away if I use the new JAXP 1.4 APIs to force the use of
> Xerces.
>
> I reason as follows: in a live copy of tomcat or jetty, the 'system'
> classpath is whatever jars are sitting in the containers system library
> directory. When these plugins deploy a webapp, they don't have a system
> library directory. They instead have whatever classpath maven invokes them
> with, based on their declared dependencies and the transitive closure that
> reaches into plexus and such. There could easily be some ancient xml-apis
> jar in there, or some other source of interference, which I am not
> preempting in my webapp.
>
> If dependency:tree worked for a plugin classpath, then I might be able to
> figure out the real source of the problem and fix it by tinkering with
> dependencies on the plugin. But I can't figure out how to get a full tree
> for maven-tomcat-plugin (e.g.).
>
>
> On Thu, Oct 29, 2009 at 10:32 PM, Brett Randall <javabrett@...>wrote:
>
>> On Fri, Oct 30, 2009 at 6:45 AM, Benson Margulies <bimargulies@...
>> >wrote:
>>
>> > I've got code that works fine when run as a pojo and fails when run in a
>> > webapp, either via tomcat:run or jetty:run. I suspect, because I can't
>> > think
>> > of anything else, that there is detritus in the 'system' classpaths of
>> > these
>> > containers. However, mvn dependency:tree does not tell me much about the
>> > maven-jetty-plugin. Neither does dependency:resolve-plugins.
>> >
>> > Is there some way to get a clearer view of this question?
>> >
>>
>> What is the mode of failure?
>>
>> Brett
>>
>
>

[Antonio Parolini]

Hello,

config:
maven-eclipse-plugin 2.7
eclipse 3.4

We have a multiproject where the war module depends of EJB module.

On the WAR pom:

                <dependency>
                        <groupId>jade.framework.showcase</groupId>
                        <artifactId>showcase-ejb</artifactId>
                        <version>${pom.version}</version>
                        <type>ejb</type>
                </dependency>


When we run the task eclipse:clean eclipse:eclipse using the eclipse-maven-plugin, the "java EE Module Dependencies" of the WAR eclipse project is missing the dependency to the EJB module. We have add the check box by hand ( project properties/ java EE Module Dependencies/ check the checkbox of the ejb module), which is a bit of a pain.

This java EE dependence is important for the Webapp to work when run on our Eclipse configured Tomcat server.

I couldn't find any plugin option to switch this on automatically.

Thanks for your help.

antonio






-----Message d'origine-----
De : Benson Margulies [mailto:bimargulies@...]
Envoyé : mardi, 3. novembre 2009 11:53
À : PAROLINI Antonio; Maven Users List
Objet : Re: tracking down jetty/tomcat dependencies

I'm still wishing that someone could help me figure out just what is on the
classpath inside of tomcat:run.

To a first approximation, jetty:run and tomcat:run had the same problem.
However, I was a able to cure it in jetty and not in tomcat. It LOOKS as if
tomcat is depending on an old version of Xalan.


On Fri, Oct 30, 2009 at 5:16 AM, Benson Margulies <bimargulies@...>wrote:

> I wrote it up on the mojo user list once I got a clearer picture, but here
> goes again.
>
> The code calls DocumentBuilderFactory and SchemaFactory to parse an XML
> file to DOM with schema validation. Run in the plugins, it fails with an
> impossible validation error (a claim that a valid attribute is invalid). The
> backtrace shows a combination of xerces and JDK classes. I have xerces in
> the webapp's class path.
>
> The same code works fine, with or without xerces, run as a pojo or a junit
> test.
>
> If I try to use 100% Xerces by referring to their implementation classes
> (DocumentBuilderImpl and XMLSchemaFactory) it still fails in the plugins.
>
> The problem goes away if I use the new JAXP 1.4 APIs to force the use of
> Xerces.
>
> I reason as follows: in a live copy of tomcat or jetty, the 'system'
> classpath is whatever jars are sitting in the containers system library
> directory. When these plugins deploy a webapp, they don't have a system
> library directory. They instead have whatever classpath maven invokes them
> with, based on their declared dependencies and the transitive closure that
> reaches into plexus and such. There could easily be some ancient xml-apis
> jar in there, or some other source of interference, which I am not
> preempting in my webapp.
>
> If dependency:tree worked for a plugin classpath, then I might be able to
> figure out the real source of the problem and fix it by tinkering with
> dependencies on the plugin. But I can't figure out how to get a full tree
> for maven-tomcat-plugin (e.g.).
>
>
> On Thu, Oct 29, 2009 at 10:32 PM, Brett Randall <javabrett@...>wrote:
>
>> On Fri, Oct 30, 2009 at 6:45 AM, Benson Margulies <bimargulies@...
>> >wrote:
>>
>> > I've got code that works fine when run as a pojo and fails when run in a
>> > webapp, either via tomcat:run or jetty:run. I suspect, because I can't
>> > think
>> > of anything else, that there is detritus in the 'system' classpaths of
>> > these
>> > containers. However, mvn dependency:tree does not tell me much about the
>> > maven-jetty-plugin. Neither does dependency:resolve-plugins.
>> >
>> > Is there some way to get a clearer view of this question?
>> >
>>
>> What is the mode of failure?
>>
>> Brett
>>
>
>

[Sony Antony]

( IIRC xalan is used for xslt transformation. xerces is teh parser )

I think the war file is supposed to be self sufficient - meaning it should
contain all teh jar files/libraries application needs.
This is is what maven's war packaging does - it puts all the dependency
artifacts inside WEB-INF/lib directory of the war file.
( make sure none of the dependencies are given <scope>provided<scope> at teh
war's pom.xml. Did you check this ?

most of the app servers I know load the library from WEB-INF/lib first and
falls back on teh app server's classpath only if the class is not found
there.


ideally I would not want any of the classpath components inherited by teh
running container ( jetty/tomcat )
But I dont think there is a way to turn off this inheritance

--sony




On Tue, Nov 3, 2009 at 5:53 AM, Benson Margulies <bimargulies@...>wrote:

> I'm still wishing that someone could help me figure out just what is on the
> classpath inside of tomcat:run.
>
> To a first approximation, jetty:run and tomcat:run had the same problem.
> However, I was a able to cure it in jetty and not in tomcat. It LOOKS as if
> tomcat is depending on an old version of Xalan.
>
>
> On Fri, Oct 30, 2009 at 5:16 AM, Benson Margulies <bimargulies@...
> >wrote:
>
> > I wrote it up on the mojo user list once I got a clearer picture, but
> here
> > goes again.
> >
> > The code calls DocumentBuilderFactory and SchemaFactory to parse an XML
> > file to DOM with schema validation. Run in the plugins, it fails with an
> > impossible validation error (a claim that a valid attribute is invalid).
> The
> > backtrace shows a combination of xerces and JDK classes. I have xerces in
> > the webapp's class path.
> >
> > The same code works fine, with or without xerces, run as a pojo or a
> junit
> > test.
> >
> > If I try to use 100% Xerces by referring to their implementation classes
> > (DocumentBuilderImpl and XMLSchemaFactory) it still fails in the plugins.
> >
> > The problem goes away if I use the new JAXP 1.4 APIs to force the use of
> > Xerces.
> >
> > I reason as follows: in a live copy of tomcat or jetty, the 'system'
> > classpath is whatever jars are sitting in the containers system library
> > directory. When these plugins deploy a webapp, they don't have a system
> > library directory. They instead have whatever classpath maven invokes
> them
> > with, based on their declared dependencies and the transitive closure
> that
> > reaches into plexus and such. There could easily be some ancient xml-apis
> > jar in there, or some other source of interference, which I am not
> > preempting in my webapp.
> >
> > If dependency:tree worked for a plugin classpath, then I might be able to
> > figure out the real source of the problem and fix it by tinkering with
> > dependencies on the plugin. But I can't figure out how to get a full tree
> > for maven-tomcat-plugin (e.g.).
> >
> >
> > On Thu, Oct 29, 2009 at 10:32 PM, Brett Randall <javabrett@...
> >wrote:
> >
> >> On Fri, Oct 30, 2009 at 6:45 AM, Benson Margulies <
> bimargulies@...
> >> >wrote:
> >>
> >> > I've got code that works fine when run as a pojo and fails when run in
> a
> >> > webapp, either via tomcat:run or jetty:run. I suspect, because I can't
> >> > think
> >> > of anything else, that there is detritus in the 'system' classpaths of
> >> > these
> >> > containers. However, mvn dependency:tree does not tell me much about
> the
> >> > maven-jetty-plugin. Neither does dependency:resolve-plugins.
> >> >
> >> > Is there some way to get a clearer view of this question?
> >> >
> >>
> >> What is the mode of failure?
> >>
> >> Brett
> >>
> >
> >
>