commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship" <hlshipli...@comcast.net>
Subject RE: [HiveMind] Force loading of Services
Date Wed, 24 Mar 2004 17:24:44 GMT
I'm unconvinced this is necessary. I would tend to think that it is counter-productive. With
late
building of services (behind proxies), you will see error messages related to the construction
of a
service just where methods are first invoked on it. With the discussion of forced loading
of
services, you will see all errors for all services in one ungainly clump.

--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Tapestry: Java Web Components 
http://howardlewisship.com


> -----Original Message-----
> From: Christian Essl [mailto:christianessl@yahoo.de] 
> Sent: Tuesday, March 23, 2004 5:49 AM
> To: commons-dev@jakarta.apache.org
> Subject: [HiveMind] Force loading of Services
> 
> 
> A few days ago Benjamin had mainly the complain about the 
> current service 
> handling, that problems in the service construction may arise 
> very late 
> during runtime. While we discussed very lenghty why this is 
> so in Hivemind 
> I somehow share his whishes that it should be possible to get 
> an exception 
> either at Registry build time or at first access for at least special 
> marked services.
> 
> Maybe it could help if the Registry had a method 
> getLoadedService() this 
> method would instruct (via the ServiceExtensionPoint) the 
> Model to load a 
> deffered Proxy. An alternative would be to add to the services a 
> mixin-interface which has a load() method and would just load 
> the proxy.
> 
> To enable checking at Registry build time 
> service-implementations could be 
> marked to be loaded at start-up. This could happen with an 
> extra attribute 
> 'load-at-startup'. Again an alternative would be to have start-levels 
> (OSGi like). This would also help to start timers etc.
> 
> -- 
> 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


Mime
View raw message