On Sun, 2002-08-18 at 23:00, Peter Donald wrote:
> On Sun, 18 Aug 2002 23:51, Peter Royal wrote:
> > Pete: You describe some "hairy" problems
> > (http://marc.theaimsgroup.com/?l=avalon-dev&m=102833233625631&w=2), but we
> > can work through them, yes?
>
> The problems can be worked through and have been many times in the past. It
> basically comes down to different tradeoffs. Much like Context
> implementations it becomes relatively container specific as soon as you add
> any useful features to it.
>
> You can develope API layers to abstract these things in the container and
> allow container plugins. However even if this is done we would need a lot of
> testing before it became something we could promote to framework CVS.
true. Still, I do feel controlled plugin support for well-defined
problem spaces with low container impact is something we can do in the
4.x series of framework. The lifecycle extension setup as recently
discussed by Marcus et al is, IMO, approaching a point where it could be
moved to framework.
> Consider the case of EJB model. The client API to concerns (say persistence)
> is relatively stable and works across containers. However the Persistent
> manager/engine/facility API is different for every different container.
>
> ie I suspect it would be impossible to directly move a persistence manager (or
> Transaction Manager or whatever) from JBoss to Weblogic, Websphere, OpenEJB
> or Jonas. You would need container specific abstraction layers in each case.
>
> We could define a container API for each of those facilities but I think it
> would be a mistake as it unecessarily constrains evolution.
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.
Similarly, systems that completely expose their pipeline like Axis,
JEdit, to me show that it *is* possible to provide a common pluggability
architecture.
> We should defining the client interface and allow the container writer the
> freedom of how they implement it. This is how most of the successful specs
> evolve so I don't see a problem with this approach.
+1
> So if a Persistence phase is needed then we can define its client API and see
> how it works. If it ends up working brilliantly in a wide enough range of
> situations then we can import the API into framework
conceptually, that would be okay. However, it is impossible to
anticipate in advance all the lifecycle phases important enough to
support. Initial work on the lifecycle definition took years and years,
and yet there is valid need for extension.
Thus, I would rather see a mechanism that would allow the client to plug
in their specific lifecycle extension needs into any avalon container.
<snip explanation of ComponentInfo support for extensions/>
> 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";
// ...
}
...as it seems to me that is storing metadata inside java sources....?
> 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.
cheers,
- Leo
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
