Hi Emmanuel,
here's a brief overview of what is happening.
RIFE does one 'nasty' trick in its classloader that doesn't respect
the standard contract for classloaders. Normally, a classloader is
supposed to first delegate the loading of classes to the parent
classloader (which is this case is the web application's servlet
classloader). However, if RIFE does this, it would not be able to
load any of the web application's classes, since the parent
classloader is able to load them all.
So what RIFE does is artificially trying to determine which classes
and jars are part of the web application alone. It does this by
looking up their resources and checking for the presence of "WEB-
INF". Sadly I wasn't able to find a standard way that allows you to
do this, but this seems to work fine. At that point, all the web app
classes can be automatically instrumented at load time for
continuations and meta data merging.
This problem arises when you have classes in your web applications
that are loaded by other frameworks or libraries (Log4J for example)
outside the scope of RIFE's filter or servlet. If these are accessed
form within the RIFE application, RIFE has to check if the parent
classloader hasn't already loaded them, since loading them twice
would result into errors. This method works fine unless you have
package-private classes that are not loaded outside the RIFE filter,
but that are accessed by classes that are already loaded from within
the RIFE filter. These package-private classes will not be loaded by
the parent classloader, but they will be loaded by RIFE's instead,
creating permission exceptions.
I've tried to find ways around this while still maintaining the ease-
of-use of RIFE's setup, but there's no strategy that I can come up
with that allows solving this problem without extensive (and
expensive) tracking of where the loaded classes belong. This would
have a profound impact on performance.
So the best solution is to move these libraries outside of WEB-INF,
into the standard library of the servlet container. As far as RIFE is
concerned, these are then outside the web application and will not be
loaded by the RIFE classloader.
The best solution now, is to wait a while for Mustang to come out and
in the meantime develop a collection of instrumentation agents and
get rid of the classloader. These agents need to be setup manually in
1.5, but in 1.6 there's a mechanism for them to be automatically and
dynamically added at runtime. The agent does exactly what the
classloader does, change the bytecode for additional functionalities.
However, this will not fully replace RIFE's classloader, since there
are some tricks in there for reloading element implementations, even
if hotswap can'.
Hope this was somewhat clear.
Best regards,
Geert
On 01 May 2006, at 03:03, Emmanuel Okyere wrote:
not that i'm experiencing this, but yes, pls post the specifics.
thanks,
eokyere
On 4/12/06, Eddy Young <[EMAIL PROTECTED]> wrote:
Eddy Young wrote:
> Hi all,
>
> Is there a known classloader-related error between RIFE and Log4J?
Indeed, there was a classloader-related problem between RIFE and
Log4j,
as Geert managed to track down. But, it is debatable whether the
fault
can be attributed to RIFE at all. If you want to know the specifics,
please ask. We can then post a detailed analysis which might even be
useful to troubleshoot similar problems in your applications.
In short, the solution is to move Log4J jar-files from WEB-INF/lib
into
common/lib of the servlet container *and* restart the container.
Eddy
--
http://coding.mu
http://priscimon.com/blog
_______________________________________________
Rife-users mailing list
Rife-users@uwyn.com
http://lists.uwyn.com/mailman/listinfo/rife-users
--
Johann Wolfgang von Goethe - "Character develops itself in the
stream of life."
_______________________________________________
Rife-users mailing list
Rife-users@uwyn.com
http://lists.uwyn.com/mailman/listinfo/rife-users
--
Geert Bevin Uwyn bvba GTalk: [EMAIL PROTECTED]
"Use what you need" Avenue de Scailmont 34 Skype: gbevin
http://www.uwyn.com 7170 Manage, Belgium AIM: geertbevin
gbevin at uwyn dot com Tel: +32 64 84 80 03 Mobile: +32 477 302 599
PGP Fingerprint : 4E21 6399 CD9E A384 6619 719A C8F4 D40D 309F D6A9
Public PGP key : available at servers pgp.mit.edu, wwwkeys.pgp.net
_______________________________________________
Rife-users mailing list
Rife-users@uwyn.com
http://lists.uwyn.com/mailman/listinfo/rife-users
