dkateros
2013-08-04 23:17:22 UTC
Hello,
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
issue).
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
classes?
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: http://apache-geronimo.328035.n3.nabble.com/Classes-generated-on-runtime-javassist-classloader-issue-tp3987097.html
Sent from the Users mailing list archive at Nabble.com.
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
issue).
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
classes?
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: http://apache-geronimo.328035.n3.nabble.com/Classes-generated-on-runtime-javassist-classloader-issue-tp3987097.html
Sent from the Users mailing list archive at Nabble.com.