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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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>
