river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gregg...@gmail.com>
Subject Re: Lookup Service Discovery using DNS?
Date Mon, 25 Jan 2010 16:48:02 GMT
Peter Firmstone wrote:
> Gregg Wonderly wrote:
>> I think that there are lots of choices about service location and 
>> activation of proxies.  The MarshalledObject mechanism allows one to 
>> wrap proxies at any point and make them available for remote 
>> consumption.
>> Downloading a proxy via http instead of Reggie works fine.
> Good point.
>> We need to document things and provide the convienence methods and 
>> classes that will promote standard practices.
> We can set up an experimental documents area on svn, scanned 
> scratchings etc while we're hashing things out?  The crawler lookup 
> service might discard non conformant proxies to assist in promoting 
> standard practices.  The lookup service might also advertise what 
> River platform versions it's compatible with.
Another thought.  The MarshalledObject mechanism seems simple to use, 
but not quite.  The problem is that there is the RMIClassLoaderSPI 
mechanism that requires support for the annotation in the 
MarshalledObject, to already exist.  Further, things that commonly go 
along with the annotation, such as URL protocol support have to already 
exist too.  Thus, any particular Jini deployment or use almost always 
has to be preplanned from the client and server perspective, unless you 
don't use anything different for annotations.

Things like conditional download, cached download etc need to be done in 
ways that are invisible to the system, or they have to be part of your 
planning.  The use of httpmd: for example, requires 
-Djava.protocol.handler.pkgs=net.jini.url on the command line, but what 
if you are not responsible for the JVMs lifecycle?

I still have this gut feeling that we need to rethink how 
MarshalledObject is used and how we might make the whole mechanism 
managed more as a Thread or ThreadPool based mechanism instead of a 
whole JVM mechanism.  It is true that context class loader mechanisms 
help contain the view of foreign classes.  But we need the ability to 
"allow injection" of unmarshalling support classes so that a service can 
be more independent of the clients environment.  I don't have a clear 
view of what yet, I'm just mulling around about this.

Gregg Wonderly

View raw message