commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scot Hale" <hal...@hotmail.com>
Subject Re: [Hivemind] ServiceImplementationFactory - no Exception (?)
Date Thu, 18 Mar 2004 21:31:58 GMT
I haven't used Hivemind, but I am going to suggest this anyways :

couldn't you just provide a service that returns the exception  
"getServiceX()"

and another that returns null "getService()"?

Then it would be up to the user of the API which one they used.


Scot Hale

----Original Message Follows----
From: Harish Krishnaswamy <hkrishnaswamy@comcast.net>
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [Hivemind] ServiceImplementationFactory - no Exception (?)
Date: Thu, 18 Mar 2004 12:08:48 -0500

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

_________________________________________________________________
Is your PC infected? Get a FREE online computer virus scan from McAfeeŽ 
Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963


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