river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Creswell <dan.cresw...@gmail.com>
Subject Re: river.jar
Date Tue, 04 Jan 2011 09:07:02 GMT
So....

On 3 January 2011 22:31, Peter Firmstone <jini@zeus.net.au> wrote:

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