Hi Peter,
On 3 January 2011 01:56, Peter Firmstone <j...@zeus.net.au> 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. > > 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. > I think the general solution for much of the versioning comes down to "proper" use of PreferredClassLoader. I think probably anything that is generally required/assumed by all of service, proxy and client is platform. Utility classes for service implementations you discuss above possibly aren't platform unless they are used by all services always. > 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. > I imagine that the Service Starter framework would provide support for most of that already. Would still need some tweaks though.... > > 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. > > Okay, so if we're going that way, we all should read Mike Warres' paper way back in the day that covers much of the classloader ball of mud, preferred class loading and outstanding issues: http://labs.oracle.com/techrep/2006/smli_tr-2006-149.pdf > 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >> >> > >
