cglib 2.1_3 no dep and NPE in AbstractClassGenerator

[Costin]

Hi guys,

I get a strange NPE:

Caused by: java.lang.NullPointerException
        at net.sf.cglib.core.AbstractClassGenerator.getClassNameCache(AbstractClassGenerator.java:80)
        at net.sf.cglib.core.AbstractClassGenerator.create(AbstractClassGenerator.java:218)
        at net.sf.cglib.reflect.FastClass$Generator.create(FastClass.java:64)
        at net.sf.cglib.proxy.MethodProxy.helper(MethodProxy.java:81)
        at net.sf.cglib.proxy.MethodProxy.create(MethodProxy.java:47)
        at $java.util.ArrayList$$EnhancerByCGLIB$$99b990fd.CGLIB$STATICHOOK3(<generated>)
        at $java.util.ArrayList$$EnhancerByCGLIB$$99b990fd.<clinit>(<generated>)


which points to:

    private Set getClassNameCache(ClassLoader loader) {
        return (Set)((Map)source.cache.get(loader)).get(NAME_KEY);
    }

Basically, it seems that there the classloader asked from the cache, does not exist.
The problem occured when doing some proxying on OSGi for java.util.ArrayList. I'm completely buffled on why this occurs - seems to be working fine with other java classes such as java.util.Date.


Thanks,
 Costin

[Chris Nokleberg]

On 4/25/07, Costin <costin.leau@...> wrote:
> Basically, it seems that there the classloader asked from the cache, does
> not exist.
> The problem occured when doing some proxying on OSGi for
> java.util.ArrayList. I'm completely buffled on why this occurs - seems to be
> working fine with other java classes such as java.util.Date.

That is pretty strange. Have you made any progress? I don't really
have a good way to test this problem. If you could put a zip together
with all the necessary jars and a sample program we can probably track
it down quickly. Of course the answer may just end up being an issue
in OSGi.

Chris

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
cglib-devel mailing list
cglib-devel@...
https://lists.sourceforge.net/lists/listinfo/cglib-devel

[Costin]

Chris Nokleberg wrote:

On 4/25/07, Costin <[e-mail]> wrote:
> Basically, it seems that there the classloader asked from the cache, does
> not exist.
> The problem occured when doing some proxying on OSGi for
> java.util.ArrayList. I'm completely buffled on why this occurs - seems to be
> working fine with other java classes such as java.util.Date.

That is pretty strange. Have you made any progress? I don't really
have a good way to test this problem. If you could put a zip together
with all the necessary jars and a sample program we can probably track
it down quickly. Of course the answer may just end up being an issue
in OSGi.

Chris

I suspect that my environment (OSGi) is to quite different then the traditional J2EE
 but so far I haven't been able to identify the exact cause. By looking at the cglib code, it seems that the classloader should be already in the cache but I can't figure out where the initialization occurs.
I'll post back more information once I have it.

Cheers,
  Costin

[Costin]

Hi Chris,

I've uploaded a test case which, at least on my machine, gives the error after multiple runs.
You can d/l from here: http://www.gigasize.com/get.php/-1100218755/cglib.bug.zip 

It's a maven project which d/ls the requires the libraries and then bootstraps the OSGi platform and runs the test.
From what I can see, as OSGi handles the classloaders, the weakHashMap that CGLIB uses can have a certain key reclaimed during a class generation which leads to the NPE problem.
A simple if/cache population on the fly should do the trick but maybe it's something bigger.

Thanks for looking into this!

Cheers,
  Costin

Costin wrote:

Chris Nokleberg wrote:

On 4/25/07, Costin <[e-mail]> wrote:
> Basically, it seems that there the classloader asked from the cache, does
> not exist.
> The problem occured when doing some proxying on OSGi for
> java.util.ArrayList. I'm completely buffled on why this occurs - seems to be
> working fine with other java classes such as java.util.Date.

That is pretty strange. Have you made any progress? I don't really
have a good way to test this problem. If you could put a zip together
with all the necessary jars and a sample program we can probably track
it down quickly. Of course the answer may just end up being an issue
in OSGi.

Chris

I suspect that my environment (OSGi) is to quite different then the traditional J2EE
 but so far I haven't been able to identify the exact cause. By looking at the cglib code, it seems that the classloader should be already in the cache but I can't figure out where the initialization occurs.
I'll post back more information once I have it.

Cheers,
  Costin

[timeck]

Hi Costin,

I know this is an old item, but the JIRA is still open. Is that test code you wrote still available someplace? For some odd reason I feel like debugging this :-)

Maybe best to attach the source to the JIRA item actually

thanks
-tim
 


Hi Chris,

I've uploaded a test case which, at least on my machine, gives the error after multiple runs.
You can d/l from here: http://www.gigasize.com/get.php/-1100218755/cglib.bug.zip 

It's a maven project which d/ls the requires the libraries and then bootstraps the OSGi platform and runs the test.
From what I can see, as OSGi handles the classloaders, the weakHashMap that CGLIB uses can have a certain key reclaimed during a class generation which leads to the NPE problem.
A simple if/cache population on the fly should do the trick but maybe it's something bigger.

