Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
From: "Howard M. Lewis Ship" <hlship@comcast.net>
To: "'Jakarta Commons Developers List'" <commons-dev@jakarta.apache.org>
Subject: RE: [HiveMind] extend BuildFactory to use static fields/methods
Date: Wed, 1 Oct 2003 10:08:37 -0400
Message-ID: <016101c38825$82f90070$6501a8c0@ALMIGHTYBEAST>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In-Reply-To: <oprwdamhzg5c7tcy@localhost>
Importance: Normal

You'll see errors logged when there are problems (missing properties, missing values) while
constructing the service.  Later, you'll probably see NullPointerExceptions from within the service
implementation.

That's the general approach inside HiveMind: complain loudly (log an ERROR) but then hobble on ...
not to gloss over the error, but to allow the developer to see what else is broken before making
fixes and restarting.  Certainly no developer should deploy an application that includes such
errors.

--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com

> -----Original Message-----
> From: Johan Lindquist [mailto:johan@kawoo.co.uk] 
> Sent: Wednesday, October 01, 2003 10:03 AM
> To: Jakarta Commons Developers List
> Subject: Re: [HiveMind] extend BuildFactory to use static 
> fields/methods
> 
> 
> Ok, I may have not tested this fully ... [Note to self: must 
> make time to 
> test more configuration options]  But if the service specified in the 
> builder factory setting and a valid service doesn't exists for that 
> particular setter, won't the builder factory complain?
> 
> Johan
> 
> On Wed, 01 Oct 2003 15:37:08 +0200, Christian Essl 
> <christianessl@yahoo.de> wrote:
> 
> > Well if you mean the BuilderFactory than I think most 
> people (like me)
> > relay just on the properties. That means at least for me 
> that I always 
> > end up implementing the initilizableObject method just to 
> check if the 
> > properties where set in the right combiniation (alone the 
> combination 
> > check in one method is no fun). Using a configuration-point 
> makes it 
> > even worse. I have to implement an extra class allmost for 
> nothing where 
> > I still have to check the same - all in one method - as with the 
> > properties. (The configuration-point also has the problem 
> that not only 
> > the 'constructor' can specify the properties but anyone can 
> contribute 
> > and also anyone can define a configuration-point).
> >
> > If you mean the ConfigurationBilderFactory - proposed by me 
> - I have 
> > to
> > admit that when I read the static thing I realized how 
> stupid I was. The 
> > main thing I wanted it for (the constructor thing) can be 
> done with the 
> > static methods (maybe it's a bit less convinient).
> >
> > On Wed, 01 Oct 2003 15:05:53 +0200, Johan Lindquist 
> > <johan@kawoo.co.uk>
> > wrote:
> >
> >> Wouldn't the configuration passed to the factory will make sure the
> >> service is returned in a 'usable' state?  The user doesn't do any 
> >> configuration at that level?
> >> And the service interface shouldn't really allow 
> configuration changes 
> >> or?
> >>
> >> And I am all for the pattern to ensure consistency in 
> created objects
> >> ... Not sure if it applies here though ...
> >>
> >> Johan
> >>
> >>
> >> On Wed, 01 Oct 2003 15:05:16 +0200, Christian Essl
> >> <christianessl@yahoo.de> wrote:
> >>
> >>> You are right HiveMind always returns the same instance, 
> but I mean
> >>> there can be services which have no state or the state of 
> which is 
> >>> just defined at construction time and for these it makes 
> in my opinion 
> >>> sense to declare them as (default-variant) static fields. 
> Further for 
> >>> those Services the static field gives a level of indirection.
> >>>
> >>> But certainly the more intresting idea was the one of 
> >>> static-factory-
> >>> methods. I personally hate nothing more than making a default 
> >>> constructor for classes which need external data to be ready for 
> >>> usage. I don't want to construct my classes and than rely 
> on the user 
> >>> that he might set the needed data sometime . When a class is 
> >>> constructed it should be in a valid state or otherwise throw an 
> >>> Exception. And as you know a pattern to ensure that is to use a 
> >>> static-factory-method and a private (maybe protected) constructor.
> >>>
> >>> On Wed, 01 Oct 2003 14:29:49 +0200, Johan Lindquist
> >>> <johan@kawoo.co.uk> wrote:
> >>>
> >>>> I may have misunderstood this - but doesn't hivemind 
> always return
> >>>> the same instance when you ask for a service once it has 
> created one 
> >>>> (unless it is a threaded service model, when you are 
> worried about 
> >>>> state anyway and probably want different instances)?  If 
> so, what is 
> >>>> the need to have a static instance?  I suppose I can see 
> a use for it 
> >>>> to share data between threads, but the singleton service should 
> >>>> suffice?
> >>>>
> >>>> Johan
> >>>>
> >>>> On Wed, 01 Oct 2003 13:52:58 +0200, Christian Essl
> >>>> <christianessl@yahoo.de> wrote:
> >>>>
> >>>>> That's very good (and fast implemented). But do you 
> realy have to 
> >>>>> do
> >>>>> the double-check on the class. I mean the user sees anyway what 
> >>>>> class it is from the JavaDoc and HiveMind will always 
> check that it 
> >>>>> fits the Service interface.
> >>>>>
> >>>>> Sure if the static field changes this ensures 
> consistency, but on
> >>>>> the other hand it would be also very convient to change 
> all services 
> >>>>> referenced but just changing the static field without 
> the need to go 
> >>>>> into the module.
> >>>>>
> >>>>>
> >>>>> On Wed, 1 Oct 2003 12:40:12 +0200, Knut Wannheden
> >>>>> <knut.wannheden@paranor.ch> wrote:
> >>>>>
> >>>>>> I have created a copy of the hivemind.BuilderFactory service 
> >>>>>> which
> >>>>>> allows me
> >>>>>> to write:
> >>>>>>
> >>>>>> <invoke-factory service-id="my.BuilderFactory"> <construct 
> >>>>>> class="foo.Bar" static-field="foo.Bar.INSTANCE"/> 
> >>>>>> </invoke-factory>
> >>>>>>
> >>>>>> given that I have something like:
> >>>>>>
> >>>>>> package foo;
> >>>>>> public interface Bar {
> >>>>>> static final INSTANCE = new BarImpl();
> >>>>>> }
> >>>>>>
> >>>>>> The class attribute is used to check that the object 
> specified by
> >>>>>> the
> >>>>>> static-field is of a given type, which is an interface in this 
> >>>>>> example.
> >>>>>>
> >>>>>> --knut
> >>>>>>
> >>>>>>> That's certainly a good idea.
> >>>>>>>
> >>>>>>> On Wed, 1 Oct 2003 07:50:42 +0200, Knut Wannheden 
> >>>>>>> <knut.wannheden@paranor.ch> wrote:
> >>>>>>>
> >>>>>>> > Hi,
> >>>>>>> >
> >>>>>>> > I was wondering whether it would make sense to extend the
> >>>>>>> BuildFactory
> >>>>>>> > service (or maybe add a new wervice) to also be able to 
> >>>>>>> > construct
> >>>>>> objects
> >>>>>>> > by
> >>>>>>> > returning the value of a classes static field or by 
> calling a
> >>>>>>> static
> >>>>>>> > method
> >>>>>>> > on a class. The former would obviously be simpler. 
> E.g. (as a 
> >>>>>>> > new
> >>>>>>> > service):
> >>>>>>> >
> >>>>>>> > <invoke-factory service-id="hivemind.StaticBuilderFactory">
> >>>>>>> > <construct class="foo.Bar" static-field="BAZ"> <set.../>
> >>>>>>> > </construct>
> >>>>>>> > </invoke-factory>
> >>>>>>> >
> >>>>>>> > --knut
> >>>>>>> >
> >>>>>>> >
> >>>>>>> >
> >>>>>>> >
> >>>>>>> > 
> >>>>>>> 
> ----------------------------------------------------------------
> >>>>>>> ---
> >>>>>>> --
> >>>>>>> > To unsubscribe, e-mail:
> >>>>>>> commons-dev-unsubscribe@jakarta.apache.org
> >>>>>>> > For additional commands, e-mail: commons-dev-
> >>>>>>> help@jakarta.apache.org
> >>>>>>> >
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> -- Using M2, Opera's revolutionary e-mail client:
> >>>>>>> http://www.opera.com/m2/
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> 
> -----------------------------------------------------------------
> >>>>>> ----
> >>>>>> To unsubscribe, e-mail: 
> commons-dev-unsubscribe@jakarta.apache.org
> >>>>>> For additional commands, e-mail: 
> commons-dev-help@jakarta.apache.org
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >
> 
> 
> 
> -- 
> you too?
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org