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 Wed, 17 Mar 2004 13:20:27 GMT


btomasini@neteverything.com wrote:

> Thanks for the answer.  I am sure I need to get my head around the 
> whole picture some more.
>
> My concern is mainly at load time.  You mentioned modules and 
> descriptors...  Does HiveMind also load all services and 
> implementations when the modules are loaded?  If that is the case, are 
> you saying that the app is best off by checking all of the services 
> initially, and providing some way to verify that everything is ok, say 
> by checking for service != null.  That is workable.

Yes HiveMind will load all the modules (via proxies) at load time and so 
it will know any problems with contributions at that time.

>
> The picture I walked away with was that the services would be created 
> more on-demand, and each service / impl would have a lifecycle that 
> may not mirror the startup / shutdown of the containing app.

Mostly correct, but AFAIK all services/configuration will be available 
immediately after startup.

>
> Personally, I still don't like the idea of knowing that something went 
> wrong because of a null result.  It makes it more difficult to 
> determine the root case.  Of course, that is what LOG.error is for, I 
> guess.  It would be nice to see a load-time exception of some sort, IMO.

I had the same feeling too when I first came across this, I have a mixed 
feeling about it now. May be an exception is appropriate, like JNDI.

-Harish

>
>
>
>
>
> On Tue, 16 Mar 2004 22:34:54 -0500
>  Harish Krishnaswamy <hkrishnaswamy@comcast.net> wrote:
>
>> 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