> If such concepts exist then they will be specified by metadata of some
sort.
> Could be like fortress with per assembly metadata or like Phoenix with per
> component metadata.
So you are promoting a flexibile metadata approach derived from the
component source files? Do you propose a tool and standard manifest format
so that a jar can carry metadata related to its 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?
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?
> For Selectors that take strings then hopefully
> lookup( Blah.ROLE + "/Selector" ).get( "foo" );
> will be replaced by
> lookup( Blah.ROLE + "/foo" );
Can we please have some terse and pithy technical discussion related to
Peter's proposal vs. the existing proposal put forth by Berin, Stephen, et
al?
Please remember that technical assessments require proper justification. To
preempt a repeat of earlier conversational patterns, let me note in advance
that words like "interface", "metadata", "flexible", "reentrant",
"performance", "overhead", or even "flawed" are descriptive. Words like
"sucks" and "stupid" are inappropriate; they may be emotionally satisfying,
but are hardly technical in nature. Given the fact that no one has yet to
release a processor with an ego pipeline, let's stick to the 1s and 0s.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
