So.... On 3 January 2011 22:31, Peter Firmstone <j...@zeus.net.au> wrote:
> Dan Creswell wrote: > >> 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.... >> >> > > Penny for your thoughts on tweaks? > > > Only a foggy thought about the current set of ServiceDescriptors and whether they are best for clients. I could imagine using (and have used) a NonActivatableServiceDescriptor to fire up a client but the need for the object constructor as it is, the spec'ing of codebase and so on feels like overkill or at least there could be a simpler option for clients that don't have codebases etc. > > >> >> >>> 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 >> >> >> >> > > Damn good suggestion, I was actually going over it again yesterday. > > Code base annotation loss is a big problem, when non preferred classes are > resolved by the application class loader, that and code base location > changes over time and codebase configuration problems. > > Preferred class loading for preferred classes doesn't follow the rule of > delegating class loading first to the parent class loader. > > Preferred class loading is used when proxy classes also exist in the parent > class loader. > > The best option appears to be to limit the classes in the application class > loader to jini platform classes, this minimizes the classes that need to be > preferred. > > One problem with using a child class loader for jini platform > implementation classes, is some of these classes may invariably be > serialized with api classes from the platform and need to be deserialized, > if they're not visible to the application class loader... I've been going > over these classes one by one, I'm not finding any serializable classes > yet... I'm starting to think a child class loader for the platform > implementation would be an unnecessary complication. > > Codebase services was intended to be a solution to codebase migration and > configuration issues, the codebase service was found using discovery. > > I've been having some thoughts about a custom URL handler, that utilises > DNS-SRV discovery to locate codebases. Each domain could provide a list of > codebase servers, these could be redundant. > > A custom URL format could have the following information: > > * The domain in which to discover the codebase server. > * The jar archive name (or other file type name). > * A message digest of the file. > * A file size limit. (download is aborted after this limit is exceeded) > * A hashcode of the Server's Subject's certificate (the cert itself > could be too large) > > The Certificate hashcode provides an identity for the URL (which provides a > reasonable probability of being unique when combined with other > information), we might consider using a Subject to uniquely identify a > ClassLoader namespace, to avoid class sharing between proxies with identical > code, but different server subjects. The Subject certificate hashcode would > need to be checked as part of the verification process, albeit after > unmarshalling. > > The problem here is we're bumping into the limitations of the java > platform, which the missing Isolates API was designed to address, identical > classes could be used by separate identities in separate isolates. > > If we didn't have a hashcode relating to the server subject, would it be > reasonable to expect all servers from the same domain to have the same > server Subject? > No real comment other than to say, feels like a narrowing assumption that could provide a nasty surprise later so I would be inclined not to make it. > Cheers, > > Peter. > > 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> >>>> >>> >>> >> >> >> > >
