Greg Trasuk wrote:
On Sun, 2010-12-12 at 02:39, Peter Firmstone wrote:
Yes, I had noticed the container, interesting.
Do you think it's possible to organise runtime ClassLoader's so Jini's
API, Java and the Service API are loaded with Java's application class
loader, while all implementations are loaded into separate child class
loaders? If we do this, we can keep, service implementations, client
code and proxy's in separate namespaces, forcing them to cooperate using
only Java, Jini's API and Service API. Sort of like having separate
Classpath's for each, many are compiled separately so it makes sense if
they each bring their own lunch and don't step on each others
implementations and libraries etc.
Goes without saying...Also that we don't put every single jar file in
the codebase annotation. Usually it's only the "-api" and "-dl" jar
files, although there might be plain libraries as well.
If done properly, the api exists at the client, so we shouldn't need to
annotate it, I proposed a way of extending Service API in
https://issues.apache.org/jira/browse/RIVER-341
This would allow additional classes not present at the client to be
loaded into the proxy's class loader. Since the deployed client doesn't
have these classes, it only interacts using the Service API.
If there is a buggy implementation class in the original Service API
installed in the client, the extended service API can provide an
implementation class that extends and overrides the object method with
the bug, the client only see's the service API class, while it uses the
implementation class. Polymorphism.
Eg a proxy should bring with it any
additional libraries it needs and not rely on them being present at the
client.
That's automatically handled by the rmi classloader
(PreferredClassLoader I believe) and the appropriate codebase
annotations.
Application libraries shouldn't be visible to the proxy. Sort
of like Preferred Classes, but automatic without configuration.
That's actually up to the application author; in many cases, there is a
need to have a dependent library available locally (e.g. for
business-domain object classes). The PreferredClassLoader mechanism
used by Jeri allows the proxy to require a remotely downloaded class
where it's absolutely necessary.
Sounds like that library should be loaded with the same classloader as
the Service API. Is it typical in this case that the Service API
contain a parameter or return class that is part of a business domain
library?
If Service API depends on anything other than Jini & Java, that also
needs to be included with the service API.
I'd like to provide a mechanism or encourage a practice to load
application (implementation) classes into a child class loader, with a
separate name space to proxy's or other service implementations.
Tell me what you think?
http://labs.oracle.com/techrep/2006/smli_tr-2006-149.pdf
Cheers,
Peter.
