-
1. Re: exception handling
jacklaasen Feb 25, 2002 12:17 PM (in response to dporter)I am having a similar problem using 3.0.0alpha(200202222247) - jetty , Redhat 7.2, jdk1.3.1_02.
I am trying to throw application exceptions to a client (Servlet) from Session facade (stateful session bean) using local interfaces. But when the facade throws the exceptions...... it comes through to the client as an UndeclaredThrowableException.
I have really tried to solve this before bothering the guru's ..... but could any one please throw me a hint...I will handle it as an exception :)
Here? the code involved :
CLIENT (Servlet)
-----------------------------------
// create EJB through local interface
InitialContext ic = new InitialContext();
Object ref = ic.lookup(?ejb/local/OutfitterClientFacade?);
OutfitterClientFacadeLocalHome home = (OutfitterClientFacadeLocalHome)
PortableRemoteObject.narrow(ref,OutfitterClientFacadeLocalHome.class);
local = home.create();
.......
try {
local.setOutfitter(
request.getParameter(?outfitterLoginId?)
,request.getParameter(?outfitterLoginPwd?));
.......
} catch (OutfitterDAOInvalidUserid re) {
.......
}
catch (java.lang.reflect.UndeclaredThrowableException ae) {
//******> CAUGHT HERE INSTEAD OF AT OutfitterDAOInvalidUserid
}
LOCAL INTERFACE
-------------------------------------------
public interface OutfitterClientFacadeLocal extends EJBLocalObject {
public void setOutfitter(String userId,String pwd) throws OutfitterDAOInvalidUserid;
...........
}
SESSION BEAN (OutfitterClientFacadeLocal)
---------------------------------------------------------------
....
public void setOutfitter(String userId,String pwd)
throws OutfitterDAOInvalidUserid
{
try {
........
} catch (OutfitterDAOInvalidUserid re) {
throw re;
//******> THROWN FROM HERE
}
EXCEPTION
------------------
public class OutfitterDAOInvalidUserid extends Exception
implements java.io.Serializable {
.....
} -
2. Re: exception handling
jacklaasen Feb 25, 2002 12:48 PM (in response to dporter)I am sorry...I forgot to include stack trace :
2002-02-25 11:49:18,268 ERROR [Default] java.lang.reflect.UndeclaredThrowableException:
2002-02-25 11:49:18,275 ERROR [Default] java.rmi.ServerException: null
Embedded Exception
Login id do not exists; nested exception is:
javax.ejb.EJBException: null
Embedded Exception
Login id do not exists
2002-02-25 11:49:18,283 ERROR [Default] javax.ejb.EJBException: null
Embedded Exception
Login id do not exists
2002-02-25 11:49:18,286 ERROR [Default] at org.jboss.ejb.StatefulSessionContainer$ContainerInterceptor.invoke(StatefulSessionContainer.java:783)
2002-02-25 11:49:18,291 ERROR [Default] at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:127)
2002-02-25 11:49:18,295 ERROR [Default] at org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invoke(StatefulSessionInstanceInterceptor.java:248)
2002-02-25 11:49:18,300 ERROR [Default] at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:96)
2002-02-25 11:49:18,304 ERROR [Default] at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:158)
2002-02-25 11:49:18,308 ERROR [Default] at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:64)
2002-02-25 11:49:18,312 ERROR [Default] at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:166)
2002-02-25 11:49:18,316 ERROR [Default] at org.jboss.ejb.StatefulSessionContainer.invoke(StatefulSessionContainer.java:352)
2002-02-25 11:49:18,324 ERROR [Default] at org.jboss.ejb.plugins.local.BaseLocalContainerInvoker.invoke(BaseLocalContainerInvoker.java:346)
2002-02-25 11:49:18,327 ERROR [Default] at org.jboss.ejb.plugins.local.BaseLocalContainerInvoker$StatefulSessionProxy.invoke(BaseLocalContainerInvoker.java:516)
2002-02-25 11:49:18,330 ERROR [Default] at $Proxy6.setOutfitter(Unknown Source) -
3. Re: exception handling
jacklaasen Feb 25, 2002 2:39 PM (in response to dporter)Ok...i have soved it. My mistake
After debugging the server code I realized that my application exception was still compiled as an extention RuntimeException and not as just as an Exception. That caused the StatelessSessionContainer to transform it into a EJBException.
THIS IS ONE MORE CLASSIC CASE SHOWING THE BENEFIT OF HAVING AN OPEN-SOURCE SERVER, EVEN FOR A ROOKIE LIKE ME
Here's the relevant StatelessSessionContainer code
if (ex instanceof EJBException)
throw (EJBException)ex;
else if (ex instanceof RuntimeException)
throw new EJBException((Exception)ex); // transform runtime exception into what a bean *should* have thrown
else if (ex instanceof Exception)
throw (Exception)ex;
else
throw (Error)ex; -
4. Re: exception handling
jbossid Mar 13, 2002 8:06 AM (in response to dporter)hi could you please tell me how you coded the exception handling ,i need to do the same.
where you coded that exception ? please tell this clearly.i am struglling with the same problem -
5. Re: exception handling
jacklaasen Mar 14, 2002 1:10 PM (in response to dporter)
I needed the ability to throw an exception from an EJB such that the container meerly re-throw it to the client. As you can see in StatelessSessionContainer code snippet above, if you throw instance of RuntimeException or EJBException, it is handled as an EJBException and the container then handle the exception appropriately(e.g. destroy your EJB). You will then not see the same exception thown to the client.
So I created an application exception (Note - it extends Exception):
public class OutfitterDAOInvalidUserid extends Exception
implements java.io.Serializable {
.....
}
In the EJB (in this case session bean) I throw it:
public void setOutfitter(String userId,String pwd)
throws OutfitterDAOInvalidUserid
{
..
throw new OutfitterDAOInvalidUserid();
..
} // NOTE!! Make sure your local/remote interface also show the exception being thrown
Then on client(this case servlet), I catch it
try {
.......
} catch (OutfitterDAOInvalidUserid re) {
.......
}
Hope this helps, I'm a newbie to J2EE. -
6. Re: exception handling
mulicheng Mar 25, 2002 12:58 PM (in response to dporter)I am using JBoss3.0 Beta.
I had problems with 2.4.4 with the user defined exception being transformed into a TransactionRolledBackException so I decided to try 3.0.
3.0 works when I start the server the first time. I throw an Exception from the EJB (ie: UserNameTakenException), the client catches my exception ok.
Next, I make some changes to my ejb, actually, I don't even have to make changes, lets say I just recopy a new jar file into the deploy directory. The ejb is redeployed, but things function differently.
Instead of the UserNameTakenException, the client gets a server exception. Notice the UndeclaredThrowableException at the very bottom of the stack trace.
Stack Trace on Client Side:
java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.ServerException: null
Embedded Exception
null; nested exception is:
javax.ejb.EJBException: null
Embedded Exception
null
java.rmi.ServerException: null
Embedded Exception
null; nested exception is:
javax.ejb.EJBException: null
Embedded Exception
null
javax.ejb.EJBException: null
Embedded Exception
null
at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:245)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:220)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:122)
at org.jboss.invocation.jrmp.server.JRMPInvoker_Stub.invoke(Unknown Source)
at org.jboss.invocation.jrmp.interfaces.JRMPInvokerProxy.invoke(JRMPInvokerProxy.java:174)
at org.jboss.proxy.ejb.GenericProxy.invoke(GenericProxy.java:182)
at org.jboss.proxy.ejb.StatefulSessionProxy.invoke(StatefulSessionProxy.java:132)
at $Proxy17.registerUser(Unknown Source)
at org.apache.jsp.test$jsp._jspService(test$jsp.java:94)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:107)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:202)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:474)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:247)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:243)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:190)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2343)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:564)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:429)
at org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:495)
at java.lang.Thread.run(Thread.java:484)
java.lang.reflect.UndeclaredThrowableException: [The username is already taken.]
If I restart jboss, the client again receives my UserNameTakenException. Any suggestions/help appreciated. Restarting JBoss each time We want to deploy just doesn't seem to be the right thing to do. -
7. Re: exception handling
adrian.brock Mar 25, 2002 1:21 PM (in response to dporter)Hi,
There were some problems with redeploying in the
beta, especially on windows.
You will find latest CVS is much better.
Regards,
Adrian -
8. Re: exception handling
mulicheng Mar 25, 2002 4:08 PM (in response to dporter)Thank you very much, that solved the problem.
I believe we're using 3.0 beta 2 now. (On Linux)
-Dennis -
9. Re: exception handling
razvjedtjik Apr 16, 2002 9:51 AM (in response to dporter)Interesting discussion, guys!
I am interested in a variation of the problem.
What about exceptions from the callback methods (ejbLoad and ejbStore for example)?
I am using Jboss 2.4.4 and this is my problem:
Actors:
1 Struts action
1 Stateless session bean (TX Supports)
1 BMP entity bean (TX Required)
What happens:
The action calls a method in the SLSB(facade) via remote interface. The SB (successfully) creates an instance of the entity bean (via the local interface). Within the same method scope I call a set-method on the bean i just created. This causes ejbStore to be invoked. In ejbStore I (purposely) throw an EJBException (I am testing this behavior.
The sb does NOT receive an EJBException at this point. It receives a java.lang.reflect.UndeclaredThrowableException which wraps a javax.transaction.RollbackException. I guess this is ok in a sense, but the (2.0, pp. 379) specification says that the client (which I guess is the SB in this case) should receive either an EJBException or more likely in this case a javax.ejb.TransactionRolledbackLocalException.
The remote client (which initiated the transaction) then gets a java.rmi.RemoteException caused by the same chain as above. Shouldn't IT at least get a javax.transaction.TransactionRolledbackException? (This, of course, is a "should" in the spec.).
All this makes it hard to get any information to the client on what caused the problem on a store callback. I could of course treat this as a generic "something-went-wrong-error" but we would like to know if the error was due to some parameter/sql/dao error and get this information to the client.
How do you treat your store:s and load:s?
Regards,
Jonas Bergqvist -
10. Re: exception handling
chandrag59 Aug 28, 2002 11:36 AM (in response to dporter)I am working with an EJB session bean and call a method on a java class to authenticate a user in LDAP. If there is an error I thorw a new RemoteExcpetion("Error Authenticating.")
For the front-end I am using Struts and catch the RemoteException in my login action class. When I try to print the error message with
System.out.println("Error Msg is : "+re.getMessage());
I see this:
Error Authenticating; nested exception is: java.rmi.RemoteException: Error Authenticating
why is it nesting the exception??
If I don't catch RemoteException and just catch Exception, and print the exception it says the exception type is java.rmi.ServerException!!!
I am running JBoss 3.0.1 version.
How do I un-wrap this on the client side. I don't want to do string parsing etc...