river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike McGrady <mmcgr...@topiatechnology.com>
Subject Re: Thinking Aloud - fundamental challenges of jvm based distributed computing
Date Wed, 16 Nov 2011 03:42:55 GMT
+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:
> 
>> If we share only the Service API, Java and Jini Platform classes and
>> objects, then we minimise Java platform issues.
>> 
> 
> I must have done something wrong in the past then, because that was always
> the case for me.
> 
> 
>> if the proxy is later transferred to another node in the network, the
>> codebase annotations have been lost because the classes were loaded by the
>> 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.
>> 
> 
> 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.
> 
> 
>> 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 network
>> to support multicast discovery.
>> 
> 
> Agree that it might help, or not...  If you are forced to understand
> classloader mechanics, I think you will learn to design better applications.
> 
> 
>> Some options:
>> 
>> 1. Use the extension classloader
>> 2. OR Create a new child classloader, for the application and all
>>    libraries.
>> 3. OR Use a Subprocess
>> 
> 
> Not sure I like any of those.
> 
> 
> 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?
>> 
>> What are the requirements for such a container?
>> 
> 
> There a bunch of containers already, why not then discuss the pros/cons of
> each and see how what feedback there is.
> 
> 
> Cheers
> -- 
> Niclas Hedhman, Software Developer
> http://www.qi4j.org - New Energy for Java
> 
> I live here; http://tinyurl.com/3xugrbk
> I work here; http://tinyurl.com/6a2pl4j
> I relax here; http://tinyurl.com/2cgsug

Mime
View raw message