On Mon, 2002-08-19 at 11:29, Peter Donald wrote: > 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?
what is your argument? That because some people at some point about something mentioned it was a good idea where it was not means me stating something else is a good idea also means it is not? > I think a little wider testing is needed before you could adopt it. I feel safe adopting the idea that a common pluggable facility architecture is a good idea =) > > 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 ... none. That is why we have avalon: to make that happen. There are many pluggability architectures, most are remarkably similar, yet there is no reuse. Avalon to the rescue! > 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? nah. In fact, apart from CORBA, I can't think of a common API that really facilitates clean reuse across servers...except avalon. > > > 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 > > <snip> > nope. <snip> > > > 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 ... So there is an ample supply of examples of projects with clean, similar, pluggable architectures, yet you feel it is impossible to extract the common ground between them? why? Seems to me Avalon is halfway already. cheers, Leo -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
