commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juozas Baliuka" <bali...@centras.lt>
Subject Re: [general][attributes][clazz][A5] metadata & the java world
Date Fri, 03 Jan 2003 19:14:03 GMT
I do not think workarounds is good way to solve problems like this,  we can
start [compiler] project
in commons, it is possible to implement attribute stuff and more.
We can forke some open source compiler for JVM, but I think it must not be a
problem for jakarta developers to implement  compiler.
 jakarta# ;)
----- Original Message -----
From: "Leo Simons" <leosimons@apache.org>
To: <commons-dev@jakarta.apache.org>
Cc: <avalon-dev@jakarta.apache.org>
Sent: Friday, January 03, 2003 5:38 PM
Subject: [general][attributes][clazz][A5] metadata & the java world


> Hi gang,
>
> (commons peeps, my first post here I think, did read
> http://jakarta.apache.org/commons/charter.html but couldn't find
> anything on mailing list conventions so hope all is ok)
>
> read a few books on .net 'n stuff last week. Got me thinking again on
> metadata in the java world. I'm gonna throw an overview of various stuff
> out at y'all, along with some thoughts. Additions/corrections much
> needed I suspect ;)
>
> ----------------
> .Net
> ----------------
>
> .net stores metadata in compiled tables, basically mapping a reference
> (to a class, object, method, whatever) to a serialized representation of
> an attribute. An attribute is simply a serializable object extending a
> base Attribute class, very bean-like in nature.
>
> In C#, you apply attributes to objects by placing the constructor for
> the attribute between square brackets, and optionally including a list
> of properties to set.
>
> here's how'd might work in "Java.Net" pseudocode:
>
>    [Avalon.Attributes.Lifestyle("singlethreaded", poolable=true)]
>    class MyClass {}
>
>    [Avalon.Attributes.Lifestyle("threadsafe")]
>    class MyClass2 {}
>
> would be preprocessed into something like:
>
>    class MyClass
>    {
>      static public Attributes[] _att;
>      static
>      {
>        _att = new Attributes[1];
>        _att[0] = new Avalon.Attributes.Lifestyle("singlethreaded");
>        _att[0].setPoolable(true);
>      }
>    }
>
>    class MyClass2
>    {
>      static public Attributes[] _att;
>      static
>      {
>        _att = new Attributes[1];
>        _att[0] = new Avalon.Attributes.Lifestyle("threadsafe");
>      }
>    }
>
> and the _att stuff is then serialize()d and stored into a table, ie
> resulting in something like (in some hypothetical serialization format I
> just made up):
>
> MyAssembly.jar!/META-INF/ClassMetaData.properties
> -------------------------------------------------
>
MyClass.attributes=array:1:Avalon.Attributes.Lifestyle(f0:singlethreaded:f1:
*:f2:1):
>
MyClass2.attributes=array:1:Avalon.Attributes.Lifestyle(f0:threadsafe:f1:*:f
2:*):
>
>
> When the class loads, the attributes are deserialized and are then
> easily accessible through introspection tools, ie you have something like
>
> class AttributeUtil
> {
> public static boolean isSet(Object o,
> String attributeName) { ... };
> public static Attribute getAttribute(Object o,
> String attributeName ) { ... };
> }
>
> There's more to it of course (for example, if you leave out constructor
> argument and property info, you can leave off the (), and you can also
> often do without the full package spec), but the basic idea is simple
> enough.
>
> ----------------
> Avalon
> ----------------
>
> As putting [] in your sourcefiles is a bit troublesome (most editors
> won't cope, for one), Pete (or someone else, doesn't matter, but he was
> the first to commit some code dealing with this that I saw) had the
> bright and obvious idea some time ago to put the metadata in the javadoc
> comments instead, ie the modified example becomes:
>
>    /**
>     * @attribute Avalon.Attributes.Lifestyle("singlethreaded",
>     *                   poolable=true)
>     */
>    class MyClass {}
>
>    /**
>     * @attribute Avalon.Attributes.Lifestyle("threadsafe")
>     */
>    class MyClass2 {}
>
> and as it is somewhat cumbersome to do actual preprocessing, the idea
> was to just store the metadata information somewhere well-known (where
> the utility classes would know how to find it). So instead of
>
> MyAssembly.jar!/META-INF/ClassMetaData.properties
> -------------------------------------------------
>
MyClass.attributes=array:1:Avalon.Attributes.Lifestyle(f0:singlethreaded:f1:
*:f2:1):
>
MyClass2.attributes=array:1:Avalon.Attributes.Lifestyle(f0:threadsafe:f1:*:f
2:*):
>
> what we get is:
>
> MyAssembly.jar!/MyClass.xinfo
> -----------------------------
> <Attributes>
> <Lifestyle type="singlethreaded">
> <poolable value="true"/>
> </Lifestyle>
> </Attributes>
>
> MyAssembly.jar!/MyClass2.xinfo
> ------------------------------
> <Attributes>
> <Lifestyle type="threadsafe"/>
> </Attributes>
>
> So far so good. Of course, with a verbose xml format for storing the
> metadata information, it is also possible to edit and maintain the xml
> files by hand.
>
> There's one big difference though: with .Net, basically their designers
> figured out a compact way to specify the metadata by closely tying their
> semantics to objects. The way we're going now, with the metadata dtds,
> we loose some compactness, but more importantly the close ties are gone.
> "Custom metadata" is more difficult with the avalon setup.
>
> (note: none of the above actually works; it's just pseudocode examples)
> ------------------
> Commons Attributes
> ------------------
>
> Commons Attributes (which I just took a first look at) is more similar
> to the .Net setup. It also uses QDox for parsing, but instead of
> defining some xml scheme, simply stores a serialized properties file.
> This is neat and simple (there's very little code neccessary to make it
> all work, the attribute parsing being handled by QDox).
>
> Commons Attributes atm doesn't define a standard location to store
> attribute properties, nor does it contain code to automatically load the
> properties from that location and construct metadata object from them.
>
> There's also less possibility for more complex setups than with the .Net
> way, as an attribute is a name/value pair rather than a potentially
> complex object.
>
> ----------------
> Commons Clazz
> ----------------
>
>
> Then there's Commons Clazz, which does a lot more, full of reflection
> tools and the like. There's also the idea within Clazz to support
> metadata, I'm not quite sure where they're at just yet. No website
> available yet, the only docs are @
>
http://cvs.apache.org/viewcvs.cgi/*checkout*/jakarta-commons-sandbox/clazz/P
ROPOSAL.html?rev=1.2
>
> As there's less docs I have less of an opinion on Clazz, but it looks
> complex to me.
>
> ----------------
> QDox, XDoclet
> ----------------
>
> The QDox and XDoclet folks are also working on metadata stuff themselves
> I believe. Haven't looked at it much, but wanna. I'd say it'd be best to
> seperate the javadoc parsing from the metadata semantics.
>
> ---------------------
> So which way forward?
> ---------------------
>
> I'm currently thinking about which way to go with avalon re: all this.
> I'm still liking the approach taken in .net/C# the most.
>
> I think a way forward might be to only so slightly extend Commons
> Attributes to support the "constructor-with-property", or basically the
> GlorifiedHashMap, along with defining a common location for metadata to
> be stored in jar files, and along with an avalon container that handles
> the reading writing of that data and automatically loads it for all
> managed components.
>
> I'm not liking the complexity and size of Clazz very much atm (for
> dealing with this metadata thing that is; I think it'll be good at
> accomplishing its primary goal of reflection done right).
>
> Avalon peeps, I think a good place to work on the basics is Jakarta
> Commons; what we need first is some utility code for constructing and
> destructing metadata, the IoC specifics 'n stuff can come later. With
> gmane setup, it is no longer neccessary to subscribe to
> yet-another-gazillion-messages-a-day list :D
>
>
> cheers all,
>
> - Leo
>
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message