[ http://issues.apache.org/jira/browse/COCOON-1955?page=all ]
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
COB-INF/shielded/lib
COB-INF/shielded/classes
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: http://issues.apache.org/jira/browse/COCOON-1955
> 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="com.mindquarry.search.solr.solr-select-block"
> 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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
