You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "Peter Firmstone (JIRA)" <ji...@apache.org> on 2012/11/14 12:04:12 UTC
[jira] [Created] (RIVER-414) LookupLocator needs cleaning up
Peter Firmstone created RIVER-414:
-------------------------------------
Summary: LookupLocator needs cleaning up
Key: RIVER-414
URL: https://issues.apache.org/jira/browse/RIVER-414
Project: River
Issue Type: Improvement
Components: net_jini_core
Affects Versions: River_2.2.0
Reporter: Peter Firmstone
Fix For: River_2.2.1
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (RIVER-414) LookupLocator needs cleaning up
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Firmstone updated RIVER-414:
----------------------------------
Description:
Dan Creswell wrote:
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 that produces sockets that aren't
"compatible" with the URL type.
The documentation would suggest there is only one type of URL acceptable:
The syntax of the URL must be that of a *hierarchical*
URI<http://java.sun.com/j2se/1.4.2/docs/api/java/net/URI.html> with
a *server-based naming authority*. Requirements for the components are as
follows:
- A *scheme* of "jini" must be present.
- A *server-based naming authority* must be present; *user-info* must
not be present. The *port*, if present, must be between 1 and 65535
(both included). If no port is specified, a default value of 4160 is
used.
- A *path* if present, must be "/"; *path segment*s must not be present.
- There must not be any other components present.
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.
Thus adding a socket factory implies a change to the mechanism for
discovery and support for different kinds of URLs etc.
So, when we added a socket factory, what were we trying to do? That might
then tell us a bit more about the vector of solutions we're looking at.
On 14 November 2012 02:57, Gregg Wonderly <ge...@cox.net> 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 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 <ji...@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 to
> > perform discovery.
>> > >
>> > > LookupLocator requires a defined static port, otherwise 4160 is used if
> > no port is defined.
>> > >
>> > > Recently a SocketFactory was added to LookupLocator, however this is
> > only used by the obsolete version 1 discovery in LookupLocator and not by
> > LookupLocatorDiscovery.
>> > >
>> > > LookupLocator is also Serializable, but it's constructed with multicast
> > discovery where the SocketFactory cannot be transferred.
>> > >
>> > > It seems we'd be better off using URI, in fact when LookupLocator is
> > constructed, it uses URI to assist parsing the host name and port.
>> > >
>> > > Instead of mandating Socket we could consider using a jeri Endpoint.
>> > >
>> > > A URI scheme provider could be used for plugging in different schemes to
> > obtain the Endpoint.
>> > >
>> > > This might allow the use of maven provisioning or similar to obtain an
> > unknown scheme or Endpoint.
>> > >
>> > > This would allow plugging in dns-srv URI's and other unknown future
> > protocols for obtaining a registrar proxy.
>> > >
>> > > A default jini://host:port provider can be supplied for backward
> > compatibility.
>> > >
>> > > Thoughts?
>> > >
>> > > Peter.
>> > >
>> > >
>> > > ----- Original message -----
>>> > >>
>>> > >> On Tue, 2012-11-13 at 08:31, Peter Firmstone wrote:
>>>> > >>> 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
>>>> > >>> discovery using constraints.
>>>> > >>>
>>>> > >>> We modified LookupLocator to accept a SocketFactory via a constructor
>>>> > >>> (approx 2 years ago).
>>>> > >>>
>>>> > >>> LookupLocator is built around tcp, but there are obviously many
> > protocols.
>>>> > >>>
>>>> > >>> Any ideas?
>>> > >>
>>> > >> I'm not sure I understand the question. Is there a problem with
>>> > >> LookupLocator?
>>> > >>
>>> > >> Cheers,
>>> > >>
>>> > >> Greg.
> LookupLocator needs cleaning up
> -------------------------------
>
> Key: RIVER-414
> URL: https://issues.apache.org/jira/browse/RIVER-414
> Project: River
> Issue Type: Improvement
> Components: net_jini_core
> Affects Versions: River_2.2.0
> Reporter: Peter Firmstone
> Fix For: River_2.2.1
>
>
> Dan Creswell wrote:
> 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 that produces sockets that aren't
> "compatible" with the URL type.
> The documentation would suggest there is only one type of URL acceptable:
> The syntax of the URL must be that of a *hierarchical*
> URI<http://java.sun.com/j2se/1.4.2/docs/api/java/net/URI.html> with
> a *server-based naming authority*. Requirements for the components are as
> follows:
> - A *scheme* of "jini" must be present.
> - A *server-based naming authority* must be present; *user-info* must
> not be present. The *port*, if present, must be between 1 and 65535
> (both included). If no port is specified, a default value of 4160 is
> used.
> - A *path* if present, must be "/"; *path segment*s must not be present.
> - There must not be any other components present.
> 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.
> Thus adding a socket factory implies a change to the mechanism for
> discovery and support for different kinds of URLs etc.
> So, when we added a socket factory, what were we trying to do? That might
> then tell us a bit more about the vector of solutions we're looking at.
> On 14 November 2012 02:57, Gregg Wonderly <ge...@cox.net> 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 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 <ji...@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 to
> > > perform discovery.
> >> > >
> >> > > LookupLocator requires a defined static port, otherwise 4160 is used if
> > > no port is defined.
> >> > >
> >> > > Recently a SocketFactory was added to LookupLocator, however this is
> > > only used by the obsolete version 1 discovery in LookupLocator and not by
> > > LookupLocatorDiscovery.
> >> > >
> >> > > LookupLocator is also Serializable, but it's constructed with multicast
> > > discovery where the SocketFactory cannot be transferred.
> >> > >
> >> > > It seems we'd be better off using URI, in fact when LookupLocator is
> > > constructed, it uses URI to assist parsing the host name and port.
> >> > >
> >> > > Instead of mandating Socket we could consider using a jeri Endpoint.
> >> > >
> >> > > A URI scheme provider could be used for plugging in different schemes to
> > > obtain the Endpoint.
> >> > >
> >> > > This might allow the use of maven provisioning or similar to obtain an
> > > unknown scheme or Endpoint.
> >> > >
> >> > > This would allow plugging in dns-srv URI's and other unknown future
> > > protocols for obtaining a registrar proxy.
> >> > >
> >> > > A default jini://host:port provider can be supplied for backward
> > > compatibility.
> >> > >
> >> > > Thoughts?
> >> > >
> >> > > Peter.
> >> > >
> >> > >
> >> > > ----- Original message -----
> >>> > >>
> >>> > >> On Tue, 2012-11-13 at 08:31, Peter Firmstone wrote:
> >>>> > >>> 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
> >>>> > >>> discovery using constraints.
> >>>> > >>>
> >>>> > >>> We modified LookupLocator to accept a SocketFactory via a constructor
> >>>> > >>> (approx 2 years ago).
> >>>> > >>>
> >>>> > >>> LookupLocator is built around tcp, but there are obviously many
> > > protocols.
> >>>> > >>>
> >>>> > >>> Any ideas?
> >>> > >>
> >>> > >> I'm not sure I understand the question. Is there a problem with
> >>> > >> LookupLocator?
> >>> > >>
> >>> > >> Cheers,
> >>> > >>
> >>> > >> Greg.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (RIVER-414) LookupLocator needs cleaning up
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Firmstone resolved RIVER-414.
-----------------------------------
Resolution: Fixed
Fix committed to svn, unfortunately River-414 commit didn't attach.
commit -m "River-414 ..." C:/Users/peter/Documents/NetBeansProjects/peterConcurrentPolicy/src/org/apache/river/impl/net/UriString.java C:/Users/peter/Documents/NetBeansProjects/peterConcurrentPolicy/src/net/jini/core/discovery/LookupLocator.java
Sending C:/Users/peter/Documents/NetBeansProjects/peterConcurrentPolicy/src/net/jini/core/discovery/LookupLocator.java
Sending C:/Users/peter/Documents/NetBeansProjects/peterConcurrentPolicy/src/org/apache/river/impl/net/UriString.java
Transmitting file data ...
Committed revision 1409151.
Revision: 1409151
Author : peter_firmstone
Date : 14/11/2012 9:03:45 PM
River-414
Clean up LookupLocator as per mail list comments, removed SocketFactory prior to release.
==[IDE]== 14/11/2012 9:03:53 PM Committing... finished.
> LookupLocator needs cleaning up
> -------------------------------
>
> Key: RIVER-414
> URL: https://issues.apache.org/jira/browse/RIVER-414
> Project: River
> Issue Type: Improvement
> Components: net_jini_core
> Affects Versions: River_2.2.0
> Reporter: Peter Firmstone
> Fix For: River_2.2.1
>
>
> Dan Creswell wrote:
> 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 that produces sockets that aren't
> "compatible" with the URL type.
> The documentation would suggest there is only one type of URL acceptable:
> The syntax of the URL must be that of a *hierarchical*
> URI<http://java.sun.com/j2se/1.4.2/docs/api/java/net/URI.html> with
> a *server-based naming authority*. Requirements for the components are as
> follows:
> - A *scheme* of "jini" must be present.
> - A *server-based naming authority* must be present; *user-info* must
> not be present. The *port*, if present, must be between 1 and 65535
> (both included). If no port is specified, a default value of 4160 is
> used.
> - A *path* if present, must be "/"; *path segment*s must not be present.
> - There must not be any other components present.
> 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.
> Thus adding a socket factory implies a change to the mechanism for
> discovery and support for different kinds of URLs etc.
> So, when we added a socket factory, what were we trying to do? That might
> then tell us a bit more about the vector of solutions we're looking at.
> On 14 November 2012 02:57, Gregg Wonderly <ge...@cox.net> 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 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 <ji...@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 to
> > > perform discovery.
> >> > >
> >> > > LookupLocator requires a defined static port, otherwise 4160 is used if
> > > no port is defined.
> >> > >
> >> > > Recently a SocketFactory was added to LookupLocator, however this is
> > > only used by the obsolete version 1 discovery in LookupLocator and not by
> > > LookupLocatorDiscovery.
> >> > >
> >> > > LookupLocator is also Serializable, but it's constructed with multicast
> > > discovery where the SocketFactory cannot be transferred.
> >> > >
> >> > > It seems we'd be better off using URI, in fact when LookupLocator is
> > > constructed, it uses URI to assist parsing the host name and port.
> >> > >
> >> > > Instead of mandating Socket we could consider using a jeri Endpoint.
> >> > >
> >> > > A URI scheme provider could be used for plugging in different schemes to
> > > obtain the Endpoint.
> >> > >
> >> > > This might allow the use of maven provisioning or similar to obtain an
> > > unknown scheme or Endpoint.
> >> > >
> >> > > This would allow plugging in dns-srv URI's and other unknown future
> > > protocols for obtaining a registrar proxy.
> >> > >
> >> > > A default jini://host:port provider can be supplied for backward
> > > compatibility.
> >> > >
> >> > > Thoughts?
> >> > >
> >> > > Peter.
> >> > >
> >> > >
> >> > > ----- Original message -----
> >>> > >>
> >>> > >> On Tue, 2012-11-13 at 08:31, Peter Firmstone wrote:
> >>>> > >>> 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
> >>>> > >>> discovery using constraints.
> >>>> > >>>
> >>>> > >>> We modified LookupLocator to accept a SocketFactory via a constructor
> >>>> > >>> (approx 2 years ago).
> >>>> > >>>
> >>>> > >>> LookupLocator is built around tcp, but there are obviously many
> > > protocols.
> >>>> > >>>
> >>>> > >>> Any ideas?
> >>> > >>
> >>> > >> I'm not sure I understand the question. Is there a problem with
> >>> > >> LookupLocator?
> >>> > >>
> >>> > >> Cheers,
> >>> > >>
> >>> > >> Greg.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (RIVER-414) LookupLocator needs cleaning up
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13497030#comment-13497030 ]
Hudson commented on RIVER-414:
------------------------------
Integrated in River-trunk-jdk7 #126 (See [https://builds.apache.org/job/River-trunk-jdk7/126/])
River-414
Clean up LookupLocator as per mail list comments, removed SocketFactory prior to release. (Revision 1409151)
Result = SUCCESS
> LookupLocator needs cleaning up
> -------------------------------
>
> Key: RIVER-414
> URL: https://issues.apache.org/jira/browse/RIVER-414
> Project: River
> Issue Type: Improvement
> Components: net_jini_core
> Affects Versions: River_2.2.0
> Reporter: Peter Firmstone
> Priority: Minor
> Fix For: River_2.2.1
>
>
> Dan Creswell wrote:
> 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 that produces sockets that aren't
> "compatible" with the URL type.
> The documentation would suggest there is only one type of URL acceptable:
> The syntax of the URL must be that of a *hierarchical*
> URI<http://java.sun.com/j2se/1.4.2/docs/api/java/net/URI.html> with
> a *server-based naming authority*. Requirements for the components are as
> follows:
> - A *scheme* of "jini" must be present.
> - A *server-based naming authority* must be present; *user-info* must
> not be present. The *port*, if present, must be between 1 and 65535
> (both included). If no port is specified, a default value of 4160 is
> used.
> - A *path* if present, must be "/"; *path segment*s must not be present.
> - There must not be any other components present.
> 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.
> Thus adding a socket factory implies a change to the mechanism for
> discovery and support for different kinds of URLs etc.
> So, when we added a socket factory, what were we trying to do? That might
> then tell us a bit more about the vector of solutions we're looking at.
> On 14 November 2012 02:57, Gregg Wonderly <ge...@cox.net> 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 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 <ji...@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 to
> > > perform discovery.
> >> > >
> >> > > LookupLocator requires a defined static port, otherwise 4160 is used if
> > > no port is defined.
> >> > >
> >> > > Recently a SocketFactory was added to LookupLocator, however this is
> > > only used by the obsolete version 1 discovery in LookupLocator and not by
> > > LookupLocatorDiscovery.
> >> > >
> >> > > LookupLocator is also Serializable, but it's constructed with multicast
> > > discovery where the SocketFactory cannot be transferred.
> >> > >
> >> > > It seems we'd be better off using URI, in fact when LookupLocator is
> > > constructed, it uses URI to assist parsing the host name and port.
> >> > >
> >> > > Instead of mandating Socket we could consider using a jeri Endpoint.
> >> > >
> >> > > A URI scheme provider could be used for plugging in different schemes to
> > > obtain the Endpoint.
> >> > >
> >> > > This might allow the use of maven provisioning or similar to obtain an
> > > unknown scheme or Endpoint.
> >> > >
> >> > > This would allow plugging in dns-srv URI's and other unknown future
> > > protocols for obtaining a registrar proxy.
> >> > >
> >> > > A default jini://host:port provider can be supplied for backward
> > > compatibility.
> >> > >
> >> > > Thoughts?
> >> > >
> >> > > Peter.
> >> > >
> >> > >
> >> > > ----- Original message -----
> >>> > >>
> >>> > >> On Tue, 2012-11-13 at 08:31, Peter Firmstone wrote:
> >>>> > >>> 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
> >>>> > >>> discovery using constraints.
> >>>> > >>>
> >>>> > >>> We modified LookupLocator to accept a SocketFactory via a constructor
> >>>> > >>> (approx 2 years ago).
> >>>> > >>>
> >>>> > >>> LookupLocator is built around tcp, but there are obviously many
> > > protocols.
> >>>> > >>>
> >>>> > >>> Any ideas?
> >>> > >>
> >>> > >> I'm not sure I understand the question. Is there a problem with
> >>> > >> LookupLocator?
> >>> > >>
> >>> > >> Cheers,
> >>> > >>
> >>> > >> Greg.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (RIVER-414) LookupLocator needs cleaning up
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Firmstone updated RIVER-414:
----------------------------------
Priority: Minor (was: Major)
> LookupLocator needs cleaning up
> -------------------------------
>
> Key: RIVER-414
> URL: https://issues.apache.org/jira/browse/RIVER-414
> Project: River
> Issue Type: Improvement
> Components: net_jini_core
> Affects Versions: River_2.2.0
> Reporter: Peter Firmstone
> Priority: Minor
> Fix For: River_2.2.1
>
>
> Dan Creswell wrote:
> 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 that produces sockets that aren't
> "compatible" with the URL type.
> The documentation would suggest there is only one type of URL acceptable:
> The syntax of the URL must be that of a *hierarchical*
> URI<http://java.sun.com/j2se/1.4.2/docs/api/java/net/URI.html> with
> a *server-based naming authority*. Requirements for the components are as
> follows:
> - A *scheme* of "jini" must be present.
> - A *server-based naming authority* must be present; *user-info* must
> not be present. The *port*, if present, must be between 1 and 65535
> (both included). If no port is specified, a default value of 4160 is
> used.
> - A *path* if present, must be "/"; *path segment*s must not be present.
> - There must not be any other components present.
> 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.
> Thus adding a socket factory implies a change to the mechanism for
> discovery and support for different kinds of URLs etc.
> So, when we added a socket factory, what were we trying to do? That might
> then tell us a bit more about the vector of solutions we're looking at.
> On 14 November 2012 02:57, Gregg Wonderly <ge...@cox.net> 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 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 <ji...@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 to
> > > perform discovery.
> >> > >
> >> > > LookupLocator requires a defined static port, otherwise 4160 is used if
> > > no port is defined.
> >> > >
> >> > > Recently a SocketFactory was added to LookupLocator, however this is
> > > only used by the obsolete version 1 discovery in LookupLocator and not by
> > > LookupLocatorDiscovery.
> >> > >
> >> > > LookupLocator is also Serializable, but it's constructed with multicast
> > > discovery where the SocketFactory cannot be transferred.
> >> > >
> >> > > It seems we'd be better off using URI, in fact when LookupLocator is
> > > constructed, it uses URI to assist parsing the host name and port.
> >> > >
> >> > > Instead of mandating Socket we could consider using a jeri Endpoint.
> >> > >
> >> > > A URI scheme provider could be used for plugging in different schemes to
> > > obtain the Endpoint.
> >> > >
> >> > > This might allow the use of maven provisioning or similar to obtain an
> > > unknown scheme or Endpoint.
> >> > >
> >> > > This would allow plugging in dns-srv URI's and other unknown future
> > > protocols for obtaining a registrar proxy.
> >> > >
> >> > > A default jini://host:port provider can be supplied for backward
> > > compatibility.
> >> > >
> >> > > Thoughts?
> >> > >
> >> > > Peter.
> >> > >
> >> > >
> >> > > ----- Original message -----
> >>> > >>
> >>> > >> On Tue, 2012-11-13 at 08:31, Peter Firmstone wrote:
> >>>> > >>> 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
> >>>> > >>> discovery using constraints.
> >>>> > >>>
> >>>> > >>> We modified LookupLocator to accept a SocketFactory via a constructor
> >>>> > >>> (approx 2 years ago).
> >>>> > >>>
> >>>> > >>> LookupLocator is built around tcp, but there are obviously many
> > > protocols.
> >>>> > >>>
> >>>> > >>> Any ideas?
> >>> > >>
> >>> > >> I'm not sure I understand the question. Is there a problem with
> >>> > >> LookupLocator?
> >>> > >>
> >>> > >> Cheers,
> >>> > >>
> >>> > >> Greg.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira