commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Tirsén <>
Subject RE: [attributes] Jakarta Commons Attributes, Nanning & XRAI
Date Mon, 18 Nov 2002 07:17:12 GMT

> -----Original Message-----
> From: Ara Abrahamian [] 
> Sent: den 15 november 2002 22:35
> To:; 'James Strachan';
> Cc:
> Subject: RE: [attributes] Jakarta Commons Attributes, Nanning & XRAI
> Ok, here is what I have to add to this thread.
> First of all: both xrai and nanning's attribute stuff will 
> die, commons-attribute is the only runtime attribute api 
> we'll deal with.

Ok, this is not according to the scope of the project that I had in my
mind. You may be correct, we just need to discuss this so we agree.

My understanding of the scope of this project was that
commons-attributes was a thin pluggable layer for a runtime API. Several
different implementations would exist. We've already seen many different
approaches: property-files, serialized objects, *BeanInfo-like class,
attributes added to the .class-file using BCEL. I imagine there will be
several thriving projects implementing attributes XRAI, attrib4j, the
JSR and so on.

Ok, so maybe we just have to change our mind. What you are proposing is
that commons-attributes is the de facto runtime-implementation of
attributes. It could still be pluggable but we have a very rich default
implementation derived from the XRAI effort. Did I understand this

My opinion on this: Sure, I could do that. One very important thing on
my agenda is timing. I think we need to focus on having a 1.0 with the
least possible functionality that is usable out during this year. Then
we would have time experimenting with the other cool features you've
been talking about. If we could agree on this I'm all for it.

I'll still comment some of the design. But I think it's important that
everyone agrees on the basic scope of the project.

> I've changed the hierarchy a bit:
> We have the Attributes class which is like the XRaiFacade 
> class. We have the ClassMetaData class which contains 
> Attributes and get/setAttribute methods. DefaultClassMetaData 
> provides the default implementation. Attribute interface is 
> the parent of all attribute types. I've moved all 
> SimpleAttribute stuff here:
> String getStringProperty(String prop_name)
> void getStringProperty(String prop_name, String value)
> Object getProperty(String prop_name)
> void getProperty(String prop_name, Object value)
> So we can ask for a string representation of a property from 
> any Attribute. We can ask for an Object representation too 
> which is useful when the derived Attribute class has 
> properties of other types, say int/date/etc.

Ok, we've basically agreed then. Good.

Another thing: Your attribute seems to be a map of name-value-pairs. Is
it possible to mandate this for all attributes? Isn't some attributes
going to be more of a list of parameters, some is going to be one-value
only, some is going to be your name-value-pairs.

> There are other methods in Attribute too, metadata of the 
> attribute: int getLevel() -> a bitset of the levels the 
> attribute is applicable to, method/class/field/constructor/package
> some convenience methods like: isClassLevel/isMethodLevel/etc
> These methods help us do validation on user's input.

Ok, seems nice. Do we really need a bitset thingy? Doesn't just the
predicates do? Bitsets are ugly and seems so old and outdated.

> DefaultAttribute is a concrete implementation of Attribute 
> interface. It's back by a Map of name/value properties. It 
> returns all-levels for the attribute and returns true from 
> isClassLevel/etc methods.


> Now regarding custom attributes:
> A CustomAttribute interface is defined which derives from 
> Attribute interface. There's an AbstractCustomAttribute class 
> defined too. The methods from Attribute are implemented via 
> reflection on get/set property access methods 
> (getJndiName/etc) in AbstractCustomAttribute.


> ClassMetaData has these methods:
> Attribute getAttribute(String name)
> void getAttribute(String name, Attribute attr)
> DefaultAttribute getDefaultAttribute(String name)
> void getDefaultAttribute(String name, DefaultAttribute attr)
> Later we'll define an XmlAttribute class too. It's derived 
> from DefaultAttribute and looks at an attribute definition file
> (attributes.xml) to validate the input. Other implementations 
> could exist too: a ValidListAttribute which has an array of 
> valid values for properties, for example.
> Step by step of course....


> > > - Then we'll let user define
> > > EjbAttribute/custom-attribute derived from
> > > the new CustomAttribute class, CustomAttribute
> > > derived from
> > > SimpleAttribute. C#/jsr175 style. What it does is it responds to
> > > getProperty (overridden from SimpleAttribute) by
> > > doing getMethod() for
> > > the attribute property and fulfill that request.
> > 
> > Yep, but this goes into XRAI, right?
> EjbBeanAttribute and basically all concrete attributes will 
> be defined in xdoclet. Commons-attribute is only the base mechanism.

Well, not all concrete attributes will be defined in Xdoclet of course.
But the concrete attributes will not be defined by commons-attributes.

> > > - We can add xdoclet xtags style attributes too,
> > > later. So you define an
> > > attributes.xml class, where you define @ejb.bean/etc attributes
> > > according to the dtd, then the serializer app looks
> > > at the @tags and
> > > according to dtd validate the @tags user put in the
> > > code, and finally
> > > serialize the XmlAttribute class.
> > 
> > Yup. Goes into XRAI too, right?
> No, it will be in commons-attributes 'cause it's quite 
> general and very handy.

As I've said, we have to agree on scope here.

> > Okay, you've got a point. So let's add one more
> > interface: ClassMetaData/ClassAttributes (I think 
> ClassAttributes is 
> > better because there's a lot of different MetaData, but we're doing 
> > Attributes here). But we should really try hard to minimize the API
> > here.
> ClassMetaData is better, we'll add a PackageAttribute class 
> too. C# also has assembly/package level attribute. This is 
> quite useful, Rickard already gave us an example in his weblog.

Hmm... ClassMetaData but PackageAttribute? Then let's name that
PackageMetaData too.

> > Re modify attributes at runtime. I'm really having
> > troubles understanding the semantics of this. Does it
> > update the source-code? I'm opting for read-only
> > attributes in common-attributes and XRAI may add 
> modification-support.
> Yes and no:
> - in the runtime api, modifying the attributes/properties 
> only updates the in-memory object. Where's the use of it? 
> Well the best example I have is the transaction attribute. So 
> in the AOP framework you add a TransactionAspect, calculate 
> the correct transaction level (required/requires-new/etc), 
> set the attribute for the method, call the method, now the 
> method should only get the transaction level and begin/end 
> the transaction conditionally based on it.
> - in parsing time:
> 	- in AttributeSerializer it's just used for filling the 
> attributes for serialization
> 	- in xdoclet's xdocletgui app it's used for modifying 
> the attributes visually and then saving the modification to 
> source code.

Ok, that does seem reasonable. Separate processors could add and modify
attributes to classes at runtime (and compile-time). Sure, we'll
investigate that.

One more thing. Don't we need to add a validate()-method to Attribute so
attributes can hook in and check wheather they've got all the parameters
they require and so on? This will be called runtime (when demarshalling
attributes, attribute-implementation may have changed since
compile-time) and compile-time (before marshalling attributes).

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message