Nicola, >> 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. It could be we >> are talking about Phoenix obsolesence (I am not). > > > I am *definately* not either.
Kewl, it looks we're all on the same page then. > Phoenix has his very important space, Merlin/Fortress will have his. > The more they can work together and in *synergy* the better. I agree. >> 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. >> >> My feeling is that this single issue is nothing to do with the >> attributes thread. 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. > > > You are saying that a container that wants to use Phoenix-compatible > Components use BlockContext? > > Hmmm..., rephrasing: that a Container that uses Phoenix's blocks must > use other Phoenix stuff too? I'm uncomfortable with the word stuff Nicola. BlockContext for one, other classes from phoenix-client.jar too. I've suggested before that phoenix-client can be paired down a little further and think we should revisit that in a later discussion. > Now, since Cornerstone is about Phoenix blocks IIUC, does this mean > that the Phoenix blocks are the standard Avalon Components? People in this list for a while know I sway away from the use the of the word Avalon in anything other than a 'project' sense. Avalon is not a product it has not components. Avalon-Framework is a set of of interfaces (++) that define the way that a nomber of containers interoperate with lifecycle things. Some things in excalibur are simple A-F aware components that can be used like normal libraries jars by Java classes. Something are containers for special situations - ECM for Servlets (not exclusive). Tweety for play, Phoenix for enterprise. Some of these containers have different rules as the lacing together of components. Phoenix separates lacing-together into assembly.xml and configuration into config.xml. Others are less strict. A less strict one is EOB, which affords its components the runtime binding that Phoenix itself does not. > If yes, they should be in framework IMNSHO. I might agree that, given our time over that would be a better place. However that is off-topic. We are principally addressing one element of the recent disagreement. Namely the adding of GenericBlockContext to Phoenix CVS. Its author did so because he felt it was the only choice. Between us we have come up with an alternate solution that seems to be more inline with the original design of Phoenix. Nicola, please take a look at the contents of phoenix-client.jar - it is quite benign. > If no, it should be clearly stated that they are Phoenix-only compatible. > And compatibility should not be attained by wrapping Phoenix stuff > artificially, but by hierarchically containing Phoenix, which is a > much cleaner solution. > > I don't like your proposal. Well that is a shame, but you are admitting that is a possible solution to the central issue of this thread which was the adding of GenericBlockContext tp Phoenix by Stephen. I do intend to adress the enhanced featuresof Merlin later. I also intend to be favourable to the concept of value-added. One issue at a time please. >>>>> 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). > > > So you are saying that the Phoenix BlockContext has to be regarded as > the standard Container Context? Yup, it seems that the multi-year-old BlockContext is part of a defacto API. If you look at phoenix-client.jar you'll see that it is quite small and given amazing accident or far-sighted design by Stefano/Fede and others marks a good division between interface and impl of Phoenix from the component writers point of view. Yes, it has the word phoenix in it, but as I have pointed out before does not mean that all of Phoenix has to be included. It is already a better interface/impl separation than Sun's JMX or Servlet APIs are which require forking by alternative container developers. > This I understand, and I would like to see it become part of the > containerkit somehow or of the framework if this is the case. > > Don't ask me why, it's obvious. Apart from backards compatability. Yes, I might agree to a move to A-F. No, I might agree that it we had our design time again, we'd have a hierarchy (or not) of Context in A-F. A move to containerkit is not going to please the Merlin folks as they are based on excalibur/container. However the central point of this thread is to adress the need for GenericBlockContext in Phoenix CVS. Perhaps my suggested vote topic was wrong. It should have been "[Vote] GenericBlockContext in Phoenix CVS is the wrong solution +1" >>>>> 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. >> 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 :-)) > > > I completely disagree. > > *If* I understand what you are saying that is... > > To be more clear, *what* are we discussing about? > > A temporary solution for interoperability between Phoenix and > Merlin/Fortress or standard way of defining the Context? > > If it's the first case, I agree; this is the easiest solution ATM and > the best given that Phoenix is mature while Merlin is still growing. > > If it's the second case, I really fail to understand how you think > that all Containers must adopt Phoenix inventions. I did not say that. Do not put words in my mouth. I am suggesting that all 'enterprise' containers that look to support blocks should be compatible with phoenix. I'm not covering ECM here. I'm not covering Servlet containers etc. I am covering containers who's stated aim is some level of interoperability with Pheonix. Could we try to keep discussion on the topic of GenericBlockContext. > I thought they had to adopt the framework. As well yes. That /is/ a prerequisite for all Lifecycle aware containers. Again though, that does not cover Servlet containers, or EJB containers. It also does not cover Applets (given they too are mounted in a container). > IMHO this has come out from the fact that Phoenix has been defining > (in a concerted effort) and bringing forward the concept of Blocks and > SARs. > > These are becoming important concepts for Component reuse, and Peter > is correctly working with ContainerKit for better reusability. With all due respect to Peter's effort there, Merlin is not using it. You will have a diffucult time convincing Stephen to move Merlin to containerkit. At a certain 'personal choice' level he should not have to. > Can we make this "spec" become more clearly defined and part of > framework somehow? > Do I understand correctly that ContainerKit is Peter's tentative in > that direction, and that Merlin is Stephen's? No Merlin is a container that cn do the lot. Container kit is a reusable kit that a container writer may use as a part of a larger development which is a container. > I repeat myself, let's define the contracts and the boundaries well, > and I humbly suggest you to also tackle the block and SAR think, > because I think that they are valuable concepts that need to be > integrated more at a lower level. Could we try to keep discussion on the topic of GenericBlockContext. SAR, Block, Assembly, .xinfo later please. - Paul -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
