avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [PROPOSAL] lifecycle release
Date Tue, 18 Mar 2003 10:18:44 GMT
Peter Donald wrote:
> On Mon, 17 Mar 2003 06:23, Stefano Mazzocchi wrote:
>>>The JSR has not been made public but from the grapevine heres the scoop.
>>>The metadata will be store in .class file as "class attributes". So it
>>>will not require a JVM change but the utility files to load the metadata
>>>will be in the next JVM. However that does not stop us developing our own
>>>loader that parses the the .class files using BCEL.
>>I see.
>>But once you have that metadata inside your class, how are you going to
>>find out something about it? introspection or direct bytecode manipulation?
> direct bytecode manipulation pre jdk1.5. However we can also store metadata 
> side by side class and load via standard classloader.

I see.

>>Those sounds much less elegant than any instanceof() calls. What am I
> you can include rich metadata in here that interfaces can't handle. ie You can 
> say method X is capable of being remoted, interface y is transaction aware, 
> component y takes a service using key A of type B but it is optional etc.


>>>@meta Fortress{lifecycle="ThreadSafe"}
>>>@fortress lifecycle="ThreadSafe"
>>>@meta org.apache.avalon.fortress.FortressMetaData("ThreadSafe")
>>Ok, makes sense.
>>do you think this is going to be enough for the metadata needs you
>>foresee? just curious.
> Mostly. Somethings are ugly. Essentially it gets ugly when you nest metadata 
> greater than two levels and have repeating groups. 

Yes, that's what I was envisioning.

> However I have only needed 
> that once and after going through the dot.net stuff and following xdoclet 
> development I can see there is always work arounds. ie Rather than repeating 
> groups xdoclet tends to design their tag schemas to use different prefixes. 

micro-namespacing. I see.

makes sense.

Thanks for filling up some of my ignorance on these topics.


To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message