Hi Cheng,
The logging requirements in the spec for exceptions are not that
literal. The goal is
to ensure that certain problems (namely, system errors) are brought to the
attention of a system administrator. Here's an example from the
exceptions chapter :
"[A] Log the exception or error means that the container logs the
exception or
error so that the System Administrator is alerted of the problem. "
EJBTransactionRequiredException and
TransactionRequiredLocalException represent the same problem -- that a
tx was required for an ejb invocation but was not found.
The exception contract coded to by the application is much more precise.
In that
case, the actual exception received by the caller at runtime must match the
spec requirements. Otherwise, the code would not be portable.
The main reason the container handles the exception processing this way is
for simplicity. The concrete exception delivered to the caller can
depend on
many factors such as which physical transport is being used and how the
remote business interface was coded. In many cases it's easier to perform
the appropriate exception translation later in the invocation handling,
at times
even in the client itself. None of this matters to the application as
long as it
receives the correct exception.
I don't see any spec compliance problem here, but you can file an issue
if you
feel the content of the log is too confusing. E.g., the container could
add some additional text about the interface through which the call was made
and a short explanation of the problem.
--ken
Cheng Fang wrote:
> EchoBean has a remote and local business interfaces, and its business
> methods are annotated with @TransactionAttribute(Mandatory). The
> TestServlet client invokes EchoBean remotely and locally thru their
> respective business interface, with no transaction context.
>
> I do get expected javax.ejb.EJBTransactionRequiredException for both
> remote and local invocation. I also noticed in server.log, a
> javax.ejb.TransactionRequiredLocalException is logged for both local
> and remote invocation.
>
> The required exception expected by the client,
> javax.ejb.EJBTransactionRequiredException, is not logged in either case.
>
> So it seems there are 2 problems:
> 1. ejb spec requires system exception
> (javax.ejb.EJBTransactionRequiredException) to be logged, but
> glassfish doesn't;
> 2. exceptions irrelevant to the client are logged, which is a
> ease-of-use issue.
>
> from server.log:
> ============
> TestServlet about to invoke remoteIntEchoBean.reverse(1)|#]
>
> [#|2006-09-01T12:41:15.119-0400|INFO|sun-appserver-ee9.1|javax.enterprise.system.container.ejb|_ThreadID=34;_ThreadName=httpWorkerThread-8080-1;EchoBean;|EJB5018:
> An exception was thrown during an ejb invocation on [EchoBean]|#]
>
> [#|2006-09-01T12:41:15.120-0400|INFO|sun-appserver-ee9.1|javax.enterprise.system.container.ejb|_ThreadID=34;_ThreadName=httpWorkerThread-8080-1;|
>
> javax.ejb.TransactionRequiredLocalException
> at
> com.sun.ejb.containers.BaseContainer.preInvokeTx(BaseContainer.java:3143)
> at
> com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1164)
> at
> com.sun.ejb.containers.EJBObjectInvocationHandler.invoke(EJBObjectInvocationHandler.java:189)
>
> at
> com.sun.ejb.containers.EJBObjectInvocationHandlerDelegate.invoke(EJBObjectInvocationHandlerDelegate.java:67)
>
> at $Proxy115.reverse(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.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:200)
>
> at
> com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:119)
>
> at
> com.sun.corba.ee.impl.presentation.rmi.bcel.BCELStubBase.invoke(BCELStubBase.java:197)
>
> <other parts not shown>
>
> If the servlet client prints stack trace, it shows
> javax.ejb.EJBTransactionRequiredException wraps a
> javax.ejb.TransactionRequiredLocalException:
>
> javax.ejb.EJBTransactionRequiredException
> at
> com.sun.ejb.containers.BaseContainer.mapBusinessInterfaceException(BaseContainer.java:1389)
>
> at
> com.sun.ejb.containers.BaseContainer.postInvoke(BaseContainer.java:1300)
> at
> com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:192)
>
> at
> com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:71)
>
> at $Proxy105.reverse(Unknown Source)
> .... ...
> Caused by: javax.ejb.TransactionRequiredLocalException
> at
> com.sun.ejb.containers.BaseContainer.preInvokeTx(BaseContainer.java:3143)
> at
> com.sun.ejb.containers.BaseContainer.preInvoke(BaseContainer.java:1164)
> at
> com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:182)
>
> ... 36 more
>
>
>