river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: river.jar
Date Mon, 03 Jan 2011 05:39:02 GMT
That's similar to my thinking.

The reason class loaders are of interest, is the jar archives we produce affect our ability
to segregate these classes into separate class loaders at runtime.

If we put platform implementation classes into a child class loader, they're no longer visible
to proxy's, services or clients, it improves security and prevents implementation changes
breaking application code.

The platform will need a reference to the implementation class loader in order to instantiate
objects. Probably obtained from a static class method. 

Don't let me stop you, by all means please create a maven build, we need to ensure we don't
loose the svn history.

Cheers,

Peter.

----- Original message -----
> I'm sure I'm missing something, but I'm not sure what a modular build has to do
> with classloading at this point. I would think an initial goal of a modular
> build would be to create the same [1] (or as close to same) jars that the one
> monolithic build produces, but in a modular fashion. The approach I was going to
> take was to create a mulit-module maven project similar to the following:
>
> river-\
>                | - start (produces start.jar)
>                | - platform (produces jsk-platform, jsk-lib.jar and jsk-dl.jar)
>                | - outrigger (outrigger.jar, outrigger-proxy.jar)
>                | - reggie (reggie, reggie-proxy.jar)
>                | etc ...
>
> The various services depend in artifacts produced by platform, names could
> change (as far as the module names and organization of them) but the modularity
> and ensured and it follows a simple convention. Providing an assembly would also
> make it simple to produce the distribution that includes the complete River
> distribution, or it would be fairly easy to produce an assembly that includes
> River with just reggie and outrigger, or any combination of the services.
>
> IMO, the approach really simplifies the project structure. Services are broken
> out into their own module, the platform and the current container
> (ServiceStarter as found in start.jar).
>
> Not sure if this helps or hinders, its just the way I'm thinking about this
> issue and considering how to address the modularity issue(s).
>
> Regards
>
> Dennis
>
> 1. Sans the old jini-core.jar and sun-util.jar
>
> On Jan 2, 2011, at 1009PM, Greg Trasuk wrote:
>
> >
> > Hi all:
> >
> > Some thoughts inserted inline....
> >
> > Cheers,
> >
> > Greg.
> >
> > On Sun, 2011-01-02 at 20:56, Peter Firmstone wrote:
> > > 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.
> > >
> >
> > The most reasonable starting point for modularity would be (in my mind
> > anyway) the definitions of "Infrastructure", "Programming model", and
> > "Services" specified in the Jini Architecture specification.
> > "Infrastructure" and "Programming Model" are roughly reflected by
> > 'jsk-platform.jar' and 'jsk-lib.jar', whereas the "Services" are roughly
> > reflected in 'reggie.jar', 'outrigger.jar', 'mahalo.jar', etc.
> >
> > In other words, I could see separating out the shared services as
> > separate builds that essentially depend on 'jsk-lib', 'jsk-platform' and
> > perhaps one or more 'river-commons-*' modules.
> >
> > > 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,
> >
> > Are you sure of that?  Having a quick look for instance at
> > 'mahalo-dl.jar', I see that it contains a file called
> > 'META-INF/PREFERRED.LIST', which includes Preferred: true for all of
> > com.sun.jini.  Similarly in 'jsk-dl.jar' the PREFERRED.LIST include
> > Preferred:true for just about everything except the platform classes.
> > These settings indicate to JERI's unmarshaller that the classes should
> > be from the proxy's codebase rather than the parent classloader.
> >
> > > 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.
> > >
> > Agreed, and the "surrogate" container I'm working on allows for separate
> > classloaders and protection domains for each application.  So as you say
> > above, if one "application"  provides a service and another
> > "application" consumes that service, they are entirely independent of
> > each other.
> >
> > > 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 <trasukg@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 <jini@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.
> > > > > > >
> > > > > > > trasukg@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
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > > >
> > > >
> >
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message