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.
> 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.
Stephen has been suggesting that Phoenix should be maintaining a compatability
layer for Merlin because Phoenix is legacy, badly written etc.
> 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.
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.
> 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.
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.
--
Cheers,
Peter Donald
----------------------------------------
"Liberty means responsibility. That is
why most men dread it." - Locke
----------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
