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.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
