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 Wed, 17 Mar 2004 21:03:06 GMT
Yes intresting points. Certainly need some discussion.

On Wed, 17 Mar 2004 10:37:53 -0800, <btomasini@neteverything.com> wrote:

> You are right.  I probably got a good proxy, but a null in a dependancy 
> caused this.
>
> Here are a few points:
>
> 1. I see HiveMind being much more dynamic and inline to the app than a 
> deployed servlet.  This comparison was done as a reason for not throwing 
> an exeption.
>

That's certainly true.

> 2. ** When I moved code from...
>
> // Load up static config
> MyClass.configure(arg1, arg2, arg3)
> MyClass service = MyClass.getInstance();
>
> to //
>
> (MyClass) service = (MyClass) registry.getService(....
>
> My overall after debugging the error was "Hivemind makes it harder to 
> unit test because there is this nasty buried exception".
>

I think I see what you mean.

The primitive service-model does basicly what your original code did. It 
loads the acutual service-implementation when you first retrieve the 
service. Any exceptions (or null implementaition) are thrown at this 
moment. On the other hand the (default) singleton service-model returns a 
proxy which loads the service-implementation when the first method is 
called. This is important for circular dependencies. Something you could 
not have in your original code. So using the primitive model would help 
you to get immidiately the exception.

> 3. Hivemind is, at its core, object creational (via creating services).  
> There are a bunch of things that can go wrong here.  If we want to 
> encourage users to use HiveMind services with lots of small components, 
> I see good expcetion handling being critical.
>
> HiveMind is flexible, which has its price with runtime problems.
>
> The statement...
>
> } catch (Exception e) {
>    LOG.error("Opps")
>    // Bury it here
> }
>
> is quite brittle to the calling app.
>
>
> *** $64000 Final question
>
> Without an exception, and since my object was not null, how does the app 
> know a problem was encountered??  log4j is great for humans viewing the 
> log, but log4j is not a notification mechanism for the app, and does not 
> affect control flow.
>

Yes I agree concerning the singleton-model. Any solutions? Maybe a two 
step initilitation process - construct, save, init, return (takes some 
flexibility from the ServiceImplementationFactories)? Or feeding the proxy 
before returning it (more circular restrictive)?

>
>
>
>
> On Wed, 17 Mar 2004 14:26:12 +0100
>   Christian Essl <christianessl@yahoo.de> 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
>>
>>
>>
>> -- Christian Essl 
>> ---------------------------------------------------------------------
>> 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