avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [Vote] GenericblockContext (was Re: BlockContext & Merlin).
Date Mon, 26 Aug 2002 17:19:55 GMT

Paul Hammant wrote:

 > Stephen,
 >>>>>>>>> 1) Merlin includes phoenix-client.jar and provides
 >>>>>>>>> alternate implemetations of the BlockContext
 >>>>>>>>> interface.
 >>>>>>>> Thats the only real solution at this stage.
 >>>>>>> There could be some reason why that is not possible.
 >>>>>> It will become a lot more difficult in the future when
 >>>>>> classLoader and interceptor stuff get integrated but it
 >>>>>> should be possible to no-op those features - not sure.
 >>>>> Well let's tackle future features in the future.  For now
 >>>>> though I think that useing a Phoenix jar to be Phoenix
 >>>>> compatible is perfectly possible.
 >>>> I am not sure what you are saying. If you want to implement
 >>>> BlockContext then that is fine but the implementation is
 >>>> inherently container specific. The implementation should not
 >>>> even be in the same classloader as the interface.
 >> The GenericBlockContext provides a solution for any Avalon
 >> container to workaround the Phoenix BlockContext dependency issue.
 >> It deals with the very situation you mention below - the inclusion
 >> of container specific APIs - in this case a Phoenix specific APIs.
 >> What GenericBlockContext does is to provide a mechanism for any
 >> container to be able to deal with the legacy of Phoenix dependent
 >> components that include references to the BlockContext interface.
 >> The implementation solves the problem by allowing a container to
 >> handle the association of keys and values using java.util.Map and
 >> the Context class.  Boyond this it has to implement the
 >> BlockContext interface in order to solve the issue of Phoenix API
 >> exposure towards components. Relative to a container, the
 >> GenericBlockContext depedencies are on Map, Context, String and a
 >> client supplied classpath.  Relative to the component the
 >> dependency is on Phoneix and the A-F.  GenericBlockContext provides
 >> the bridge between the two.
 >> Everything about this is solving a Phoneix issue.  But, yes - the
 >> solution can be included inside Merlin.  Yes we can create
 >> artificial depedencies between the Merlin Project and the Phoenix
 >> Project.  Yes we can oblige Merlin installations to include APIs to
 >> another container for those occasions where the client is dealing
 >> with Phoenix legacy and already have phoenix-client.jar in place.
 >> Yes, we could write this up in the FAQ and explain why its a good
 >> thing - but I may need some help on that!
 > Refering to "..artificial dependencies between the Merlin Project and
 >  the Pheonix Project" and "..Phoenix legacy..":- Phoenix
 > compatability is what we are talking about here unless I am wrong.

I believe it is the wrong focus.

The problem space concerns the use and deployment of Avalon components
arcross different containers.  We are dealing with a "legacy of
components that have been build on the assumption of one container
called Phoenix".  These components (such as Cornerstone and any other
component including Phoneix specific APIs - such as EOB) have to be
managed in a special way - in effect to take from Phoneix dependent to
being container independent via utilities.  Within this scenario Merlin
is simply the container that is pushing the envelope - its raising the
issues of non-component portability. This isn't a Merlin thing - this is
a component-to-container contract thing.  GenericBlockContext is utility
that addressed this isssue as it relates to legacy Phoenix components.

 > It could be we are talking about Phoenix obsolesence (I am not).

Nobody is talking about Phoniex obsolesence.  Pheonix is great - it
is a way cool product and the source for much of the design of Merlin.

Phoneix has features that may never exist in Merlin. Merlin has
features that may never exist in Phoniex.  Please undertand that the
term "legacy" is complete appropriate when discussing the issue of
portable components relative to the component that exist today.

 > We have an agreement a way forward for on the BlockContext issue.  It
 >  is simply to include the BlockContext class (via phoenix-client.jar)
 >  in second and subsequent Phoenix compatible containers.  Given
 > K/HC/CAPI conversation of the past, and the need for separation of
 > CAPI and K, GenericBlockContext in Phoenix CVS is the wrong solution,
 >  I think we all agree that.  Given also that the home for
 > GenericBlockContext is not certain (A-F is mooted above, but Phoenix
 > is where it was added). Given also that the content of
 > GenericBlockContext was nothing special - nothing that could not be
 > added to another kernel's CVS tree.

I don't see how you reach the conclusion the GenericBlockContext could
live anywhere.  It is completely related to Phoneix components - it is
unrelated to any other container.  I know your thinking to yourself -
but Merlin is pushing it - and I'll re-state that this is only because
Merlin is iniative that is dealing with the portability issue - dealing 
with territory that has not been tackled before within the Avalon community.

 > My feeling is that this single issue is nothing to do with the
 > attributes thread.

It has everything to do with the attribute thread.