Thanks for looking into this!

Cheers,
  Costin

Costin wrote:

Chris Nokleberg wrote:

On 4/25/07, Costin <[e-mail]> wrote:
> Basically, it seems that there the classloader asked from the cache, does
> not exist.
> The problem occured when doing some proxying on OSGi for
> java.util.ArrayList. I'm completely buffled on why this occurs - seems to be
> working fine with other java classes such as java.util.Date.

That is pretty strange. Have you made any progress? I don't really
have a good way to test this problem. If you could put a zip together
with all the necessary jars and a sample program we can probably track
it down quickly. Of course the answer may just end up being an issue
in OSGi.

Chris

I suspect that my environment (OSGi) is to quite different then the traditional J2EE
 but so far I haven't been able to identify the exact cause. By looking at the cglib code, it seems that the classloader should be already in the cache but I can't figure out where the initialization occurs.
I'll post back more information once I have it.

Cheers,
  Costin

[Costin]

Hi Tim,
I'll update the test case and make it available shortly - thank for your interest. However, in the mean time please see the rest of this thread - the problem is that the retrieval from the weak hash map always returns a non-null object. I think some analysis tools (like findbugs) will also point this out.

Thanks

Hi Costin,

I know this is an old item, but the JIRA is still open. Is that test code you wrote still available someplace? For some odd reason I feel like debugging this :-)

Maybe best to attach the source to the JIRA item actually

thanks
-tim
 

Costin wrote:

Hi Chris,

I've uploaded a test case which, at least on my machine, gives the error after multiple runs.
You can d/l from here: http://www.gigasize.com/get.php/-1100218755/cglib.bug.zip 

It's a maven project which d/ls the requires the libraries and then bootstraps the OSGi platform and runs the test.
From what I can see, as OSGi handles the classloaders, the weakHashMap that CGLIB uses can have a certain key reclaimed during a class generation which leads to the NPE problem.
A simple if/cache population on the fly should do the trick but maybe it's something bigger.

Thanks for looking into this!

Cheers,
  Costin

Costin wrote:

Chris Nokleberg wrote:

On 4/25/07, Costin <[e-mail]> wrote:
> Basically, it seems that there the classloader asked from the cache, does
> not exist.
> The problem occured when doing some proxying on OSGi for
> java.util.ArrayList. I'm completely buffled on why this occurs - seems to be
> working fine with other java classes such as java.util.Date.

That is pretty strange. Have you made any progress? I don't really
have a good way to test this problem. If you could put a zip together
with all the necessary jars and a sample program we can probably track
it down quickly. Of course the answer may just end up being an issue
in OSGi.

Chris

I suspect that my environment (OSGi) is to quite different then the traditional J2EE
 but so far I haven't been able to identify the exact cause. By looking at the cglib code, it seems that the classloader should be already in the cache but I can't figure out where the initialization occurs.
I'll post back more information once I have it.

Cheers,
  Costin

[Costin]

Hi Tim, apparently the latest version of Spring-DM, 1.0.2 (which addressed the classloader identity) doesn't exhibit this problem which leads me to believe that the problem was on our side.
I've updated the test case that I had and all tests pass fine on jdk 1.4 to 1.6. Thanks for the interest.


Hi Tim,
I'll update the test case and make it available shortly - thank for your interest. However, in the mean time please see the rest of this thread - the problem is that the retrieval from the weak hash map always returns a non-null object. I think some analysis tools (like findbugs) will also point this out.

Thanks

Hi Costin,

I know this is an old item, but the JIRA is still open. Is that test code you wrote still available someplace? For some odd reason I feel like debugging this :-)

Maybe best to attach the source to the JIRA item actually

thanks
-tim
 

Costin wrote:

Hi Chris,

I've uploaded a test case which, at least on my machine, gives the error after multiple runs.
You can d/l from here: http://www.gigasize.com/get.php/-1100218755/cglib.bug.zip 

It's a maven project which d/ls the requires the libraries and then bootstraps the OSGi platform and runs the test.
From what I can see, as OSGi handles the classloaders, the weakHashMap that CGLIB uses can have a certain key reclaimed during a class generation which leads to the NPE problem.
A simple if/cache population on the fly should do the trick but maybe it's something bigger.

Thanks for looking into this!

Cheers,
  Costin

Costin wrote:

Chris Nokleberg wrote:

On 4/25/07, Costin <[e-mail]> wrote:
> Basically, it seems that there the classloader asked from the cache, does
> not exist.
> The problem occured when doing some proxying on OSGi for
> java.util.ArrayList. I'm completely buffled on why this occurs - seems to be
> working fine with other java classes such as java.util.Date.

That is pretty strange. Have you made any progress? I don't really
have a good way to test this problem. If you could put a zip together
with all the necessary jars and a sample program we can probably track
it down quickly. Of course the answer may just end up being an issue
in OSGi.

Chris

I suspect that my environment (OSGi) is to quite different then the traditional J2EE
 but so far I haven't been able to identify the exact cause. By looking at the cglib code, it seems that the classloader should be already in the cache but I can't figure out where the initialization occurs.
I'll post back more information once I have it.

Cheers,
  Costin