river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sim IJskes - QCG <...@qcg.nl>
Subject RIVER-325: Use of socket factory in LookupLocator
Date Tue, 10 Nov 2009 16:38:04 GMT
Gregg,

i'm not sure which view you are adressing, but it looks like you prove 
my point. That is, don't use a configuration instance. :-)

The problem with this example is that you force all LookupLocator's to
use the same socketFactory.

If the designers of Jini would have wanted a system-wide SocketFactory 
or a configuration entry there should be some evidence of this. As the 
Endpoints show us, they use SocketFactories and no Configuration entries.

Gr. Sim

Gregg Wonderly wrote:
> I assume that you want to create a TCP socket factory that will do 
> something special with connection management?  Can you describe what you 
> need the factory to do?
> 
> Practically, expanding the constructor arguments is something to always 
> consider carefully.  Adding a Configuration argument would allow the 
> obvious construction technique shown below.
> 
> net.jini.core.discovery.LookLocator {
>     socketFactory = new MySocketFactory();
> }
> 
> org.my.something.Service {
>     locators = new LookupLocator[] {
>         new LookupLocator("jini://my.first.host",this);
>     };
> }
> 
> The problem is that if a factory is required for one instance, and not 
> another, how do you convey this so that things can work correctly?
> 
> Gregg Wonderly


-- 
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Leiden: 28088397


Mime
View raw message