geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ivan <xhh...@gmail.com>
Subject Re: Classes generated on runtime (javassist) classloader issue
Date Mon, 05 Aug 2013 13:59:03 GMT
It is possible that javassist from the server side was used. Could you try
to use hidden-class in your geronimo-web.xml to prevent using javassist
from Geronimo server.

<*hidden*-*classes*><filter>javassist</filter></*hidden*-*classes*>

Hope it helps.


2013/8/5 dkateros <dkateros@gmail.com>

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



-- 
Ivan

Mime
View raw message