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