commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ara Abrahamian" <>
Subject RE: [attributes] Jakarta Commons Attributes, Nanning & XRAI
Date Fri, 15 Nov 2002 21:34:32 GMT
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.

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

There are other methods in Attribute too, metadata of the attribute:
int getLevel() -> a bitset of the levels the attribute is applicable to,
some convenience methods like: isClassLevel/isMethodLevel/etc

These methods help us do validation on user's input.

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.

> Agreed in principal. If we add getText/getProperty to
> Attribute-interface a trivial client can *always* use
> the Strings. A non-trivial client can cast it to the
> strongly-type (C#-style) Attribute-class.


> > - 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

> 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.

> 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.

How does is look now?


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

View raw message