Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <16728341.1202943549372.JavaMail.jira@brutus>
Date: Wed, 13 Feb 2008 14:59:09 -0800 (PST)
From: "Chris Wilson (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Updated: (JCR-1382) [PATCH] ResourceConfig Classloading
In-Reply-To: <19031260.1202943313326.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/JCR-1382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chris Wilson updated JCR-1382:
------------------------------

    Description: 
Ran into a ClassNotFoundException when trying to load a custom IOManager from webdav's config.xml. 

Setup:
-	All the dependency jars as well as Jackrabbit jars were installed in $CATALINA_HOME/common/lib in order to reference the JCR with JNDI using class org.apache.jackrabbit.core.jndi.BindableRepositoryFactory

-	Default install of jackrabbit-webapp-1.4 with custom IOManager(s) in $CATALINA_HOME/ jackrabbit-webapp-1.4/WEB-INF/classes

On app startup the ResourceConfig was being referenced from the common Classloader. Since the current implementation is using the Class.forName method of loading a dynamic class. It was unable to find the custom IOManager which was on the webapps classloader.

Patch file implements pattern to attempt to use the Threads contextClassloader and defaults to Class.forName

This issue also exists in 1.3 but can be worked around by removing the jackrabbit-webdav-1.3.3.jar from the common Classloader. The workaround does not work in 1.4. Earlier versions then 1.3 are unknown since they were not tested.


  was:
Ran into a ClassNotFoundException when trying to load a custom IOManager from webdav's config.xml. 

Setup:
-	All the dependency jars as well as Jackrabbit jars were installed in $CATALINA_HOME/common/lib in order to reference the JCR with JNDI using class org.apache.jackrabbit.core.jndi.BindableRepositoryFactory

-	Default install of jackrabbit-webapp-1.4 with custom IOManager(s) in $CATALINA_HOME/ jackrabbit-webapp-1.4/WEB-INF/classes

On app startup the ResourceConfig was being referenced from the common Classloader. Since the current implementation is using the Class.forName method of loading a dynamic class. It was unable to find the custom IOManager which was on the webapps classloader.

Patch file implements pattern to attempt to use the Threads contextClassloader and defaults to Class.forName

This issue also exists in 1.3 but can be worked around by removing the jackrabbit-webdav-1.3.3.jar from the common Classloader. This workaround does not work in 1.4. Earlier version then 1.3 are unknown since they were not tested.


> [PATCH] ResourceConfig Classloading
> -----------------------------------
>
>                 Key: JCR-1382
>                 URL: https://issues.apache.org/jira/browse/JCR-1382
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: jackrabbit-jcr-server, jackrabbit-webdav
>    Affects Versions: 1.3, 1.3.1, 1.3.3, 1.4
>         Environment: JDK 1.5, Tomcat 5.5, Xnix/Windoze
>            Reporter: Chris Wilson
>            Priority: Critical
>             Fix For: 1.4.1, 1.5
>
>         Attachments: classloader.patch
>
>
> Ran into a ClassNotFoundException when trying to load a custom IOManager from webdav's config.xml. 
> Setup:
> -	All the dependency jars as well as Jackrabbit jars were installed in $CATALINA_HOME/common/lib in order to reference the JCR with JNDI using class org.apache.jackrabbit.core.jndi.BindableRepositoryFactory
> -	Default install of jackrabbit-webapp-1.4 with custom IOManager(s) in $CATALINA_HOME/ jackrabbit-webapp-1.4/WEB-INF/classes
> On app startup the ResourceConfig was being referenced from the common Classloader. Since the current implementation is using the Class.forName method of loading a dynamic class. It was unable to find the custom IOManager which was on the webapps classloader.
> Patch file implements pattern to attempt to use the Threads contextClassloader and defaults to Class.forName
> This issue also exists in 1.3 but can be worked around by removing the jackrabbit-webdav-1.3.3.jar from the common Classloader. The workaround does not work in 1.4. Earlier versions then 1.3 are unknown since they were not tested.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.