Re: [PROPOSAL] lifecycle release

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
>>missing?
> 
> 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.

Gotcha.

>>>@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.

Stefano.