Return-Path: 
 <dev-return-90977-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 78631 invoked from network); 23 Nov 2006 11:20:28 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 23 Nov 2006 11:20:28 -0000
Received: (qmail 83956 invoked by uid 500); 23 Nov 2006 11:20:34 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 83874 invoked by uid 500); 23 Nov 2006 11:20:34 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
List-Post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
List-Id: <dev.cocoon.apache.org>
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 83860 invoked by uid 99); 23 Nov 2006 11:20:33 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 23 Nov 2006 03:20:33 -0800
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 23 Nov 2006 03:20:23 -0800
Received: from brutus (localhost [127.0.0.1])
	by brutus.apache.org (Postfix) with ESMTP id 2C6EA7141E4
	for <dev@cocoon.apache.org>; Thu, 23 Nov 2006 03:20:03 -0800 (PST)
Message-ID: <23806289.1164280803179.JavaMail.jira@brutus>
Date: Thu, 23 Nov 2006 03:20:03 -0800 (PST)
From: =?utf-8?Q?J=C3=B6rg_Heinicke_=28JIRA=29?= <jira@apache.org>
To: dev@cocoon.apache.org
Subject: [jira] Commented: (COCOON-1955) [Patch] Allow shielded class
 loading for a single block
In-Reply-To: <29891702.1163783377165.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Virus-Checked: Checked by ClamAV on apache.org

    [ http://issues.apache.org/jira/browse/COCOON-1955?page=3Dcomments#acti=
on_12452208 ]=20
           =20
J=C3=B6rg Heinicke commented on COCOON-1955:
---------------------------------------

I did not want to change the behaviour. So, yes, you are right. It was only=
 an accidental removal.

> [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-aop-shieldingblockservlet.patch, cocoon-enabl=
e-shielded-block-libs.patch, cocoon-new-shieldingblockservlet.patch
>
>
> =3D=3D Problem =3D=3D
> 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.
> =3D=3D Solution =3D=3D
> Since we integrate the SolrServlet (and the other servlets from solar) in=
side a BlockServlet to have them all inside our cocoon webapp with consiste=
nt URLs, we considered adding a ShieldingServlet. Thus the BlockServlet wra=
ps the ShieldingServlet which in turn wraps the SolrServlet. The configurat=
ion for the BlockServlet bean looks like this:
> =09<bean id=3D"com.mindquarry.search.solr.solr-select-block"
> =09=09class=3D"org.apache.cocoon.blocks.BlockServlet">
> =09=09<property name=3D"mountPath" value=3D"/solr-select" />
> =09=09<property name=3D"servletClass"
> =09=09=09value=3D"org.apache.cocoon.bootstrap.servlet.ShieldingServlet" /=
>
> =09=09<property name=3D"blockContextURL"
> =09=09=09value=3D"blockcontext:/mindquarry-solr-block/" />
> =09=09<property name=3D"properties">
> =09=09=09<map>
> =09=09=09=09<entry key=3D"servlet-class"
> =09=09=09=09=09value=3D"org.apache.solr.servlet.SolrServlet" />
> =09=09=09=09<entry key=3D"bootstrap-classpath-file"
> =09=09=09=09=09value=3D"/paranoid-classpath.txt" />
> =09=09=09=09<entry key=3D"bootstrap-classloader-debug" value=3D"true" />
> =09=09=09=09<entry key=3D"bootstrap-classloader-factory"
> =09=09=09=09=09value=3D"org.apache.cocoon.classloader.DefaultClassLoaderF=
actory" />
> =09=09=09</map>
> =09=09</property>
> =09</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
> =3D=3D The Patch =3D=3D
> To get the ShieldingServlet work with the blocks-fw and the basic shieldi=
ng 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 getCla=
ssLoader() a new ClassLoader is created. That method is exactly called 2 ti=
mes in our situation: first by the cocoon webapp shielding listener and the=
n 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.

--=20
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: htt=
p://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira