I suggest that it be one mechanism for creating the meta-data class. We've got two issues to consider. 1) How to create the meta-data class/classes 2) What the meta-data class looks like [OK, that looks blindingly obvious to me, now that it's down on pixels]
Doclets are a compile time mechanism. I'd like to see things also be able to be delayed until deploy or run-time. I think exploring what meta-data will be exposed might help drive the nature of the mechanisms for exposing the meta-data. On Saturday 26 October 2002 05:54 pm, Dmitri Plotnikov wrote: > I appreciate the power of attributes and I think we should consider > supporting them very seriously. But before we do that, we need to figure > out the hourse-cart relationship between [clazz] and doclet-based metadata. > > Will doclets be *the* design for [clazz] or *a* pluggable implementation? > > If we choose to commit [clazz] to the doclet approach, > > 1. We have to have source code processing as a mandated part of the build > process. > 2. We cannot add or modify metadata for pre-existing or code-generated > classes. > 3. We still haven't answered the requirements for DynaBeans, Maps where > there is no source code to augment with doclets. > > IMO, we should allow a doclet-based plug-in, but it should be a > specialization of a more generic mechanism. > > - Dmitri > > > ----- Original Message ----- > From: "Berin Loritsch" <[EMAIL PROTECTED]> > To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> > Sent: Saturday, October 26, 2002 4:33 PM > Subject: Re: [clazz] Type-based or instance-based metadata? > > > Dmitri Plotnikov wrote: > > > Berin, > > > > > > ----- Original Message ----- > > > From: "Berin Loritsch" <[EMAIL PROTECTED]> > > > To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> > > > Sent: Friday, October 25, 2002 11:57 PM > > > Subject: Re: [clazz] Type-based or instance-based metadata? > > > > > >>Dmitri Plotnikov wrote: > > >>>Another dilemma we'll have to resolve is whether metadata will be > > >>>type-based, instance-based or both. > > > > <skip/> > > > > >>Most meta info that is useful is type based, not instance based. > > > > > > I guess my examples are not very convincing. What I am trying to say > > > is that type-based metadata is only as detailed as the type. For > > > example, > > if > > > > you declare a property as "int" you have said quite a bit about the > > > property, however if you declare it as "Object" you have said almost > > > nothing. Better yet, all DynaBeans are of the same type - DynaBean. > > > Looking at the type says nothing at all. Same with Map. > > > > > >>What you are looking at is instance based reflection info. Not a more > > >>generic meta info. > > > > > > First, we do want to have more metadata than mere reflection. We would > > like > > > > to capture information on how to store XML with Betwixt or JAXB, how to > > > access objects with JXPath etc. > > > > > > Second, we are looking to support a wider variety of object models > > > than > > can > > > > be supported via Java reflection alone (DynaBeans, Maps etc) > > > > Then focus on an "extension" of the Class object (I know it is declared > > final, > > > so inheritance is out of the question), that has a set of "attributes". > > These > > > attributes mean different things to different people/contexts. Also, > > don't think > > > of attributes as a simple name=value pair. C# attributes have the > > concept > > of > > > parameters as well as the attribute itself. For example: > > > > /** > > * @avalon:component > > * @avalon:role=org.apache.excalibur.DataSourceComponent > > * @avalon:creation-policy=singleton > > * @test:multi-value=value1,value2,value3 > > */ > > > > This would declare a class to have the "avalon:component" attribute, the > > "avalon:role" attribute with the value set to > > "org.apache.excalibur.DataSourceComponent", > > > etc. > > > > These attributes can be read from the IClass (BTW, I hate prefixed > > interfaces/etc.-- > > > interfaces should be your primary type, so if we have any idioms put it > > on > > the > > > implementing class). Attributes that are method specific would be put in > > the > > > javadoc for your method. In your case you want to know the type info for > > a DynaBean > > > return value: > > > > /** > > * @dynabean:return=java.util.Date > > */ > > Object getDate(); > > > > You would want the "dynabean:return" attribute for the "getDate()" > > IMethod, or whatever > > > you call it. > > > > The Attribute approach is very simple, and is easy to use. Its meaning > > only gives > > > purpose based on the context. The "test:multi-value" attribute in the > > first example > > > would be used in a testing framework so that you can apply the same unit > > test for a > > > suite of methods/classes--and they don't even have to set up the same > > interface (the > > > Delegate stuff can take care of it). In fact using attributes is a great > > way to > > > *generate* JUnit tests automagically! > > > > >>Meta info that is useful to me is things like this: > > >> > > >>* Creation policy (pooled components, thread local components, > > >> singleton components, etc.) > > > > > > Agreed. > > > > > >>* Required components (i.e. when one component requires a component of > > >> another type) > > > > > > Could you provide more details on this one? > > > > In Avalon components can require other components to function. An > > example would be the DatabaseReader from Cocoon. It reads information > > from a > > database, > > > but uses the org.apache.avalon.excalibur.DataSourceComponent to get the > > connection > > > from a pool. By declaring this dependency up front, the attributes for > > the class > > > would enable a container to ensure that an implementation of the required > > component > > > existed. If it did not, the container can post a failure notice > > immediately that > > > makes sense. > > > > > > -- > > > > "They that give up essential liberty to obtain a little temporary safety > > deserve neither liberty nor safety." > > - Benjamin Franklin > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:commons-dev-unsubscribe@;jakarta.apache.org> > > > For additional commands, e-mail: > > <mailto:commons-dev-help@;jakarta.apache.org> -- To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
