On Wed, 17 Mar 2004 10:37:53 -0800, <[EMAIL PROTECTED]> wrote:
You are right. I probably got a good proxy, but a null in a dependancy caused this.
Here are a few points:
1. I see HiveMind being much more dynamic and inline to the app than a deployed servlet. This comparison was done as a reason for not throwing an exeption.
That's certainly true.
2. ** When I moved code from...
// Load up static config MyClass.configure(arg1, arg2, arg3) MyClass service = MyClass.getInstance();
to //
(MyClass) service = (MyClass) registry.getService(....
My overall after debugging the error was "Hivemind makes it harder to unit test because there is this nasty buried exception".
I think I see what you mean.
The primitive service-model does basicly what your original code did. It loads the acutual service-implementation when you first retrieve the service. Any exceptions (or null implementaition) are thrown at this moment. On the other hand the (default) singleton service-model returns a proxy which loads the service-implementation when the first method is called. This is important for circular dependencies. Something you could not have in your original code. So using the primitive model would help you to get immidiately the exception.
3. Hivemind is, at its core, object creational (via creating services). There are a bunch of things that can go wrong here. If we want to encourage users to use HiveMind services with lots of small components, I see good expcetion handling being critical.
HiveMind is flexible, which has its price with runtime problems.
The statement...
} catch (Exception e) { LOG.error("Opps") // Bury it here }
is quite brittle to the calling app.
*** $64000 Final question
Without an exception, and since my object was not null, how does the app know a problem was encountered?? log4j is great for humans viewing the log, but log4j is not a notification mechanism for the app, and does not affect control flow.
Yes I agree concerning the singleton-model. Any solutions? Maybe a two step initilitation process - construct, save, init, return (takes some flexibility from the ServiceImplementationFactories)? Or feeding the proxy before returning it (more circular restrictive)?
On Wed, 17 Mar 2004 14:26:12 +0100 Christian Essl <[EMAIL PROTECTED]> wrote: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
I agree. Actullay I was always expecting HiveMind to do that. This is also more consistent, because if the module or the ServiceExtensionPoint is not found an ApplicationRuntimeException is thrown.
But now I am a bit confused about where this null comes from. As I see all ServiceModels - except of primitive - always return a proxy, independent of what the factory actually returns. And the primitive ServiceModel (and as I think the other Models as well) uses AbstractServiceModelImpl.constructCoreServiceImplementation() which does check for null and throws an ApplicationRuntimeException.
Maybe Benjamin you could tell how you got this null. So that it could be reproduced on the current HiveMind from the cvs. To me it looks like a bug. Or maybe you used an ServiceImplementationFactory directly - Spring like? Or I just miss something.
Thanks, Christian
On Wed, 17 Mar 2004 01:34:28 -0500, Geoff Longman <[EMAIL PROTECTED]> 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]
-- 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]
--
Christian Essl
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
