Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of dennis.reedy@gmail.com
 designates 209.85.216.175 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=content-type:mime-version:subject:from:in-reply-to:date
         :content-transfer-encoding:message-id:references:to:x-mailer;
        b=P79xejgELHER9MdtOQOVMvSFiRjNWNnu7ioIpJ95puxritCeTKV576RT8wJZaWc1r/
         HnekWaW+b3zAUXAKJhRaPQohzc/Qy4HLN3EABaNjHvvuQ9Ira5c10NU3NM6WlkOAnkh3
         o4ViAEY2CaZ4V5xDGsJGlB9Mob+bzh3XHKfmA=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
Subject: Re: river.jar
From: Dennis Reedy <dennis.reedy@gmail.com>
In-Reply-To: <1294024192.3904.62.camel@cameron>
Date: Sun, 2 Jan 2011 22:49:05 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <68F908AC-7478-4E0B-81E4-D70F9EB18A33@gmail.com>
References: 
 <868267689-1293812305-cardhu_decombobulator_blackberry.rim.net-1615482016-@bda634.bisx.prod.on.blackberry>
 <4D203C95.1010404@zeus.net.au>
 <AANLkTin+OtGa3jc08L98qTkCw1ftoJmX+X5C1vAGmZ9s@mail.gmail.com>
 <1293986161.3904.13.camel@cameron>
 <AANLkTinLD_3OF2ph8rYLWqSu+4aoeT8Wyrr44rr4yfda@mail.gmail.com>
 <4D212CCE.8000303@zeus.net.au> <1294024192.3904.62.camel@cameron>
To: river-dev@incubator.apache.org

I'm sure I'm missing something, but I'm not sure what a modular build =
has to do with classloading at this point. I would think an initial goal =
of a modular build would be to create the same [1] (or as close to same) =
jars that the one monolithic build produces, but in a modular fashion. =
The approach I was going to take was to create a mulit-module maven =
project similar to the following:

river-\
        | - start (produces start.jar)
        | - platform (produces jsk-platform, jsk-lib.jar and jsk-dl.jar)
        | - outrigger (outrigger.jar, outrigger-proxy.jar)
        | - reggie (reggie, reggie-proxy.jar)
        | etc ...

The various services depend in artifacts produced by platform, names =
could change (as far as the module names and organization of them) but =
the modularity and ensured and it follows a simple convention. Providing =
an assembly would also make it simple to produce the distribution that =
includes the complete River distribution, or it would be fairly easy to =
produce an assembly that includes River with just reggie and outrigger, =
or any combination of the services.

IMO, the approach really simplifies the project structure. Services are =
broken out into their own module, the platform and the current container =
(ServiceStarter as found in start.jar).=20

Not sure if this helps or hinders, its just the way I'm thinking about =
this issue and considering how to address the modularity issue(s).

Regards

Dennis

1. Sans the old jini-core.jar and sun-util.jar

On Jan 2, 2011, at 1009PM, Greg Trasuk wrote:

>=20
> Hi all:
>=20
> Some thoughts inserted inline....
>=20
> Cheers,
>=20
> Greg.
>=20
> On Sun, 2011-01-02 at 20:56, Peter Firmstone wrote:
>> I'm currently experimenting with a modular build, I've laid out the=20=

>> framework in skunk and I've got a local build where I'm trying to =
define=20
>> what to include in the platform.
>>=20
>> The most obvious is to create the platform module based on what's=20
>> included in jsk-platform.jar
>>=20
>> As has been pointed out there's also jsk-lib.jar and  jsk-dl.jar
>>=20
>> Services that utilise the jsk-lib also need to have jsk-dl in their=20=

>> codebase for clients to download.
>>=20
>=20
> The most reasonable starting point for modularity would be (in my mind
> anyway) the definitions of "Infrastructure", "Programming model", and
> "Services" specified in the Jini Architecture specification.=20
> "Infrastructure" and "Programming Model" are roughly reflected by
> 'jsk-platform.jar' and 'jsk-lib.jar', whereas the "Services" are =
roughly
> reflected in 'reggie.jar', 'outrigger.jar', 'mahalo.jar', etc.
>=20
> In other words, I could see separating out the shared services as
> separate builds that essentially depend on 'jsk-lib', 'jsk-platform' =
and
> perhaps one or more 'river-commons-*' modules.
>=20
>> There are also a number of utility classes shared by service=20
>> implementations, included in their proxy's and it wouldn't make sense =
to=20
>> have these duplicated in each service implementation for maintenance=20=

>> reasons.  This also presents an interesting situation, when these=20
>> classes already exist in the client's classpath, the additional =
classes=20
>> are not loaded into the proxy classloader, since the parent =
classloader=20
>> can resolve them,=20
>=20
> Are you sure of that?  Having a quick look for instance at
> 'mahalo-dl.jar', I see that it contains a file called
> 'META-INF/PREFERRED.LIST', which includes Preferred: true for all of
> com.sun.jini.  Similarly in 'jsk-dl.jar' the PREFERRED.LIST include
> Preferred:true for just about everything except the platform classes.=20=

