Fortress and Events

[Daniel Krieg <dk...@kc.rr.com>]

How does Fortress support the Excalibur Events package in regard to Commands.  I see that there is a
Queue that the AbstractContainer has optional dependencies on, but what is the intended use here?
Is there a CommandManager?  If I am writing a Container class how do I configure it to use the 
Queue...do I need to implement code similar to what CommandManager does or can I somehow
utilize that class?

Re: Fortress and Events

[Daniel Krieg <dk...@kc.rr.com>]

Berin,

> The DefaultContainer has a reference to the CommandManager's Sink.
> It passes a reference to that Sink via the Context at this time.
> The key is in the ContainerConstants interface AFAIR.
How do I set up the CommandManager...registerSignalHandler( )...
if I am using DefaultContainer with containment stategy?


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Fortress and Events

[Berin Loritsch <bl...@citi-us.com>]

> From: Daniel Krieg [mailto:dkrieg@kc.rr.com]
> 
> Berin,
> 
> Thanks for your reply.  I have some followup questions that you
> may be able to address.  The application I am developing will
> be a server app hosted within Phoenix.  Several of the sub-system
> components that I am developing are an assembly/composition of
> smaller services/components.  These sub-system components are
> unlikely to change configuration often, however with respect 
> to Phoenix,
> the assembly of these Blocks (sub-system components) will likely
> change...(Does this make any sense???)

I think so.


> I think it is more appropriate to implement these sub-system
> components using Fortress Container and assemble them together
> as Phoenix Blocks.  One requirement I have is that these components
> take advantage of the SEDA architecture within Excalibur Events.
> I would like to use CommandManager to handle dispatching of
> Commands.  Does the DefaultContainer do this implicitly?  What
> alternatives are available?

The DefaultContainer has a reference to the CommandManager's Sink.
It passes a reference to that Sink via the Context at this time.
The key is in the ContainerConstants interface AFAIR.


> Is it more appropriate to define my sub-system components by
> extension or containment of the Fortress DefaultContainer?

It depends on what you want to do.  If you are merely *using*
the Fortress DefaultContainer, then contain it.  If you want
to change some aspects of how it configures information, then
extend it.

In most cases, I suggest containment.

> If I have a component A and component B needs to send a
> Command to component A, and that Command needs access to
> a service held within component A in order to execute, what is
> the proper IOC approach? (...Again, make any sense???).

Let's see if I can refrase this:

Component B wants to perform an asynchronous operation on
Component A.

In order to make this happen, the Command needs a reference
to the other component.  There are two ways you can achieve
that:

1) Pass in the ServiceManager to the Command, and let the Command
   lookup Component A.

2) Pass in a reference to Component A.

The tradeoffs are:

Option 1 allows you to work with components of any lifestyle,
making the lookup/release cycle all within one context.

Option 2 forces you to work with "ThreadSafe" components, or
provide complicated and error prone lookup/release logic.

Either approach will allow you to perform whatever you need
to do.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Fortress and Events

[Daniel Krieg <dk...@kc.rr.com>]

Berin,

Thanks for your reply.  I have some followup questions that you
may be able to address.  The application I am developing will
be a server app hosted within Phoenix.  Several of the sub-system
components that I am developing are an assembly/composition of
smaller services/components.  These sub-system components are
unlikely to change configuration often, however with respect to Phoenix,
the assembly of these Blocks (sub-system components) will likely
change...(Does this make any sense???)

I think it is more appropriate to implement these sub-system
components using Fortress Container and assemble them together
as Phoenix Blocks.  One requirement I have is that these components
take advantage of the SEDA architecture within Excalibur Events.
I would like to use CommandManager to handle dispatching of
Commands.  Does the DefaultContainer do this implicitly?  What
alternatives are available?

Is it more appropriate to define my sub-system components by
extension or containment of the Fortress DefaultContainer?

If I have a component A and component B needs to send a
Command to component A, and that Command needs access to
a service held within component A in order to execute, what is
the proper IOC approach? (...Again, make any sense???).

> > From: Daniel Krieg [mailto:dkrieg@kc.rr.com]
> >
> > How does Fortress support the Excalibur Events package in regard to
> > Commands.  I see that there is a
> > Queue that the AbstractContainer has optional dependencies
> > on, but what
> > is the intended use here?
> > Is there a CommandManager?  If I am writing a Container class how do I
> > configure it to use the
> > Queue...do I need to implement code similar to what
> > CommandManager does
> > or can I somehow
> > utilize that class?
>
>
> Currently the CommandQueue is passed in through the Context.
> All you have to do is use it.
>
> In the future, the service related things will be moved into
> the ServiceManager.  To ease the pain of this minor change,
> the service related things will still be available through the
> context, but you will get a [WARNING] log message telling you
> about the deprecation each time you ask for it from that
> location.
>
> Most times, the DefaultContainer will be more than sufficient
> for your needs.
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Fortress and Events

[Berin Loritsch <bl...@citi-us.com>]

> From: Daniel Krieg [mailto:dkrieg@kc.rr.com]
> 
> How does Fortress support the Excalibur Events package in regard to
> Commands.  I see that there is a
> Queue that the AbstractContainer has optional dependencies 
> on, but what
> is the intended use here?
> Is there a CommandManager?  If I am writing a Container class how do I
> configure it to use the 
> Queue...do I need to implement code similar to what 
> CommandManager does
> or can I somehow
> utilize that class?


Currently the CommandQueue is passed in through the Context.
All you have to do is use it.

In the future, the service related things will be moved into
the ServiceManager.  To ease the pain of this minor change,
the service related things will still be available through the
context, but you will get a [WARNING] log message telling you
about the deprecation each time you ask for it from that
location.

Most times, the DefaultContainer will be more than sufficient
for your needs.

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>