Proxies

The short answer is we do not generate java code containing any ejb logic at all as other platforms like WebSphere and WebLogic do. We use dynamic proxy generation via java.lang.reflect.Proxy.

Most of the commercial platforms predate dynamic proxy generation and not only statically generate java files which are then compiled and included in the app but decided as long as they were generating java files that they would jam-pack them with as many optimizations as they could. The result was that significant portions of your application data such as transaction attributes and database queries were stuck in generated vendor code. We don’t have any equivalent to that.

Dynamic proxies such as java.lang.reflect.Proxy or cglib byte code in memory, not java source, which is immediately turned into a class definition and used. The basic paradigm is that you give the library the interfaces you want implemented and some sort of Handler object. The library will give you back a proxy instance that does nothing more than call your handler every time a method is called. Now it’s possible with some trickery to pull the byte code for any java.lang.Class instance out of the classloader and then use some sort of java decompiler library to turn that into some sort of java source file, however there’s no real motivation to do so as the VM generated proxies are quite dumb and the code that does all the work is not generated and available for download or svn checkout.

If you are coming from a commercial vendor and simply looking for a good place to begin your debugging, look for implementations java.lang.reflect.InvocationHandler and slap a breakpoint in the "invoke" method and you’ll be all set.