[jira] Commented: (AXIS-1298) Inconsistent invocation of JAX-RPC handlers

[ji...@apache.org]

The following comment has been added to this issue:

     Author: Davanum Srinivas
    Created: Sun, 11 Apr 2004 3:19 AM
       Body:
Can you please submit a patch? ("cvs diff -u")

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

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

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: AXIS-1298
    Summary: Inconsistent invocation of JAX-RPC handlers
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Axis
 Components: 
             Basic Architecture
   Versions:
             1.2 Beta

   Assignee: 
   Reporter: Thilo Frotscher

    Created: Sat, 10 Apr 2004 8:02 PM
    Updated: Sun, 11 Apr 2004 3:19 AM
Environment: all

Description:
Axis supports JAX-RPC handlers by two means: 1) wrapping them using class JAXRPCHandler, and 2) adding them "directly" to the message processing using wsdd elements <handlerInfoChain> and <handlerInfo>. This bug report is about the second way.

On the client side, handlers are called in the following order (see class AxisClient, method invoke(MessageContext msgContext):
- service-specific request chain
- global request chain
- JAX-RPC handlers (method handleRequest)
- transport-specific request chain
- transport sender
- transport-specific response chain
- JAX-RPC handlers (method handleResponse)
- global response chain
- service-specific response chain

However, on the server side handlers are called in another order (see classes AxisServer and SOAPService, methods invoke(MessageContext msgContext)):

- transport-specific request chain
- global request chain
- JAX-RPC handlers (method handleRequest)
- service-specific request chain
- web service
- service-specific response chain
- JAX-RPC handlers (method handleResponse)
- global response chain
- transport-specific response chain
 
Of course, this order is mirrored. But that's not the case. The problem is that JAX-RPC handlers are called between global chain and service-specific chain on the server, while they are called between transport-specific chain and the global chain on the client. This can be tested by installing dummy handlers that simply log a message in every chain.

Now, why is this problematic. Let's imagine we have a handler E that encrypts a message and another handler D that decrypts a message. E is installed in the global chain on the client, D is installed in the global chain on the server. Additionally, we have two JAX-RPC-Handlers  Z and U, which zip and unzip a certain part of the soap body. Z is installed using <handlerInfoChain> on the client, while U is installed the same way on the server.

The current implementation leads to the following processing order:
client app -> Encrypt -> Zip -> ...network transport... -> Decrypt -> Unzip. Since Encryption and Compression are usually not commutative, the intended functionality will fail.

Conclusion: JAX-RPC handlers must be called at the same position on client and on server, either between global chain and transport- specific chain, or between global chain and service-specific chain. In my opinion, the latter is better with regard to the JAX-RPC spec.




---------------------------------------------------------------------
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