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
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
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
]
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
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
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
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
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
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