river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: river.jar
Date Mon, 03 Jan 2011 22:31:20 GMT
Dan Creswell wrote:
> Hi Peter,
>
>
> On 3 January 2011 01:56, Peter Firmstone <jini@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?


>
>   
>> 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?

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 <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
View raw message