Hi,
Tom Cook wrote:
> On Thu, 15 Feb 2001, you wrote:
> > Problem is, while it would make
> > sense to serve the interface classes
> > (but not implementation classes) of
> > the EJB jar, there are no sure way
> > to differentiate what classes are
> > interface and which are
> > implementation.
>
> What about having a peek at the deployment descriptor? That's a fairly sure
> way of finding out which is which...
The interface of a bean is not just
the remote and home interfaces.
It can also include the primary key
of an entity bean, and value classes
used for passing data.
> But why not just expose everything to the outside world? What if the developer
> _wants_ to expose all of the classes?
Could also ask: What if the developer
does _not_ want to expose all of the
classes?
Bean implementation can contain
trade secrets that clients should not
have access to.
> Anyway, it is not the interfaces which are missing because this code:
>
> URL urls[] = new URL[1];
> urls[0] = new URL( "http://localhost:8083" );
> ClassLoader cl = new URLClassLoader( urls );
> Thread.currentThread().setContextClassLoader( cl );
> System.setSecurityManager( new RMISecurityManager );
> System.out.println( "Set class loader and security manager." );
>
> URL classResource = cl.getResource( "my.home.interface" );
> System.out.println( classResource.toString() );
>
> Class homeClass = cl.loadClass( "my.home.interface" );
> System.out.println( "Home interface class loaded." );
>
> InitialContext ctx = new InitialContext();
> Object o = ctx.lookup( "my_home_interface_in_jndi" );
> my.home.interface if = (my.home.interface)PortableRemoteObject.narrow( o,
>my.home.interface.class );
>
> gives this output:
>
> Set class loader and security manager.
> http://localhost:8083/my/home/interface.class
> Home interface class loaded
> java.lang.ClassNotFoundException: my.home.interface at...
>
> which is very strange indeed, I know, but there it is. I thought that when I
> ran it in a debugger, it failed loading javax.ejb.EJBHome or something like
> that, but maybe I was wrong.
Yes, I was wrong here.
When looking at the source, is seems
that the webserver is serving any class
it can find in any application's class
loader. Looks like it also is serving
any class found in classloaders of
applications that no longer exist.
As for the code above: I would try to
use introspection on variables "o" and
"homeClass". "o" should implement the
same my.home.interface as "homeClass".
> > I seperate my EJBs in different jars
> > for implementation and interface.
> > EJB implementation jars go to deploy
> > directory, while interface jars go
> > in classpath.
>
> Don't you have to restart the server every time you change an interface then?
Yes, if I have the interface in the
server's classpath. That is what I
currently do.
But I could also add the interface
to the implementation jar classpath
(manifest file), and any bean jars
that use the interface to avoid
restarting the server.
But any clients that have already
downloaded interface classes that
are changed will have to be restarted
anyway.
If we are lucky, these clients just
crash, but they might not.
Consider the following remote
interface change that will not make
clients crash:
<< /** Set time in seconds. */
<< void setTime(int seconds)
--
>> /** Set time in milliseconds. */
>> void setTime(int millis)
> Even Weblogic 5 gives that sort of re-deploy, doesn't it?
Don't know Weblogic.
But what would they do about clients
that already downloaded old classes
that have been replaced?
Best Regards,
Ole Husgaard.
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
