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:08:13 GMT

     [ 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 <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