On Fri, 14 Mar 2003 09:10, Noel J. Bergman wrote: > So you are promoting a flexibile metadata approach derived from the > component source files?
I would promote a extensible metadata approach but are less concerned about flexability except at a few important join points - in particular the mechanism via which metadata is loaded should be relatively flexible. One of my friends is currently loading metadata from a database (yikes!) and thinks that is the ants pants because of ability to centrally manage this. But then again I tend to consider metadata that needs to be managed as configuration rather than type information and thus probably should not be stored with component as such or maybe via some other mechanism. Marking up metadata in source files is definetly my preferred approach but there is plenty of other mechanisms that are valid. > Do you propose a tool and standard manifest format > so that a jar can carry metadata related to its components? I will eventually when I find one I like. A standard manifest format is going to be harder to do given the broad range of resources usually stored in jars. However it would be more than possible to have to get a stop gap measure in that just stored classnames of components. > > The last six months I have been developing a container that extracts all > > metadata from attributes/javadoc tags (similar to commons-attributes, > > dot.net attributes or the various interceptor frameworks). So it would > > end up being specified by something like > > > > @fortress.lifecycle name="ThreadSafe" > > Is it necessary for the container name to be part of the tag? How do I > declare the metadata to be more portable between containers? Or am I > misunderstanding the tag semantics? The tags can be whatever you want. Very little of it is cross container though hence they should stay in container specific or domain specific namespaces. ie altrmi.* is for altrmi stuff, fortress.* for fortress stuff etc. I used to have some docs up on the website but it looks like someone disapeared them. You can see the source of the docs in avalon-sandbox/info. Have a look at doclet.xml and you will see a bunch of tags that define common meta data for resources required and offered by the component. It does not define the full set but it does define a common subset. Also look to features.xml and you will see the mechanism by which extensions are added and required. So a component can declare that it requires "fortress" semantics present to run and will optionally use "altrmi" features if present. The info docs are relatively old and crusty but there is a bit in there that I will eventually harvest again. > Also, is there a mechanism for components to modify the container > lifecycle, e.g., to add new lifecycle methods that are managed by container > extensions? In my system - yep. Hell - the components don't even have to be Avalon components, they can be RMI objects, JMX objects or some custom lifecycle objects. They can be any objects from any system that I can see. Just another interceptor chain. Avalon is justa an implementation detail. -- Cheers, Peter Donald -------------------------------------------------- Logic: The art of being wrong with confidence... -------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
