Resent from JBoss-User...
=========================
Hello,
Sorry to insist on this topic... but it is late and I think it is really
strange.
In org.jboss.ejb.ContainerFactory.deploy (line 342 and around), we have
this:
// create the _real_ classloader for this app
ClassLoader cl = new URLClassLoader( jarUrls,
Thread.currentThread().getContextClassLoader() );
app.setClassLoader( cl );
for( int i = 0; i < jarUrls.length; i++ )
deploy( app, jarUrls[ i ], cl );
// Init application
app.init();
// Start application
app.start();
// Add to webserver so client can access classes through dynamic class
downloading
WebServiceMBean webServer = (WebServiceMBean)
BeanProxy.create( WebServiceMBean.class, WebServiceMBean.OBJECT_NAME );
webServer.addClassLoader( cl );
=>
- a new classloader is created for the application
- each jar of the application is deployed thanks to this newly created CL
- the webserver is extended with our new CL so that it is able to also
provide this application classes
BUT when we deploy an application through the deploy directory, jarUrls will
point to a *file* URL (e.g. /c:/jboss/tmp/deploy/default/myBean.jar).
Consequently, when the RMI engine will create the home and remote stub, it
will set its codebase to the URLClassLoader URL and *not* to the webService
URL.
=> the client, potentially located on another host, will try to download
the missing class from a *file path* that does not exist on its system and
not from a http URL (the one of our webservicembean)
Please, tell me that I am wrong... it kills me... ;)
Thank you. Cheers,
Sacha
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
