Yes. What your doing is not dynamic class loading ala RMI annotated
codebases. Your using the WebServer as the application class loader. I
fixed a problem with the RMI dynamic class loading as well as a problem
where class identity was not associated with the server side jar from which
the class was loaded. There can be multiple deployments of an application that
use a class named se.benefit.rita.checkout.client.Client and the request you show
below is amiguous. I can look at restoring the previous behavior if the request
is not for an annotated class.
----- Original Message -----
From: "Lennart Petersson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 20, 2001 4:25 PM
Subject: SV: [JBoss-user] Dynamic classloading
he he he... just tested in 2.4 and it is no longer working :-/ Before i was running a
2.2.something... and it worked ok.
Why? Well looking in WebServer.java i see some 'crap' added by Scott (just kidding :-)
where he is splitting the requested class
name into a classloader key and a file path. So when i'm trying to dynamically load
'se.benefit.rita.checkout.client.Client' it
takes 'se' as the classloader key and 'benefit.rita.checkout.client.Client' as the
class which of course is not found. See this
screen shot:
[Default] WebServer: raw path=GET /se/benefit/rita/checkout/client/Client.class
HTTP/1.1
[Default] WebServer: loaderKey = se/
[Default] WebServer: filePath = benefit/rita/checkout/client/Client.class
[Default] WebServer: loader = null
[Default] WebServer: loading className = benefit.rita.checkout.client.Client
Any ideas Scott?
/Lennart
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
