river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Thinking Aloud - fundamental challenges of jvm based distributed computing
Date Wed, 16 Nov 2011 03:09:22 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message