commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Essl <christiane...@yahoo.de>
Subject Re: [Hivemind] ServiceImplementationFactory - no Exception (?)
Date Thu, 18 Mar 2004 18:47:49 GMT
Well Hivemind is new and everyone is new to Hivemind. While I am not (hope 
fully soon) a commiter I am sure if you realy get registry.getService() == 
null than this is a bug and everyone will be happy if you patch that.

However if you want to add a throws declaration I agree with Harish that 
there is not much difference, because neither ServiceImplementationFactory 
nor Initilizable.initialize() is thought to be called directly by the 
application. Both are called by the Registry and - except of the primitive 
model - not directly but through the returned proxy when a method is 
called on the service interface. In effect this means that for all the 
models - except of primitive - a checked exception will be wrapped up in a 
RuntimeException (as it is now).

I totally share your concerns that such an construction-exception can 
happen often very late after you got the service. I also prefer to get 
 from the registry either a valid setup service or an exception. However 
IMO there are some issues there which gave me a lot of thinking the last 
ours. If you have a solution for that I'd realy love to see it. Maybe you 
could before spending your time writing the patch share some of your 
thoughts.

Thanks,
Christian

On Thu, 18 Mar 2004 12:08:48 -0500, Harish Krishnaswamy 
<hkrishnaswamy@comcast.net> 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
>
> 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



-- 
Christian Essl 

---------------------------------------------------------------------
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