IoC doesn't mean that there's no flow of information from the component to the container, just that *the container has the final word* regarding what is actually *done* with the information.
The way I was looking at it, the container controls when information flows, and the component is not allowed to initiate any communication on its own ("You shall speak only when spoken to"). Your definition is much more useful.
thinking...it seems like the "Will only speak when spoken to" is a natural property for passive components (ie that don't implement startable nor use seperate threads of execution), whereas you won't be able to hold it for active components.
I have no problem with your use of lookup() to obtain a monitor. Perhaps even more in line would be to use the Context for this, though. (Or are we getting rid of that one in favor of the ServiceManager?)
here we go again :D
I believe the last time we talked about all this we resolved (after three weeks of debate or so) that the context is used for container-component communication and the servicemanager for inter-component communication. The tricky part is when you have a service which can either be provided by the container or by another component. Muddy, since your average container makes most things into components.
So no clear answer here.
Me, I'm a type 3 convert, and in that world there is no distinction between container or component-provided services. Which works.
Regarding the multitude of status messages - I don't think that will be any help.
It ties in with the no-logging idea I think. You want the container to notify an admin that a component died. It'd be useful for the admin to know why that happened. Hence the specific message. And since, in java, things die because of exceptions, that's a nice way of providing the message.
I don't really want to have one component notify every other component that they're broken, because there's usually nothing the other components can do about it.
agreed.
Just throwing more into the mess - multithreading:
actually...no problem at all!
The socket server IMV is not actually concerned with multithreading, nor does it need to be (unless you're running an infiniband-style 200-processor server where a single processor cannot accept() connections as fast as the networking hardware). Just let the executor and handlers worry about that.
The single function of the socket server is to hand off connections to a handler. The handler is allowed to do multithreading if it wants to. It might again depend on an Executor, like this:
class AlternatingConnectionHandler implements ConnectionHandler
// code sketch
{
/** in this example: a specialized pool that will call setSocket()
on get() */
WorkerPool m_workers = /* ... */ handle( Socket socket )
{
worker = m_workers.get( socket );
m_executor.execute( worker );
} stop()
{
m_workers.stopAll();
} class Worker implements Runnable
{
Worker() { /* ... */ }
setSocket( Socket socket ) { /* ... */ }
run()
{
try
{
/* ... */
if(!running) return; Thread.yield();
/* ... */
if(!running) return; Thread.yield();
/* ... */
}
finally
{
m_workers.release( this );
}
}
stop() { running = false; }
}
}and you just happen to pass in a PooledExecutor here when you want multi-threading. Or you might just let connections queue up in your handler. Or...
> m_executor.interruptAndStopAll(); // Does this method even exist?
nope, it doesn't. In fact, the executor interface specifies that it might even be single-threaded. But if you're using a PooledExecutor, for example, it does:
http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/PooledExecutor.html#shutdownNow()
However, in general, it is not the responsibility of the server or handler components to shut down the threads in a pool, but of the pool itself (which, after all, is a component, too).
cheers!
- LSD
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
