axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 17950] - Defect of the jax-rpc handler impl on the processing model
Date Fri, 14 Mar 2003 18:19:44 GMT
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=17950>.
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=17950

Defect of the jax-rpc handler impl on the processing model





------- Additional Comments From kimuratsy@nttdata.co.jp  2003-03-14 18:19 -------
Hi dims,

  Thank you for your rapid response.

  I don't make a decision whether I should reopen this bug
or not. In advance, I'd like to hear the opinions of you
and some others.

  The latest code doesn't have the onFalseRestartAt parameter
to provide the functionality for the flexible flow management.
So, sometime axis users might have troubles.
  I'll try to explain the reason in the following scenario;

-- <CUT> ----- <CUT> ----- <CUT> ----- <CUT> ----- <CUT> --
 [Condition]: (*** Please see below with your fixed font ***)
  - There're three jax-rpc handler impl; H1, H2, H3
  - H1(req) indicates the handleRequest  method of H1 instance
  - H1(res) indicates the handleResponse method of H1 instance
  - The items mentioned above for H1 are same as H2, H3

 [*] === Normal sequence ===: JAX-RPC handler Processing Model

    [H1(req)]-->[H2(req)]-->[H3(req)]-->[deserializer]---+
                                                         |
                                                         V
                                                  [Eend-point]
                                                         |
                                                         V
    [H1(res)]<--[H2(res)]<--[H3(res)]<--[ serializer ]---+

 [*] === 'return false' sequence ===: H2(req) returned false

      [H1(req)]-->[H2(req)]------+
                     |           |
    <-(1)------------|           |
          |(2)       |(3)        |(4)
          V          V           V
    <--[H1(res)]<--[H2(res)]<--[H3(res)]

       (1): H2(req) generates a response msg and the runtime
            directly sends back it to the client
       (2): H1(res) adds additional processings to a response
            msg, and the runtime sends back it to the client
       (3): H2(res) adds additional processings to a response
            msg, and the runtime invokes the next handler
            ( handleResponse of H1 ), then ...
           *** The spec says "It should be the default" ***
       (4): H3(res) adds additional processings to a response
            msg, and the runtime invokes the next handler
            ( handleResponse of H2 ), then H1(res) ...
-- <CUT> ----- <CUT> ----- <CUT> ----- <CUT> ----- <CUT> --

  The latest code can take the flow (3) as default, however,
there is no way for the axis users to select the other flows
like as the sequence (1), (2), and (4).
  Are you acceptable to this situation ? I don't think so.

Best Regards,

  Toshi (Toshiyuki Kimura) <kimuratsy@nttdata.co.jp>
  R&D Headquarters
  NTT DATA Corporation

Mime
View raw message