ejb@glassfish.java.net

Re: Need Help on EJB code generation

From: <Jason.Huang_at_Sun.COM>
Date: Tue, 28 Nov 2006 17:22:31 +0800

Ken Cavanaugh wrote:
> On Mon, 2006-11-27 at 02:55 -0800, Mahesh.Kannan wrote:
>> Jason.Huang_at_Sun.COM <mailto:Jason.Huang_at_Sun.COM> wrote:
>>
>> > Hi, All
>> >
>> > I have some questions about the implementation of EJB container.
>> >
>> > I have a Stateless bean in EJB2.x style which has a remote business
>> > method like:
>> > -----------------------------------------------------
>> >
>> > public String sayHi() {
>> > Thread.dumpStack();
>> > return "Foo";
>> > }
>> > -----------------------------------------------------
>> >
>> > I call the EJB from a standalone client, the output of the
>> > Thread.dumpStack(); is:
>> > ------------------------------------------------
>> > java.lang.Exception: Stack trace
>> > at java.lang.Thread.dumpStack(Thread.java:1158)
>> > at ejb.demo.helloworld2.HelloWorldBean.sayHi(HelloWorldBean.java:63)
>> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> > at
>> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> >
>> > at
>> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> >
>> > at java.lang.reflect.Method.invoke(Method.java:585)
>> > at
>> > com.sun.enterprise.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1051)
>> >
>> > at
>> > com.sun.enterprise.security.SecurityUtil.invoke(SecurityUtil.java:165)
>> > at
>> > com.sun.ejb.containers.BaseContainer.invokeTargetBeanMethod(BaseContainer.java:2812)
>> >
>> > at
>> > com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:3896)
>> > at
>> > com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:190)
>> >
>> > at
>> > com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:107)
>> >
>> > at $Proxy88.sayHi(Unknown Source)
>> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> > at
>> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>> >
>> > at
>> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>> >
>> > at java.lang.reflect.Method.invoke(Method.java:585)
>> > at
>> > com.sun.corba.ee.impl.presentation.rmi.ReflectiveTie._invoke(Unknown
>> > Source)
>> > at
>> > com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatchToServant(Unknown
>> > Source)
>> > at
>> > com.sun.corba.ee.impl.protocol.CorbaServerRequestDispatcherImpl.dispatch(Unknown
>> > Source)
>> > at
>> > com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequestRequest(Unknown
>> > Source)
>> > at
>> > com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(Unknown
>> > Source)
>> > at
>> > com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleInput(Unknown
>> > Source)
>> > at
>> > com.sun.corba.ee.impl.protocol.giopmsgheaders.RequestMessage_1_2.callback(Unknown
>> > Source)
>> > at
>> > com.sun.corba.ee.impl.protocol.CorbaMessageMediatorImpl.handleRequest(Unknown
>> > Source)
>> > at
>> > com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.dispatch(Unknown
>> > Source)
>> > at
>> > com.sun.corba.ee.impl.transport.SocketOrChannelConnectionImpl.doWork(Unknown
>> > Source)
>> > at
>> > com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(Unknown
>> > Source)
>> > ------------------------------------------------
>> > In the stack trace, I found class Proxy88 is called. However I cannot
>> > find the code which generate Proxy88.
>>
>> This is an instance of JDK Proxy itself.
>>
>> > I've read some codes in the package com.sun.ejb.codegen.
>> > According to my understanding, I assume that the WrapperGenerator
>> > will help generate the EJB Object implementation(XXXX_EJBObjectImpl),
>> > and this remote object will delegate the method to bean object itself.
>> > However I cannot find where the WrapperGenerator is used.
>> >
>> WrapperGenerators *were* used previously to generate implementation
>> classes for EJB 2.x impl classes.
>>
>> > I found the input parameters for the rmic are the Remote and Remote
>> > Home interface, which can generate the stub classes. Where can I find
>> > the tie classes?
>>
>> rmic -iiop generates both stub and tie classes. However, glassfish
>> doesn't use rmic anymore. It uses dynamic class generation techniques to
>> generate stub and tie classes.
>>
>> The container now uses dynamic class generators to generate true IIOP
>> classes. For example, RemoteGenerator and Remote30WrapperGenerator are
>> now used by the container to dynamically generate the required iiop
>> classes dynamically.
>>
>>
>>
>> > Coud you give some suggestions or documents on the EJB code generation?
>>
>
> I'll address the CORBA side of this. The dynamic RMI-IIOP code in
> CORBA uses BCEL to generate
> a stub dynamically from the remote interface. That's all that's
> needed for EJB 2.x. However,
> EJB 3 requires in addition the generation of the remote interface from
> the business interface,
> and also an adapter class that wraps exceptions and converts them from
> the RMI world
> to EJB 3. In all cases, there are no generated ties: we just use a
> ReflectiveTie class in the
> ORB for all Tie functions (which also relies on the dynamic RMI-IIOP
> infrastructure to determine
> how to unmarshal parameters and marshal the result). There is
> documentation on
> dynamic RMI-IIOP available at:
>
> https://glassfish-corba.dev.java.net/design/dynamic_rmi_iiop.htm
>
> The GlassFish ORB also supplies the codegen library that EJB 3 uses to
> generate the remote
> interface and adapter class. The only docs available for codegen are
> the JavaDocs,
> which unfortunately do not appear where they ought to in the
> glassfish-corba project.
> If you are really interested, you could build the JavaDocs from the
> glassfish-corba project,
> then look at the classes in the com.sun.corba.se.spi.codegen package
> (particularly in the
> Wrapper class).
>

Hi, Ken,

Thanks for the help.
Another question, I found in the glassfish project is pakcage name of
CORBA part is "com.sun.corba.ee....",
however, in the glassfish-corba project the package name is
"com.sun.corba.se...".
I'm wondering if there're any difference between them, or just the
change of package name?

Best Regards,
-Jason
> Ken.