Nicola, >>> I do not see how this would fail to add value towards the Avalon >>> user. Perhaps you could provide your recommendations for the best >>> approach for users who are considering the development of new >>> components that they indented to be container neutral? A Phoenix >>> wrapper hides the problem, but I don't think this is the best >>> approach given the different features and benefits presented some of >>> the more recent generation containers? >> >> >> >> Now mate, I'm getting worse again. I'll reread later and see if it >> makes any sense! It looks at first glance like sales blurb for Merlin > > > Paul, now it's you who is being blind. > > The above paragraph says nothing about Merlin.
I inferred it, in a tongue-in-cheek way from 'more recent generation'. > It says that we should strive to make the same Components workable in > all containers, even the more recent ones. > "given the different features and benefits" only hints that other > containers like Merlin have *different* features and benefits, not better. > > But if it were a sales blurb for Merlin? > Does it annoy you? > > Given your previous conciliatory mails, I hope not. > Let's get the best of both worlds instead of fighting. If you read my single line again, you'll note that it is concilliatory (the word 'mate'). Indicates I am going to comback with something of acomment that is less throw away. I really don't want to be pointed at as part of the problem. I really do not want that. I am going to ask you to not question my impartiality again. There are risks inherent in that that make me shrink from my mediation path. > <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> > > I see three issues to tacle ATM: > > 1) define a simple and workable set of rules to make container nesting > seamless. Peter has already said that it can be done, and it would > make it possible to embed seamlessly Merlin in Phoenix, or viceversa, > or any other, as I proposed in previous mail as a workable cooperation > solution. Which is sort of what we are doing. I'm choosing to tackle an issue at a time. Currently I am dwelling on phoenix-client.jar the previous required class GenericBlockContext. > 2) define a set of common attributes. Some attributes are like > interfaces, and must be discussed on and standardized on (see the > common-attributes-revisited thread). Attributes is in process as a discussion. I see no need to interfere with the lengthy discussion on that at the present moment. All parties moved on the naming of attributes as the discussion progressed. There is no need to mediate. > 3) define a common startup layer for the Avalon Containers, so that it > can be used with all containers. I imagine a single set of shell > scripts, a single servlet container, a single class container, which > can use inside any other container. > This would make it possible to run Phoenix or Merlin or whatever as > standalone, or in a servlet, or in another program... and also nested. I don't think you can count servlet. Why? It is not an Lifecycle using API. > This would eliminate the problems we are having now, by making > components usable in all containers by nesting containers, and making > any container easily embedded in other apps. With respect, I have written two containers that sit on top of the default container Phoenix. They are Jesktop and EOB. Both of them handle classloading of their separate componets well enough. It would be nice for me to use ContainerKit or Excalibur/Container to save lines of code, but I have not done so yet. Anyway, the point is that container-in-container is possible already. *Please* let me continue with my slow programme of issue-by-issue conflict resolution. Regards, - Paul -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
