commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harish Krishnaswamy <hkrishnasw...@comcast.net>
Subject Re: [Hivemind] ServiceImplementationFactory - no Exception (?)
Date Thu, 18 Mar 2004 04:32:04 GMT
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 
> <glongman@intelligentworks.com> 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" <hkrishnaswamy@comcast.net>
>> To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
>> 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: 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
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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