commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Juozas Baliuka" <bali...@mwm.lt>
Subject Re: [clazz] Metadata Provider [was: Passive or active metadata?]
Date Mon, 28 Oct 2002 12:10:58 GMT


Yes, it must be some way to extend meta info without source.


> Juozas,
>
> Good idea. I believe we should have this mechanism.  I saw something
> similar in WebLogic's ejbgen tool. There you encode metadata in
> javadoc-style comments and then the tool uses it to generate various
> Java and XML source files.
>
> However, I don't think this can be the only mechanism provided by
> [clazz].
>
> 1. In some cases bundling metadata with the source violates
> architectural layering of the app.  For example, some people would
> argue that a back-end model object should not have any front-end
> metadata such as formatting etc hardcoded in it.
>
> 2. In some cases you need to add a new aspect of metadata to a class
> that cannot be modified, e.g. third-party library, generated code etc.
>
> 3. In some cases different metadata needs to be produced for a class in
> different contexts.  For example, bean-XML mapping may be different in
> the context of [betwixt] and [JAXB].  Both perform the same task, but
> they do so somewhat differently and therefore need different metadata.
>
> How about this design:
>
> 1. We define a MetaDataProvider interface
> 2. We create a registry for MetaDataProviders
> 3. We use the Chain-Of-Responsibility pattern in every case to pick the
> provider.
>
> Of course, one of the providers in the chain can lookup static methods
> like the ones you are proposing on the class itself and thus delegate
> the customization of the meta data to the class itself.
>
> - Dmitri
>
>
> --- Juozas Baliuka <baliuka@mwm.lt> wrote:
> >
> >
> > we do not need customize metadata at JVM level, it is possible to use
> > usual
> > java and class files.
> > compiler can add "attributes" to class file, or it can be static
> > fields or
> > some methods generated by
> > compiler to return metadata.
> > something like this :
> >
> >  /**
> >  * @attribute MyAttribute("remote","persistent")
> > *  @attribute Roles( "admin","manager" )
> > **/
> > public int  myMethod(){
> >    return 2*2;
> > }
> > ........................
> > compiler can generate byte code for sometnig like this :
> > // it is not very interesting to code manualy:
> > public static Attributes attributes = new Attributes();
> >  static{
> >       attributes.add( MyClass.class.getMethod("myMethod" ,null ), new
> > MyAttribute ("remote","persistent" )  );
> >        .............................................................
> >   }
> >
> > public int  myMethod(){
> >    return 2*2;
> > }
> >
> > and some API can be implemented to read "attributes" like:
> >
> > Attribute attributes[] =  Reflect.getAttributes(
> > MyClass.class.getMethod("myMethod" ,null ) );
> >
> > this data can be used to generate XML descriptors, SQL, "garbage" ...
> > or can
> > be used directly by some framework;
> > It is not a new idea, I do not remember M$ stuff, but it seems J#
> > or/and J++
> > uses something like this.
> >
> > But we do not have compiler implementation at this time :(.
> >
> > > Juozas,
> > >
> > > IMO, the idea of customizing meta data at the JVM level is a little
> > too
> > > ambitious for what we can hope to accomplish in [clazz].  I think
> > we
> > > should stick to customization via delegation, things like BeanInfo,
> > > DynamicPropertyHandler and such.
> > >
> > > - Dmitri
> > >
> > >
> > > --- Juozas Baliuka <baliuka@mwm.lt> wrote:
> > > >
> > > > I think all these things interesting for reflection or meta
> > > > programming.
> > > > It is a problem with metadata at compile time, compiler must be
> > > > customized
> > > > to add metadata ( attributes ) for classes and methods, I think
> > > > preprocessing or
> > > > XML stuff generation from source  is not a very good solution,
> > but it
> > > > is not
> > > > trivial
> > > > to implement java compiler and it will be out of scope for this
> > > > project.
> > > > There are some opensource compilers like
> > > > http://pizzacompiler.sourceforge.net/,
> > > > we can start some project for compiler in sandbox too, is it can
> > be
> > > > usefull
> > > > ?
> > > >
> > > > > Folks,
> > > > >
> > > > > I think there are at least four parts to what we ultimately
> > expect
> > > > from
> > > > > this:
> > > > >
> > > > > 1. A way to capture some type of meta model. For instance,
> > > > JavaBeans
> > > > > describe objects in terms of Types and Properties (scalar or
> > > > indexed).
> > > > >
> > > > > 2. A way to extract a meta model from Java runtime.  That's
> > where
> > > > the
> > > > > mapping of method names to properties and all that stuff comes
> > in.
> > > > >
> > > > > 3. A way to customize the meta model extracted from Java
> > runtime.
> > > > We
> > > > > want to be able to bend or redefine the mapping rules.
> > > > >
> > > > > 4. A way to use the meta data to manipulate objects and object
> > > > graphs
> > > > > in a generic fashion.  I am talking about methods like
> > > > > get(propertyName), set(propertyName), add, remove etc.
> > > > >
> > > > > Are all these four things addressed between [reflect] and
> > [clazz]?
> > > > >
> > > > > - Dmitri
> > > > >
> > > > > __________________________________________________
> > > > > Do you Yahoo!?
> > > > > Y! Web Hosting - Let the expert host your web site
> > > > > http://webhosting.yahoo.com/
> > > > >
> > > > > --
> > > > > 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>
> > > >
> > >
> > >
> > > __________________________________________________
> > > Do you Yahoo!?
> > > Y! Web Hosting - Let the expert host your web site
> > > http://webhosting.yahoo.com/
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <mailto:commons-dev-help@jakarta.apache.org>
> >
>
>
>
> __________________________________________________
> Do you Yahoo!?
> Y! Web Hosting - Let the expert host your web site
> http://webhosting.yahoo.com/
>
> --
> 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