You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "Daniel Fagerstrom (JIRA)" <ji...@apache.org> on 2007/01/13 19:28:27 UTC
[jira] Commented: (COCOON-1955) [Patch] Allow shielded class
loading for a single block
[ https://issues.apache.org/jira/browse/COCOON-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12464505 ]
Daniel Fagerstrom commented on COCOON-1955:
-------------------------------------------
Apllied, thanks for the patch. Please check.
> [Patch] Allow shielded class loading for a single block
> -------------------------------------------------------
>
> Key: COCOON-1955
> URL: https://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-aop-shieldingblockservlet.patch, 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: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira