I'm going to show my .NET ignorance here, but does it already handle the
active metadata scenario that you gave as an example? Could you elaborate a
bit on what it does provide (or point me to some quick high-level docs that
explain it)?
Thanks,
Erik
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, March 25, 2002 6:14 PM
Subject: RE: [Xdoclet-user] Java meta-data JSR from Sun
> Well, I would expect a little bit more since .NET already provides more.
> It's not just about passive metadata (like a XML file, for instance) but
> it's about "active metadata" (or whatever we called it), active in the
sense
> that the metadata could trigger/implement some runtime behavior... Think
AOP
> (Aspect Oriented Programming). My point is that if they want to do it
right
> and I'm sure they do (and will :-)) they're going to have to change/extend
> the current VM and that's take time and a lot of intelligent people. I
> wouldn't worry about the need for intelligent people since Joshua Bloch is
> already there. The issue here is time as always.
>
> Now I would like to clarify what I mean by active metadata. Imagine the
> following scenario: you want all the calls to the method foo to be
> automagically logged for you. After browsing the java.util.logging
> documentation you discover that all you have to do is to tag the method
with
> the Log attribute (the samples uses the C# syntax that looks a lot like
> IDL):
>
> package foo.bar;
>
> import java.util.logging.Level;
> import java.util.logging.attributes.Log; // fictional attribute class
>
> import javax.xml.attributes.XmlElement; // fictional attribute class
>
> [XmlElement(Namespace="urn:foo:bar")] // Passive metadata (someone might
use
> this)
> public class Bar implements java.io.Serializable
> {
> [Log(Logger="foo.bar")] // Active metadata (introduce runtime
> behavior)
> public void foo()
> {
> //1) Logger.getLogger("foo.bar").enter("foo") implicitly
> called by attribute
>
> ...
>
> //2) Logger.getLogger("foo.bar").leave("foo") implicitly
> called by attribute
> }
> }
>
> The lines marked 1 and 2 are behavior introduced automagically by the
> attribute, you don't have to type those lines but the method behaves as if
> you did. So, somehow, the runtime will have to change to give attributes a
> chance to pre and post process method calls when they need to.
>
> Can we live without it? Yes, we have AspectJ, XDoclet and IContract. But,
> frankly, I think attributes and "active metadata" would be a nice addition
> to our toolset.
>
> Rodrigo
>
> ----- Original Message -----
>
> > >From the points there, it is exactly XDoclet isn't it.... afaik, no
other
> 'code annotation tools' provide the framework that XDoclet
> > does - includeing the 'Definition of a runtime delivery format for
> metadata and of runtime APIs so that tools and libraries can
> > accesss metadata information at deployment time and at runtime'.
>
> Speaking of which.... it would be fairly straightforward to have XDoclet
> create an XML file (or some other metadata format, perhaps even serialized
> objects generated from post processing of the XML?) for each class
processed
> and create a utility to make all that information available to the class
at
> runtime.
>
> Anyone ever considered this? Done it?
>
> Its not really necessary, generally speaking, since XDoclet builds the
> pieces we need at runtime anyhow, except in a more narrow/specific way. A
> generalized mechanism could be an interesting addition, and beat this JSR
> release for sure, and compete head-to-head with .NET's capabilities.
>
> What kinds of suggestions do folks have for how such a mechanism would
work?
> Via Castor maybe (? I don't know Castor's details)?
>
> Erik
>
>
>
> _______________________________________________
> Xdoclet-user mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/xdoclet-user
>
_______________________________________________
Xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user
