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 17:08:48 GMT
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

btomasini@neteverything.com 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 <hkrishnaswamy@comcast.net> 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 
>>> <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
>>
>
>
> ---------------------------------------------------------------------
> 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