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. Eg a proxy should bring with it any
additional libraries it needs and not rely on them being present at the
client. Application libraries shouldn't be visible to the proxy. Sort
of like Preferred Classes, but automatic without configuration.
Cheers,
Peter.
Greg Trasuk wrote:
On Wed, 2010-12-08 at 21:37, Peter Firmstone wrote:
Usability is a tough problem we need to solve, I recall Dan Creswell
highlighted some relevant issues. If your looking at all the
different down stream projects and want to get their cooperation for
some common functionality, we'll need to get some community buy in.
These people are probably more aware of the pitfalls and I think we need
their insight.
There's all the different containers too. Perhaps it's time we have a
standardised deployment container? So users can choose and migrate
among any of the downstream projects or our own in house simple version
(that supports what you're working on) without lock in.
So, I've been working on a clean-room implementation of the Surrogate
spec. The work so far (mainly some building blocks) is in Subversion
under jtsk/skunk/surrogate.
I concluded early on that hosting Surrogates was really a subset of
hosting plain old services. As a result, the emerging architecture is
that of a container that manages the classloaders and codebase servers,
but that has a pluggable deployment architecture that can support
surrogate packages, "starter-style" packages or other deployment units.
To some extent, this container is "Harvester 2.0"; it reflects my unease
with going through and restructuring the Harvester code for Apache
release (I had thought about contributing Harvester, but decided to do
this new surrogate container instead).
I am envisioning a deployer that would support definition of services
using annotations, much like EJB3 supports, e.g.
public interface HelloInterface {
public String sayHello(String name) throws IOException;
}
@Service
public HelloService implements HelloInterface {
public String sayHello(String name) { return "Hi there " + name); }
/* @Proxy says "Inject my exported proxy here, please!" */
@Proxy
HelloInterface myProxy=null;
}
You would create your services, pack them into a jar file (with an
appropriate manifest) and copy the jar file into the deployment
directory. The deployer then goes through the jar file looking for
@Service annotations and exports them.
The container will also host (with all the codebase crap handled!)
instances of the River infrastructure services (Reggie, Mahalo,
Outrigger, etc). Plus it appears that enabling it for JMX monitoring
and management will not be awfully difficult.
The goal, much like Harvester, is one-shot deployment, with a
programming model that will not seem alien to servlet or EJB
programmers.
So, stand by, the container is starting to come together. Once it's in
a form that can host Reggie and deploy a service or two, I'll let you
know. At that point, I suppose we'll want a catchy name...
Cheers,
Greg.
