[jira] Commented: (AXIS-1187) Un-serializable response message

[ji...@apache.org]

The following comment has been added to this issue:

     Author: Davanum Srinivas
    Created: Sun, 11 Apr 2004 7:43 AM
       Body:
Do you have any suggestions? specifically patches? (against latest CVS)

thanks,
dims
---------------------------------------------------------------------
View this comment:
  http://issues.apache.org/jira/browse/AXIS-1187?page=comments#action_32847

---------------------------------------------------------------------
View the issue:
  http://issues.apache.org/jira/browse/AXIS-1187

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: AXIS-1187
    Summary: Un-serializable response message
       Type: Bug

     Status: Open

    Project: Axis
 Components: 
             Serialization/Deserialization
   Versions:
             1.1

   Assignee: Axis Developers Mailing List
   Reporter: alan Murphy

    Created: Thu, 15 Jan 2004 9:58 AM
    Updated: Sun, 11 Apr 2004 7:43 AM
Environment: Operating System: Other
Platform: PC

Description:
When a RuntimeException is thrown from one of an EJB's container managed 
method's (e.g. ejbLoad()), a series of events can be set in motion that results
in AXIS returning an un-serializable response message to the client.

Consider the following sample scenario: a stateless session bean called
SSFacadeBean is responsible for creating and returning an instance of an entity
EJB called EmployeeBean. AXIS recieves a SOAP request to invoke getEmployee()
from SSFacadeBean, and does so accordingly. At the request of SSFacadeBean,
Weblogic duely invokes EmployeeBean.ejbLoad(), which loads the Employee data
from a database. An error occurs and ejbLoad() throws an SQLException. 

Unfortunately, the nature of Weblogic dictates that this SQLException does not
filter back from the EmployeeBean.ejbLoad() to SSFacadeBean.getEmployee(). 
Instead, in instance of EmployeeBean is returned to SSFacadeBean.getEmployee(),
who is completely unaware that anything has gone wrong. It is only when
SSFacadeBean, or the client who invoked the SSFacadeBean (i.e Apache AXIS in
this scenario) attempt to call a method of the EmployeeBean instance that the
SQLException is thrown, wrapped as a RemoteException, back to the client. 

So, to recap, a RuntimeException thrown from the ejbLoad() method of an entity
bean WILL NOT stop the entity bean instance from being created. The
RuntimeException will only be presented to the client when they actually try
call a method from the invalid entity bean. 

This problem is exacerbated when Apache AXIS creates a response message, passing
the Entity Bean instance into the constructor of org.apache.axis.Message. The
defunct, unuseable entity bean now lies insideously within the Message object,
which AXIS will pass back to the originating client. Only when the client
actually tries to extrapolate the contents of the message (e.g. by calling
getSOAPPartAsString()) will the RuntimeException() throwm from ejbLoad() be
escalated. And it will not be escalated as the causal SQLException, or
RemoteException, but as an IOException. 

This IOException is thrown because the Message object has tried to serialize the
Employee object to XML, and obviously can't because every time it tries to
invoke a member method of the bean the original SQLException is thrown an caught. 

Whilst I realise that this problem may stem from shortcomings of WebLogic, AXIS
could probably do more to ensure that a RuntimeException such as SQLException
thrown from an EJB it has invoked, ends up as an SQLException in the client (or
at least an SQLException wrapped in a RemoteException). To have it manifest
itself as an IOException is poor. The patch I have put in place on my particular
project is to validate the entity bean before returning it to AXIS. This is
simply done by calling any method of the bean before returning, and if there is
a dormant RuntimeException lying insideously within the bean, it will be thrown
back to AXIS instead of a defunct bean instance. But this patch shouldn't be
necessary.

Thanks,
Alan


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira