[JBoss-dev] XDoclet and C# style metadata
I was just thinking how cool it would be to generically associate xml with a method declaration. Back story: I am working on unit test cases for JBossCMP using JUnitEJB and it would be really useful to mark a test method with a tx attribute. Now this test code is not an EJB or an XMBean, so I don't have a descriptor file (this is not important; I just wanted to avoid the lame make it an ejb emails). Idea (I only know a little about XDoclet an less about C#) Mark up the code with XDoclet tags that contain generic xml. Then run XDoclet to preprocess the java file and generate a new java file with an additional method getClassMetaData. This class would work like the getClass stuff, but would add additional methods to return the extra metadata specified in the class. Use: In my case, the server side tester would get the metadata, check for a tx tag and would start a tx if required by the tag. We could use the same tricks with MBeans, JBoss Enterprise Beans (JEBs), and anything. This is something (I think) C# has and is unbelievably powerful. What do you think? -dain ___ Hundreds of nodes, one monster rendering program. Now thats a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] XDoclet and C# style metadata
Ok, I'm responding to my own email. Sometimes I get to excited. This is technique will only be useful in some circumstances because it requires changing your source code to change a simple configuration. In my case this is acceptable, because I'm talking about test cases. It would also be useful for many EJB programmers, as they use XDoclet to set TX attributes (although they can still change the dd, they are not editing the source of truth). I still think it would be very useful, but it is not as ungodly powerful as I first thought. -dain Dain Sundstrom wrote: I was just thinking how cool it would be to generically associate xml with a method declaration. Back story: I am working on unit test cases for JBossCMP using JUnitEJB and it would be really useful to mark a test method with a tx attribute. Now this test code is not an EJB or an XMBean, so I don't have a descriptor file (this is not important; I just wanted to avoid the lame make it an ejb emails). Idea (I only know a little about XDoclet an less about C#) Mark up the code with XDoclet tags that contain generic xml. Then run XDoclet to preprocess the java file and generate a new java file with an additional method getClassMetaData. This class would work like the getClass stuff, but would add additional methods to return the extra metadata specified in the class. Use: In my case, the server side tester would get the metadata, check for a tx tag and would start a tx if required by the tag. We could use the same tricks with MBeans, JBoss Enterprise Beans (JEBs), and anything. This is something (I think) C# has and is unbelievably powerful. What do you think? -dain ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Hundreds of nodes, one monster rendering program. Now thats a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] XDoclet and C# style metadata
Unless the getClassMetaData() loaded up the config info from a resource xml file. The XDoclet stuff would just generate the getClassMetaData() method (that just loads the data from the xml file) and the .xml that holds the class metadata. If getClassMetaData() returned a really generic object like a xml dom, then you would never have to change getClassMetaData(). Regards, Hiram From: Dain Sundstrom [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] XDoclet and C# style metadata Date: Fri, 17 May 2002 14:12:53 -0500 Ok, I'm responding to my own email. Sometimes I get to excited. This is technique will only be useful in some circumstances because it requires changing your source code to change a simple configuration. In my case this is acceptable, because I'm talking about test cases. It would also be useful for many EJB programmers, as they use XDoclet to set TX attributes (although they can still change the dd, they are not editing the source of truth). I still think it would be very useful, but it is not as ungodly powerful as I first thought. -dain Dain Sundstrom wrote: I was just thinking how cool it would be to generically associate xml with a method declaration. Back story: I am working on unit test cases for JBossCMP using JUnitEJB and it would be really useful to mark a test method with a tx attribute. Now this test code is not an EJB or an XMBean, so I don't have a descriptor file (this is not important; I just wanted to avoid the lame make it an ejb emails). Idea (I only know a little about XDoclet an less about C#) Mark up the code with XDoclet tags that contain generic xml. Then run XDoclet to preprocess the java file and generate a new java file with an additional method getClassMetaData. This class would work like the getClass stuff, but would add additional methods to return the extra metadata specified in the class. Use: In my case, the server side tester would get the metadata, check for a tx tag and would start a tx if required by the tag. We could use the same tricks with MBeans, JBoss Enterprise Beans (JEBs), and anything. This is something (I think) C# has and is unbelievably powerful. What do you think? -dain ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Hundreds of nodes, one monster rendering program. Now thats a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx ___ Hundreds of nodes, one monster rendering program. Now thats a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] XDoclet and C# style metadata
Not sure if this helps, but JDK 1.5 is planning to put this in and make the meta data accessible from the runtime as well as tools like Javadoc. James -Original Message- From: Hiram Chirino [mailto:[EMAIL PROTECTED]] Sent: Friday, May 17, 2002 4:08 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] XDoclet and C# style metadata Unless the getClassMetaData() loaded up the config info from a resource xml file. The XDoclet stuff would just generate the getClassMetaData() method (that just loads the data from the xml file) and the .xml that holds the class metadata. If getClassMetaData() returned a really generic object like a xml dom, then you would never have to change getClassMetaData(). Regards, Hiram From: Dain Sundstrom [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [JBoss-dev] XDoclet and C# style metadata Date: Fri, 17 May 2002 14:12:53 -0500 Ok, I'm responding to my own email. Sometimes I get to excited. This is technique will only be useful in some circumstances because it requires changing your source code to change a simple configuration. In my case this is acceptable, because I'm talking about test cases. It would also be useful for many EJB programmers, as they use XDoclet to set TX attributes (although they can still change the dd, they are not editing the source of truth). I still think it would be very useful, but it is not as ungodly powerful as I first thought. -dain Dain Sundstrom wrote: I was just thinking how cool it would be to generically associate xml with a method declaration. Back story: I am working on unit test cases for JBossCMP using JUnitEJB and it would be really useful to mark a test method with a tx attribute. Now this test code is not an EJB or an XMBean, so I don't have a descriptor file (this is not important; I just wanted to avoid the lame make it an ejb emails). Idea (I only know a little about XDoclet an less about C#) Mark up the code with XDoclet tags that contain generic xml. Then run XDoclet to preprocess the java file and generate a new java file with an additional method getClassMetaData. This class would work like the getClass stuff, but would add additional methods to return the extra metadata specified in the class. Use: In my case, the server side tester would get the metadata, check for a tx tag and would start a tx if required by the tag. We could use the same tricks with MBeans, JBoss Enterprise Beans (JEBs), and anything. This is something (I think) C# has and is unbelievably powerful. What do you think? -dain ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Hundreds of nodes, one monster rendering program. Now thats a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] XDoclet and C# style metadata
Hi Dain, How about byte code post-processing to add the metadata? This would allow changing the metadata without changing or recompiling the code. The class could also optionally contain a reference id for the metadata, rather than the metadata itself, so that it could be changed dynamically at runtime without even reloading the class file. (This second idea would involve a runtime library to support a metadata store, which could optionally be persistent.) -Dan On 17 May 2002, at 14:12, Dain Sundstrom wrote: Ok, I'm responding to my own email. Sometimes I get to excited. This is technique will only be useful in some circumstances because it requires changing your source code to change a simple configuration. In my case this is acceptable, because I'm talking about test cases. It would also be useful for many EJB programmers, as they use XDoclet to set TX attributes (although they can still change the dd, they are not editing the source of truth). I still think it would be very useful, but it is not as ungodly powerful as I first thought. -dain Dain Sundstrom wrote: I was just thinking how cool it would be to generically associate xml with a method declaration. Back story: I am working on unit test cases for JBossCMP using JUnitEJB and it would be really useful to mark a test method with a tx attribute. Now this test code is not an EJB or an XMBean, so I don't have a descriptor file (this is not important; I just wanted to avoid the lame make it an ejb emails). Idea (I only know a little about XDoclet an less about C#) Mark up the code with XDoclet tags that contain generic xml. Then run XDoclet to preprocess the java file and generate a new java file with an additional method getClassMetaData. This class would work like the getClass stuff, but would add additional methods to return the extra metadata specified in the class. Use: In my case, the server side tester would get the metadata, check for a tx tag and would start a tx if required by the tag. We could use the same tricks with MBeans, JBoss Enterprise Beans (JEBs), and anything. This is something (I think) C# has and is unbelievably powerful. What do you think? -dain ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Hundreds of nodes, one monster rendering program. Now thats a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Hundreds of nodes, one monster rendering program. Now thats a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] XDoclet and C# style metadata
1. Why is it lame to tell you to make this into a session bean so you can use xdoclet to generate the tx attribute tags? Maybe it's obvious, but I'm not getting it. 2. If you still don't want a session bean, when the ejb and mbean interceptor stacks are unified you should be able to use the tx attribute interceptor in front of an mbean, thus providing at least the specific functionality you are talking about without modifying your class at all, just using an xml descriptor. david jencks On 2002.05.17 15:03:30 -0400 Dain Sundstrom wrote: I was just thinking how cool it would be to generically associate xml with a method declaration. Back story: I am working on unit test cases for JBossCMP using JUnitEJB and it would be really useful to mark a test method with a tx attribute. Now this test code is not an EJB or an XMBean, so I don't have a descriptor file (this is not important; I just wanted to avoid the lame make it an ejb emails). Idea (I only know a little about XDoclet an less about C#) Mark up the code with XDoclet tags that contain generic xml. Then run XDoclet to preprocess the java file and generate a new java file with an additional method getClassMetaData. This class would work like the getClass stuff, but would add additional methods to return the extra metadata specified in the class. Use: In my case, the server side tester would get the metadata, check for a tx tag and would start a tx if required by the tag. We could use the same tricks with MBeans, JBoss Enterprise Beans (JEBs), and anything. This is something (I think) C# has and is unbelievably powerful. What do you think? -dain ___ Hundreds of nodes, one monster rendering program. Now thats a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Hundreds of nodes, one monster rendering program. Now thats a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] XDoclet and C# style metadata
David Jencks wrote: 1. Why is it lame to tell you to make this into a session bean so you can use xdoclet to generate the tx attribute tags? Maybe it's obvious, but I'm not getting it. It is a unit test test under JUnit it has nothing to do with ejbs. I can manage the tx by hand I just rather do it declarativly. Anyway, I am thinking outside the ejb box (not everything will be an ejb). 2. If you still don't want a session bean, when the ejb and mbean interceptor stacks are unified you should be able to use the tx attribute interceptor in front of an mbean, thus providing at least the specific functionality you are talking about without modifying your class at all, just using an xml descriptor. That is what I am talking about, but instead of having a separate xml file it is embedded into the class. David, take a second lean back and think about what you could do with this system. It is very powerful, but MS popularized it first I am sure the didn't invent it; they never invent anything new. -dain ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] XDoclet and C# style metadata
Are you reinventing metaclasses/metaobject protocols/metaprogramming? Are you thinking of something like the jdo bytecode enhancer to add these metaclass activities to the compiled class? Unless you actually change the bytecode to perform these operations in the class I'm not sure what the advantage of putting the metadata in the class rather than in an xml file is. I certainly agree that metaclass programming is extremely powerful. david jencks On 2002.05.17 23:32:23 -0400 Dain Sundstrom wrote: David Jencks wrote: 1. Why is it lame to tell you to make this into a session bean so you can use xdoclet to generate the tx attribute tags? Maybe it's obvious, but I'm not getting it. It is a unit test test under JUnit it has nothing to do with ejbs. I can manage the tx by hand I just rather do it declarativly. Anyway, I am thinking outside the ejb box (not everything will be an ejb). 2. If you still don't want a session bean, when the ejb and mbean interceptor stacks are unified you should be able to use the tx attribute interceptor in front of an mbean, thus providing at least the specific functionality you are talking about without modifying your class at all, just using an xml descriptor. That is what I am talking about, but instead of having a separate xml file it is embedded into the class. David, take a second lean back and think about what you could do with this system. It is very powerful, but MS popularized it first I am sure the didn't invent it; they never invent anything new. -dain ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] XDoclet and C# style metadata
I don't know what I'm reinventing. I like it better then hacking byte code. Anyway the advantage over a separate xml file is you don't have to have a separate file. -dain David Jencks wrote: Are you reinventing metaclasses/metaobject protocols/metaprogramming? Are you thinking of something like the jdo bytecode enhancer to add these metaclass activities to the compiled class? Unless you actually change the bytecode to perform these operations in the class I'm not sure what the advantage of putting the metadata in the class rather than in an xml file is. I certainly agree that metaclass programming is extremely powerful. david jencks On 2002.05.17 23:32:23 -0400 Dain Sundstrom wrote: David Jencks wrote: 1. Why is it lame to tell you to make this into a session bean so you can use xdoclet to generate the tx attribute tags? Maybe it's obvious, but I'm not getting it. It is a unit test test under JUnit it has nothing to do with ejbs. I can manage the tx by hand I just rather do it declarativly. Anyway, I am thinking outside the ejb box (not everything will be an ejb). 2. If you still don't want a session bean, when the ejb and mbean interceptor stacks are unified you should be able to use the tx attribute interceptor in front of an mbean, thus providing at least the specific functionality you are talking about without modifying your class at all, just using an xml descriptor. That is what I am talking about, but instead of having a separate xml file it is embedded into the class. David, take a second lean back and think about what you could do with this system. It is very powerful, but MS popularized it first I am sure the didn't invent it; they never invent anything new. -dain ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
