river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: static exporter
Date Tue, 02 Mar 2010 16:43:15 GMT
Sim IJskes - QCG wrote:
> Gregg Wonderly wrote:
>> Sim IJskes - QCG wrote:
>>> Hello,
>>> Has anybody ever worked on/with a static class that functions as a 
>>> exporter registry? And, is it a really bad idea?
>>> I would love to be able to do 'mysrv = GlobalExporter.export(myobj);'.
>> I've done this to create tracking of "authenticated" exports that 
>> allow me to free some resources when these objects become unreferenced 
>> or unexported explicitly.
> And whats your view on using it? Did it work, would it be apropriate in 
> River?

What I've found is that if I creat a "JiniIsTheWorld" class, which contains 
"export this object", "get a lease", "get a transaction" "get an exported lease 
listener", "get an exported transaction participant" etc methods/mechanisms, 
then it makes the use of Jini much more obvious to people who have never used 
it.  For interfaces that needed to have a remote implementation exported, the 
method accepts an instance of the interface, and then use 
java.lang.reflect.Proxy to create and exported Object with that interface that 
then delegates to the passed implementation.

I can then put Exporter and exported references into a holding map, and do some 
other things with PhantomReference to see the references expire and do the 
unexport to mimic DGC etc.

In doing this, all the system constraints, known and unknown are managed in one 
place, instead of all over the place.

>> I use single instance instead of static instance as my model though so 
>> that I can create test instances and do particular injections for 
>> other reasons too.
> So this means, 'mysrv = GlobalExporter.getExporter().export(myobj);' yes?
> And what do you think about a GlobalExporter with a list of exporters 
> with priorities, who are allowed to have a go in order of priority until 
> one exports? Would you still use a single instance?

The Configuration mechanism is meant to provide the plug-ability of all the JERI 
bits into an application.  At some levels of your code, you may no longer have a 
Configuration visible, and for testing or other reuse, being able to substitute 
implementation is a good thing.  Over the years, I've found it more easily 
managed using an instance of some type of factory or delegating object.

Gregg Wonderly

View raw message