You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Alexander Klimetschek <al...@mindquarry.com> on 2006/11/22 11:08:34 UTC
Problem with JAXP and shielding (was Re: Shielded class loading between
blocks)
Alexander Klimetschek schrieb:
> IMHO this might happen any time again and having the flexibility of
> classloading in Java is perfect for solving those problems. I have
> implemented that shielded groups stuff in the old
> BootstrapClassLoaderManager, right now, I am writing on a
> ShieldingBlockServlet as a proof of concept and to be up-to-date with
> the cocoon trunk.
The new ShieldingBlockServlet works except for one annoying thing: when
serving JSPs I get this exception:
java.lang.ClassCastException:
org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
(see full stacktrace below at the end of the mail).
This actually worked before when I used the shielding classloading stuff
from cocoon-bootstrap, i.e. exactly the same shielded classloading code
as used for the shielding of cocoon, only with an additional lib/
directory inside the block.
Now I have a ShieldingBlockServlet which is like the current
o.a.c.maven.deployer.servlet.ShieldingServlet and it uses the
o.a.c.classloader.DefaultClassLoader, which is setup only with lib and
classes directory from the block (well, this might be different to the
previous case, where also the standard WEB-INF/lib etc. were set, but
IIRC they couldn't be found anyway, since they were looked up from the
BlockContext).
The classloader hierarchy also seems to be ok, my DefaultClassLoader has
the o.a.c.maven.deployer.servlet.ShieldedClassLoader as parent and that
one has the WebappClassLoader as its parent.
With a look at Carsten ;-), what could be wrong?
Alex
The full stacktrace:
java.lang.ClassCastException:
org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
at
javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:98)
at
org.apache.jasper.xmlparser.ParserUtils.parseXMLDocument(ParserUtils.java:188)
at
org.apache.jasper.compiler.JspConfig.processWebDotXml(JspConfig.java:110)
at org.apache.jasper.compiler.JspConfig.init(JspConfig.java:282)
at org.apache.jasper.compiler.JspConfig.findJspProperty(JspConfig.java:347)
at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:220)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:620)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:602)
at
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:618)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:329)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:440)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:335)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.cocoon.components.jsp.JSPEngineImpl.executeJSP(JSPEngineImpl.java:74)
at org.apache.cocoon.reading.JSPReader.generate(JSPReader.java:115)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.core.container.spring.avalon.PoolableFactoryBean$ProxyHandler.invoke(PoolableFactoryBean.java:349)
at $Proxy5.generate(Unknown Source)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processReader(AbstractProcessingPipeline.java:649)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:429)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.cocoon.core.container.spring.avalon.PoolableFactoryBean$ProxyHandler.invoke(PoolableFactoryBean.java:349)
at $Proxy4.process(Unknown Source)
at
org.apache.cocoon.components.treeprocessor.sitemap.ReadNode.invoke(ReadNode.java:94)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:55)
at
org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:87)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:152)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:93)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:239)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:170)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:232)
at
org.apache.cocoon.servlet.RequestProcessor.process(RequestProcessor.java:397)
at
org.apache.cocoon.servlet.RequestProcessor.service(RequestProcessor.java:162)
at org.apache.cocoon.sitemap.SitemapServlet.service(SitemapServlet.java:61)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.cocoon.blocks.BlockContext$PathDispatcher.forward(BlockContext.java:529)
at
org.apache.cocoon.blocks.BlockContext$PathDispatcher.forward(BlockContext.java:511)
at
org.apache.cocoon.blocks.ShieldingBlockServlet.service(ShieldingBlockServlet.java:136)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.cocoon.blocks.DispatcherServlet.service(DispatcherServlet.java:127)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.cocoon.maven.deployer.servlet.ShieldingServlet.service(ShieldingServlet.java:95)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:445)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1050)
at
com.mindquarry.webapp.servlet.AuthenticationFilter.doFilter(AuthenticationFilter.java:216)
at
org.apache.cocoon.maven.deployer.servlet.ShieldingServletFilter.doFilter(ShieldingServletFilter.java:50)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1041)
at
org.apache.cocoon.servlet.multipart.MultipartFilter.doFilter(MultipartFilter.java:104)
at
org.apache.cocoon.maven.deployer.servlet.ShieldingServletFilter.doFilter(ShieldingServletFilter.java:50)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1041)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:354)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:226)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:627)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:149)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:123)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:141)
at org.mortbay.jetty.Server.handle(Server.java:269)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:430)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:687)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:492)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:199)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:339)
at
org.mortbay.jetty.nio.HttpChannelEndPoint.run(HttpChannelEndPoint.java:270)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
--
Alexander Klimetschek
http://www.mindquarry.com
Re: Problem with JAXP and shielding (was Re: Shielded class loading
between blocks)
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> Daniel Fagerstrom wrote:
>> Yes, I think we should consider complicated class loading issues being
>> outside the scope of Cocoon 2.2.
> Yepp.
>
>> Right now I think that the main focus should be getting 2.2 release out
>> the door. What are the outstanding issues?
> As far as I can see, there are no outstanding *code* issues. The
> documentation needs some updates, but I think the most important topics
> are at least "covered". So we should just release the next milestone.
+1
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Re: Problem with JAXP and shielding (was Re: Shielded class loading
between blocks)
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Carsten Ziegeler skrev:
>> Daniel Fagerstrom wrote:
>>
> ...
>>> Right now I think that the main focus should be getting 2.2 release
>>> out the door. What are the outstanding issues?
>>>
>> As far as I can see, there are no outstanding *code* issues. The
>> documentation needs some updates,
> OK, so what are the outstanding documentation issues? We need to make a
> plan for what needs to be done for getting a good enough 2.2
> documentation (maybe there already is something like that?).
I created the structure of what I would expect at
http://cocoon.zones.apache.org/daisy/cdocs-core/.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Re: Problem with JAXP and shielding (was Re: Shielded class loading
between blocks)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler skrev:
> Daniel Fagerstrom wrote:
>
...
>> Right now I think that the main focus should be getting 2.2 release out
>> the door. What are the outstanding issues?
>>
> As far as I can see, there are no outstanding *code* issues. The
> documentation needs some updates,
OK, so what are the outstanding documentation issues? We need to make a
plan for what needs to be done for getting a good enough 2.2
documentation (maybe there already is something like that?).
> but I think the most important topics
> are at least "covered". So we should just release the next milestone.
>
+1
/Daniel
Re: Problem with JAXP and shielding (was Re: Shielded class loading between blocks)
Posted by Mark Lundquist <ml...@wrinkledog.com>.
On Nov 28, 2006, at 6:41 PM, Vadim Gritsenko wrote:
> Can the shielding be switched off by default? (unless it already is?)
> I don't think majority of users will ever need it.
...and wouldn't it be better if it were not a build-time option at all,
but a run-time option — if that's even possible? Any cocoon user
should be able to start from an archetype, whether they need the
shielding loader. I guess if that introduces too much complexity we
could still say, "if you need shielding classloading, you have to build
your own Cocoon from source..."
—ml—
Re: Problem with JAXP and shielding (was Re: Shielded class loading
between blocks)
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Carsten Ziegeler wrote:
> Vadim Gritsenko wrote:
>> Can the shielding be switched off by default? (unless it already is?) I don't
>> think majority of users will ever need it.
>
> Sure, just change the default setting of the boolean variable in the
> deploy plugin to false.
Done.
Vadim
Re: Problem with JAXP and shielding (was Re: Shielded class loading
between blocks)
Posted by Carsten Ziegeler <cz...@apache.org>.
Vadim Gritsenko wrote:
> Carsten Ziegeler wrote:
>> Daniel Fagerstrom wrote:
>>> Yes, I think we should consider complicated class loading issues being
>>> outside the scope of Cocoon 2.2.
>> Yepp.
>
> Can the shielding be switched off by default? (unless it already is?) I don't
> think majority of users will ever need it.
>
Sure, just change the default setting of the boolean variable in the
deploy plugin to false.
I don't care what the default is, as I don't use the plugin anyway.
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Problem with JAXP and shielding (was Re: Shielded class loading
between blocks)
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Carsten Ziegeler wrote:
> Daniel Fagerstrom wrote:
>> Yes, I think we should consider complicated class loading issues being
>> outside the scope of Cocoon 2.2.
> Yepp.
Can the shielding be switched off by default? (unless it already is?) I don't
think majority of users will ever need it.
Vadim
Re: Problem with JAXP and shielding (was Re: Shielded class loading
between blocks)
Posted by Carsten Ziegeler <cz...@apache.org>.
Daniel Fagerstrom wrote:
> Yes, I think we should consider complicated class loading issues being
> outside the scope of Cocoon 2.2.
Yepp.
>
> Right now I think that the main focus should be getting 2.2 release out
> the door. What are the outstanding issues?
As far as I can see, there are no outstanding *code* issues. The
documentation needs some updates, but I think the most important topics
are at least "covered". So we should just release the next milestone.
>
> Then we can start to work on using OSGi again.
:) Or use something different (just kidding) :)
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Problem with JAXP and shielding (was Re: Shielded class loading
between blocks)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler skrev:
> Daniel Fagerstrom wrote:
>
>> How would that work? Running an xslt-transformer within a block local
>> class loader (using an block local Xalan and Xerces) is one thing.
>> Exposing the xslt-transformer to the rest of the blocks is something
>> entirely different, we have no mechanism for that.
>>
> Oh yes, right - I didn't want to imply that we have something for that
> today, I just wanted to hint that this might be the better approach.
>
Agree.
>> To achieve this you need a mechanism where you can configure what
>> classes (or packages) that should be exported from a block classloader
>> and what should be local. You also need a mechanism for importing
>> classes to a block classloader from other block classloaders.
>>
>> We have nothing like this in Cocoon.
>>
> True, but isn't OSGi promissing exactly this?
Exactly :)
> Thinking about all these
> class loading issues it would be easier if Cocoon at the current state
> would not support anything for shielded loading and we would wait for
> the real implementation.
>
Yes, I think we should consider complicated class loading issues being
outside the scope of Cocoon 2.2.
Right now I think that the main focus should be getting 2.2 release out
the door. What are the outstanding issues?
Then we can start to work on using OSGi again.
/Daniel
Re: Problem with JAXP and shielding (was Re: Shielded class loading
between blocks)
Posted by Carsten Ziegeler <cz...@apache.org>.
Daniel Fagerstrom wrote:
>
> How would that work? Running an xslt-transformer within a block local
> class loader (using an block local Xalan and Xerces) is one thing.
> Exposing the xslt-transformer to the rest of the blocks is something
> entirely different, we have no mechanism for that.
Oh yes, right - I didn't want to imply that we have something for that
today, I just wanted to hint that this might be the better approach.
>
> To achieve this you need a mechanism where you can configure what
> classes (or packages) that should be exported from a block classloader
> and what should be local. You also need a mechanism for importing
> classes to a block classloader from other block classloaders.
>
> We have nothing like this in Cocoon.
True, but isn't OSGi promissing exactly this? Thinking about all these
class loading issues it would be easier if Cocoon at the current state
would not support anything for shielded loading and we would wait for
the real implementation.
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Problem with JAXP and shielding (was Re: Shielded class loading
between blocks)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler skrev:
...
> Definitly - now, what about adding the jasper engine to the classpath of
> the webapp
> by putting it in web-inf/lib?
>
> Looking at this scenario, I have the feeling that sooner or later you
> hit similar problems in other cases as well. As soon as you access
> something the container provides for you, you might end up with the same
> mess.
> So, perhaps we have to take a step back and think, why we think that
> shielded class loading is a great feature. One reason is commons logging
> (which should be solved with newer versions) and the other one is the
> endorsed problem with Xalan and Xerces as the most promintent candidates.
> Perhaps our blocks concept helps here? If our xslt transformer would be
> in its separate block using its own class loader with its own version of
> Xalan, the problem would be solved as well. Everything else could run in
> the webapp classloader.
How would that work? Running an xslt-transformer within a block local
class loader (using an block local Xalan and Xerces) is one thing.
Exposing the xslt-transformer to the rest of the blocks is something
entirely different, we have no mechanism for that.
To achieve this you need a mechanism where you can configure what
classes (or packages) that should be exported from a block classloader
and what should be local. You also need a mechanism for importing
classes to a block classloader from other block classloaders.
We have nothing like this in Cocoon.
/Daniel
Re: Problem with JAXP and shielding (was Re: Shielded class loading
between blocks)
Posted by Carsten Ziegeler <cz...@apache.org>.
Alexander Klimetschek wrote:
> The problem also exists without my ShieldingBlockServlet, I just tested
> serving jsps from a sitemap that is part of a normal cocoon webapp with
> shielding done by the deployer plugin and the same exception pops up
> upon requesting the jsp.
>
> The actual bug is that the cocoon-jsp block does not work with any kind
> of shielding, since it uses the jasper jsp engine provided by the webapp
> and that one expects its own JAXP implementation. The jasper jsp engine
> can be loaded, but during compiling of a jsp it tries to load some JAXP
> class, which fails, because that loading is done by the shielding
> classloader, which has another version of Xerces and xalan. (IIRC, the
> latter point is the reason for shielding anyway, since many
> transformation stuff done with cocoon sitemaps does not work with older
> XSLT implementations provided by the webapp container - some really
> annoying problem we already stepped into).
Yepp, you're right of course - so just forget my last answer.
>
> A solution to that kind of problem is not easy. The first idea would be
> to explicitly check for the classloader in the cocoon JSP component
> before executing the Jasper enginge, but how do you find out if you got
> a shielding classloader or not? You cannot cast, not for the
> ShieldingClassLoader which will be part of the maven-war-plugin you
> don't want to have a dependency to, and also not for the
> WebappClassLoader, because that one is webapp container specific (and
> there is no API for that in the servlet specs).
>
> So a dirty Hack would be to do a check like
>
> ClassLoader cl = this.getClass().getClassLoader();
> // step over all shielding class loaders to find the webapp classloader
> while (cl.getClass().getName().indexOf("Shielded")) {
> cl = cl.getParent();
> }
>
> // set cl as context classloader
> // start jsp engine
>
>
> Looks kinda ugly....
>
Definitly - now, what about adding the jasper engine to the classpath of
the webapp
by putting it in web-inf/lib?
Looking at this scenario, I have the feeling that sooner or later you
hit similar problems in other cases as well. As soon as you access
something the container provides for you, you might end up with the same
mess.
So, perhaps we have to take a step back and think, why we think that
shielded class loading is a great feature. One reason is commons logging
(which should be solved with newer versions) and the other one is the
endorsed problem with Xalan and Xerces as the most promintent candidates.
Perhaps our blocks concept helps here? If our xslt transformer would be
in its separate block using its own class loader with its own version of
Xalan, the problem would be solved as well. Everything else could run in
the webapp classloader.
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Problem with JAXP and shielding (was Re: Shielded class loading
between blocks)
Posted by Alexander Klimetschek <al...@mindquarry.com>.
Carsten Ziegeler schrieb:
> I guess you have a xerces version in your web-inf/lib /or
> web-inf/shielded/lib. So you have two versions in your classpath.
> Try removing your version (put it either in the endorsed lib if you need
> your own version), the same applies for xalan.
The problem also exists without my ShieldingBlockServlet, I just tested
serving jsps from a sitemap that is part of a normal cocoon webapp with
shielding done by the deployer plugin and the same exception pops up
upon requesting the jsp.
The actual bug is that the cocoon-jsp block does not work with any kind
of shielding, since it uses the jasper jsp engine provided by the webapp
and that one expects its own JAXP implementation. The jasper jsp engine
can be loaded, but during compiling of a jsp it tries to load some JAXP
class, which fails, because that loading is done by the shielding
classloader, which has another version of Xerces and xalan. (IIRC, the
latter point is the reason for shielding anyway, since many
transformation stuff done with cocoon sitemaps does not work with older
XSLT implementations provided by the webapp container - some really
annoying problem we already stepped into).
A solution to that kind of problem is not easy. The first idea would be
to explicitly check for the classloader in the cocoon JSP component
before executing the Jasper enginge, but how do you find out if you got
a shielding classloader or not? You cannot cast, not for the
ShieldingClassLoader which will be part of the maven-war-plugin you
don't want to have a dependency to, and also not for the
WebappClassLoader, because that one is webapp container specific (and
there is no API for that in the servlet specs).
So a dirty Hack would be to do a check like
ClassLoader cl = this.getClass().getClassLoader();
// step over all shielding class loaders to find the webapp classloader
while (cl.getClass().getName().indexOf("Shielded")) {
cl = cl.getParent();
}
// set cl as context classloader
// start jsp engine
Looks kinda ugly....
Alex
--
Alexander Klimetschek
http://www.mindquarry.com
Re: Problem with JAXP and shielding (was Re: Shielded class loading
between blocks)
Posted by Carsten Ziegeler <cz...@apache.org>.
I guess you have a xerces version in your web-inf/lib /or
web-inf/shielded/lib. So you have two versions in your classpath.
Try removing your version (put it either in the endorsed lib if you need
your own version), the same applies for xalan.
Carsten
Alexander Klimetschek wrote:
> Alexander Klimetschek schrieb:
>> IMHO this might happen any time again and having the flexibility of
>> classloading in Java is perfect for solving those problems. I have
>> implemented that shielded groups stuff in the old
>> BootstrapClassLoaderManager, right now, I am writing on a
>> ShieldingBlockServlet as a proof of concept and to be up-to-date with
>> the cocoon trunk.
>
> The new ShieldingBlockServlet works except for one annoying thing: when
> serving JSPs I get this exception:
>
> java.lang.ClassCastException:
> org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
>
> (see full stacktrace below at the end of the mail).
>
> This actually worked before when I used the shielding classloading stuff
> from cocoon-bootstrap, i.e. exactly the same shielded classloading code
> as used for the shielding of cocoon, only with an additional lib/
> directory inside the block.
>
> Now I have a ShieldingBlockServlet which is like the current
> o.a.c.maven.deployer.servlet.ShieldingServlet and it uses the
> o.a.c.classloader.DefaultClassLoader, which is setup only with lib and
> classes directory from the block (well, this might be different to the
> previous case, where also the standard WEB-INF/lib etc. were set, but
> IIRC they couldn't be found anyway, since they were looked up from the
> BlockContext).
>
> The classloader hierarchy also seems to be ok, my DefaultClassLoader has
> the o.a.c.maven.deployer.servlet.ShieldedClassLoader as parent and that
> one has the WebappClassLoader as its parent.
>
> With a look at Carsten ;-), what could be wrong?
>
>
> Alex
>
>
> The full stacktrace:
>
> java.lang.ClassCastException:
> org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
> at
> javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:98)
> at
> org.apache.jasper.xmlparser.ParserUtils.parseXMLDocument(ParserUtils.java:188)
> at
> org.apache.jasper.compiler.JspConfig.processWebDotXml(JspConfig.java:110)
> at org.apache.jasper.compiler.JspConfig.init(JspConfig.java:282)
> at org.apache.jasper.compiler.JspConfig.findJspProperty(JspConfig.java:347)
> at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:220)
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:620)
> at org.apache.jasper.compiler.Compiler.compile(Compiler.java:602)
> at
> org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:618)
> at
> org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:329)
> at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:440)
> at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:335)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
> at
> org.apache.cocoon.components.jsp.JSPEngineImpl.executeJSP(JSPEngineImpl.java:74)
> at org.apache.cocoon.reading.JSPReader.generate(JSPReader.java:115)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.cocoon.core.container.spring.avalon.PoolableFactoryBean$ProxyHandler.invoke(PoolableFactoryBean.java:349)
> at $Proxy5.generate(Unknown Source)
> at
> org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.processReader(AbstractProcessingPipeline.java:649)
> at
> org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:429)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.apache.cocoon.core.container.spring.avalon.PoolableFactoryBean$ProxyHandler.invoke(PoolableFactoryBean.java:349)
> at $Proxy4.process(Unknown Source)
> at
> org.apache.cocoon.components.treeprocessor.sitemap.ReadNode.invoke(ReadNode.java:94)
> at
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:55)
> at
> org.apache.cocoon.components.treeprocessor.sitemap.MatchNode.invoke(MatchNode.java:87)
> at
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77)
> at
> org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:152)
> at
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:77)
> at
> org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:93)
> at
> org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:239)
> at
> org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:170)
> at
> org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:232)
> at
> org.apache.cocoon.servlet.RequestProcessor.process(RequestProcessor.java:397)
> at
> org.apache.cocoon.servlet.RequestProcessor.service(RequestProcessor.java:162)
> at org.apache.cocoon.sitemap.SitemapServlet.service(SitemapServlet.java:61)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
> at
> org.apache.cocoon.blocks.BlockContext$PathDispatcher.forward(BlockContext.java:529)
> at
> org.apache.cocoon.blocks.BlockContext$PathDispatcher.forward(BlockContext.java:511)
> at
> org.apache.cocoon.blocks.ShieldingBlockServlet.service(ShieldingBlockServlet.java:136)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
> at
> org.apache.cocoon.blocks.DispatcherServlet.service(DispatcherServlet.java:127)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
> at
> org.apache.cocoon.maven.deployer.servlet.ShieldingServlet.service(ShieldingServlet.java:95)
> at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:445)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1050)
> at
> com.mindquarry.webapp.servlet.AuthenticationFilter.doFilter(AuthenticationFilter.java:216)
> at
> org.apache.cocoon.maven.deployer.servlet.ShieldingServletFilter.doFilter(ShieldingServletFilter.java:50)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1041)
> at
> org.apache.cocoon.servlet.multipart.MultipartFilter.doFilter(MultipartFilter.java:104)
> at
> org.apache.cocoon.maven.deployer.servlet.ShieldingServletFilter.doFilter(ShieldingServletFilter.java:50)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1041)
> at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:354)
> at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:226)
> at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:627)
> at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:149)
> at
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:123)
> at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:141)
> at org.mortbay.jetty.Server.handle(Server.java:269)
> at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:430)
> at
> org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:687)
> at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:492)
> at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:199)
> at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:339)
> at
> org.mortbay.jetty.nio.HttpChannelEndPoint.run(HttpChannelEndPoint.java:270)
> at
> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
>
>
>
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/