hammett wrote:
----- Original Message ----- From: "Stephen McConnell" <[EMAIL PROTECTED]>
org.apache.avalon.composition.model.impl.Scanner (in the
merlin/composition/impl package) you will see an example of the appraoch
used within the Merlin container (basically for all entries in the
classpath, scan each entry for component definitions).
That's very simple indeed. The .roles file in Fortress will be overrided by
meta, I wonder about the .xconf files...
I saw .xprofile files in merlin, seems nice. As curiosity: is this the only
way to configure components?
A component type may have a default static configuration (defined in xconf). It may also have multiple package profiles that include specialized configurations that suppliment the default (defined in xprofile). That's it from the component developer perspective. Now over to the assembler - the assembly can define supplimentary configurations that are applied over a profiles configuration. These different aspect establishes the initial configuration. There is also runtime control - when a component type manager is in an undeployed state - a management application can modify aspects of its meta-models (including configuration, startup policy, context handling, parameters, etc.).
Are we planning a wonderfull world where people could deploy their services on fortress or merlin without bothering about their differences? If so, the Avalon meta is the first step - from my point of view - and more things, like Merlin scanner, should go up to a common-shared project to be used by merlin and fortress and by anyone who feels like want to.
I agree - that's the principal reason for the seperation of the composition, activation and merlin packages. The composition package deals with the synchronization of meta-info, meta-data and runtime context. However, it is dealing with meta-data and that means we are getting further a particular apprach for declaration of component deployment. For example - using the Scanner assumes that the container implementation recognizes and works with object like ContainermentProfile, DeploymentProfile, ProfilePackage, etc. In theory the composition package could be split out into a data package and a model package - if the need arrises.
I still believing in a container spec in a neutral language/plataform
fashion with basics rules that container implementors must follow and
suggestions of implementation.
+1
Steve.
Regards, hammett
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
