Sun, 30 Sep 2001 22:48:31 -0700

Hello Anil,
                The reason why we do not permit generic 'Exception'
with the RemoteException is clearfiied as below:
 
Exceptions in EJBs

The EJB specification defines two types of exceptions.
1. System Exceptions
2. Application Exceptions

The spirit behind the categorization is that the application exceptions
are those arising out of application logic and rules. The EJB container
is to ignore these type of exceptions happening in the code. They are to
be handled by the application. On the other hand there will be
occassions when exceptions happen outside the scope of the application
like Connection exceptions, Runtime exceptions etc from which the
application cannot recover. In such cases the EJB specification puts the
responsibility of cleaning and unlocking resources held by that
transaction.

To give a simple example an Account bean could throw a
IllegalAmountException to specify the lack of funds to carry out a debit
operation. On the other hand a failre to obtain connection to the DB at
the time of operations would be notified to the Container through an
EJBException (which is a runtime exception). The container treats this
exception as a System Exception and starts the cleanup process.

Consider now the case of a bean defining a generic Exception in it's
throws clause. In this case all exceptions coming out of the bean have
to be caught in the client of the bean. If this bean, say A, is being
invoked by bean B then B will have a catch(Exception e) block in it's
code. But the bean writer has to make sure he doesnt gobble up the
runtime and remote exceptions. These have to be propogated back so
container can take appropriate action. So something like

try{
    A.someMethod();
}catch(Exception e){
    if(e instanceof RemoteException){
        .....
        throw (RemoteException)e;
    }else if(e instance of RuntimeException){
        ....
        throw (RuntimeException)e;
    }
}
or multiple catch blocks have to written. But the important point is
that the bean writer has to make sure that the System exceptions are
propogated back. It is very easy to miss this (forget to throw back the
exception)

Since the EJB 1.1 specification is not explicit in this regard we have
debated over this and came to the conclusion that to avoid these
mistakes it is best not to allow beans to throw generic Exception in
their business methods. They can always throw an ApplicationException
or subclasses thereof. Also, in most developments it is expected that
the Exceptions across modules are defined and would be derived from a
Hiererchial structure themselves. Thus it is possible to catch all
ApplicationExceptions by catching the Super class of
ApplicationExceptions and not by catching generic Exception.

Note that the EJB 2.0 section 17.2.1 the specification clearly defines
the bean providers responsibilities for Exceptions as

"An application exception class must be a subclass (direct or indirect)
of java.lang.Exception.
An application exception class must not be defined as a subclass of the
java.lang.RuntimeEx-ception,
or of thejava.rmi.RemoteException. These are reserved for system
exceptions
(See next subsection)."

thus clearing the amiguity existing in EJB 1 1 specification. (which
also falls in line with our view explained above)

For your problem we suggest that you have a hiererchy of
ApplicationExceptions and not use Exception as the super class of
application exceptions.
MySuperApplicationException extends Exception
    MyModule1Exception extends MySuperApplicationException
    MyModule2Exception extends MySuperApplicationException
Then if you want to catch all application exception you can catch the
MySuperApplicationException.
Regards,
 
Ritesh
 
 
 
----- Original Message -----
From: SEKHAR JS <[EMAIL PROTECTED]>
Sent: Saturday, September 29, 2001 3:37 PM
Subject: Ejb Deployment Problem

> Hi,
>
>     This is ANIL,
>
>     Since yesterday i am waiting for your reply.
>
>     Here i am sending two attachments one is Java code
> and another is EJB. I hope first you will run these
> two attachments and give me your feed back.
>
>     1) In the Java attachment code in the Third.java
> file i mentioned a comment, you please go through it.
>
>     2) Here i am able to deploy the EJB attachment in
> WEBLOGIC Server and if i try the same bean in the
> PRAMATI SERVER i am getting an error as follows,
>
>
> ***********Error Message from Log
> File*****************
>
> Pramati Server Started on 192.168.128.2:9191, HTTP
> Port 8181
>
> Reading pramati-j2ee-server.xml....
> Reading ejb-jar.xml....
> Deploying ejbComponent...
> base location
> isd:\PServer25\server\nodes\StandAlone\user2\archives\Test.jar
>    Generating the Impl java files of remote interface
> for the bean Test
>    Generating the Impl java files of home interface
> for the bean Test
>       Code generation complete for Test.jar
>       Compiling 2 files of Test.jar
> d:\PServer25\server\nodes\StandAlone\user2\archives\Test.jar\java\TestRemoteImpl_1226327922.java:157:
> catch not reached.
> }catch(Exception ex){
> ^
> 1 error
> d:\PServer25\server\nodes\StandAlone\user2\archives\Test.jar\java\TestRemoteImpl_1226327922.java:157:
> catch not reached.
> }catch(Exception ex){
> ^
> 1 error
>
> ***********************************************************
>
> I don't know why i am getting this ERROR only with
> PRAMATI SERVER, If possible to you please try to
> deploy the EJB attachment in WEBLOGIC and then come
> to a Conclusion.
>
> *****
>        Here one important point is, the EJB jar that i
> deployed in the Weblogic Server should be deployed in
> Pramati Server without any modifications in code.
> *****
>
>       Please do reply as soon as possible because with
> this simple problem i have been StruckedUP for a
>       couple of days.
>
>       Thank You,
>
>       With Regards,
>
>       Anil K Pendela
>    
>
>              
>    
>
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Listen to your Yahoo! Mail messages from any phone.
> http://phone.yahoo.com

Reply via email to