hi leo,

thanks for the nice summary.
I have thought about custom meta data and .Net style attributes too. 

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

</snip>

how about a custom classloader and storing them as a custom java class
file attribute.

as the avalon framework controls the loading process (IoC) through the
service/component manager this shouldn't be a problem.

I imagine implementing it like this:

* every constant pool element in a java class file can have custom
attributes

* custom attributes in a java class file are just raw data - so you can
store an arbitrary serialized object as a custom attribute

http://java.sun.com/docs/books/vmspec/2nd-edition/html/ClassFile.doc.html#43817

attribute_info {        
        u2 attribute_name_index;        
        u4 attribute_length;            
        u1 info[attribute_length];    
}

* during class-loading, the class loader overloads the defineClass
method and intercepts the class for custom attributes which are .Net
like attributes.

* then it builds an attribute object model and associates with the
loaded class and its code source.

just my 2 cent.

to inject the attributes you would need a kind of tacker component that
tacks the attributes, based on a javadoc description onto a compiled
class file.

this would be insofar interesting as attributes can be attached to any
kind of constant pool item - fields and methods too can have custom
attributes.


With 
> gmane setup, it is no longer neccessary to subscribe to 
> yet-another-gazillion-messages-a-day list :D
> 
sounds interesting, can you point me to more information about that 


-- Jakob


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

Reply via email to