You can look at the initMetaData code in ContainerMetaData.
We create a new URLClassLoader that points to the jar you supply.
Then the classLoader is set as the
"Thread.currentThread.setContextClassLoader(classLoader)" in
Container.invoke() so that the thread that is fielding your invocation
in the container has the right classloader working for it...
I say this because, unlike what I said yesterday, I don't believe
anymore that this part is buggy, we actually made it very
straightforward (like most of jBoss 1.0 early code). Turns out there is
a bug in the 1.3 VM (SUN, havent tried IBM yet) that doesn't resolve
ProxyClasses quite right on deserialization.. but again that has nothing
to do with the visibility of "normal" classes in that thread.
I recommend you hack the "MethodInvocation, invoke" and try to say
try {
Thread.currentThread().getContextClassLoader().loadClass("You.class.Here");
Tracer.trace("YEP I FOUND IT IN MY CONTEXT");
}
catch {
Tracer.trace("HUH THAT IS STRANGE");
}
right before you "invoke on the target bean and you should see that the
context class loader does hold your thing...
wait..........
does your code (or Xerces) call Class.forName(.....) ????
In that case (although I haven't looked at it, check the java.lang.Class
source) I suspect it might be the same bug as the one we were tracking
yesterday which says that the implementation says "
getLastUserDefinedContext()
which is a "NATIVE" implementation in the VM.
And returns the System, class loader which doesn't see the class since
it is in the context one.
wait.........
you said that this doesn't work even when you put it in the System Class
loader (as in classpath???) that I have a harder time believing...
.. try the above and let me know
marc
Steve Meister wrote:
>
> I'm using the Xerces parser within an EJB deployed under jBoss 1.0.
>
> The Xerces DOM parser has a mechanism wherein you can specify your own
> org.w3c.dom.Document class to be created when you parse an XML file. This is
> done by setting a property in the parser, basically you just give it a
> string containing the fully-qualified classname of a class that implements
> the appropriate interface (or extends their Document implementation). Then,
> when the document is parsed, the class you specify is instantiated in place
> of the Xerces DocumentImpl class.
>
> This all works great outside of an EJB.
>
> Inside an EJB, when I parse the document, I'm getting an error in the midst
> of parsing that leads me to believe that, for some reason, the EJB's
> classloader is not able to find my Document class. Here's the error (which
> appears in the jBoss console):
>
> error java.lang.NoClassDefFoundError
> java.lang.ClassCastException: java.lang.NoClassDefFoundError
>
> and then the stack trace, which I can reproduce if you think it's valuable.
> I've isolated the error as occuring within the Xerces DOMParser.parse
> method, and it DOESN'T occur if I let the Xerces parser use its own
> DocumentImpl class. So the EJB is definitely NOT finding my DocumentImpl
> subclass when the DOMParser is looking for it.
>
> The thing is, not only is that class present in the JAR file which contains
> the EJB, it's also (the same exact version) found within the CLASSPATH used
> by jBoss.
>
> Any ideas why the classloader might not be able to find it? Are there
> security restrictions or other gotcha's with using things like Class.forName
> within an EJB?
>
> Or am I just seeing a generic error report that really has little to do with
> what ACTUALLY happened?
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
