You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter Firmstone <ji...@zeus.net.au> on 2011/11/16 00:10:20 UTC
Thinking Aloud - fundamental challenges of jvm based distributed
computing
With River, we execute separately compiled bytecodes at runtime by
taking advantage of discovery and lookup services - distributed
dependency injection. Service API, Java and Jini Platforms provide
compatibility, for separately compiled components, these are the parent
classes and interfaces that clients and services use for communicating
across compile time boundaries, demarcated by Service API.
Determining classes to be shared between proxy and client namespaces and
identifying what shouldn't be creates challenges for developers, who
currently need to define preferred class lists.
My personal preference is to share as little as possible, how selfish!
The Java platform itself presents issues with Memory isolation,
namespace visibility, class resolution and codebase annotation loss for
proxy's or distributed objects.
proxy - remote reference, implements Remote
distributed object - local copy of an object, serialized, implements
Serializable.
If we share only the Service API, Java and Jini Platform classes and
objects, then we minimise Java platform issues.
Proxy classes that extend services API, java or Jini platform classes
don't need to be visible to the client (the reverse holds true also),
since client code uses the super classes and interfaces in the Service
API, Java or Jini Platform.
In reality client classes and any other libraries are loaded into the
application ClassLoader with the Service API and Jini Platform, so all
these additional classes are also visible to proxy's.
If the proxy uses libraries or has classes in the same namespace as the
client, unless the proxy's classes are preferred, they will be resolved
by the application ClassLoader (the classes may or may not be
compatible), 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.
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.
Some options:
1. Use the extension classloader (command line option, not
/jre/lib/ext/) for ServiceAPI and Jini Platform classses, the
classpath will then not be visible to the proxy's that reside in
child classloaders of the extension classloader. Note classes in
the extension classloader can have reduced permission and don't
have to be AllPermission.
2. OR Create a new child classloader, for the application and all
libraries.
3. OR Use a Subprocess JVM for all smart proxy's (identified as
classes implementing Remote and having codebase annotations), the
JVM has been optimised to share platform class files with
subprocess jvm's for fast startup and less memory consumption.
However this requires reflective proxy's to represent smart
proxy's in the main jvm, the part I haven't figured out yet is how
to have a reflective proxy replaced by a smart proxy when it gets
transferred to another machine. Perhaps it might be possible
using a marker interface on the reflective proxy, however I'll
save that discussion for another thread.
To have any of these work properly would require a container, Tim
Blackman's Jini in a jar https://issues.apache.org/jira/browse/RIVER-342
solves a number of the configuration, command line options and classpath
visibility issues using a new URL scheme, which enables a Jini
application to be run from a jar file.
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?
Regards,
Peter.
Re: Thinking Aloud - fundamental challenges of jvm based distributed computing
Posted by Dan Creswell <da...@gmail.com>.
Inline....
On 15 November 2011 23:10, Peter Firmstone <ji...@zeus.net.au> wrote:
> With River, we execute separately compiled bytecodes at runtime by taking
> advantage of discovery and lookup services - distributed dependency
> injection. Service API, Java and Jini Platforms provide compatibility, for
> separately compiled components, these are the parent classes and interfaces
> that clients and services use for communicating across compile time
> boundaries, demarcated by Service API.
>
> Determining classes to be shared between proxy and client namespaces and
> identifying what shouldn't be creates challenges for developers, who
> currently need to define preferred class lists.
>
Unless we find some means to make that a lot easier....
> My personal preference is to share as little as possible, how selfish!
>
Uh huh, useful default, see above.
> The Java platform itself presents issues with Memory isolation, namespace
> visibility, class resolution and codebase annotation loss for proxy's or
> distributed objects.
>
> proxy - remote reference, implements Remote
> distributed object - local copy of an object, serialized, implements
> Serializable.
>
> If we share only the Service API, Java and Jini Platform classes and
> objects, then we minimise Java platform issues.
>
> Proxy classes that extend services API, java or Jini platform classes don't
> need to be visible to the client (the reverse holds true also), since client
> code uses the super classes and interfaces in the Service API, Java or Jini
> Platform.
>
> In reality client classes and any other libraries are loaded into the
> application ClassLoader with the Service API and Jini Platform, so all these
> additional classes are also visible to proxy's.
>
> If the proxy uses libraries or has classes in the same namespace as the
> client, unless the proxy's classes are preferred, they will be resolved by
> the application ClassLoader (the classes may or may not be compatible), 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.
>
True but, as I'm hinting, the problem is preferred classes aren't
being set up right and that's where we should be focusing IMHO.
> 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.
>
Yep, you could try to solve these problems this way but I have a
pretty strong feel in my gut that it'll be hard work, increase
complexity substantially and be full of holes.
Many of the problems you list ought to be solved in the JDK itself
rather than fudged around with complex classloader structures (we all
know where this goes, see any J2EE container for reference). That
seems like an unlikely possibility so I'd be taking path of least
resistance which appears to be improving the way we deal in preferred
classes and establishing some meaningful defaults for setting up the
necessary manifest entries etc.
You could for example have the proxy share nothing of the platform
bringing with it it's own versions on the basis that makes future
versioning problems minimal. Of course it'll make for big .jars as
downloads but hey ho.
> Some options:
>
> 1. Use the extension classloader (command line option, not
> /jre/lib/ext/) for ServiceAPI and Jini Platform classses, the
> classpath will then not be visible to the proxy's that reside in
> child classloaders of the extension classloader. Note classes in
> the extension classloader can have reduced permission and don't
> have to be AllPermission.
> 2. OR Create a new child classloader, for the application and all
> libraries.
> 3. OR Use a Subprocess JVM for all smart proxy's (identified as
> classes implementing Remote and having codebase annotations), the
> JVM has been optimised to share platform class files with
> subprocess jvm's for fast startup and less memory consumption.
> However this requires reflective proxy's to represent smart
> proxy's in the main jvm, the part I haven't figured out yet is how
> to have a reflective proxy replaced by a smart proxy when it gets
> transferred to another machine. Perhaps it might be possible
> using a marker interface on the reflective proxy, however I'll
> save that discussion for another thread.
>
>
> To have any of these work properly would require a container, Tim
> Blackman's Jini in a jar https://issues.apache.org/jira/browse/RIVER-342
> solves a number of the configuration, command line options and classpath
> visibility issues using a new URL scheme, which enables a Jini application
> to be run from a jar file.
>
> 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?
>
> Regards,
>
> Peter.
>
Re: Thinking Aloud - fundamental challenges of jvm based
distributed computing
Posted by Peter <ji...@zeus.net.au>.
See inline:
----- Original message -----
>
> On Wed, 2011-11-16 at 21:48, Peter Firmstone wrote:
>
> > +1 for Greg's new container too. I've briefly looked at the code and
> > will have some time soon to study it more in depth. Greg, is it
> > possible to integrate security and configuration as well? Is some of
> > the stuff from Tim Blackman's Jini in a jar of use?
>
> The container is designed for:
> - pluggable deployers. One for 'ServiceStarter' services, one for
> surrogates, perhaps one for an annotation-based service API, etc. In
> fact it's a great platform for experimentation, as we can easily create
> deployers to test out various service-creation API approaches. No need
> to standardize on any particular one.
> - pluggable configuration. There is a 'core configuration'in an xml
> file in the bootstrap classpath that further loads other configuration.
> Right now, that 'further configuration' is another xml file in the file
> system, but there's no reason that yet further configuration couldn't be
> pulled from a remote configuration service. So far I'm just solving the
> immediate problem, but trying not to rule out possibilities.
> - pluggable security definition. It'll be easier to explain when I'm
> just a little further on in the implementation.
> - It's actually built on a dependency-injection framework that is sort
> of a minimalist version of Spring or Google Guice. In retrospect I
> probably could have used an existing framework, but was having a good
> time learning about annotations.
Are you using the jsr 330 API annotations? Recent versions of Guice and spring support it, it's a very minimal api.
>
> I haven't looked at "Jini in a jar".
Well worth a look, it allows a user to run a Jini application simply by downloading and running a jar file, it contains the platform, configuration and security config including a key server and has a sysres url scheme to locate resources.
Tim donated it to River last year.
Cheers,
Peter.
>
> I'm pretty close to being able to host "ServiceStarter" services inside
> the container, such that the container hosts its own infrastructure
> (reggie, mahalo, outrigger, etc). Next step will be to make the
> security infrastructure work, then setup monitoring of a deployment
> directory such that applications can be dynamically deployed/undeployed
> (a-la Tomcat or JBoss) by copying them into the deployment directory.
>
> I'll keep you posted...
>
> Greg.
>
>
Re: Thinking Aloud - fundamental challenges of jvm based
distributed computing
Posted by Greg Trasuk <tr...@stratuscom.com>.
Good point, Gregg. Thanks for the input. I've noticed the same thing
with some servers. JBoss seems to do OK with it, so reasonable
behaviour appears possible. I'll make sure to test for it.
Greg Trasuk
On Thu, 2011-11-17 at 09:10, Gregg Wonderly wrote:
> On 11/16/2011 9:27 PM, Greg Trasuk wrote:
> > I'm pretty close to being able to host "ServiceStarter" services inside the
> > container, such that the container hosts its own infrastructure (reggie,
> > mahalo, outrigger, etc). Next step will be to make the security infrastructure
> > work, then setup monitoring of a deployment directory such that applications
> > can be dynamically deployed/undeployed (a-la Tomcat or JBoss) by copying them
> > into the deployment directory. I'll keep you posted... Greg.
>
> As you are working on the deployment mechanisms and deployment detection, think
> about how to keep partial downloads from being loaded and then aborted. Tomcat,
> in particular, has a behavior that when I just scp a .war into the WEB-INF tree,
> if it scans while the copy is in progress, and then starts loading before the
> copy finishes, two bad things happen; 1) the class loading aborts with an EOF or
> other error due to the .WAR file not being complete, and 2) Tomcat will ignore
> the final, complete download if it finishes cleaning up after the download
> completes. You then have to either restart tomcat, or try and copy the .WAR
> again. The service disappears while you straighten things out. The update
> should try and provide an atomic switch between the old version and the new
> version without any loss of service.
>
> Gregg
Re: Thinking Aloud - fundamental challenges of jvm based distributed
computing
Posted by Gregg Wonderly <gr...@wonderly.org>.
On 11/16/2011 9:27 PM, Greg Trasuk wrote:
> I'm pretty close to being able to host "ServiceStarter" services inside the
> container, such that the container hosts its own infrastructure (reggie,
> mahalo, outrigger, etc). Next step will be to make the security infrastructure
> work, then setup monitoring of a deployment directory such that applications
> can be dynamically deployed/undeployed (a-la Tomcat or JBoss) by copying them
> into the deployment directory. I'll keep you posted... Greg.
As you are working on the deployment mechanisms and deployment detection, think
about how to keep partial downloads from being loaded and then aborted. Tomcat,
in particular, has a behavior that when I just scp a .war into the WEB-INF tree,
if it scans while the copy is in progress, and then starts loading before the
copy finishes, two bad things happen; 1) the class loading aborts with an EOF or
other error due to the .WAR file not being complete, and 2) Tomcat will ignore
the final, complete download if it finishes cleaning up after the download
completes. You then have to either restart tomcat, or try and copy the .WAR
again. The service disappears while you straighten things out. The update
should try and provide an atomic switch between the old version and the new
version without any loss of service.
Gregg
Re: Thinking Aloud - fundamental challenges of jvm based
distributed computing
Posted by Greg Trasuk <tr...@stratuscom.com>.
On Wed, 2011-11-16 at 21:48, Peter Firmstone wrote:
> +1 for Greg's new container too. I've briefly looked at the code and
> will have some time soon to study it more in depth. Greg, is it
> possible to integrate security and configuration as well? Is some of
> the stuff from Tim Blackman's Jini in a jar of use?
The container is designed for:
- pluggable deployers. One for 'ServiceStarter' services, one for
surrogates, perhaps one for an annotation-based service API, etc. In
fact it's a great platform for experimentation, as we can easily create
deployers to test out various service-creation API approaches. No need
to standardize on any particular one.
- pluggable configuration. There is a 'core configuration'in an xml
file in the bootstrap classpath that further loads other configuration.
Right now, that 'further configuration' is another xml file in the file
system, but there's no reason that yet further configuration couldn't be
pulled from a remote configuration service. So far I'm just solving the
immediate problem, but trying not to rule out possibilities.
- pluggable security definition. It'll be easier to explain when I'm
just a little further on in the implementation.
- It's actually built on a dependency-injection framework that is sort
of a minimalist version of Spring or Google Guice. In retrospect I
probably could have used an existing framework, but was having a good
time learning about annotations.
I haven't looked at "Jini in a jar".
I'm pretty close to being able to host "ServiceStarter" services inside
the container, such that the container hosts its own infrastructure
(reggie, mahalo, outrigger, etc). Next step will be to make the
security infrastructure work, then setup monitoring of a deployment
directory such that applications can be dynamically deployed/undeployed
(a-la Tomcat or JBoss) by copying them into the deployment directory.
I'll keep you posted...
Greg.
Re: Thinking Aloud - fundamental challenges of jvm based distributed
computing
Posted by Peter Firmstone <ji...@zeus.net.au>.
Dan is right, these issues are Jvm issues, perhaps we should take a wait
and see approach?
Could a service API annotation be of use to assist preferred list
generation? @Service
1. Developer annotates the Service Interface.
2. Modify classdep to identify Service API (the dependencies of the
Service Interface identified by the @Service annotation).
3. Ensure everything other than Service API and it's dependencies are
preferred by the proxy, perhaps using classdep to generate the
preferred list, given the proxy.
4. The developer can remove items from the preferred list to increase
sharing.
On the one hand I'd like to discourage the use of ClassDep, and
encourage better structuring of codebase artifacts, to minimise, if not
eliminate, duplication of classes in jar files. Perhaps we could
provide a tool with a new name, that uses the existing ClassDepend code
(based on ASM) to produce the preferred class list.
I'm impartial to Nic's idea also, use reachable URL's for all code, it
partially solves the codebase annotation loss issue, it doesn't prevent
the classes being loaded into the wrong classloader, which may also
cause version conflicts, but it will enable the object to be
deserialised elsewhere.
Perhaps if we put more focus on codebase annotations. URL - Universal
Resource Locator and that's the problem, it's location is hard coded,
which doesn't allow for inexpensive replication or relocation.
Proxy codebase annotations need to be identity based. We can discover
location if we have an identity.
However this in itself causes some issues, the codebase annotation is
sent with every class, sending large identity key strings could present
a performance problem. Then there's compatibility, how do we know the
jar file is the correct version.
Mike Warres used MD5 checksum's for the identity of a jar file, however
this is no longer considered secure and using a checksum also prevents
changes being made to the jar file after deployment, sometimes there may
be legitimate reasons to do so.
Then we have the Maven option, not everyone is happy about using maven.
Although it's worth noting that new IDE's now load maven projects
without requiring configuration on the developers part.
What if we had a URI (URL Scheme) that consisted of a domain or list of
domains (where to start looking), name and a version (what to look for)
and we define a version scheme to indicate compatibility, to allow
upgrades? Rather than use an MD hash to determine if something has been
modified in transit, why not sign jar files and use DownloadPermission
instead?
If we followed Nic's suggestion and used this type of URI scheme for
codebase annotations, an annotation replaced with an earlier version,
due to classloader resolution, can be replaced by the latest compatible
version of the jar archive when it is re-transferred. Unfortunately
there is no way at present to prevent.
We could use discovery to locate Codebase Services, from the domain
provided and ask that service for the name and version. The codebase
service could be a smart proxy for maven, or uses any popular type of
repository, or even just the latest location of an http based
repository, so we'd need to define a service interface that's relevant
to all types. A CodebaseServiceManager, might manage a list of codebase
services and cache downloaded artifacts.
Perhaps we could use DNS-SD based discovery to locate the codebase
service? This would provide both a local network multicast and internet
DNS-SRV based record search.
Optionally if the codebase service cannot be discovered in the domain
provided, the search could be expanded to use other domains as well.
Domains are typically represented by Group's in Jini, although this
isn't mandatory.
Gregg did some work recently (from memory), with
CodebaseAccessClassloader, a replacement interface for RMIClassLoader
that may also be relevant.
+1 for Greg's new container too. I've briefly looked at the code and
will have some time soon to study it more in depth. Greg, is it
possible to integrate security and configuration as well? Is some of
the stuff from Tim Blackman's Jini in a jar of use?
Thoughts, Ideas, problems or better solutions?
Succinct points:
Niclas Hedhman wrote:
> 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.
>
Greg Trasuk wrote:
> Just between us...
>
> The surrogate container I've been working on in
> http://svn.apache.org/viewvc/river/jtsk/skunk/surrogate/
> is only incidentally a container for surrogates.
<SNIP>
>
>
> For the record, I'm still opposed to the idea of defining "the"
> Jini/River container; I believe the deployment environment is an
> implementation detail, and nothing should prevent the current diversity
> of containers and deployment approaches. Having said that, one of our
> persistent challenges has been the "rocket scientist" nature of getting
> Jini/River up and running, and I believe that a container approach that
> makes packaging service applications as simple as packaging web
> applications will help immensely.
>
Dan Creswell wrote:
> True but, as I'm hinting, the problem is preferred classes aren't
> being set up right and that's where we should be focusing IMHO.
>
>
<SNIP>
> Many of the problems you list ought to be solved in the JDK itself
> rather than fudged around with complex classloader structures (we all
> know where this goes, see any J2EE container for reference). That
> seems like an unlikely possibility so I'd be taking path of least
> resistance which appears to be improving the way we deal in preferred
> classes and establishing some meaningful defaults for setting up the
> necessary manifest entries etc.
>
> You could for example have the proxy share nothing of the platform
> bringing with it it's own versions on the basis that makes future
> versioning problems minimal. Of course it'll make for big .jars as
> downloads but hey ho.
I tend to agree on the ClassLoader structure issues, although I'm
interested in using a subprocess jvm as an Executor, which eliminates
the ClassLoader issue, fixes memory isolation and security visibility
issues, and also might allow for defensive copies (via serialization) of
objects returned from method calls on smart proxy's. But this hasn't
been demonstrated, we don't know how well it performs (memory
consumption) and it creates unnecessary complexity if Oracle decides to
address the jvm's long overdue memory isolation and ClassLoader issues,
then the exercise would be a complete waste of time.
Some interesting Java memory isolation research:
http://www.cs.purdue.edu/homes/peugster/Ribbons/
River container. was: Re: Thinking Aloud - fundamental challenges
of jvm based distributed computing
Posted by Greg Trasuk <tr...@stratuscom.com>.
Just between us...
The surrogate container I've been working on in
http://svn.apache.org/viewvc/river/jtsk/skunk/surrogate/
is only incidentally a container for surrogates. It is really a
generalized container (Harvester v2, if you will) that happens to have
the capability (or will have anyway) to host surrogates. It includes a
refactored version of ClassServer for the purpose of serving out the
classpath (although it could be replaced by a different web server if
necessary). It also includes handling for hosting multiple service
applications under separate classloaders (in fact, not even the Jini API
is shared between them), and facilities for setting up separate
protection domains.
Current status is that it is just about able to host services designed
for deployment under the "ServiceStarter" paradigm, given that they are
packaged into a module with their appropriate classpath components.
To be entirely open, I haven't mentioned it so far, because I wanted to
have a working code drop, then propose it as a separate River
deliverable. But since the topic of containers has showed up, I thought
I'd jump in.
For the record, I'm still opposed to the idea of defining "the"
Jini/River container; I believe the deployment environment is an
implementation detail, and nothing should prevent the current diversity
of containers and deployment approaches. Having said that, one of our
persistent challenges has been the "rocket scientist" nature of getting
Jini/River up and running, and I believe that a container approach that
makes packaging service applications as simple as packaging web
applications will help immensely.
Cheers,
Greg.
On Tue, 2011-11-15 at 22:09, Niclas Hedhman wrote:
> On Wed, Nov 16, 2011 at 7:10 AM, Peter Firmstone <ji...@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
Re: Thinking Aloud - fundamental challenges of jvm based distributed computing
Posted by Mike McGrady <mm...@topiatechnology.com>.
+1
Sent from my iPhone
On Nov 15, 2011, at 7:09 PM, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Wed, Nov 16, 2011 at 7:10 AM, Peter Firmstone <ji...@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
Re: Thinking Aloud - fundamental challenges of jvm based distributed computing
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wed, Nov 16, 2011 at 7:10 AM, Peter Firmstone <ji...@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