You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Dmitri Plotnikov <dp...@yahoo.com> on 2002/10/25 20:14:24 UTC
Re: [clazz] Metadata Provider [was: Passive or active metadata?]
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 <ba...@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 <ba...@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:
> > > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > >
> >
> >
> > __________________________________________________
> > Do you Yahoo!?
> > Y! Web Hosting - Let the expert host your web site
> > http://webhosting.yahoo.com/
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do you Yahoo!?
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [clazz] Metadata Provider [was: Passive or active metadata?]
Posted by Juozas Baliuka <ba...@mwm.lt>.
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 <ba...@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 <ba...@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:
> > > > <ma...@jakarta.apache.org>
> > > > > For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > >
> > >
> > >
> > > __________________________________________________
> > > Do you Yahoo!?
> > > Y! Web Hosting - Let the expert host your web site
> > > http://webhosting.yahoo.com/
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
>
>
> __________________________________________________
> Do you Yahoo!?
> Y! Web Hosting - Let the expert host your web site
> http://webhosting.yahoo.com/
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [clazz] Metadata Provider [was: Passive or active metadata?]
Posted by Berin Loritsch <bl...@apache.org>.
Henri Yandell wrote:
>
> On Fri, 25 Oct 2002, Dmitri Plotnikov wrote:
>
>
>>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.
>
>
> You mean xdoclet? They're pretty big over at sourceforge.
>
> I need to start reading this thread, having to save it all up atm.
XDoclet, QDox They both do the same thing.
However, what are you planning on doing with it?
Here is what we are doing in Avalon land. We are using QDox (which is
faster BTW) to generate the meta information for the components. We wrote
an ANT task to read the javadoc tags and create new XML files to describe
the metainfo for the component.
What would be better is to permanently associate the meta info directly
with the implementation/interface classes. Using a new MetaInfo enabled
ClassLoader to pull the meta info programatically from the Class itself.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [clazz] Metadata Provider [was: Passive or active metadata?]
Posted by Juozas Baliuka <ba...@mwm.lt>.
Yes, the most simple way to use custom doclet to generate "grabage",
It can be XXXBeanInfo.
>
>
> On Fri, 25 Oct 2002, Dmitri Plotnikov wrote:
>
> > 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.
>
> You mean xdoclet? They're pretty big over at sourceforge.
>
> I need to start reading this thread, having to save it all up atm.
>
> Hen
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [clazz] Metadata Provider [was: Passive or active metadata?]
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 25 Oct 2002, Dmitri Plotnikov wrote:
> 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.
You mean xdoclet? They're pretty big over at sourceforge.
I need to start reading this thread, having to save it all up atm.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>