Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: converting RegistrarImpl to public class
Date: Mon, 10 Jan 2011 14:27:36 -0500
Message-ID: 
 <77F1E32F67C8D5479858C0C7E93EB46504BBF15A@WAL-MAIL.global.avidww.com>
In-Reply-To: <4D2AD1DF.3070407@qcg.nl>
Thread-Topic: converting RegistrarImpl to public class
Thread-Index: AcuwqTBhR8pIe4arQ5qcWTY+GzgQWQAUpcYg
References: <4D284C27.2090309@qcg.nl>
	<AANLkTi=8gbv_qfXofvUDnE9MJJHoZ_xHOMq7vDdLR0H6@mail.gmail.com>
	<4D28514A.7020804@qcg.nl>	<4D286AE7.8070101@zeus.net.au>
	<4D29936D.5020905@qcg.nl>
 <AANLkTi=ERa1q6J=5CE3xkMBunZU1BiPRnugvxXBcXHr0@mail.gmail.com>
 <4D2AD1DF.3070407@qcg.nl>
From: "Christopher Dolan" <christopher.dolan@avid.com>
To: <river-dev@incubator.apache.org>

I would strongly support a change to 'public' with a 'protected'
constructor.  Currently my RegistrarImpl subclass has to live in the
com.sun.jini.reggie package, which I find distasteful.  The primary
purpose of that subclass is to have a public constructor, so I would
also be happy if RegistrarImpl had a public constructor (or factory
method).

Chris

-----Original Message-----
From: Sim IJskes - QCG [mailto:sim@qcg.nl]=20
Sent: Monday, January 10, 2011 3:31 AM
To: river-dev@incubator.apache.org
Subject: Re: converting RegistrarImpl to public class

On 09-01-11 12:29, Dan Creswell wrote:
> For a simple "make something local" exercise, slight tweaks to the
service
> impl like making it public are enough. For more in depth stuff, as
you're
> suggesting (and as done with Blitz's LocalSpace) there tends to be a
lot
> more wiring and infrastructure that doesn't necessarily fit well
inside of
> the core service impl.

I agree that the wiring does not necessary have to be in the
river-runtime.

> A factory makes it nice and easy to get what one is after whilst
providing a
> layer of separation that affords a lot of flex in building exactly
what's
> required.

Shall we go for a 'protected' for both registrar implementations then?=20
Because if you want to work with the binary dist, and stay out of the=20
package space for river, work without reflection, you need to have some=20
access.

Gr. Sim

--=20
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397