-Harish
Geoff Longman wrote:
Wait a sec. Sure log errors when the modules are parsed. That makes sense.
But, if I'm a client and I call registry.getService() I absolutely want a service or an exception! Otherwise I have to stick null checks in all over the place.
Geoff ----- Original Message ----- From: "Harish Krishnaswamy" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Tuesday, March 16, 2004 10:34 PM Subject: Re: [Hivemind] ServiceImplementationFactory - no Exception (?)
Not throwing an exception is a conscious decision. HiveMind is a microkernal to be thought of as a servlet container - it loads all modules at startup and any problems with the descriptors will be identified and logged at load time but will continue to run. I can see an exception being thrown at load time when there is a problem but certainly disagree with the idea of throwing exceptions at runtime. If a service is not loaded properly you have two options - don't care or fix it and reload it!
-Harish
Benjamin Tomasini wrote:
I have started to use Hivemind and have been successful in porting over some existing work. It is quite nice! Very well thought out. Keeping the service / proxy layer in place is cool.
One suggestion so far...
I had a case where my service object from Registry.getService came back null. One of the services used the BuilderFactory. I was getting a log4j ERROR message, but no exception was thrown to my app. It was a simple runtime error - a typo in a config file.
Looking further, I see that
in
org.apache.hivemind.ServiceImplementationFactory
the method
createCoreServiceImplementation(....)
does not throw an exception or anything.
It seems that this prevents calling applications from knowing about problems creating a service. I could always check for null in the service object, but this isn't quite right, IMO. Especially with the lazy loading, I think burying any exception here is bad, especially for apps that depend on a large number of services.
I would be willing to put some work into this and submit a patch if we think we need some exception handling here.
Ben
--------------------------------------------------------------------- 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]
--------------------------------------------------------------------- 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]