With resolution of the attribute thread subject - component authors can
choose between a Phoenix dedicated component approach or a portable 
component approach.  You own work in EOB is currently depedent on 
Phoenix as a container - you can choose to move to a container neutral 
approach providing the attribute question is resolved.  Resolving the 
attributes issue immediately lowers the priority on something like 
GenericBlockContext (GBC) because we could rapidly update cornerstone
and the need for GBC within Avalon becomes debatable.  In the absence of 
common attribute naming and semantics GBC is a necessity.

 > That attributes need to be handled correctly designed properly and
 > due consideration given to backards compatability is paramount.  Can
 > multiple containers handle attribute changes (well additions reeally)
 >  as they are rolled out?  Yes, in my opinion.  Should attribute
 > strings be added to BlockContext, yes in my opinion.
 > *** Vote *** As such, can we vote on the recommendation :
 > (*) The Avalon team recommends that Phoenix compatile container
 > include phoenix-client.jar in their distribution and make it visible
 > to hosted components at runtime. The Avalon team recommends that
 > Phoenix compatible containers hide their implementations of
 > BlockContext in the kernel's classloader and further hide the impl
 > via use of a Refelection's dynamic proxy.
 >>>> Look at the Servlet/EJB/other APIs. They all follow this
 >>>> pattern and I believe some (servlet API 2.1+) actually mandates
 >>>> that no container specific classes can be in same classloader.
 >> Such a policy concerning Avalon containers is also appropriate.  In
 >>  general we should not be exposing container specific APIs to
 >> components. It locks the component to a particular container and
 >> introduces the problems we are currently dealing with.
 > For Phoenix, given its separation of interface and impl, it is only
 > the word phoenix that is objectionable in the phoenix-client.jar and
 > its attendant package names.  If we had our time over we could have
 > moved these classes to another tree/package.  Like with othr packages
 >  in Avalon, we are keeping there where they are for compatability
 > reasons. This line of discussion deviates from (*) above and its
 > central discussion point alternatives for GenericBlockContext (being
 > added to Phoenix CVS).

I disagree - the Framework is the source of the defintion of what a 
component is.  The Context class provides a container neural mechanism 
to the values that are needed.  This issue concerns the management of 
components that are using the BlockContext interface in the absence of a 
context management solution in Phoenix today.

   * This has nothing to do with the framework
   * This has nothing to do with Fortress
   * This has nothing to do with Tweety
   * This has nothing to do with Merlin
   * This is related to Phoenix
   * This has everything to do with components that tied to Phoneix
     by the org.apache.avalon.phoniex.BlockContext interface

 >>>> And we don't want to limit our evolution in future for so
 >>>> little a gain as having a generic implementation. It is rare
 >>>> that the implementations are more than 20-30 lines of code, so
 >>>> I am not sure what the great technical difficulty is.
 >>> Err I agree with you Peter.  The interface remains in
 >>> phoenix-client.jar and the impl is left to the container in
 >>> question.  I think Stephen is coming round to the possibility of
 >>> that fact.
 >> I'm comming around to the conclusion that :
 >> 1. the first step is to resolve the context key issue
 >> - context keys are part of the Avalon component contract - contract
 >> are intended to be maintained - solving this issue has to be
 >> addressed as a higher priority than convinience interfaces, Phoenix
 >> fixes, or other actions such as defining additional interfaces
 > I completely disagree.  We have got so far on the GenericBlockContext
 >  (the need for it in Phoenix CVS) issue.  Please don't switch
 > conversational threads when we are on the cusp of an agreement.

I don't think we are on a cusp of an agreement.  GBC is a workaround. 
Reoslution of the attributes issue elininates 95% of the need for the 

 > Please let me tackle these issues one by one.  I'll move on to
 > attributes, meta info and other issues in time. It is important for a
 >  sense of progress during mediation to resolve an issue.  Please try
 > to meet me on this simple goal Stephen.  Just because this is against
 > you original posting of GenericBlockContext does not mean all things
 > in this process are going to fall against you.  Besides, you see the
 > logic of the BlockContext argument don't you :-))

Any container with a half-reasonable context management solution will 
need something like GBC to deal with components like the cornerstone 
suite, unitil the attributes issue is resolved and the common model is 
(a) implemented in Phoneix, and (b) Conerstone component's are 
neutralized with respect to Phoneix as container.

I really think that resolution of the attribute issue is the issue that
needs to be dealt with in the short term.

Consider the following:

    // Phoneix dependent version
    File file = context.getWorkingDirectory();

    // portable component version
    File file = (File) context.get("avalon:home");

The attribute documentation over on 
excalibur/container/src/xdocs/attributes.xml provides a good picture of 
what's needed on common context keys.

Cheers, Steve.


Stephen J. McConnell

digital products for a global economy

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