Hi, I've written the proxy generation code, and got it working (I think!) with a set of tests which ensure the correct bytecode is generated for different parameters and return types (including primitives, arrays (including multi-dimension arrays) and collections) and exceptions.
I've attached a patch to the Jira issue for OPENEJB-1188. It doesn't really touch anything else at the moment, so if there's no objections I'll commit it in the next day or so, and then start on the code to actually use it :) Please shout if you have any comments. Cheers Jon On Sat, Jan 23, 2010 at 12:43 AM, Jonathan Gallimore < [email protected]> wrote: > Hi David, > > Many thanks for the pointers, I'm going to start having a go at this > tomorrow morning. I've seen some of the CMP code we have that uses ASM. I've > wanted to have a go with ASM for a while and never quite got round to it! > > No doubt I'll have some questions, but hopefully I'll get something > happening over the weekend. > > Cheers > > Jon > > > On Thu, Jan 21, 2010 at 5:10 PM, David Blevins <[email protected]>wrote: > >> Got the subject wrong. One more try :) >> >> On Jan 21, 2010, at 4:24 PM, David Blevins wrote: >> >> Moving to a new thread. >>> >>> On Jan 21, 2010, at 3:02 PM, Jonathan Gallimore wrote: >>> >>> I've signed up for the no-interface view (as long as no-one objects >>>> ;-)), >>>> sounds pretty interesting, and I'm sure I'll learn a fair bit from it >>>> :-) >>>> >>> >>> Great. So for this one the primary missing part we need is essentially >>> something that looks and feels like java.lang.reflect.Proxy but allows for >>> subclassing (i.e. the super class to be passed in) instead of just >>> interfaces. >>> >>> The library cglib will do this, but I'd strongly prefer us not use it. >>> It generates one class per method of the subclass or interface and in real >>> world use it quickly eats away all your permgen space and severely increases >>> load time. To date, anytime we've needed to do some dynamic class creation >>> (CMP for example) we've just done it ourselves using ASM directly and it >>> works out pretty great with usually just a couple classes to pull off rather >>> than a whole library. >>> >>> ASM is actually pretty easy to work with. Standard approach most people >>> take is just to hand code an example of the class you want to generate, then >>> use the ASMifier util to have it spit out the java code that uses ASM to >>> build that exact class. I have a little script like this to make it easy to >>> do from the command line: >>> >>> http://gist.github.com/282865 >>> >>> So basically you'd create a test bean, then hand code a subclass of that >>> bean that accepts an InvocationHandler in the constructor and where every >>> method of the test bean is overridden in the subclass to simply call the >>> InvocationHandler and return the value the handler gives (or the exception >>> it throws). Get it working exactly the way you want it, and only then start >>> the ASM work. Where possible it's best to move as much code off to utility >>> methods or some other class just to keep the subclass code (and therefore >>> the ASM code) down to a minimum. >>> >>> This basic proxy class can go into org.apache.openejb.util as well and >>> just needs a really good test case to verify it works. Once we have that we >>> can start in on the more tedious process of weaving the @LocalBean meta-data >>> through the codebase -- far less of an isolated task. >>> >>> Anyway, hope that's enough to get things started. Fire questions at >>> will. >>> >>> -David >>> >>> >>> >>> >> >
