geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dkateros <>
Subject Classes generated on runtime (javassist) classloader issue
Date Sun, 04 Aug 2013 23:17:22 GMT

I stumbled on this issue while testing an application with the geronimo 3.01
release (currently runs on geronimo 2.2 for development and Websphere 8.5
for production).

This application creates concrete classes on runtime based on abstract
classes that exist on compile time.

Imagine the following scenario (extremely naive, but demonstrates the

public abstract class Foo { //exists on compile time
   Set<String> strings; //package visible

public class FooConcreteEnhanced extends Foo { //generated on runtime
    public FooConcreteEnhanced() { strings = new HashSet<String>(); }

When the app attempts to instantiate FooConcreteEnhanced, the following
error is thrown:

java.lang.IllegalAccessError: tried to access field pkg.Foo.strings from
class pkg.FooConcreteEnhanced

This might be caused if the runtime package of the classes is different,
which happens if the two classes are loaded by two different classloaders.
Changing the access modifier of strings to protected circumvents the
problem, but is not desirable, since a lot of the app's unit tests rely on
package visibility of fields.

Is there any configuration available that I might use to force the generated
classes to be loaded by the same class loader of the apps build time

PS: Note that the javassist.ClassPool instance that hosts the generated
classes is scoped on the jars of my application (as opposed to being scoped
on the default javassist ClassPool that might be loaded by a parent
classloader in case the application server loads the javassist library for
other reasons - like WebSphere 8.5 does). 

View this message in context:
Sent from the Users mailing list archive at

View raw message