geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Woolsey <jwool...@activation.net>
Subject Re: Enterprise Bean Structure
Date Thu, 19 Aug 2004 12:28:36 GMT
Thank you for your reply. It is a neat feeling to be part of the 
community. I am going to move forward with text code generation. Mostly 
because this is an educational project. For me and anyone else who wants 
to learn from it. I figure readable java files are easier to learn from 
and debug. I might even add autogen docs to them :) On to working on my 
deployer. I think I am going to start with a JMS bean.

						- bfn - JAW

Dain Sundstrom wrote:

> On Aug 18, 2004, at 5:25 AM, John Woolsey wrote:
> 
>> Ok I will stop being a lurker. Mostly because I have started playing 
>> with code :) I am working on writing my own bits of a j2ee engine from 
>> scratch. At the moment it is more of a paralell self discovery project 
>> to Geronimo.
> 
> 
> cool
> 
>> I was wondering what the preferred method to creating objects for 
>> Enterprise Beans is. The obvious way is to use code generation to wrap 
>> the interfaces. There might also be a way to do it with reflection. I 
>> can see both ways as being effective. Which way do you think is better?
> 
> 
> I assume you mean what is the best way to create the client stub (i.e., 
> the class that implements either the remote or local interface).  There 
> are really only two ways to do this, generate java code and compile it 
> into byte code, or generate the byte code directly.  Generating java 
> code is pain because you must have a java compiler in you server, and 
> for the most common compiler, javac, you have to have the source saved 
> to disk, and all jars needed during the compile on disk.
> 
> The preferred method to generate the stub is to generate the byte code 
> directly.  Normally people use java.lang.reflect.Proxy to generate the 
> byte code implementation of the interface.  In Geronimo, we use cglib to 
> generate the byte code, because it gives us much more control over the 
> generated code.  CGLib is much more complex then reflection proxy, so if 
> you are just hacking some example code, I suggest you just stick with 
> reflection Proxy.
> 
> -dain
> 
> 
> 



Mime
View raw message