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.
>
Based on the work undertake on the Fortress/Merlin combined lifestyle
management - the actual implact is very minimal - two container
independent interfaces.
F:\content\doc\merlin\api\assembly\org\apache\excalibur\container\lifecycle\package-summary.html
Implemetation of these interrfaces are in place.
Demonstrations are available.
>
>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.
>
I agreee.
>
>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.
>
This is equivalent to the Merlin/Fortress solution.
An implementation and container indepents interface specfication.
>
>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.
>
Don't follow.
The requirement is to provide customer extension of the Avalon component
lifecycle in a manner that is well structured and consitent with the
current approach to component creation and access. It's not about
providing a Persistence phase one day and addreessing a Security phase
another day. It's about providing the abstraction of a pluggable phase/s.
>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
>
This would require the container to know about specific extension types.
The basically what we have been working hard to avoid.
>
>
>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.
>
The Type structure was designed to allow the natural incorporation of
lifestyle extensions but considering an extension as something
equivilent to the more familiar notions of component services and
component dependecies. In Merlin, extension providers are components
and are handled iun the same way a s service providers. Just as a
component may have service dependecies, a component may also have stage
depedencies. The container is responsible to assembly (i.e. the same
sort of thing you do in Phoenix today - but applied to lifestyles).
>
>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.
>
Attribute names are insufficient - you need a model that is relativly
parrallel with the notion fo service provision/dependency.
For the component providing an extension it needs to be able to publish
this ability. I.e. you need a reference to the lifestyle interface it
handles. This is just the same as the <services> concept in blockinfo
or containerkit - except is concerns the lifecycle. A component may
provide support for multilpe extensions. On the opposite side of the
equation you need to be able to express the stage interfaces that a
component is depednent on. This is just the same as the notion of
dependency declarations but applied to lifestyle extensions.
Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
