Andrzej Jan Taramina wrote:
Antti said:
<snip/>
Good stuff, Antti....comments intersperced below...
Thanks! <snip/>
One area where stop/start() are very useful is the handling of dependencies between different services as they are created/started. Having a clear separation between the creation and start/resume makes dependency implementation a bit easier. You might want to review what JBoss did in this regard using their JMX-enabled service dependencies. It's pretty easy to provide a abstract component class (should the developer wish to use such) that provides default implementations for the lifecycle methods (most of which do nothing). The bulk of developers would just override the start()/resume() method....and leave the create() one alone.I definitely agree, provided that the surrounding contract is clear, i.e. the component developers know when these methods are expected to be called (see Stephen's reply).
I wanted to demonstrate that the context could also contain literal entries, e.g. String, Integer, Configuration (immutable by definition), as well as thread-safe services that don't need to be released (service interface states that all implementations must be synchronized). Technically, using a Handle is also not required if the (client) component has its own dedicated service instance. I think we can all see why the following wouldn't fly:This would also give clear semantics to suspend() and resume(). To summarize, here's a crude example:
public class MyComponent implements ...
{
void initialize( Context ctx ) throws AppropriateException
{
Logger logger = (Logger) ctx.lookup("...");
Configuration conf = (Configuration) ctx.lookup("...");
serviceHandle = (Handle) ctx.lookup("...");
This doesn't make much sense to me. Why are the Logging and Configuration services returned as 1st class objects, but other services are returned through a redirection (Handle)? It would be more elegant if only one method was used consistently (either get the real object or all services are returned as a Handle).
Logger logger = null;
try {
logger = (Logger) loggerHandle.access();
if (logger.isDebugEnabled()) {
logger.debug("Logging made easy!");
}
} finally {
if (logger != null) {
loggerHandle.release(logger);
}
}
So, the Handle interface is there to provide consistent access to all shared services that allow unsynchronized implementations. Now, this still leaves the issues of hot deploying thread-safe services, for which me might have to use dynamic proxies, but this isn't something the client has to worry about.
(: A ;)
--
Antti Koivunen (Mr.) <[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
