Nicola Ken Barozzi wrote:
>
> Peter Donald wrote:
>
>> On Mon, 26 Aug 2002 21:56, Nicola Ken Barozzi wrote:
>>
>>> If yes, they should be in framework IMNSHO.
>>> If no, it should be clearly stated that they are Phoenix-only
>>> compatible.
>>
>>
>> Well given that cornerstone was designated a "Set of default services
>> for Avalon/Phoenix" I think it is a given that they are only
>> considered to be supported for Phoenix deployments. The link against
>> Phoenix can be broken for some of them after the next evolution stage
>> and most of the components will be migrated back into excalibur.
>
>
> Yes, ok. It's mainly a user-perception issue ATM.
>
> IMHO the next evolution stage is near, hence my "proactive" thinking ;-)
>
>>> So you are saying that the Phoenix BlockContext has to be regarded as
>>> the standard Container Context?
>>
>>
>>
>> Nope. I don't think anyone one has suggested that.
>> However if a container needs to run components that were written to a
>> particular containers API then they need to have a compatability
>> layer. Much like if you use a bunch of components in excalibur you
>> are still largely restricted to ECM/Fortress unless you want to
>> extend your component or your container.
>
>
> Yes, I understand/agree.
>
>> Stephen has been suggesting that Phoenix should be maintaining a
>> compatability layer for Merlin because Phoenix is legacy, badly
>> written etc.
>
>
> I didn't understand he meant that, and privately he has never said so.
> He says that Phoenix is *different* from Merlin, and for some
> functionality, Merlin is better, that's all.
>
> If he intended in any way discredit Phoenix, and I don't think he did,
> I would have backed your resentment from the start.
>
>>> Can we make this "spec" become more clearly defined and part of
>>> framework somehow?
>>
>>
>> This is where things are going. Just need more time to experiment
>> with things to make sure we are going in the right direction. The
>> core ideas are relatively stable and are mostly derived and enhanced
>> Phoenix ideas.
>>
>> See
>> jakarta-avalon-excalibur/containerkit/src/java/org/apache/avalon/framework/info/
>>
>>
>> For the "code" view of Component info (descendents of BlockInfo).
>> They basically describe the requirements of a Component (ie what
>> services it needs, services it exports, context entrys it requires,
>> loggers it uses etc.
>
>
> Hey, this is what Merlin does... hmmm...
>
>> Each aspect of component can be extended by "attributes". Attributes
>> are key=value pairs that store extra information about the aspect and
>> allow you to extend it in all sorts of ways.
>> It is the attributes that are the things proving difficult to define
>> as they require all sorts of experimentation. It is these attributes
>> that are the causing the delay in it coming about.
>
>
> Ah, ok.
> I still don't understand well why you and Stephan say the same things
> but have two different Containers...
>
> IIRC you and Stephen were working both on ContainerKit, why does
> Stephen (question for Stephen, and *please* be short) think that this
> approach is not enough?
Containerkit is too much and not enough.
The containerkit package is a overall container architecture that goes
from the lowest levels such as xinfo DTDs, through meta-info (the
defintion of an object model describing a type of component), up through
meta-data (information describing component deployment) and the way in
which this information is managed by a kernel.
While working on containerkit I came experienced:
* functional limitations at the meta-info and meta-data levels
* architecture too closely following Phoenix static assembly model
* architecture not sufficient abstract to support the Merlin dynamic
approach
* unnecesasary implemetation complexities when attemting to use the model
* extreme difficulties in collaboration on the activity (too many -1s)
* major loss of time attempting to communicate requirements
This resulted in the fork of a small part of containerkit dealing with
the xinfo and meta-info model (no container in the excalibur/meta
package). Since the fork, excalibur/meta has grown substantiallly in
terms of documentation, has evolved to refelect suggestions and
concensus on terminology discussed on this list, and has incorporated
the hooks necessary to allow Fortress and Merlin specific management of
extensions.
>
>
>>> 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.
>>
>>
>>
>> The notion of a Block disapears in next stage of evolution - there is
>> just Components and all of them are really super-charged Blocks in
>> current terminology.
>
>
> Yes, I understood that and it's very nice :-)
>
>> I don't think it is appropriate just yet to define the SAR deployment
>> format (which includes all the assembly/configuration/environment
>> data) because containers will definetly need different things in this
>> area. It may be possible to define a package (jar) format. Possibly
>> something like
>>
>> * standard naming convention for JDK1.3 Extensions in manifest
>> * standard mechanism for defining components (ie
>> META-INF/avalon/components.xml)
>> * standard mechanism for defining factorys, resources and possibly
>> "roles"[1] (ie META-INF/avalon/roles.xml, META-INF/avalon/resources.xml)
>>
>> [1] Note that this is partially inheriting from work in myrmidon and
>> may not be so appropriate for phoenix and merlin. But it would be
>> appropriate for Cocoon and Myrmidon. However this will take longer to
>> figure out if we can figure it out at all.
>
>
> Ok.
> But again, it seems that you are not giving a look at what Merlin did
> about this IIUC it did some experimentation about it.
>
> Why can't some of the more generic Merlin features on this part be used?
>
> I understood that lifecycle extensions tend to ring alarm bell on you,
> and I have personally accepted that ATM it's better to relefate them
> to a Merlin/Fortress container specific thing.
It is important to note that the excalibur/meta meta-info model does not
oblige a container to implement lifecycle extensions. It simply
provides the hooks against which contains can provide solutions. Work on
excalibur/meta is much more a case of the minimal meta model package -
the meta-model that does not tell you how to build a container but
provides the foundations. Incorporation of excalibur/meta into
containerkit is totally possible.
Cheers, Steve.
>
>
> Let my try to enucleate Merlin "features" and how they relate to
> current issues.
> Please be patient, it's difficult for me because you are so quick and
> nimble on these things, I'm not so into them so deeply yet.
>
> Merlin Kernel
> --------------
> A Merlin and a Phoenix abstraction for Container management.
> IMHO there is no need to expose this out of the Merlin Container.
> Maybe in the future Phoenix and Merlin Kernels will be interoperable,
> maybe.
>
> Cascading containers
> ---------------------
> No need to expose this outside of Merlin.
>
> Exported services
> ------------------
> If Merlin is run as a Phoenix block, it can expose services it Manages
> well, so this is a possibility of playing well with Phoenix.
>
> Lifecycle Extensions
> ----------------------
> Controversial, there is no immediate need to expose them to *all*
> containers.
> We should though define that any Container that implements extensions
> is highly recommended to use the standard extension mechanism.
>
> Deployment & Assembly
> ------------------------
>
> Highly important that we get this to a common level.
> If you regerd that having all components use a single Container model
> is too limiting ATM, and I respect that, we must achieve compatibility
> on the descriptors.
>
> http://jakarta.apache.org/avalon/merlin/assembly.html
> http://jakarta.apache.org/avalon/merlin/deployment.html
>
--
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]>
