I'm just thinking out loud. Adding constructor args can quickly cause
variations to come about that change the number of constructors in the API in
quadratic or worse rates.
It seems that we need to add two constructors in this case so that the default
port for lookup doesn't have to be "knowledge" that is always reflected in the
constructors if you use a factory. Thoughts on one vs two constructors? I
haven't looked at your patch.
Gregg Wonderly
Sim IJskes - QCG wrote:
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
