cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander Klimetschek (JIRA)" <>
Subject [jira] Closed: (COCOON-1955) [Patch] Allow shielded class loading for a single block
Date Thu, 12 Apr 2007 12:21:32 GMT


Alexander Klimetschek closed COCOON-1955.

       Resolution: Fixed
    Fix Version/s: 2.2-dev (Current SVN)

Tested with servlet-services and works.

> [Patch] Allow shielded class loading for a single block
> -------------------------------------------------------
>                 Key: COCOON-1955
>                 URL:
>             Project: Cocoon
>          Issue Type: New Feature
>          Components: * Cocoon Core, - Servlet service framework
>    Affects Versions: 2.2-dev (Current SVN)
>            Reporter: Alexander Klimetschek
>             Fix For: 2.2-dev (Current SVN)
>         Attachments: cocoon-aop-shieldingblockservlet.patch, cocoon-enable-shielded-block-libs.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.
You can reply to this email to add a comment to the issue online.

View raw message