I think I see what you mean. Two me, there are two sides of this.
1. On the intial load of modules / services, I would like to see the application have a complete excepion chain to whatever is loading the registry. In specific, Intializable.initializeService does not throw an exception. If there is an error in here, it would be nice for the registry to know about it, log it, and invalidate the service.
2. On the getService side, here are my thoughs.
(A) If a service fails to initialze in step 1, have getService throw and exception, too. That is fine with me.
(B) If a service fails to initialize in setp 1, return null. This is also fine with me.
(C) If a service has an error initializing, say in Initializable.initializeServce, why would I want an instance of anything? To me, a half-initialized service is worse.
I want my service to run 100% out of the box, or have a good strong error, even an NPE from the calling application (B above). I see no value in pretending everything was ok.
On Thu, 18 Mar 2004 12:08:48 -0500 Harish Krishnaswamy <[EMAIL PROTECTED]> wrote:
Let me ask you this, how are contemplating handling these exceptions? Are you going to be catching exceptions when ever you do a lookup or are you planning on letting these exceptions cascade up to the top and throw a message to the client. 'Cause either way would be no different than what it is now, wouldn't you say?
-Harish
[EMAIL PROTECTED] wrote:
Great! I may take my hand at a patch, but I fear am too new to this project to get my head around it. Maybe I will Bugzilla this one if I have some time.
Great product all in all. BTW, any thoughts for Intializable.initializeService() throwing an exception, too?
I don't want to open pandora's box here, but I hit a similar issue with that as well.
Ben
On Wed, 17 Mar 2004 23:32:04 -0500 Harish Krishnaswamy <[EMAIL PROTECTED]> wrote:
Christian is absolutely right, I don't know what I was thinking. The conscious decision was about not throwing the exception at load time and should always expect to see an exception when accessing a service point that has no contribution or had problems loading it. Sorry Benjamin! That should certainly be a bug.
-Harish
Christian Essl 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]
---------------------------------------------------------------------
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]
