Am Die, 2003-01-07 um 17.44 schrieb Leo Simons:
> Jakob Praher wrote:
> > hi all,
> > 
> > as we (Leo and I) have talked about custom metadata attribute support
> > for java lately, I wanted to know whether this should be done inside
> > avalon, or should be delegated to another (jakarta) project.
> 

btw: just came accross following site: http://attrib4j.sourceforge.net/
they are doing what I proposed using bcel - don't know any details yet.

nanning.sourceforge.net also adds attribute tags (commons-attribute uses
the doclet names of the nanning project)


> according to KISS, it should be a standalone library. There's lots of 
> locations where something like that can be done. Sice Jakarta Commons 
> already has some stuff regarding this in their sandbox I figured we'd 
> start there.
> 
agreed - KISS is an important design goal. 

> > if inside avalon, I was wondering what approach towards implementing
> > them should be taken. (class augmentation, manifest files, ...)
> 
> I'm leaning towards parsing of
> 
> /** @attribute SomeClassNameAttribute("blaat") */
> class MyClass
> 
> where an ant+qdox solution is run over this at build time. Such an 
> AttributeParserTask could generate lots of stuff. The most important 
> thing to agree on the syntax of the source files; you can always plug in 
> lots of different generators.

nanning and commons-attribute use:

@classAttribute
@methodAttribute
@fieldAttribute

but as you sugested I too would like to use the more generic

@attribute FQCN( ActualPars )

syntax.
according to a paper I found via google, that's what J# is doing to bind
CLR attributes to "Java.NET".
  
> 
> I would probably be most comfortable with this ending up in an xml file 
> coupled to the class, ie something like:
> 
> MyClass.attributes
> ------------------
> <attributes>
>       <attribute
>               class="SomeClassName"
>               target="class">
>               <constructor>
>                       <string value="blaat"/>
>               </constructor>
>       </attribute>
> </attributes>
> 

I found something similiar with the betwixt project.
I like the idea, but would also like to define a sort of object model to
discover attributes at runtime:

something like:

class AttributedClass {

        Attribute[] getClassAttribtues( )
        Attribute[] getMethodAttribtues( String methodName );
        Attribute[] getFieldAttributes( String fieldName ) ;
}

don't actually know how's .NET Api for discovering attributes.

the only funny thing is that JMX and JMI use the term Attribute to
denote Fields, but I don't know a better name for custom meta data ....
(at least yet).

> or maybe adopt the SOAP serializers from Axis for generation of 
> everything inside <attribute/>. Something like that. (I believe .Net 
> uses SOAP for serialization by default.) That's mostly because it is 
> consistent with the approach avalon currently takes.
> 

I only know about the betwixt framework from jakarta-commons. Don't know
that much about the SOAP serializers from Axis but am very curious about
anything like that - will definitely look into it.

> > I am curious about your opinons,
> 
> me too :D I am actually waiting for a reply from some of the people 
> who've done a lot of the meta/attribute stuff currently in place @ 
> avalon, in particular Peter Donald (hi pete!). I suspect he's still 
> catching up wrt e-mail...holidays y'know.

> 
> > and I am interested in helping with the
> > implementation.

> We'll go with the flow from there (I haven't been particularly active in 
> commons before, but I believe I have commit rights to commons sandbox, 
> so if there's no response it's probably okay for us to work on it there).

jup.
thanks for your reply.

-- Jakob


> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to