DO NOT REPLY [Bug 26159] New: - Un-serializable response message

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26159>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26159

Un-serializable response message

           Summary: Un-serializable response message
           Product: Axis
           Version: 1.1
          Platform: PC
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Serialization/Deserialization
        AssignedTo: axis-dev@ws.apache.org
        ReportedBy: alanmurphy@hotmail.com


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