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. 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). 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. -- Cheers, Peter Donald ------------------------------------------------------- To fight and conquer in all your battles is not supreme excellence; supreme excellence consists in breaking the enemy's resistance without fighting. - Sun Tzu, 300 B.C. ------------------------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
