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/20 12:11:50 UTC
Shielded class loading between blocks
Let's discuss the topic of shielded class loading between blocks as
started in the thread about moving the shielded class loading stuff into
the maven-war-plugin
(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=116401943430213&w=2).
There is the patch that will eventually move out the shielded
classloading stuff from cocoon-bootstrap and cocoon-deployer-plugin into
the maven-war-plugin: http://jira.codehaus.org/browse/MWAR-84.
Conflicting with that is my simple patch for shielding between blocks at
http://issues.apache.org/jira/browse/COCOON-1955.
The optimal solution would be the OSGi support (!?), but this is too
much work and won't be part of cocoon 2.2. My patch is a lot simpler,
just fixing the BootstrapClassLoaderManager and the blocks-fw (where I
just implemented the not-yet implemented methods of those servlet
interfaces). Then it is just a simple configuration of the block servlet
using the ShieldingServlet. Here is the xml snippet, the full config can
be found in the jira issue:
<bean id="my-block"
class="org.apache.cocoon.blocks.BlockServlet">
<property name="mountPath" value="/my-block" />
<property name="servletClass"
value="org.apache.cocoon.bootstrap.servlet.ShieldingServlet" />
<property name="blockContextURL"
value="blockcontext:/mindquarry-solr-block/" />
<property name="properties">
<map>
<entry key="servlet-class"
value="org.apache.cocoon.sitemap.SitemapServlet" />
<entry key="bootstrap-classpath-file"
value="/paranoid-classpath.txt" />
<entry key="bootstrap-classloader-debug" value="true" />
<entry key="bootstrap-classloader-factory"
value="org.apache.cocoon.classloader.DefaultClassLoaderFactory" />
</map>
</property>
</bean>
So can this made be simpler? Having standard paths in the block
directory for the shielded libs and some config option to enable
shielding, which could be integrated directly in the BlockServlet?
Alex
--
Alexander Klimetschek
http://www.mindquarry.com
Re: Shielded class loading between blocks
Posted by Carsten Ziegeler <cz...@apache.org>.
Alexander Klimetschek wrote:
> Another requirement what just popped up is to allow "groups" of servlets
> that use the same classloader. This is useful if you have some Servlets
> and jsps that ought to be used together, because the multiple Servlets
> and JSPs access some singleton / static Java class. Here it is necessary
> that all servlets and stuff are loaded by the same classloader.
>
> A simple idea would be to pass the BlockServlet (that will manage the
> shielding) a parameter "shieldingGroup" that will name a group that uses
> the same classloader. There should be some kind of static Map which maps
> that groupname to a classloader so that it can be reused when another
> BlockServlet with the same groupname comes up.
>
I think we could solve this by defining a class loader bean for a block
and the various block servlets can reference the same class loader bean.
If no class loader bean is set for the servlet it just uses its own
class loader.
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Shielded class loading between blocks
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Alexander Klimetschek skrev:
> Daniel Fagerstrom schrieb:
>> Alexander Klimetschek skrev:
>>> Another requirement what just popped up is to allow "groups" of
>>> servlets that use the same classloader. This is useful if you have
>>> some Servlets and jsps that ought to be used together, because the
>>> multiple Servlets and JSPs access some singleton / static Java
>>> class. Here it is necessary that all servlets and stuff are loaded
>>> by the same classloader.
>>
>> Is this really a problem that we need to solve? In most cases using
>> the common servlet container context classloader or a block servlet
>> local classloader should be enough. I would need some concrete use
>> cases to become convinced that it is worth the extra complexity.
>
> Yes, it is. The Solr project for example consists of two Java
> Servlets, one for storing documents and one for querying documents.
> Then there is a bunch of jsps to administrate the Solr installation.
> Both Servlets and jsps make use of static methods of a "SolrCore"
> class, so they all need the same classloader. The jsps are handled via
> a sitemap (BTW, I have patched cocoon-jsp to work with BlockServlets,
> its not yet perfect, so I haven't posted a patch yet).
>
> The need for shielding comes through the dependency for a
> nightly-built Lucene, which conflicts with another part of our webapp,
> where an old Lucene is used.
>
> 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.
OK.
>> IMO it would be useful to have a classloader at the block level and
>> have some mechanism for importing and exporting packages and services
>> between the blocks. Fortunately clever people already have put
>> together a standardized solution for this ;)
>> http://www.springframework.org/osgi.
>
> How much time will it approximately take to have a stable OSGI
> implementation in cocoon?
No idea ;)
What needs to be done is:
1. Package the Cocoon blocks as OSGi bundles. There is a Maven plugin
developed by the Felix community that makes this fairly easy. But one
important complication is that OSGi class sharing is package based and
only one bundle can contribute a specific package. That means that we
have to reorganize the use of packages for some blocks (e.g.
o.a.c.transformation have components in several blocks).
2. All external dependencies must either be bundles or included in our
bundles. This is more complicated. Including dependencies in our bundles
is clumsy and packaging everything external is a huge work. Fortunately
there are work on this in other communities. Felix, Eclipse and the OSGi
organization are creating repositories with "bundelized" common jars.
Felix have also done some work on making it really easy to bundelize a
jar with a maven plugin. Maven are also working together with Felix to
make the jar plugin create a default Felix manifest.
3. The Spring configurations in the blocks needs to be extended with
special Spring-OSGi elements that describe what services (components)
that each block exposes and depends on.
4. We have to put all this in a OSGi container that is embeddable as a
webapp. Eclipse have developed a such, so this would hopefully not be
that difficult.
I would say that point 2, is the critical point.
/Daniel
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/
Problem with JAXP and shielding (was Re: Shielded class loading between
blocks)
Posted by Alexander Klimetschek <al...@mindquarry.com>.
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: Shielded class loading between blocks
Posted by Alexander Klimetschek <al...@mindquarry.com>.
Daniel Fagerstrom schrieb:
> Alexander Klimetschek skrev:
>> Another requirement what just popped up is to allow "groups" of
>> servlets that use the same classloader. This is useful if you have
>> some Servlets and jsps that ought to be used together, because the
>> multiple Servlets and JSPs access some singleton / static Java class.
>> Here it is necessary that all servlets and stuff are loaded by the
>> same classloader.
>
> Is this really a problem that we need to solve? In most cases using the
> common servlet container context classloader or a block servlet local
> classloader should be enough. I would need some concrete use cases to
> become convinced that it is worth the extra complexity.
Yes, it is. The Solr project for example consists of two Java Servlets,
one for storing documents and one for querying documents. Then there is
a bunch of jsps to administrate the Solr installation. Both Servlets and
jsps make use of static methods of a "SolrCore" class, so they all need
the same classloader. The jsps are handled via a sitemap (BTW, I have
patched cocoon-jsp to work with BlockServlets, its not yet perfect, so I
haven't posted a patch yet).
The need for shielding comes through the dependency for a nightly-built
Lucene, which conflicts with another part of our webapp, where an old
Lucene is used.
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.
> IMO it would be useful to have a classloader at the block level and have
> some mechanism for importing and exporting packages and services between
> the blocks. Fortunately clever people already have put together a
> standardized solution for this ;) http://www.springframework.org/osgi.
How much time will it approximately take to have a stable OSGI
implementation in cocoon?
Alex
--
Alexander Klimetschek
http://www.mindquarry.com
Re: Shielded class loading between blocks
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Alexander Klimetschek skrev:
> Another requirement what just popped up is to allow "groups" of servlets
> that use the same classloader. This is useful if you have some Servlets
> and jsps that ought to be used together, because the multiple Servlets
> and JSPs access some singleton / static Java class. Here it is necessary
> that all servlets and stuff are loaded by the same classloader.
Is this really a problem that we need to solve? In most cases using the
common servlet container context classloader or a block servlet local
classloader should be enough. I would need some concrete use cases to
become convinced that it is worth the extra complexity.
IMO it would be useful to have a classloader at the block level and have
some mechanism for importing and exporting packages and services between
the blocks. Fortunately clever people already have put together a
standardized solution for this ;) http://www.springframework.org/osgi.
/Daniel
Re: Shielded class loading between blocks
Posted by Alexander Klimetschek <al...@mindquarry.com>.
Another requirement what just popped up is to allow "groups" of servlets
that use the same classloader. This is useful if you have some Servlets
and jsps that ought to be used together, because the multiple Servlets
and JSPs access some singleton / static Java class. Here it is necessary
that all servlets and stuff are loaded by the same classloader.
A simple idea would be to pass the BlockServlet (that will manage the
shielding) a parameter "shieldingGroup" that will name a group that uses
the same classloader. There should be some kind of static Map which maps
that groupname to a classloader so that it can be reused when another
BlockServlet with the same groupname comes up.
WDYT?
Alex
Carsten Ziegeler schrieb:
> Alexander Klimetschek wrote:
>> The optimal solution would be the OSGi support (!?), but this is too
>> much work and won't be part of cocoon 2.2. My patch is a lot simpler,
>> just fixing the BootstrapClassLoaderManager and the blocks-fw (where I
>> just implemented the not-yet implemented methods of those servlet
>> interfaces). Then it is just a simple configuration of the block servlet
>> using the ShieldingServlet. Here is the xml snippet, the full config can
>> be found in the jira issue:
>>
>>
>> <bean id="my-block"
>> class="org.apache.cocoon.blocks.BlockServlet">
>> <property name="mountPath" value="/my-block" />
>>
>> <property name="servletClass"
>> value="org.apache.cocoon.bootstrap.servlet.ShieldingServlet" />
>>
>> <property name="blockContextURL"
>> value="blockcontext:/mindquarry-solr-block/" />
>>
>> <property name="properties">
>> <map>
>> <entry key="servlet-class"
>> value="org.apache.cocoon.sitemap.SitemapServlet" />
>> <entry key="bootstrap-classpath-file"
>> value="/paranoid-classpath.txt" />
>> <entry key="bootstrap-classloader-debug" value="true" />
>> <entry key="bootstrap-classloader-factory"
>> value="org.apache.cocoon.classloader.DefaultClassLoaderFactory" />
>> </map>
>> </property>
>> </bean>
>>
>>
>> So can this made be simpler? Having standard paths in the block
>> directory for the shielded libs and some config option to enable
>> shielding, which could be integrated directly in the BlockServlet?
>>
> Hmm, yes, what about directly adding the support to the BlockServlet
> (where imho it belongs):
>
> <bean id="my-block" class="org.apache.cocoon.blocks.BlockServlet">
> <property name="mountPath" value="/my-block" />
>
> <property name="blockContextURL"
> value="blockcontext:/mindquarry-solr-block/" />
>
> <property name="properties">
> <map>
> <entry key="classpath-file"
> value="/paranoid-classpath.txt" />
> <entry key="classloader-debug" value="true" />
> <entry key="classloader-factory"
> value="org.apache.cocoon.classloader.DefaultClassLoaderFactory"
>
> </map>
> </property>
> </bean>
>
> And yes, I think this should support some default paths, like
> {blockdir}/config/libs and {blockdir}/config/classes.
>
> Carsten
--
Alexander Klimetschek
http://www.mindquarry.com
Re: Shielded class loading between blocks
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> Daniel Fagerstrom wrote:
>> Seem like a good solution to me. I would prefer putting this
>> functionality in a ShieldingBlockServlet that extends the BlockServlet
>> though. If we put to much extras in the BlockServlet it will be hard for
>> people to understand what it does and to contribute to make it stable.
>>
> Hmm, yes, you're right - what about using Spring's AOP functionality for
> this? The problem with sub classing for a functionality is that you
> might end up with a big set of sub classes for all possible combinations.
Sounds even better than my filter idea (although the idea of Spring AOP was
heavily inspired by servlet filters ;-) ).
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Shielded class loading between blocks
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler skrev:
> Daniel Fagerstrom wrote:
>> Seem like a good solution to me. I would prefer putting this
>> functionality in a ShieldingBlockServlet that extends the BlockServlet
>> though. If we put to much extras in the BlockServlet it will be hard for
>> people to understand what it does and to contribute to make it stable.
>>
> Hmm, yes, you're right - what about using Spring's AOP functionality for
> this?
I don't have any experience of Spring's AOP, so I don't know what such a
solution would look like. But it would be interesting to see :)
> The problem with sub classing for a functionality is that you
> might end up with a big set of sub classes for all possible combinations.
Yes, that is a problem with sub classing. OTH we have only one sub class
candidate this far and it is still experimental code, so I don't know if
it matter that much yet. But if AOP is a neater solution, just go ahead
and use that instead.
As long as we don't end up with just one single monster class with
internal switches for all the possible combinations that you indicate
above. Then I'm happy.
/Daniel
Re: Shielded class loading between blocks
Posted by Carsten Ziegeler <cz...@apache.org>.
Daniel Fagerstrom wrote:
> Seem like a good solution to me. I would prefer putting this
> functionality in a ShieldingBlockServlet that extends the BlockServlet
> though. If we put to much extras in the BlockServlet it will be hard for
> people to understand what it does and to contribute to make it stable.
>
Hmm, yes, you're right - what about using Spring's AOP functionality for
this? The problem with sub classing for a functionality is that you
might end up with a big set of sub classes for all possible combinations.
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Shielded class loading between blocks
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Reinhard Poetz skrev:
>> Daniel Fagerstrom wrote:
>>
>>> Seem like a good solution to me. I would prefer putting this
>>> functionality in a ShieldingBlockServlet that extends the
>>> BlockServlet though. If we put to much extras in the BlockServlet it
>>> will be hard for people to understand what it does and to contribute
>>> to make it stable.
>>
>> Wouldn't be servlet filters the best solutions for these cross-cutting
>> concerns? (another example is the reloading classloader that we should
>> move from sitemap level to the block level).
>
> That would require that we created some kind of block filters analog to
> the block servlet and created some mechanism for wiring these together
> in the Spring container. Entirely possible, but do we really like to add
> that level of complexity?
I don't think so. I think Spring AOP would the best solution but I can live with
simple inheritance as long as we only have one or two use cases.
--
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: Shielded class loading between blocks
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz skrev:
> Daniel Fagerstrom wrote:
>
>> Seem like a good solution to me. I would prefer putting this
>> functionality in a ShieldingBlockServlet that extends the BlockServlet
>> though. If we put to much extras in the BlockServlet it will be hard
>> for people to understand what it does and to contribute to make it
>> stable.
>
> Wouldn't be servlet filters the best solutions for these cross-cutting
> concerns? (another example is the reloading classloader that we should
> move from sitemap level to the block level).
That would require that we created some kind of block filters analog to
the block servlet and created some mechanism for wiring these together
in the Spring container. Entirely possible, but do we really like to add
that level of complexity?
/Daniel
Re: Shielded class loading between blocks
Posted by Alexander Klimetschek <al...@mindquarry.com>.
Having servlet filters for the BlockServlets sounds like additional work
for making that configurable.
Alex
Reinhard Poetz schrieb:
> Daniel Fagerstrom wrote:
>
>> Seem like a good solution to me. I would prefer putting this
>> functionality in a ShieldingBlockServlet that extends the BlockServlet
>> though. If we put to much extras in the BlockServlet it will be hard
>> for people to understand what it does and to contribute to make it
>> stable.
>
> Wouldn't be servlet filters the best solutions for these cross-cutting
> concerns? (another example is the reloading classloader that we should
> move from sitemap level to the block level).
>
--
Alexander Klimetschek
http://www.mindquarry.com
Re: Shielded class loading between blocks
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> Seem like a good solution to me. I would prefer putting this
> functionality in a ShieldingBlockServlet that extends the BlockServlet
> though. If we put to much extras in the BlockServlet it will be hard for
> people to understand what it does and to contribute to make it stable.
Wouldn't be servlet filters the best solutions for these cross-cutting concerns?
(another example is the reloading classloader that we should move from sitemap
level to the block level).
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Shielded class loading between blocks
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Carsten Ziegeler skrev:
> Alexander Klimetschek wrote:
>
>> The optimal solution would be the OSGi support (!?), but this is too
>> much work and won't be part of cocoon 2.2. My patch is a lot simpler,
>> just fixing the BootstrapClassLoaderManager and the blocks-fw (where I
>> just implemented the not-yet implemented methods of those servlet
>> interfaces). Then it is just a simple configuration of the block servlet
>> using the ShieldingServlet. Here is the xml snippet, the full config can
>> be found in the jira issue:
>>
...
>> So can this made be simpler? Having standard paths in the block
>> directory for the shielded libs and some config option to enable
>> shielding, which could be integrated directly in the BlockServlet?
>>
>>
> Hmm, yes, what about directly adding the support to the BlockServlet
> (where imho it belongs):
>
> <bean id="my-block" class="org.apache.cocoon.blocks.BlockServlet">
> <property name="mountPath" value="/my-block" />
>
> <property name="blockContextURL"
> value="blockcontext:/mindquarry-solr-block/" />
>
> <property name="properties">
> <map>
> <entry key="classpath-file"
> value="/paranoid-classpath.txt" />
> <entry key="classloader-debug" value="true" />
> <entry key="classloader-factory"
> value="org.apache.cocoon.classloader.DefaultClassLoaderFactory"
>
> </map>
> </property>
> </bean>
>
> And yes, I think this should support some default paths, like
> {blockdir}/config/libs and {blockdir}/config/classes.
>
Seem like a good solution to me. I would prefer putting this
functionality in a ShieldingBlockServlet that extends the BlockServlet
though. If we put to much extras in the BlockServlet it will be hard for
people to understand what it does and to contribute to make it stable.
/Daniel
Re: Shielded class loading between blocks
Posted by Carsten Ziegeler <cz...@apache.org>.
Alexander Klimetschek wrote:
> The optimal solution would be the OSGi support (!?), but this is too
> much work and won't be part of cocoon 2.2. My patch is a lot simpler,
> just fixing the BootstrapClassLoaderManager and the blocks-fw (where I
> just implemented the not-yet implemented methods of those servlet
> interfaces). Then it is just a simple configuration of the block servlet
> using the ShieldingServlet. Here is the xml snippet, the full config can
> be found in the jira issue:
>
>
> <bean id="my-block"
> class="org.apache.cocoon.blocks.BlockServlet">
> <property name="mountPath" value="/my-block" />
>
> <property name="servletClass"
> value="org.apache.cocoon.bootstrap.servlet.ShieldingServlet" />
>
> <property name="blockContextURL"
> value="blockcontext:/mindquarry-solr-block/" />
>
> <property name="properties">
> <map>
> <entry key="servlet-class"
> value="org.apache.cocoon.sitemap.SitemapServlet" />
> <entry key="bootstrap-classpath-file"
> value="/paranoid-classpath.txt" />
> <entry key="bootstrap-classloader-debug" value="true" />
> <entry key="bootstrap-classloader-factory"
> value="org.apache.cocoon.classloader.DefaultClassLoaderFactory" />
> </map>
> </property>
> </bean>
>
>
> So can this made be simpler? Having standard paths in the block
> directory for the shielded libs and some config option to enable
> shielding, which could be integrated directly in the BlockServlet?
>
Hmm, yes, what about directly adding the support to the BlockServlet
(where imho it belongs):
<bean id="my-block" class="org.apache.cocoon.blocks.BlockServlet">
<property name="mountPath" value="/my-block" />
<property name="blockContextURL"
value="blockcontext:/mindquarry-solr-block/" />
<property name="properties">
<map>
<entry key="classpath-file"
value="/paranoid-classpath.txt" />
<entry key="classloader-debug" value="true" />
<entry key="classloader-factory"
value="org.apache.cocoon.classloader.DefaultClassLoaderFactory"
</map>
</property>
</bean>
And yes, I think this should support some default paths, like
{blockdir}/config/libs and {blockdir}/config/classes.
Carsten
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/