Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: neutral (athena.apache.org: 209.147.113.130 is neither permitted
 nor denied by domain of mmcgrady@topiatechnology.com)
References: <4EC2F15C.8080208@zeus.net.au>
 <CADmm+Ke-rOausSxHpP2hCXEDT9-p26fHrmG+2zYga8cXPAQrUg@mail.gmail.com>
In-Reply-To: 
 <CADmm+Ke-rOausSxHpP2hCXEDT9-p26fHrmG+2zYga8cXPAQrUg@mail.gmail.com>
Mime-Version: 1.0 (1.0)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii
Message-Id: <2C095517-7A8A-4527-BB07-EDC93D362B48@topiatechnology.com>
Cc: "dev@river.apache.org" <dev@river.apache.org>
From: Mike McGrady <mmcgrady@topiatechnology.com>
Subject: Re: Thinking Aloud - fundamental challenges of jvm based distributed
 computing
Date: Tue, 15 Nov 2011 19:42:55 -0800
To: "dev@river.apache.org" <dev@river.apache.org>

+1

Sent from my iPhone

On Nov 15, 2011, at 7:09 PM, Niclas Hedhman <niclas@hedhman.org> wrote:

> On Wed, Nov 16, 2011 at 7:10 AM, Peter Firmstone <jini@zeus.net.au> wrote:=

>=20
>> If we share only the Service API, Java and Jini Platform classes and
>> objects, then we minimise Java platform issues.
>>=20
>=20
> I must have done something wrong in the past then, because that was always=

> the case for me.
>=20
>=20
>> if the proxy is later transferred to another node in the network, the
>> codebase annotations have been lost because the classes were loaded by th=
e
>> application class loader and resolved from the class path.  If the 2nd
>> remote node doesn't have the required classes on its classpath, it's game=

>> over.
>>=20
>=20
> Well, not necessarily. I used http:// URLs as the classpath for the entire=

> application (yes, in its own child to the system classloader). Classpath
> annotations worked well. I could imagine that a River container has a
> webserver built--in and serving its own classes to needing clients.
>=20
>=20
>> This problem could be solved if the Classpath isn't visible to the proxy,=

>> only the ServiceAPI, Java and Jini Platform classes, so developers don't
>> have to understand ClassLoader visibility and preferred classes and may
>> instead just focus on developing services and getting their OS and networ=
k
>> to support multicast discovery.
>>=20
>=20
> Agree that it might help, or not...  If you are forced to understand
> classloader mechanics, I think you will learn to design better application=
s.
>=20
>=20
>> Some options:
>>=20
>> 1. Use the extension classloader
>> 2. OR Create a new child classloader, for the application and all
>>    libraries.
>> 3. OR Use a Subprocess
>>=20
>=20
> Not sure I like any of those.
>=20
>=20
> Do you think it's time we work towards a standard container?  So that at
>> some point in the future all the downstream projects will be able to
>> support it as well as their existing container?
>>=20
>> What are the requirements for such a container?
>>=20
>=20
> There a bunch of containers already, why not then discuss the pros/cons of=

> each and see how what feedback there is.
>=20
>=20
> Cheers
> --=20
> Niclas Hedhman, Software Developer
> http://www.qi4j.org - New Energy for Java
>=20
> I live here; http://tinyurl.com/3xugrbk
> I work here; http://tinyurl.com/6a2pl4j
> I relax here; http://tinyurl.com/2cgsug