( 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 <[email protected]>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 <[email protected] > >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 <[email protected] > >wrote: > > > >> On Fri, Oct 30, 2009 at 6:45 AM, Benson Margulies < > [email protected] > >> >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 > >> > > > > >
