> > > Can't see need to require re* components to be suspendable/resumable
> > > What wa the rationale?
> >
> > Inversion of Control is one of the core design patterns in
> Avalon. Having
> > a Component manage concurrency issues for itself seems like
> Subversion of
> > Control to me. It is probably better to modify/inherit the
> container than
> > do this (example to disprove that, anyone?).
> > What I said (I think) previously is that doing this should at least be
> > recommended at all times.
>
> This doesn't affect either IOC or the Container. Simply
> requiring a Component
> that implements a Re** interface to be smart enough to not go
> insane after the
> method is called is not subverting control. It is smart
> programming. What
> you are doing is taking the burden off of the Container who has
> *no* method
> of suspending the Re** Component.
I disagree....
> Inversion of Control states that the child reacts to events sent
> to it, and it
> does not pass those events back to the container. Clear examples
> of subversion
> of control are the following:
>
> A Component calling it's own configure() method
While a component on which reconfigure() is called which does not
implement Suspendable does not call its own suspend(), chances** are
it will run _some_ kind of code to suspend its own operations.
Conceptually, that code belongs in suspend(). Especially since
this allows the container to call suspend() once, and then call
recontextualize() _and_ reconfigure().
If you do not set up your component with suspend(), but still
have to execute some kind of suspend code within recontextualize()
and reconfigure(), smart programming is to put that code in a
separate function, which you might call, heck, suspendMe(). At
the end of recontextualze() and reconfigure(), you might then
decide to call a method called resumeMe().
Get my point?
** there may be components which are so simple that this is not
neccessary. But most of the components that warrant use of Re*
probably aren't.
> A Component altering the Context object so that the Container has
> the new object
> A Component directly calling methods on a Container.
Unless in a specific contract, the Component uses some kind of
callback/notification/event broadcast model to feed info back
into the container...something I was thinking about and it
might make sense to have a common system for this...?
(like having a skeleton event system:
package org.apache.avalon.framework.event;
interface EventException extends CascadingException {}
interface Event
{
Object getSource();
Object get( name );
} (something like Context, probably)
interface Broadcaster extends Component
{
void addListener( String name, Listener listener );
void removeListener( String name );
/* perhaps one specifically for the container, which is
an optional part of the lifecycle (probably not though): */
void setParent( Listener listener );
}
interface Listener extends Component
{
Filter getFilter();
void handleEvent( Event event );
}
interface Filter extends Component
{
boolean listensFor( Event event );
})
just some thoughts,
LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
