On Mon, 19 Aug 2002 18:35, Leo Simons wrote:
> agreed. However, defining a container API that allows plugging of any
> facility using an event- or pipeline- like architecture seems a nice
> idea, and the current work to enable this is definately moving in the
> right direction.
I remember quite a few people remarking how Component marker interface was a
good idea, or ComponentSelector was a great idea, or that all the Poolable,
Threadsafe etc interfaces were good ideas. Is this idea good in the same way?
I think a little wider testing is needed before you could adopt it.
> Similarly, systems that completely expose their pipeline like Axis,
> JEdit, to me show that it *is* possible to provide a common pluggability
> architecture.
As does cocoon, almost all enterprise/distributed servers (be they plain
rmi-like servers to EJB/CORBA servers). Even TC3 and TC4 has the notion of
interceptors. Now how many of them are actually compatible ...
JEdit is a specific container, Axis is a specific container - have you got any
examples apart from CORBA where there is a common API for extending servers?
> conceptually, that would be okay. However, it is impossible to
> anticipate in advance all the lifecycle phases important enough to
> support.
bingo!
> > We could standardize on an component attribute name that lists a set of
> > required phases that the container must implement to run component
>
> I hope you don't mean
>
> class MyComponent
> {
> public static final String CUSTOM_LIFECYCLE_REQUIREMENTS =
> "Persistence,Transaction,Command";
>
> // ...
> }
nope. In the ComponentInfo.getComponentDescriptor().getAttribute( "somekey" );
> > but other
> > than that I really don't see the need for any changes to existing
> > ContainerKit model.
>
> one issue I see is decreased reusability of the container. If changes by
> the client to the internals of a container are neccessary for the client
> to get support for their custom lifecycle needs, that is a big minus.
>
> The other option is to allow (for example) classes to be added to the
> container by putting a jar file in the container lib directory (or added
> through some other mechanism like JMX) and modifying an XML
> configuration file. Again, Axis shows it can be done cleanly.
JBoss does it fairly nice aswell, as does TC4 as does X ...
--
Cheers,
Peter Donald
*-----------------------------------------------------*
* "Faced with the choice between changing one's mind, *
* and proving that there is no need to do so - almost *
* everyone gets busy on the proof." *
* - John Kenneth Galbraith *
*-----------------------------------------------------*
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
