[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
