jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "V. W. (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-1858) ClassDescriptor ReflectionUtils ClassLoader Defect
Date Tue, 18 Nov 2008 15:39:44 GMT

    [ https://issues.apache.org/jira/browse/JCR-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648625#action_12648625
] 

V. W. commented on JCR-1858:
----------------------------

>It should be nice to have a smaller test with less dependencies and files.
It's as small as it can be. The unit test itself (AnnotatatedBeanTest\test\testpkg\TheTest.java)
is 3 lines of code and 18 lines for the fixture.

The annotated entity (AnnotatedBean\src\annotatedbean\ABean.java) is basic as well, only 2
fields.

The dependencies are:
= Basic stuff, common in most of the projects. Required to run Jackrabbit-ocm. =
commons-logging-1.1.1.jar
commons-logging-api-1.1.1.jar
log4j-1.2.15.jar

= Jar Classloader ( http://sourceforge.net/projects/jcloader ). Provides a simple way to load
a external jar and a class from it, which is not accessed by the ClassLoader, that loaded
the unit test. =
jcl.jar

= The Jackrabbit-ocm itself =
jackrabbit-ocm-1.4.jar

I don't see any problem the unit test or the dependencies; to use it, it's as simple as adding
5 files. Is maven a must-use even for a small unit test?
If one uses Eclipse, one can create a new java project and direct Eclipse to load the source
files from AnnotatatedBeanTest\test.

>Is it possible to create patch with a unit test ? 
As I've written above, in oder to fix this issue, one needs to rewrite the ClassDescriptor
so it would not rely on the `String className` (and try to load it from a random ClassLoader)
but on `Class descriptedClass`.

The problem occurs after annotation mapping, then ClassDescriptor tries to validate the existance
of the class and fails since the class is loaded from wrong ClassLoader.

Anyways, I've switched to Jcrom, so this issue is very low priority.


> ClassDescriptor ReflectionUtils ClassLoader Defect
> --------------------------------------------------
>
>                 Key: JCR-1858
>                 URL: https://issues.apache.org/jira/browse/JCR-1858
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: jackrabbit-ocm
>    Affects Versions: 1.4
>         Environment: JVM 1.6.0.6/Windows XP SP2/Netbeans 6.2 Beta
>            Reporter: V. W.
>         Attachments: TestCase.zip
>
>
> I have stumbuled on a bug in the interaction between ClassDescriptor and ReflectionUtils
classes:
> 1. ClassDescriptor.validateClassName() uses ReflectionUtils.forName(String) to resolve
an annotated class by its name
> 2. ReflectionUtils is an evil stateful statics-based singleton. It has a field of a ClassLoader,
which by default is the one that loaded the ReflectionUtils. The method forName(String) uses
this ClassLoader to resolve the annotated class.
> The problem is that the ClassDescriptor assumses that the annotated class comes from
a global ClassLoader (the one that loaded the jars), which is not always correct. The workaround
is to manually set the ReflectionUtils ClassLoader field for it to use the correct ClassLoader.
> I've found this bug while working with NetBeans, writing a small Scala application and
using ScalaTest TestNG integration for testing. Apparantly many ClassLoader need to by involved
to run a single test.
> I've created a unit test (java only, libraries included) to reproduce the bug.
> The best solution would be for the ClassDescriptor to use a Class reference (the Class
contains its ClassLoader reference) instead of just a class-name or at least pair every class-name
with its ClassLoader.

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


Mime
View raw message