I am not be following you very well, but do think fillInStackTrace()
method may help I mean to call it on the embedded exception while you
are initiating the new thrown exception with it ???
On Thu, May 22, 2008 at 3:33 AM, David Blevins <[EMAIL PROTECTED]> wrote:
>
> On May 21, 2008, at 5:04 PM, Dain Sundstrom wrote:
>
>> I think Rick may be able to provide more insight than me given his work on
>> vm class loading, but I'll take a shot at this one....
>>
>> I think the difference between the two exceptions is based on when the VM
>> discovers it has an invalid class. The second exception shows us that the
>> bad class is openejb.org.superbiz.cmp2.MovieBean, which is a class we
>> generated directly using ASM. In "Style 1", I think something about the
>> code in EjbHomeProxyHandler was causing the VM to perform a full verify on
>> the class (FWIU the vm only verifies what is needs to improve VM startup
>> time). Was EjbHomeProxyHandler doing something like scanning all the Method
>> objects? Anyway, in "Style 1", for some reason the vm didn't have (or
>> didn't provide) additional information about which class was having the
>> error, which based on my coding experience is a pretty common situation. In
>> "Style 2", the vm clearly knows what's going on and tells us everything
>> necessary to fix the problem.
>>
>> In the long term, we could catch this problem with the verifier or if they
>> turn that off, we could just fill in a do nothing implementation.
>
> Huh. Not sure. We're talking about zero code change anywhere in anything
> (even the test case) other than the following patch.
>
> Index: src/main/java/org/apache/openejb/core/ivm/EjbHomeProxyHandler.java
> ===================================================================
> --- src/main/java/org/apache/openejb/core/ivm/EjbHomeProxyHandler.java
> (revision 655683)
> +++ src/main/java/org/apache/openejb/core/ivm/EjbHomeProxyHandler.java
> (working copy)
> @@ -210,7 +210,7 @@
> if (cause instanceof RemoteException && interfaceType.isLocal())
> {
> RemoteException re = (RemoteException) cause;
> Throwable detail = (re.detail != null) ? re.detail : re;
> - cause = new EJBException(re.getMessage(), (Exception)
> detail);
> + cause = new
> EJBException(re.getMessage()).initCause(detail);
> }
> throw cause;
> /*
>
> I'm not sure how class verification, etc. could be affected. Taking a fresh
> look at this, the ClassCastException part of Style 1 looks awfully fishy...
>
> Yea, that's it. Can't believe I missed it.
>
> -David
>
>
>
>>
>>
>> -dain
>>
>> On May 21, 2008, at 4:52 PM, David Blevins wrote:
>>
>>> There seems to be some major difference between these two styles of
>>> EJBException creation. I ran into this working on a CMP example I intend to
>>> use for the whole CMP+JPA->JPA merging logic. The real error is that I
>>> forgot to implement "setEntityContext" which is an easy mistake to make as
>>> the CMP2 bean class is abstract and compiles just fine without it. I got
>>> the first stack trace below, which is useless, and decided on a whim to
>>> tweak EjbHomeProxyHandler line 213 to the second style shown below. I was
>>> and am shocked at the difference in the stack trace.
>>>
>>> [Style 1] throw new EJBException(re.getMessage(), (Exception) detail);
>>> Yields:
>>> java.lang.ClassCastException: java.lang.AbstractMethodError
>>> at
>>> org.apache.openejb.core.ivm.EjbHomeProxyHandler._invoke(EjbHomeProxyHandler.java:213)
>>> at
>>> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:274)
>>> at org.superbiz.cmp2.$Proxy26.create(Unknown Source)
>>> at org.superbiz.cmp2.MoviesTest.test(MoviesTest.java:51)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>> at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>> at
>>> com.intellij.rt.execution.junit2.JUnitStarter.main(JUnitStarter.java:32)
>>>
>>>
>>> [Style 2] throw new EJBException(re.getMessage()).initCause(detail);
>>> Yields:
>>>
>>> javax.ejb.EJBException: The bean encountered a non-application
>>> exception.; nested exception is:
>>> java.lang.AbstractMethodError:
>>> openejb.org.superbiz.cmp2.MovieBean.setEntityContext(Ljavax/ejb/EntityContext;)V
>>> at
>>> org.apache.openejb.core.ivm.EjbHomeProxyHandler._invoke(EjbHomeProxyHandler.java:213)
>>> at
>>> org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:274)
>>> at org.superbiz.cmp2.$Proxy26.create(Unknown Source)
>>> at org.superbiz.cmp2.MoviesTest.test(MoviesTest.java:51)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>> at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>> at
>>> com.intellij.rt.execution.junit2.JUnitStarter.main(JUnitStarter.java:32)
>>> Caused by: java.lang.AbstractMethodError:
>>> openejb.org.superbiz.cmp2.MovieBean.setEntityContext(Ljavax/ejb/EntityContext;)V
>>> at
>>> org.apache.openejb.core.cmp.CmpContainer.setEntityContext(CmpContainer.java:318)
>>> at
>>> org.apache.openejb.core.cmp.CmpContainer.createEJBObject(CmpContainer.java:592)
>>> at
>>> org.apache.openejb.core.cmp.CmpContainer.invoke(CmpContainer.java:250)
>>> at
>>> org.apache.openejb.core.ivm.EjbHomeProxyHandler.create(EjbHomeProxyHandler.java:267)
>>> at
>>> org.apache.openejb.core.ivm.EjbHomeProxyHandler._invoke(EjbHomeProxyHandler.java:158)
>>> ... 21 more
>>>
>>>
>>> Able to verify the stack trace behavior is this way in both intellij and
>>> maven. Obviously the stack trace for style #1 completely obfuscates the
>>> problem which is itself a big problem.
>>>
>>> Anyone have any idea, what causes this difference?
>>>
>>> Needless to say, I'll shortly be switching all our code over....
>>>
>>> -David
>>>
>>
>>
>
>
--
Thanks
- Mohammad Nour