> These settings indicate to JERI's unmarshaller that the classes should
> be from the proxy's codebase rather than the parent classloader.
>=20
>> however that could also introduce versioning=20
>> conflicts, if we have a library that experiences version changes over=20=

>> time.  There's nothing currently that prevents a client from also=20
>> utilising these library classes.
>>=20
>> This is why I think the client needs to be provided with a standard =
way=20
>> of being run from a child classloader of the jini platform class =
loader,=20
>> in this way, a service, proxy and client running within the same jvm,=20=

>> only share the jini platform (& policy) classes, everything else =
becomes=20
>> a private implementation concern, including which version of a =
library=20
>> to use.
>>=20
> Agreed, and the "surrogate" container I'm working on allows for =
separate
> classloaders and protection domains for each application.  So as you =
say
> above, if one "application"  provides a service and another
> "application" consumes that service, they are entirely independent of
> each other.
>=20
>> =46rom a versioning standpoint, we need a clean separation of name =
spaces=20
>> to avoid runtime issues.
>>=20
>> Modularity will reduce the burden of maintenance, but only if done =
properly.
>>=20
>> The most obvious places to break up the codebase are the points of=20
>> abstraction, where dynamic dependency injection is performed, these =
are=20
>> Jini Services and Service Provider Interfaces (not to be confused =
with a=20
>> jini service).
>>=20
>> =46rom observing recent improvements, the classes in com.sun.* change=20=

>> more often than those in net.jini.*, this was my reasoning for=20
>> suggesting including all net.jini.* in the platform, because I wanted =
to=20
>> know your thoughts.  But doing so may drag more of the com.sun.*=20
>> namespace into platform, which is bad, because these are then visible =
in=20
>> all namespaces.
>>=20
>> I've had thoughts of putting platform implementation classes into a=20=

>> child classloader, to make it invisible from client, proxy and =
service=20
>> namespaces, but this also presents its challenges as it requires a=20
>> superclass present in the platform classloader.  This is in some ways=20=

>> similar to the way OSGi exports a package, while keeping =
implementation=20
>> packages private.  Using OSGi to control package visibility is one=20
>> option, there's also netbeans modularity or service providers.  Of=20
>> course mentioning these utilities is akin to provoking off topic=20
>> arguments which shows how strongly people feel about River and Jini, =
but=20
>> I'd first like to discuss the actual problem and listen to solutions.
>>=20
>> Then of course there's also the argument that we should do nothing, =
so=20
>> consider this a thought experiment to discover how it might be done, =
not=20
>> that it will or must be, that can be decided later.
>>=20
>> What are your thoughts?
>>=20
>> Cheers,
>>=20
>> Peter.
>>=20
>> Jeff Ramsdale wrote:
>>> Chiming in here, perhaps off topic...
>>>=20
>>> 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).
>>>=20
>>> -jeff
>>>=20
>>> On Sun, Jan 2, 2011 at 8:36 AM, Greg Trasuk <trasukg@stratuscom.com> =
wrote:
>>>=20
>>>> On Sun, 2011-01-02 at 11:15, Tom Hobbs wrote:
>>>>=20
>>>>> 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.
>>>>>=20
>>>>> 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.
>>>>>=20
>>>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>>=20
>>>> Cheers,
>>>>=20
>>>> Greg.
>>>>=20
>>>>=20
>>>>> On Sun, Jan 2, 2011 at 8:51 AM, Peter Firmstone <jini@zeus.net.au> =
wrote:
>>>>>=20
>>>>>> I agree that dynamic proxy classes should remain dynamic =
downloads, however
>>>>>> much of net.jini.* isn't in the jsk-platform.jar
>>>>>>=20
>>>>>> Should we expand the platform to contain all net.jini.*?
>>>>>>=20
>>>>>> Except for providers? (com.sun.jini.resource.Service, similar to =
Java's
>>>>>> sun.misc.Service and java.util.ServiceLoader)
>>>>>>=20
>>>>>> Perhaps we can include more in the platform and reduce the number =
of jar
>>>>>> archives we've got?
>>>>>>=20
>>>>>> Any thoughts?
>>>>>>=20
>>>>>> Cheers,
>>>>>>=20
>>>>>> Peter.
>>>>>>=20
>>>>>> trasukg@trasuk.com wrote:
>>>>>>=20
>>>>>>> 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.
>>>>>>>=20
>>>>>>> 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
>>>>>>>=20
>>>>>>> Hello,
>>>>>>>=20
>>>>>>> anybody have an objection against a river.jar in the build that =
contains
>>>>>>> all river runtime classes?
>>>>>>>=20
>>>>>>> Gr. Sim
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>=20
>>>>=20
>>>=20
>>>=20
>=20