[ 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