Peter Kovacs wrote:
>
> Hi Philippe,
>
> Thank you for your prompt reply.
>
> I have looked at the code in JOnAS and believe that the changes described below
> would solve the problem. (This my first shot at at. I have not tried it out yet. I
> just want to
> make sure that I do not start implementing something which has its own problems
> that
> may be obvious to people much more familar with JOnAS than myself. Are patches
> considered that have been submitted by users?)
>
> 1)
> (a)The RequestCtx class should have a new field:
> private Throwable appExc ;
> with getter-setter methods.
> (b) The setter methods for both sysExc and appExc should clear the other exception
> field.
> E.g. the setSysExc method would be rewritten as follows:
> public void setSysExc(Throwable e) {
> appExc = null ;
> this.sysExc = e;
> }
>
> 2)
> The generated container classes should include a catch branch for each exception
> thrown
> by the bean:
> catch ( <app-exception> appExc ) {
> rtcx.setAppExc( appExc ) ;
> throw appExc ;
> }
> where <app-exception> is a non-system exception appearing in the signature of the
> bean
> interface method (CreateException in the case of create()).
>
> 3) The following if block should be be added to the method
> JEntityHome.postinvoke(RequestCtx rctx)
> // Commit or Rollback transaction started in preinvoke
> if (rctx.mustCommit()) {
> + if ( rctx.getAppExc != null && tm.getRollbackOnly() ) {
> + // rollback tx
> + try {
> + TraceEjb.error("Application exc. => Rollback the transaction.");
> + tm.rollback();
> + } catch (Exception e) {
> + TraceEjb.error("Exception during rollback:", e);
> + }
> + return ;
> + }
> if (rctx.getSysExc() != null) {
>
> Please, let me know your opinion as to wether the proposed patch would solve the
> problem.
> If not, why?. Are you aware of any new bugs the proposed patch would introduce? Is
> point
> 2) difficult to implement?
>
> Thank you
>
> Peter
Hi Peter,
I have worked hard on your proposal and on the problem raised.
Your proposal was a good start point, thank you very much.
I was wondering why the Finder exceptions were correctly caught in the
client
but it was not the case for CreateException and RemoveException.
In fact, I found that when an application exception was thrown in
ejbCreate the container forced the transaction to rollback (see
beforeCompletion()
in EntityContextImpl) and when the container wanted to commit the
transaction
it couldn't and it receives RollbackException and overloaded the
CreateException
with a RemoteException("Container cannot commit a transaction")
so theclient could'nt catch CreateException.
I have modified the beforeCompletion in order to avoid this problem.
For the RemoveException in was different. In fact before removing a bean
we tried to activate it and when the bean doesn't exist the client
received a RemoteException indicating that a problem occurs when loading
the bean. I have changed this also in order to rethrow RemoveException.
In Container managed persistence in the generated code the EJBException
was thrown in ejbCreate, ejbRemove when a problem occurs, but
EJBException
is a RunTimeException that was embeded in a RemoteException, so the
client
couldn't never receive CreateException.
I have change the code generation with the following politics:
If an error occurs during the SQL statements in ejbCreate
CreateException is thrown
If an error occurs during the SQL statements in ejbRemove
RemoveException is thrown
if an error occurs during ejbLoad or ejbStore EJBException is thrown.
In the ejbCreate generated I have added a test for throwing
DuplicateKeyException
when we want to create an entity bean already present in the server
So now the behavior is the same in BMP and CMP and CreateException,
RemoveException
can be catchable in the client.
The only problem I see (I hope it is a minor one) : as the generated
code CMP
throw CreateException and RemoveException it is mandatory for the bean
provider
to define javax.ejb.CreateException in the throws clause of
ejbCreate<METHOD> methods
and to define javax.ejb.RemoveException in the throws clause ejbRemove
method.
It was not mandatory in the current version of JOnAS so some existing
beans
may not compile anymore as it.
Note that the EJB2.0 specification says:
§9.7.5 ejbCreate<METHOD>methods:
The throws clause MUST define javax.ejb.CreateException. The throws
clause may define
arbitrary application specific exceptions.
The EJB1.1 Specification was saying:
§9.2.3 ejbCreate methods:
The throws clause MAY define arbitrary application specific exceptions,
including
the javax.ejb.CreateException
So the current version of JONAS that will be committed in CVS next will
be more compliant
to EJB2.0 than EJB1.1!
Best regards,
--
Philippe
Philippe Coq Evidian Phone: (33) 04 76 29 78 49
Bull S.A - 1 rue de Provence - 38432 Echirolles Cedex France
Download our EJBServer at http://www.objectweb.org
----
To unsubscribe, send email to [EMAIL PROTECTED] and
include in the body of the message "unsubscribe jonas-users".
For general help, send email to [EMAIL PROTECTED] and
include in the body of the message "help".
