Sorry if this is a stupid comment, but why can't you just look at the
ClassLoader for the class referred to by your EJB to see where it's loaded
from?
class MyEJB {
private void debug() {
log.info(MyOtherClass.class.getClassLoader());
}
}
As for ClassLoaders in general, the Parent classloader *always* gets first
crack at loading the bytes (otherwise the java security model is violated).
Since the container is JBoss and JBoss uses Log4J, the bundled 1.1.3 version
will always be loaded before your 1.2Beta3 version. This is an issue with
all Java programs that host other Java programs.
Paul
> -----Original Message-----
> From: David Jencks [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, April 16, 2002 7:19 PM
> To: James Higginbotham
> Cc: [EMAIL PROTECTED]
> Subject: [JBoss-user] Re: Tracing classloading of an EJB
>
>
> On 2002.04.16 21:42:24 -0400 James Higginbotham wrote:
> > Is there any way to trace the classloader for an EJB to
> determine where
> > a class referred to by the EJB is loaded from? I need to
> know how/why an
> > EJB that has a newer version of Log4j (1.2beta3 I think) in
> its EAR is
> > instead getting the version distributed by Jboss (1.1.3)
> instead. Should
> > this actually happen? Shouldn't the EJB's classloader find the newer
> > version in the EAR first?
>
> Not with our classloader. If its already been loaded, it
> stops looking.
> We might be able to implement some way for the server classes
> to be in a
> different classloader than application classes at some time
> in the future,
> but certainly not in 3.0
>
> I'd be interested to know if there are problems running jboss
> on Log4j 1.2.
>
> Thanks
> david jencks.
>
> >
> > Thanks,
> > James
> >
> >
>
> _______________________________________________
> JBoss-user mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-user
>
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user
