I was having an easter holiday, so I am a bit late for this discussion.
But I would just like to describe a bit similar approach which we have
been working on with a friend of mine. Some months ago we started to
make an API to instrument Java bytecode (http://jiapi.sourceforge.net).
That is, to manipulate Java bytecode at load time. This tool can be used
add features to Java classes which I think is quite similar to what you
meant by "acive metadata". The difference, as I see it, is that the
runtime can't differentiate the instrumented bytecode from the original
bytecode. If the runtime would be "metadata aware", it would be possible
to switch off or on the "active metadata" more easily.
I have also started an experiment to implement AspectJ like semantics
utilizing Xdoclet and Jiapi. I call this experimental project as
Jazzpect. The logging example you provided could be implemented with
Jazzpect as:
/**
* aspect:class target="*"
*/
public class MethodTrace extends Aspect {
/**
* @aspect:pointcut type="method-execution"
* args="this,method-name"
* method="insert"
* when="around"
*/
public void trace(Object currentObject, String methodName) {
System.out.println("enter " + currentObject.getClass().getName()
+ "." + methodName);
proceed();
System.out.println("leave " + currentObject.getClass().getName()
+ "." + methodName);
}
}
public class Bar implements java.io.Serializable {
public void foo() {
}
}
You would then compile this through Xdoclet and launch the target
application through Jiapi which would wrap each method with the above
tracing information. The difference to the "acive metadata" example is
that the behaviour is implemented separately from the target classes and
methods (as can be seen from the Bar class, it isn't aware of the
logging).
Do you have any comments about this approach? How does this fit into
metadata discussion or is this just traditional AOP with a new syntax?
--
Joni
[EMAIL PROTECTED]
http://www.shiftcontrol.com
On Tue, 2002-03-26 at 01:14, [EMAIL PROTECTED] wrote:
> 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
--
Joni
[EMAIL PROTECTED]
http://www.shiftcontrol.com
_______________________________________________
Xdoclet-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-user
