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:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > > > Sent: Tuesday, March 23, 2004 5:49 AM > > > To: [EMAIL PROTECTED] > > > 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: [EMAIL PROTECTED] > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > -- > Benjamin Tomasini > NetEverything, Inc. > 1-877-270-1391 > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
