commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <btomas...@neteverything.com>
Subject Re: [HiveMind] Force loading of Services
Date Fri, 26 Mar 2004 14:24:59 GMT


On Fri, 26 Mar 2004 08:14:12 -0500
  "Howard M. Lewis Ship" <hlshiplists@comcast.net> wrote:
>If you want to the server to fail on any HiveMind error, 
>then create a Logger that does so.

I guess I don't get when you would ever want fail and 
continue in production.  At least on the service level. 
 If your service failed to initialzie correctly, why would 
you want to use it?

>
>The problem with J2EE is a lack of flexibility: part of 
>that is the fail-on-any-error ethos.

I think you mean fail on any unhandled exception.  Java's 
try {} catch () {} handles anticpated exceptions quite 
nicely.  If an exception gets all the way up the stack, 
ususlally it means something external is not working, like 
a db, and your code have a way to respond.

>
>During DEVELOPMENT you want to fail-and-continue. You 
>should not go to PRODUCTION with any errors.
>This is the point of integeration, rather than unit, 
>testing: to ensure that all such errors have
>been weeded out. Generally, when you hit high code 
>coverage numbers, then you are there.

But all of the development, unit testing, and integration 
cannot help if my DBA decides to take down the database 
that has my shipping information in production.  Your 
analogy does not apply to runtime errors.

>
>Earlier versions of HiveMind did not have 
>fail-and-continue. Then I added a switch so I could get
>more of the system debugged. Eventually, I realized that 
>fail-and-continue should just be the norm.
>

I guess I need to understand the underlying philosophy of 
why fail-and-contine is ever desired in production.  I see 
the thinking for development, kinda.

>--
>Howard M. Lewis Ship
>Independent J2EE / Open-Source Java Consultant
>Creator, Tapestry: Java Web Components 
>http://howardlewisship.com
>
>
>> -----Original Message-----
>> From: Benjamin Tomasini 
>>[mailto:btomasini@neteverything.com] 
>> Sent: Thursday, March 25, 2004 7:58 PM
>> To: Jakarta Commons Developers List
>> Subject: RE: [HiveMind] Force loading of Services
>> 
>> 
>> You will see errors in LOG.error, but not in the form of 
>>an 
>> exception. 
>> Which, IMO, is kinda dangerous as you get half-baked 
>>services. 
>> Specifically,
>> 
>> 1. <set-service> in BuilderFactory can fail and the end 
>>result is that
>> you get a null for that dependancy - though the service 
>>is not null.
>> 2. Initializable.initializeService() does not throw an 
>>exception.
>> 
>> 
>> I do think it is counter-productive to have the option 
>>to pre-load
>> services.  It seems like that misses the point of 
>>HiveMind.  But... in
>> light of the two issues above, the reality is that we 
>>only have
>> LOG.error to tell us of the error, and I may want to 
>>know 
>> ASAP if any of
>> these error occurred.  Lesser of two evils?  Dunno.  
>> 
>> 
>> On Wed, 2004-03-24 at 12:24, Howard M. Lewis Ship wrote:
>> > I'm unconvinced this is necessary. I would tend to 
>>think 
>> that it is counter-productive. With late
>> > building of services (behind proxies), you will see 
>>error 
>> messages related to the construction of a
>> > service just where methods are first invoked on it. 
>>With 
>> the discussion of forced loading of
>> > services, you will see all errors for all services in 
>>one 
>> ungainly clump.
>> > 
>> > --
>> > Howard M. Lewis Ship
>> > Independent J2EE / Open-Source Java Consultant
>> > Creator, Tapestry: Java Web Components 
>> > http://howardlewisship.com
>> > 
>> > 
>> > > -----Original Message-----
>> > > From: Christian Essl [mailto:christianessl@yahoo.de] 
>> > > Sent: Tuesday, March 23, 2004 5:49 AM
>> > > To: commons-dev@jakarta.apache.org
>> > > Subject: [HiveMind] Force loading of Services
>> > > 
>> > > 
>> > > A few days ago Benjamin had mainly the complain 
>>about the 
>> > > current service 
>> > > handling, that problems in the service construction 
>>may arise 
>> > > very late 
>> > > during runtime. While we discussed very lenghty why 
>>this is 
>> > > so in Hivemind 
>> > > I somehow share his whishes that it should be 
>>possible to get 
>> > > an exception 
>> > > either at Registry build time or at first access for 
>>at 
>> least special 
>> > > marked services.
>> > > 
>> > > Maybe it could help if the Registry had a method 
>> > > getLoadedService() this 
>> > > method would instruct (via the 
>>ServiceExtensionPoint) the 
>> > > Model to load a 
>> > > deffered Proxy. An alternative would be to add to 
>>the services a 
>> > > mixin-interface which has a load() method and would 
>>just load 
>> > > the proxy.
>> > > 
>> > > To enable checking at Registry build time 
>> > > service-implementations could be 
>> > > marked to be loaded at start-up. This could happen 
>>with an 
>> > > extra attribute 
>> > > 'load-at-startup'. Again an alternative would be to 
>>have 
>> start-levels 
>> > > (OSGi like). This would also help to start timers 
>>etc.
>> > > 
>> > > -- 
>> > > Christian Essl 
>> > > 
>> > > 
>> ---------------------------------------------------------------------
>> > > 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
>> -- 
>> Benjamin Tomasini
>> NetEverything, Inc.
>> 1-877-270-1391
>> 
>> 
>> ---------------------------------------------------------------------
>> 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
>


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


Mime
View raw message