river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Firmstone (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (RIVER-414) LookupLocator needs cleaning up
Date Wed, 14 Nov 2012 11:06:12 GMT

     [ 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 <gergg@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 <jini@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 <gergg@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 <jini@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

Mime
View raw message