You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Chris Wilson (JIRA)" <ji...@apache.org> on 2008/02/13 23:55:13 UTC

[jira] Created: (JCR-1382) [PATCH]

[PATCH]
-------

                 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.4, 1.3.3, 1.3.1, 1.3
         Environment: JDK 1.5, Tomcat 5.5, Xnix/Windoze

            Reporter: Chris Wilson
            Priority: Critical
             Fix For: 1.4.1, 1.5


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.


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


[jira] Commented: (JCR-1382) [PATCH] ResourceConfig Classloading

Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/JCR-1382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568969#action_12568969 ] 

Jukka Zitting commented on JCR-1382:
------------------------------------

The current preferred mechanism for model 2 deployments is to have only the JCR API jar file in the shared classpath and use either cross-context attribute access (see the jackrabbit-servlet component) or a shared writable JNDI directory for sharing the reference to the repository.

With such a deployment the current class loading mechanism would not be a problem, and thus I'd prefer to resolve this as Won't Fix.

> [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.


[jira] Updated: (JCR-1382) [PATCH]

Posted by "Chris Wilson (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-1382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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

    Attachment: classloader.patch

> [PATCH]
> -------
>
>                 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. This workaround does not work in 1.4. Earlier version 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.


[jira] Updated: (JCR-1382) [PATCH] ResourceConfig Classloading

Posted by "Chris Wilson (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-1382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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

    Summary: [PATCH] ResourceConfig Classloading  (was: [PATCH])

> [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. This workaround does not work in 1.4. Earlier version 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.


[jira] Resolved: (JCR-1382) [PATCH] ResourceConfig Classloading

Posted by "Jukka Zitting (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/JCR-1382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jukka Zitting resolved JCR-1382.
--------------------------------

       Resolution: Won't Fix
    Fix Version/s:     (was: 1.4.1)
                       (was: 1.5)
         Assignee: Jukka Zitting

Resolving as Won't Fix based on the above comment.

> [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
>            Assignee: Jukka Zitting
>            Priority: Critical
>         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.


[jira] Updated: (JCR-1382) [PATCH] ResourceConfig Classloading

Posted by "Chris Wilson (JIRA)" <ji...@apache.org>.
     [ 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.