Peter Donald wrote:
Just a note that I think that we will sooner or later have to deal with the pooled concept at the framework - by the addition of a specific interface for a Pool, or, elimination of pooling notions at the level of ServiceManager and ComponentManager.On Sat, 11 May 2002 12:07, Stephen McConnell wrote:
Pete:
No problem with any of the proposed changes.
kool.
I would like to see addition of support for CascadingConfigurations together with the addition of extensions to the .xinfo file to contain a default confituation declararation (which would bring Phoenix and Merlin almost totally in sync). Any thoughts about how this can be achieved?
A few. Currently I am working on trying to get decent interoperability between Merlin, Fortress, ECM, Phoenix and Myrmidon. While each container has slightly different needs there is also a bunch of common ground. Currently the main things I am interested is getting together a single representation of component meta data.
The types of component meta data I am thinking of is mainly;
* lifecycle "style": Is it poolable, is it re-entrant, is it threadsafe, is singlethreaded etc
I'm assuming you mean something along the lines of org.apache.excalibur.context.ContextUtility (which I'm using within Merlin). It handes the above but the javadoc really needs some work.
* context: - Context Class
- Entrys in Context (both name of entry and type of entry)
* service:
- services required by component * configuration/parameters:
- schema+validaiton of Configuration/Parameters
In each different container the info is represented differently. However what I was thinking of was developing a set of standard javadoc tags and processing the sourcefile using the XDoclet tool available at;
http://sourceforge.net/projects/xdoclet
This tool would generate the manifest files, blockinfos, possibly default configurations and so forth in context of Phoenix/Merlin.
This is probably the asiest first step.
Before answering the above, I'll go into a more detail concerning Merlin configuration semantics. First of all - the import differences between Merlin and Phoenix is that Merlin's support for assembly is much more limited than Phoenix - but the other side of the coin is that it handles component assembly and execution without the overhead of assembly.xml, environment.xml, etc. Merlin achieves this through extensive application of cascading configuration information. For a top-level target component Merlin is the container. The target configuration is created based on the following:
With a different template you could use XDoclet to generate the descriptor files for Fortress/ECM/Myrmidon.
Inital ideas are either (a) implict addition of default configuration handling within Phoenix, or (b) the ability to declare an alternative/pluggable configuration resolver.
Technically is possible now. I could even add in plugin points to the deployer if you really want this right away (And you could just create a custom MerlinDeployer that uses CascadingConfiguration).
I was going to try address it in a global manner first but if you want me to make it possible for you to overide default behaviour with CascadingConfigurerr then it should be relatively easy. Just say the word.
(primary) (parent)
<configuration-file> <target-xinfo.configuration>
| |
---------------------------
|
<target-configuration>Based on the dependencies declared in the .xinfo file, the container creates and populates a service manager (or component manager) using the following cascading configuration schema:
(primary) (parent)
<container.dependency.configuration> <dependent-xinfo.configuration>
| |
-----------------------------------
|
(primary) (parent)
<target-configuration.role> <dependant-configuration>
| |
-----------------------------
|
<dependent-configuration>The above graph assumes two extensions to the Phoenix .xinfo schema. Firstly, there is the usage of a <configuration> declared as a child of the <block> element (typically used to hold release related configuration info (as distinct from deployment configuration info). Secondly, Merlin looks for a <configuration> element declared within a dependency declaration and uses this in the construction of a configuration chain for the dependent service. The overriding principal is that this collection of information should enable the complete establishment of a component and that the level of site configuration should be very small if not totally eliminated.
Example .xinfo file:
The dramtically simplifies site confugration and lets me seperate relase configuration from deployment configuration (i.e. I put release configuration in the .xinfo and deployment configuration in a seperate modifyable configuration file). The second area that I've been playing around with is the inclusion of a configuration element within a dependency declaration. The purpose of this is to declare the default configuration profile for role.
Example:
<blockinfo>
<block name="my-service"> <version>1.0</version> </block>
<services>
<service name="net.osm.HelloService" version="1.0" />
</services> <dependencies>
<dependency>
<role>directory</role>
<service name="net.osm.directory.DirectoryProvider" version="2.4"/>
<configuration>
<!--
This contains a configration elements that are used
to ensure that the dependent service is appropriately
configurared. For example, the HelloService may need
an orb that is preconfigurated with a POA and
NamingService - as such, the configuration elements
included here can be considered as constraints applied
by the HelloService that must be fulfilled by its
container.
-->
</configuration>
</dependency>
<dependencies><configuration> <!--
This configuration element contains the default configuration
for the component.
-->
</configuration>
For completeness, there are two other .xinfo additions that should be noted. Firstly, there is the introduction of the name attribute on the block element. This is used to establish the name to assign to a logging channel for the root component. Secondly, Merlin supports a <context> declarations within a .xinfo which is handled by the ContextUtility class.
Cheers, Steve.
--
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]>
