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 Mon, 03 Jan 2011 09:10:05 GMT
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....


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