Thanks for the tip on Reggie, good idea.
I did think about deprecating LookupLocator, but Serialization and inheritance
makes it impractical, the next best thing is change it to use Disco V2.
LookupLocator has a dual purpose, one an address to find a registrar and
secondly to retrieve
, for
migration purposes only.
Doing so will allow LookupLocator to function using either Discovery V1
or V2.
This also reduces code duplication, presently there are two
implementations of client side Discovery V1, this will reduce that to
one implementation only.
Regards,
Peter.
ConstrainableLookupLocator is already a compatible replacement for
LookupLocator. Just mark LookupLocator as deprecated and don’t waste any time
on it.
We might want to think about changing Reggie so it defaults to DiscoveryV2.
Right now v1 is the default.
Greg Trasuk.
On Jun 24, 2014
On 5 January 2013 05:10, Gregg Wonderly gregg...@gmail.com wrote:
LookupLocator is not something that should be passed around. It is
information that indicates a destination. The URL/URI form is all we should
plan for, for the future. This means that all dynamically discovered
On Jan 5, 2013, at 3:25 AM, Dan Creswell dan.cresw...@gmail.com wrote:
On 5 January 2013 05:10, Gregg Wonderly gregg...@gmail.com wrote:
LookupLocator is not something that should be passed around. It is
information that indicates a destination. The URL/URI form is all we should
plan
LookupLocator, but just move to a multi-protocol lookup facility.
Currently we're restricted to jini://host:port URI syntax in LookupLocator,
although we have various options for discovery, these are goverened by
constraints, but then you have the problem of the client and server being
, or
programmatically via a security based authorization. Then, we can use
LookupLocator, but just move to a multi-protocol lookup facility.
Currently we're restricted to jini://host:port URI syntax in LookupLocator,
although we have various options for discovery, these are goverened
. That is, an abstract class that has pluggable protocol
handlers which could be added to the system via configuration, or
programmatically via a security based authorization. Then, we can use
LookupLocator, but just move to a multi-protocol lookup facility.
Currently we're restricted to jini
These methods could easily return jini://host:port for standard Jini
unicast
discovery, this allows a lot more freedom for future expansion of
discovery
methods, for very little effort.
How would you see these being used in a real system? Would I want
these URL's on the Registrar? See,
task best handled via a tool operating on an Admin
interface or similar.
I suppose the use case for asking the ServiceRegistrar for a URL
(similar to LookupLocator) is weak, the client has a copy via multicast
discovery or configuration anyway, future methods might include dns-srv
records.
I
but is that the best way? As I say, feels to me like an
Admin/Config task best handled via a tool operating on an Admin
interface or similar.
I suppose the use case for asking the ServiceRegistrar for a URL (similar to
LookupLocator) is weak, the client has a copy via multicast discovery
On Jan 2, 2013, at 635AM, Dan Creswell wrote:
These methods could easily return jini://host:port for standard Jini
unicast
discovery, this allows a lot more freedom for future expansion of
discovery
methods, for very little effort.
How would you see these being used in a real
Oh yeah, I remember this one!
I reckon we could avoid that table with a simple exponential back-off
algorithm and then have a means to cap/set a maximum period of time
programmatically or via config or both.
On 2 January 2013 15:49, Dennis Reedy dennis.re...@gmail.com wrote:
On Jan 2, 2013, at
is similar to MatchSet from JavaSpace05, it allows local
filtering of ServiceItems (with only Entry's unmarshalled), delayed
unmarshalling and stream like retrieval of ServiceItems.
Well, I've been considering how LookupLocator is restricted to
jini://host:port based URI and figured
On 14-11-12 03:57, Gregg Wonderly wrote:
Of course, the practical matter, is that in this day and age, server
port numbers indicate specific types of services for the things in
/etc/services. But, really, we should move the whole discovery
business away from socket creation parameters and into
Indeed, I feel there's something slightly broken design-wise in adding a
SocketFactory parameter to LookupLocator.
See the URL basically defines the kind of connectivity (consider http
versus https) and thus the kind of socket used. It would be possible, for
example, to pass a socket factory
On 14-11-12 10:49, Dan Creswell wrote:
Which implies a socket factory isn't required because there's only one way
to do unicast and it's all taken care of under the covers.
A socketfactory is also the place to post process Sockets [1]. So if you
want to keep Socket, there is no reason to do
Reading over the comments, we all appear to be agreeing on Gregg's
approach, in that case I'll clean up LookupLocator before release, then
we can look at how we can implement a configurable deployment mechanism.
Regards,
Peter.
On 14/11/2012 8:28 PM, Dan Creswell wrote:
...
On 14 November
On 14-11-12 11:50, Peter Firmstone wrote:
Reading over the comments, we all appear to be agreeing on Gregg's
approach, in that case I'll clean up LookupLocator before release, then
we can look at how we can implement a configurable deployment mechanism.
I was against removing the SocketFactory
Is it possible for you to subclass LookupLocator and override the
getRegistrar method?
Alternatively you could subclass ConstrainableLookupLocator and subclass
com.sun.jini.discovery.internal.MultiIPDiscovery, this is far simpler to
implement and would allow you to inject a socket
On 14-11-12 13:52, Peter Firmstone wrote:
I'm familiar with the ConstrainableLookupLocator code, I could knock it
up for you in about 10 min, I actually did this when I realised the
SocketFactory in LookupLocator wasn't being used by
LookupLocatorDiscovery or ConstrainableLookupLocator, then I
On 14/11/2012 11:00 PM, Simon IJskes - QCG wrote:
On 14-11-12 13:52, Peter Firmstone wrote:
I'm familiar with the ConstrainableLookupLocator code, I could knock it
up for you in about 10 min, I actually did this when I realised the
SocketFactory in LookupLocator wasn't being used
from socket creation parameters and into a mechanism using an
interface or abstract class so that through Configuration, it would be
pluggable at deployment.
Gregg
On Nov 13, 2012, at 6:05 PM, Peter j...@zeus.net.au wrote:
Hi Greg,
LookupLocatorDiscovery uses LookupLocator to find
Presently LookupLocator is practically a URI of the form
jini://hostname:port
LookupLocator is constructed during multicast discovery at the client.
ConstrainableLookupLocator is a subclass that implements constraints.
LookupLocatorDiscovery also accepts LookupLocator to perform unicast
On 13-11-12 14:31, Peter Firmstone wrote:
Oh I found a bug in LookupLocator on ARM btw:
Ok, we should leave the ARM port for the next release then.
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
One possibility may be to consider makeing LookupLocator an interface
given that there are only two methods that really matter.
Implementations could support a socket based protocol like it is now
and other protocols in the future. I know that this would affects
current deployments; but it gives
Hi Greg,
LookupLocatorDiscovery uses LookupLocator to find a Registrar, however it only
uses the host name and port, it doesn't use LookupLocator to perform discovery.
LookupLocator requires a defined static port, otherwise 4160 is used if no port
is defined.
Recently a SocketFactory
or abstract
class so that through Configuration, it would be pluggable at deployment.
Gregg
On Nov 13, 2012, at 6:05 PM, Peter j...@zeus.net.au wrote:
Hi Greg,
LookupLocatorDiscovery uses LookupLocator to find a Registrar, however it
only uses the host name and port, it doesn't use LookupLocator
28 matches
Mail list logo
