The Avalon community recently voted to have a single platform. The core Avalon framework has traditionally offered quite a bit of leniency to container developers by not specifying certain standards. That has lead to various individual container standards which makes component reuse difficult if not impossible. This document serves to assist the Avalon community in
This is not an attempt to build from scratch new standards. It is an attempt to identify existing approaches and develop a responsible way to both support our existing users (via backwards compatibility or migration tools) and to offer a consistent platform for the future of Avalon.
A reminder of how to approach this process: http://marc.theaimsgroup.com/?l=avalon-dev&m=105965430911547&w=2
This is a good goal - try things out in separate containers and then merge back the code into the core. The problem is that such merges often take on the form: "This code works well in X. So we'll just put it in the core as it is, and no changes are allowed." Instead of looking at the concepts of that code, and, allowing it to change, get merged into the core: "These ideas works well in X, let's see if and when and in what form we can get them into the core." I think this was what caused the last eruption. If anything, this is what we need to work on. Learning not to lock ourselves into our own idea just because we like it the most. /LS |
\[add more here\] \\ |
Historical Context: http://marc.theaimsgroup.com/?l=avalon-dev&w=2&r=3&s=vote+avalon+meta&q=b
Merlin: Avalon-Meta
<type> <info> <name>my-component</name> <version>1.2.1</version> <attributes> <attribute key="color" value="blue"/> <attribute key="quantity" value="35"/> </attributes> </info> <loggers> <logger name="store"/> <logger name="store.cache"/> <logger name="verifier"/> </loggers> <context type="MyContextInterface"> <entry key="base" type="java.io.File"/> <entry key="mode" optional="TRUE"/> </context> <services> <service> <reference type="SimpleService" version="3.2"> <attributes/> </service> </services> <dependencies> <dependency optional="FALSE" key="my-transformer" type="org.apache.cocoon.api.Transformer version="1.1"> <attributes/> </dependency> </dependencies> </type> |
Fortress Meta
Example of .meta
#Meta information for org.apache.avalon.fortress.examples.components.TranslatorImpl #Mon Mar 08 10:59:53 EST 2004 x-avalon.lifestyle=singleton x-avalon.name=translator |
Example of META-INF/services/org.apache.avalon.fortress.examples.components.Translator
org.apache.avalon.fortress.examples.components.TranslatorImpl |
ECM/Fortress Roles Files
Example from avalon-standbox/examples:
<?xml version="1.0"?> <fortress-roles logger="system.roles"> <role name="org.apache.avalon.examples.simple.Simple"> <component shorthand="simple" class="org.apache.avalon.examples.simple.impl.SimpleConfigurationImpl" handler="org.apache.avalon.fortress.impl.handler.ThreadSafeComponentHandler"/> </role> </fortress-roles> |
Phoenix .xinfo
<?xml version="1.0"?> <blockinfo> <block> <version>1.2.3</version> </block> <services> <service name="com.biz.cornerstone.services.MyService" version="2.1.3" /> </services> <dependencies> <dependency> <role>com.biz.cornerstone.services.Authorizer</role> <service name="com.biz.cornerstone.service.Authorizer" version="1.2"/> </dependency> <dependency> <!-- note that role is not specified and defaults to name of service. The service version is not specified and it defaults to "1.0" --> <service name="com.biz.cornerstone.service.RoleMapper"/> </dependency> </dependencies> </blockinfo> |
Commons Attributes
Fortress
These are passed to the components. Please note that "context-root" was at one time "app.home" until it got changed--I cannot remember the circumstances of that change. * impl.workDir File (directory) temporary directory * context-root File (directory) Context directory * component.logger String Component logger name * component.id String ID used to locate the component |
Avalon Meta
urn:avalon:partition String partition name urn:avalon:name String component/scenerio name urn:avalon:home File (directory) persistent directory urn:avalon:temp File (directory) temporary directory urn:avalon:classloader ClassLoader component classloader |
Phoenix
app.name String application name block.name String component name app.home File (directory) persistent directory |
|
Datatype |
Phoenix |
Fortress |
Avalon Meta |
component name |
String |
block.name |
component.id |
urn:avalon:name |
app/block name |
String |
app.name |
component.logger |
urn:avalon:partition |
app home dir |
File |
app.home |
context-root |
urn:avalon:home |
app temp dir |
File |
|
impl.workDir |
urn:avalon:temp |
component classloader |
Classloader |
|
|
urn:avalon:classloader |
Comment from ???: Why not, if the container knows the component's intended enviroment, map? So if a component that was written for Phoenix asks for app.home, give it urn:avalon:home.
Comment from Steve: mapping from standard context entries to environment entries is handled via the Avalon Meta alias attribute as per framework documentation. This allows a Phoenix component to lookup "app.home" and get back the value corresponding to the standard "urn:avalon:home" entry.
Comment from leosutic: Sure. That solves backwards compatibility. But it'd be nice to have one canonical name for the thing, just for the sake of reducing the number of names for the same thing.
Comment from niclas: If so, feel free to implement such uniformity in the legacy containers. Or is it something I don't understand?
There are some updates to the framework itself which may need to be made:
_ just setting up the basic structure here_