avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: DTD compat -- red herring?
Date Sun, 18 Aug 2002 22:31:41 GMT

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.
> 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. 

Has this to do with the discussion we had about "make your container" 
versus "use existing containers"?

If it is, I think I understand.
ECM was used by Cocoon as a CM, but I think that in many cases if Cocoon 
created his own container, things would have been much better.

Conceptually, it would seem neat to have a "generic" container with 
pluggable stages-phases, but you say IIUC that it's too complicated and 
making an ad-hoc one is much easier and more efficient?


The problem is that if we want Components that are reusable across 
Containers, we must tell the Container what to expect, and how to treat 
the Component.
Granted, some containers might not work, but we have a standard way of 
telling the container about the handling of the Component.

We would standardize the *contract*, which seems a good thing...

> 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.
> 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 and support for it in 
> ComponentInfo. Until then we can just store extra data in a file side-by-side 
> class file or have an attribute of component define its location. ie We could 
> define
> com/biz/MyPersistent.java
> com/biz/MyPersistent-persist.xml
> If we want transaction orientated extensions then we can add that, if we want 
> instrument extensions then we can add that, if we want remoting extensions 
> then we can add that (and so on and so forth).

Ah, ok. Well, it's basically the same thing, you still define a 
contract, but in this case, you clearly separate the "endorsed" 
contracts and the "extension" contracts.

This is interesting, since it makes it much more easy to track 
evolution... but we end up with different versions of the "standard" 
contract... which would be the case anyway, I guess today's uber DTD 
will still have to be changed down the road...


The main point is that with Merlin you can not only tell the Container 
what it has to do, but also *how* to do it, ie what special provider can 
be used to make the Container handle the extension.

This is quite neat it seems.

> The ComponentInfo structure was design to allow extensions to sit side-by-side 
> while they evolve or to be integrated directly into ComponentInfo class in 
> the future.
> We could standardize on an component attribute name that lists a set of 
> required phases that the container must implement to run component but other 
> than that I really don't see the need for any changes to existing 
> ContainerKit model.

I think that as for the "contract" definition goes, this is not
equivalent to what Merlin provides.

Let's say that we put extensions in a different file, ok, no big deal, 
it can give advantages as said above... but it still hampers the ability 
to make Components work across Containers.

If we add to this "extension" the ability to specify *how* to extend, we 
gain in compatibility.
And once the feature passes from "extension" to "standard", it can be 
done by the Container itself, maybe also better.

Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message