You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "Hudson (JIRA)" <ji...@apache.org> on 2012/11/14 12:12:12 UTC
[jira] [Commented] (RIVER-414) LookupLocator needs cleaning up
[ 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