Am Sam, 2003-01-04 um 01.22 schrieb Leo Simons: > Jakob Praher wrote: > <snip/> > > I have thought about custom meta data and .Net style attributes too. > > how about a custom classloader and storing them as a custom java class > > file attribute. > > eh? (scratches head, hits google) > > > as the avalon framework controls the loading process (IoC) through the > > service/component manager this shouldn't be a problem. > > (Avalon containers far from always have control of (or want to control) > classloading, for example you might want to use 'em in a J2ME env, a > servlet engine, or any other existing app with existing classloader > infrastructure.) > your are definetly right here. but at least loading is not controlled by the user like this:
mySuperComponent = new XyzSuperComponent( ); this would worsen the approach, (not IoC). > > 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. would work via getResourceAsStream( ) at a later time too (I think, see below ) > > > > * 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. > > certainly sounds like it could work, and sounds terribly similar to the > actual .Net setup (I know mostly zip about bytecode 'n stuff though). Is > it neccessary to have control over the classloading in order to get > access to the custom attributes? It seems to me that having this as a > requirment could really limit its application. perhaps the following would work too: (w/o having control of class loading) InputStream clazzfile = ClassLoader.getResourceAsStream( "a/Foo.class" ); then you could also get access to the attributes and load it. parse the inputstream via a java class file format library and get the custom attributes out of it. the other way doesn't work out that easily, as defineClass is "final" protected final Class defineClass(String name, byte data[], int offset, int length) so you can't easily intercept the call by overriding it ... > The other thought that occured is that this might be a step further away > from the well-known (and accepted) *BeanInfo setup, and hence more > controversial. > it surely is controversal. I hope the meta data JSR group define a generic way of getting java class file attributes, this would solve much of the problems we have so far. for instance by the introduction of java.lang.reflect.Attribute and the following methods in the lang and reflect Package: class Class { ... Attribute[] getAttributes( ); } class AccessibleOBject { .. Attribute[] getAttributes( ); } the only problem with the name "Attribute" is that it is very overloaded in the java community: * in UML (OMG == CORBA) -> MOF -> JMI and JMX too there is the convention that object fields are called Attributes so it could be a little bit confusing for programmers accustomed to this api to do something like this: clazz = Class.forName( "a.Foo" ); Attribute[] attributes = clazz.getAttributes( ); so perhaps another name would suit better. > Definately sounds as something worth exploring though (for one, it would > probably be several dozen times faster than another route), even if I > don't fully understand.... > > > 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 > > gmane is a news<->email gateway, see http://www.gmane.org/. > thanks for the info - I'll check it out -- 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]>
