Leo Simons wrote:
> > Single-component container (MicroContainer):
> > Use in environments where you want to use an Avalon component
> > in a non-Avalon program. See my separate mail about this.
> > Big thing: No external metainfo.
> >
> > Embeddable Container (used to write blocks):
> > For things like Cocoon. This is where Fortress etc. fits in.
> > You have your metadata and so on, but the container is intended
> > to be used inside something else - Tomcat, for example.
> > Some external metainfo required.
> >
> > Stand alone container (used to assemble blocks):
> > Phoenix. Loads of metainfo.
>
> +1. Makes sense.
>
> Note fortress should probably become a little slimmer than it is now in
> this setup....otherwise I'd rather keep containerkit for the common
> ground between phoenix and fortress, for reasons of having a speedy
> phoenix. But I dunno much about fortress so I might be off.
I think that something like ContainerKit is vital, and should be required
when using a component.
You could have the best of both worlds -- offering users a guarantee that
they wont need to rewrite their A4 code to use A5 components -- and
allowing the A5 designers (almost) complete freedom to perfect the
interface.
Not all users are going to want to use the Avalon containers, but would
rather roll their own. And if they are calling the framework methods
directly they will complain when framework changes break their code. Or
they wont use Avalon for fear that framework changes will break their
code.
However if ContainerKit is flexible enough, adds minimal overhead, and
comes with a commitment to support A5 components once A5 is released, then
it shouldn't be too hard to persuade everyone to use it.
Here is an example of how it might work for an A4 component:
A4ComponentResources res = new SimpleA4ComponentResources(
MyComponentImpl.class, a4logger, a4ctx, a4conf, a4cm
);
A4ComponentHandler ch = new A4ComponentHandler( res );
ch.startup();
MyComponent comp = (MyComponent) ch.getComponent();
// ...
if ( ch.isPoolable() )
{
ch.recycle();
// ...
}
else
{
ch.shutdown();
ch = // ...
}
// ...
ch.shutdown();
Notice that nowhere do we have a MyComponentImpl object (though 'comp' may
be one -- or it might be a dynamic proxy). 'comp' is used as an instance
of the interface MyComponent, and all framework methods/interfaces are
handled via the A4ComponentHandler... Now, once A5 is released there is
no reason that A4ComponentHandler cant be re-released to handle both A4
and A5 components (e.g. replacing MyComponentImpl.class with
MyComponentA5Impl.class).
Of course, maybe it is too late -- A4 has been out for a year, and there
are probably lots of people using the A4 framework methods/interfaces
directly...
Robert.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
