• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

user defined exception problem in session bean.

 
Ranch Hand
Posts: 59
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I creaed one user defined exception and using this exception
in the session bean when I am trying use this bean at the client
side and cathing this exception it is not catching it properly
while server side it is throwing this exception.

I can elaborate it through client code -

try {
isModified = sessionBean1.modifyNe(Object product);
}
catch (ValidationException nve) {
throw nve;
}
catch (RemoteException remoteException) {
remoteException.printStackTrace();
}


server is throwing ValidationException but it is cathing in
the RemoteException.


stack trace is given below

java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.RemoteException: com.ss.sms.common.exception.ValidationException: name should be unique
at com.sisl.snms.server.esc.common.SmsEscBean.checkDuplicateNeName(SnmsEscBean.java:56)
at com.sisl.snms.server.esc.escatm.SessionBean1.modifyNe(EscAtmBean.java:219)
at com.pramati.ejb.runtime.EscAtmBean_LocalObject_Impl_785398532._pramati_impl_modifyNe(EscAtmBean_LocalObject_Impl_785398532.java:285)
at com.pramati.ejb.runtime.EscAtmBean_LocalObject_Impl_785398532$3.run(EscAtmBean_LocalObject_Impl_785398532.java:238)
at com.pramati.security.util.JAASSecurityHelper.doAs(JAASSecurityHelper.java:158)
at com.pramati.security.util.JAASSecurityHelper.doAs(JAASSecurityHelper.java:266)
at sun.reflect.GeneratedMethodAccessor85.invoke(Unknown Source)
\



 
Sheriff
Posts: 10445
227
IntelliJ IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Following is a brief description about how EJB container handles exceptions. I found it from some site, dont remember the source though.

How the EJB container handles exceptions:

The EJB container intercepts every method call on the EJB component. As a
result, every exception that results in a method call is also intercepted by
the EJB container. The EJB specification deals only with handling two types of
exception: application exceptions and system exceptions.

An application exception is defined by the EJB spec as any exception declared
on the method signatures in the remote interface (other than RemoteException).
An application exception is a special scenario in the business workflow. When
this type of exception is thrown, the client is given a recovery option,
usually one that entails processing the request in a different way. This does
not, however, mean that any unchecked exception declared in the throws clause
of a remote-interface method would be treated as an application exception. The
spec states clearly that application exceptions should not extend
RuntimeException or its subclasses.

When an application exception occurs, the EJB container doesn't roll back the
transaction unless it is asked to do so explicitly, with a call to the
setRollbackOnly() method on the associated EJBContext object. In fact,
application exceptions are guaranteed to be delivered to the client as is: the
EJB container does not wrap or massage the exception in any way.

A system exception is defined as either a checked exception or an unchecked
exception, from which an EJB method cannot recover. When the EJB container
intercepts an unchecked exception, it rolls back the transaction and does any
necessary cleanup. Then the container wraps the unchecked exception in a
RemoteException and throws it to the client. Thus the EJB container presents
all unchecked system exceptions to the client as RemoteExceptions (or as a
subclass thereof, such as TransactionRolledbackException).

In the case of a checked exception, the container does not automatically
perform the housekeeping described above. To use the EJB container's internal
housekeeping, you will have to have your checked exceptions thrown as unchecked
exceptions. Whenever a checked system exception (such as a NamingException)
occurs, you should throw javax.ejb.EJBException , or a subclass thereof, by
wrapping the original exception. Because EJBException itself is an unchecked
exception, there is no need to declare it in the throws clause of the method.
The EJB container catches the EJBException or its subclass, wraps it in a
RemoteException, and throws the RemoteException to the client.
reply
    Bookmark Topic Watch Topic
  • New Topic