cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Klimetschek (JIRA)" <>
Subject [jira] Updated: (COCOON-1955) [Patch] Allow shielded class loading for a single block
Date Wed, 22 Nov 2006 15:53:03 GMT
     [ ]

Alexander Klimetschek updated COCOON-1955:

    Attachment: cocoon-new-shieldingblockservlet.patch

A new approach that is independent from the now removed bootstrap module. This adds a BlockServlet
subclass called ShieldingBlockServlet that will shield its embedded servlet. The standard
path of the libs and classes is


and can be configured via the bean properties:

shieldedLib (default shielded/lib)
shieldedClasses (default shielded/classes)
shieldedGroup (default no group)
classLoaderFactory (default o.a.c.classloader.DefaultClassLoaderFactory)

The shielded group feature allows to have multiple ShieldingBlockServlets in one block that
will share the same classloader, but still shielded (or even one group across multiple blocks....
but this is not tested, here the order of loading is probably important). Just give all those
servlets the same shieldedGroup string and its done. If this property is not set, each ShieldingBlockServlet
will have a new classloader.

Apart from the new classes, ShieldingBlockServlet and ShieldedGroupClassLoaderManager, I modified
the BlockServlet to allow a subclass to handle the embedded servlet different.

Also the BlockContext was modified at many places where non-existing implementations of inherited
methods were added, especially for resolving resources of the block context. Another important
change was to remove the check that paths start with "/" in getResource(). This is needed
for the path that defines shielded/lib, it cannot start with a slash, because otherwise it
would be interpreted by the classloader factory code as an absolute path in the filesystem.

> [Patch] Allow shielded class loading for a single block
> -------------------------------------------------------
>                 Key: COCOON-1955
>                 URL:
>             Project: Cocoon
>          Issue Type: New Feature
>          Components: * Cocoon Core, - Blocks Framework
>    Affects Versions: 2.2-dev (Current SVN)
>            Reporter: Alexander Klimetschek
>         Attachments: cocoon-enable-shielded-block-libs.patch, cocoon-new-shieldingblockservlet.patch
> == Problem ==
> When trying to integrate Apache Solr in our Cocoon webapplication, we got a problem with
conflicting versions of jars. Our jackrabbit block needs an old lucene, whereas Solr wants
a fresh new lucene nightly build.
> == Solution ==
> Since we integrate the SolrServlet (and the other servlets from solar) inside a BlockServlet
to have them all inside our cocoon webapp with consistent URLs, we considered adding a ShieldingServlet.
Thus the BlockServlet wraps the ShieldingServlet which in turn wraps the SolrServlet. The
configuration for the BlockServlet bean looks like this:
> 	<bean id=""
> 		class="org.apache.cocoon.blocks.BlockServlet">
> 		<property name="mountPath" value="/solr-select" />
> 		<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.solr.servlet.SolrServlet" />
> 				<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>
> The directory structure of the solr-block:
>   src/main/resources/
>                            COB-INF/
>                                  paranoid-classpath.txt
>                                  paranoid-lib/
>                                         <shielded-jars>.jar
>                                         (including the jar which contains the solr servlet)
>                             META-INF/
>                                   cocoon/
>                                         spring/
>                                              solr-blockservlet.xml
> The paranoid-classpath.txt contains the following single line:
> lib-dir: context:paranoid-lib
> == The Patch ==
> To get the ShieldingServlet work with the blocks-fw and the basic shielding that is done
in the Cocoon webapp anyway (via a ShieldingListener in the web.xml), two things must be done:
> a) The BootstrapClassLoaderManager in cocoon-bootstrap must not store the classloader
it creates in a static variable so that in each call of getClassLoader() a new ClassLoader
is created. That method is exactly called 2 times in our situation: first by the cocoon webapp
shielding listener and then by the ShieldingServlet in our block.
> b) The method BlockContext.getResourcePaths() must be implemented to list the resources
in that block context (stuff under COB-INF of that block).
> Lots of the work was done by my colleague Alexander Saar.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message