commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Downey <steve.dow...@netfolio.com>
Subject Re: [clazz] Doclet for metadata? (was: Type-based or instance-based metadata?)
Date Sun, 27 Oct 2002 01:02:17 GMT
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" <bloritsch@apache.org>
> To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> 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" <bloritsch@apache.org>
> > > To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
> > > 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>


Mime
View raw message