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.
> 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.
> > @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. 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.
--
Cheers,
Peter Donald
----------------------------------------------
Money is how people with no talent keep score.
----------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
