Stefan Seifert wrote:
Stefan:
I think this may be the wrong approach. Instead of modifying the sources as your suggesting, I think the better approach is to either (a) modify the tools that are generating meta-info for Fortress, or (b) modify Fortress to recognize meta-info via the Avalon Meta framework.
Stephen.
Even better, but i'm not sure what your further plans concering fortress and meta framework are:
- Is ist planned to switch fortress to the new meta framework once it is ready? In this case it makes not much sense enhacing the forrest meta-info generation.
Berin has started on migrating Fortress to Avalon Meta and hammett is also looking at this.
- Is the avalon meta framework ready for broadening its scope beyond the merlin container? (i must admit that i did not have a deeper look into the current releases)
The Avalon Meta package is not specific to Merlin. It can be used in any containment solution. Runtime dependencies (exluding tools) include Avalon Framework, Excalibur Configration and Excalibur i18n.
- Is there a reason why fortress uses a different way to collect the meta-informations? Or is it just historical evolution?
Historical evolution.
- Is there already meta information defined based on avalon meta for the cornerstone components or plans to do so?
For the time being the cornerstone packages include the legacy phoniex blockinfo descriptor. As we move forward I suspect that we will want to move to full declaration using Avalon Meta info structures. We will need to keep the blockinfo descriptors to ensure backward compatibility with the Phoenix platform but we can move to a senario where these are generated based on @avalon tags.
- Is Fortress replacable by merlin?
In the future - yes.
Today - partially. Prior to the release of 3.0 the pooled component support in Merlin was pulledout because some more thinking was/is needed on this subject - so this needs to be finalized before the full set of lifestyules are supported. Secondly, there is the problem/challenge of dealing with Selector semantics used within some ECM and Fortress components. What I would like to see is the ability to declare at the component type level the semantic assumptions that a component has. We can do this at meta-info generation time (including capture of the depricated lifestyle marker interface flags), and using this information we can be smart about the container side semantics - switching in when necessary the support for ECM/Fortress assumptions (possibly using a dedicated appliance).
From the documentation i got that merlin is the sucessor of phoenix, but not suited for a embedded servlet environment like fortress. Is this correct?
No. Merlin is specifically designed to be embeddable. There are projects looking into embedding Merlin inside a web-app, and other project dealing with a web-app under Merlin. In both cases there is the subject of service access and the preferred approach here is to enable web application access to merlin services via JNDI. The JNDI aspect and kernel loading aspects are both areas under development.
Or was this already discussed on the mailing list? I searched a bit but found not much concerning fortress and cornerstone. If i know your plans i can see where i can help.
The avalon meta package does not current recognize lifestyle interface - the package could be updated to use lifestyle interfaces to establish defaults in the absence of an explicit lifestyle attribute. Also, an ant task and maven plugin that converts source files using Fortress tags to Avalon Meta tags would be a good addition to the toolkit.
Stephen.
Stefan
--------------------------------------------------------------------- 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]
