avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <pe...@apache.org>
Subject Re: Inter-SAR communication
Date Sun, 20 Oct 2002 03:40:15 GMT
On Sun, 13 Oct 2002 23:56, Paul Hammant wrote:
> This Registry thing I have made, will be replaced later with a pure JNDI
> solution (if I can get it working).  The point being that no jar will
> need to be mounted at a low point in the tree as the JNDI classes are
> already in J2SE (the primordial classloader).  It all depends on whether
> I can place instances perfectly in a VM-wide visible JNDI tree rather
> than serialized refs.  Many hint that it is possible...

The issue essentially comes down to where the interfaces for the service are 
stored. If the common service interfaces (and all their parameters) are 
stored in system/common classloader then the services can be shared directly. 
If not then no matter what you do you will need to serialize the calls (even 
if it is just local serialization and deserialization in another classloader 

So how to do this with JNDI? What I would suggest is that you create a class 
with some static Map of services that can be registered or unregistered as 
you want. See JBosses NonSerialialzableFactory (or something) for an example 
of this.

Then you register a Reference in JNDI and associate it with a ObjectFactory. 
The ObjectFactory would then retrieve the object from the 
NonSerialialzableFactory and if the classloader different create a 
local/pipe/whatever connection.

Hmm thats not exactly clear. Maybe if I put it in point for, :)

* Create an AltrmiObjectFactory that implements JNDIs ObjectFactory. It will 
use the local ClassLoader to create a Pipe/local Socket connection to provide 
object to "client".
* Create a NonSerializableFactory (NSF) which stores object reference in a 
static map.
* When registering an Altrmi object into JNDI instead create a ReferenceObject 
(associated with the AltrmiObjectFactory), store the physical object in NSF 
and then bind it to JNDI.
* When the client accesses JNDI it will ask for object. The JNDI provider will 
find the reference and use the factory to dereference the object (thus 
containing the client end of AltRMI object).

Anyways I did this in a previous life and should be able to answer any 
questions you have. However I would suggest you look at JBosses NSF (or 
whatever it is called) as you seem to prefer code snippets ;) The code is a 
bit convoluted but thats just JNDI ;)


Peter Donald
The two secrets to success:
   1- Don't tell anyone everything.

To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>

View raw message