I'm currently experimenting with a modular build, I've laid out the
framework in skunk and I've got a local build where I'm trying to define
what to include in the platform.
The most obvious is to create the platform module based on what's
included in jsk-platform.jar
As has been pointed out there's also jsk-lib.jar and jsk-dl.jar
Services that utilise the jsk-lib also need to have jsk-dl in their
codebase for clients to download.
There are also a number of utility classes shared by service
implementations, included in their proxy's and it wouldn't make sense to
have these duplicated in each service implementation for maintenance
reasons. This also presents an interesting situation, when these
classes already exist in the client's classpath, the additional classes
are not loaded into the proxy classloader, since the parent classloader
can resolve them, however that could also introduce versioning
conflicts, if we have a library that experiences version changes over
time. There's nothing currently that prevents a client from also
utilising these library classes.
This is why I think the client needs to be provided with a standard way
of being run from a child classloader of the jini platform class loader,
in this way, a service, proxy and client running within the same jvm,
only share the jini platform (& policy) classes, everything else becomes
a private implementation concern, including which version of a library
to use.
From a versioning standpoint, we need a clean separation of name spaces
to avoid runtime issues.
Modularity will reduce the burden of maintenance, but only if done properly.
The most obvious places to break up the codebase are the points of
abstraction, where dynamic dependency injection is performed, these are
Jini Services and Service Provider Interfaces (not to be confused with a
jini service).
From observing recent improvements, the classes in com.sun.* change
more often than those in net.jini.*, this was my reasoning for
suggesting including all net.jini.* in the platform, because I wanted to
know your thoughts. But doing so may drag more of the com.sun.*
namespace into platform, which is bad, because these are then visible in
all namespaces.
I've had thoughts of putting platform implementation classes into a
child classloader, to make it invisible from client, proxy and service
namespaces, but this also presents its challenges as it requires a
superclass present in the platform classloader. This is in some ways
similar to the way OSGi exports a package, while keeping implementation
packages private. Using OSGi to control package visibility is one
option, there's also netbeans modularity or service providers. Of
course mentioning these utilities is akin to provoking off topic
arguments which shows how strongly people feel about River and Jini, but
I'd first like to discuss the actual problem and listen to solutions.
Then of course there's also the argument that we should do nothing, so
consider this a thought experiment to discover how it might be done, not
that it will or must be, that can be decided later.
What are your thoughts?
Cheers,
Peter.
Jeff Ramsdale wrote:
Chiming in here, perhaps off topic...
Sometime back (maybe within the past year?) there seemed to be
agreement on removing the ClassPath manifest attributes moving forward
in order to not make assumptions concerning relative jar locations
(e.g. classpath built from local Maven repo).
-jeff
On Sun, Jan 2, 2011 at 8:36 AM, Greg Trasuk <tras...@stratuscom.com> wrote:
On Sun, 2011-01-02 at 11:15, Tom Hobbs wrote:
Am I right in thinking/remembering that, with the exception of the
*-dl.jar files, the only others that are needed are the jsk-*.jar
ones.
I'm pretty sure that many of the JARs contain the same class files, I
think that there's definitely scope to reduce the number JAR files
that the build creates.
I think you might be mistaken about that. The *-dl.jar files often
contain duplications of classes in *.jar files, but that's reasonable
and expected. The few service implementation jar files that I've looked
at contain ClassPath manifest attributes that reference jsk-lib etc.
The only real duplication I'm aware of is in the jini-core.jar,
jini-ext.jar and sun-utils.jar files, that duplicate the contents of
jsk-platform and jsk-lib. This is done for backwards compatability
(that's the way it was in Jini 1.0-days), and could probably be
deprecated at this point, after consulting with the user community.
Cheers,
Greg.
On Sun, Jan 2, 2011 at 8:51 AM, Peter Firmstone <j...@zeus.net.au> wrote:
I agree that dynamic proxy classes should remain dynamic downloads, however
much of net.jini.* isn't in the jsk-platform.jar
Should we expand the platform to contain all net.jini.*?
Except for providers? (com.sun.jini.resource.Service, similar to Java's
sun.misc.Service and java.util.ServiceLoader)
Perhaps we can include more in the platform and reduce the number of jar
archives we've got?
Any thoughts?
Cheers,
Peter.
tras...@trasuk.com wrote:
Isn't that already jsk-platform.jar? I would object to anything that
subverts the dynamic proxy loading concept that is central to Jini.
It is imperative that people don't, for instance, get the
service-registrar proxy impls in their local class path. That would break
compatibility with future or alternate impls.
Cheers,
Greg
------Original Message------
From: Sim IJskes - QCG
To: river-dev@incubator.apache.org
ReplyTo: river-dev@incubator.apache.org
Subject: river.jar
Sent: Dec 31, 2010 10:07 AM
Hello,
anybody have an objection against a river.jar in the build that contains
all river runtime classes?
Gr. Sim
