commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship" <hlshipli...@comcast.net>
Subject RE: [HiveMind] Force loading of Services
Date Fri, 26 Mar 2004 13:14:12 GMT
If you want to the server to fail on any HiveMind error, then create a Logger that does so.

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

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.

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.

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


Mime
View raw message