On Fri, 2004-05-07 at 01:50, Niclas Hedhman wrote:
> On Friday 07 May 2004 07:33, Scott Brickner wrote:
>
> If the QueueComponents are ultra-dumb, then I assume that they don't need to
> be (are not?) AF4 aware.
No, they're not quite that dumb. They're LogEnabled, Contextualizable,
Configurable, and Disposable.
The Contextualizable is only so they can get their block name for use in
toString(). And Disposable is to print out some statistics at the end.
> So I would then suggest an "CommunicationRouter" component that;
> 1. Smart enough.
> 2. Manages the LifeCycle of the Dumb components.
> 3. Has a dependee in form of the NIO component.
I'd kind of thought of that, but it's a little bit of a circular
argument. "I'm using this Merlin thing to manage the lifecycle of my
components. I can't quite figure out how to make it do what I want with
this class of components." And the answer? "Make your own component to
manage the component lifecycle."
So why use Merlin?
>
> CommunicationRouter would have in the config something like;
>
> <queues>
> <queue class="org.hedhman.niclas.queues.FtpQueue" >
> <port>21</port>
> <enabled>true</enabled>
> </queue>
> <queue class="org.hedhman.niclas.queues.SshQueue" >
> <port>443</port>
> <enabled>true</enabled>
> </queue>
> <queue class="org.hedhman.niclas.queues.HttpQueue" >
> <port>80</port>
> <enabled>true</enabled>
> </queue>
> <queue class="org.hedhman.niclas.queues.HttpQueue" >
> <port>8080</port>
> <enabled>true</enabled>
> </queue>
> </queues>
>
> IMHO, Making the Queues slightly 'smarter' so that they can register
> themselves with the NIOComponent seems like a reasonable trade-off;
Well, there are really only one or two out of the two dozen queues in
the system that would need to do this sort of registration. It like it's
breaking encapsulation in the queue's design to add that capability for
just a couple of queues. Of course, to go back to another argument, I
could subclass the WorkQueue class to make a SelfRegisteringWorkQueue -
but I know how the CoP folks hate subclassing. ;)
>
> public class FtpQueue
> implements Serviceable, Disposable, CommunicationQueue
> {
> private ConnectionManager m_ConnectionManager;
>
> /** @avalon.dependency type="org.hedhman.niclas.nio.ConnectionManager"
> key="ConnMan"
> */
> public void service( ServiceManager man ) throws ServiceException
> {
> m_ConnectionManager = (ConnectionManager) man.lookup( "ConnMan" );
> m_ConnectionManager.registerCommunicationQueue( this );
> }
>
> public void configure( Configuration conf )
> throws ConfigurationException
> {
> // Read in stuff like Port, Enabled and other config info.
> }
>
> public void dispose()
> {
> m_ConnectionManager.unregisterCommunicationQueue( this );
> }
>
> // CommunicationQueue methods
> public int getPort()
> {
> }
>
> public boolean isEnabled()
> {
> }
>
> // and so on
>
> public void connectionEstablished( CommunicationEvent event )
> {
> // whatever
> }
>
> public void connectionLost( CommunicationEvent event )
> {
> // whatever
> }
> }
>
>
> IMHO, this gives you a more powerful and less coupled system.
So, more than ninety percent of the queues have their event sources
depend directly on the queues. The assembler knows enough to set up the
dependency for this case, too. All of these proposals seem like hack
jobs to get around a limitation in Merlin for a case that seems
reasonably common.
I really think that the problem is that Merlin doesn't really have
support for an object lifestyle that's somewhere between 'singleton' and
'transient'. Maybe "lifestyle" isn't the right attribute - 'thread' and
'pooled' are kind of between singleton and transient, but they're along
a different curve.
The situation here is one of multiple homogeneous dependencies. I think
ServiceSelector used to help fill this function, but ServiceSelectors
have inadequate semantics, and it looks like they're being treated as
fatally flawed.
Nevertheless, I think this is a legitimate scenario, and one that the
container should be able to deal with, I shouldn't have to roll my own
solution.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
