Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Received-SPF: pass (athena.apache.org: domain of davanum@gmail.com designates
 72.14.246.240 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=vzhc5nTSbW4vbqMhQqAEAqN0TYFyEIqnaKFYaqvhKr4Jdti5PA0gtEwyiGWCxmETPY1w1QfzxugXRBKbqIrEDICwVFlvWF7plvN6sH5XhPHW2AWwLV/IOHnRMtWUKr+XXB5Ia3LcZexmmxn6c1wwkrYFz2xxX1fq7uIg/JtI9q4=
Message-ID: <47CF5547.6040106@gmail.com>
Date: Wed, 05 Mar 2008 21:21:59 -0500
From: Davanum Srinivas <davanum@gmail.com>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: axis-dev@ws.apache.org
Subject: Re: [axis2] [proposal] JIRA AXIS2-3568
References: 
 <OFA74902C7.43DE94E3-ON86257403.006E6035-86257403.006E85A4@us.ibm.com>
 <47CF4BB8.6070309@thoughtcraft.com>
In-Reply-To: <47CF4BB8.6070309@thoughtcraft.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Glen,

Does not help at all unfortunately for our use case :( we just don't have the information available when the mu checks
are happening...we won't even have the handlers loaded in the EJB context at this point in time :( :(

- -- dims

Glen Daniels wrote:
| Hi all:
|
| OK, I was thinking about this a little more... and I found that I was
| actually just a touch uncomfortable with the idea of totally relying on
| the MessageReceiver for the entire MU check.
|
| I realize we're almost decided on this approach, but allow me to suggest
| an alternative for JAXWSMessageReceiver to implement:
|
| interface MustUnderstandProcessor {
|   boolean understands(List qnames);
| }
|
| So instead of just punting the MU check, we'd change
| checkMustUnderstand() as follows:
|
| static List checkMustUnderstands(MessageContext context)
|    throws AxisFault {
|   // return either null (success) OR a List of unprocessed MU qnames
| }
|
| Then in receive(), we'd do something like:
|
|   List unprocessed = checkMustUnderstands(context);
|   if (unprocessed != null) {
|     // Can the MR handle more?
|     if (!(receiver instanceof MustUnderstandProcessor) ||
|         !((MustUnderstandProcessor)receiver).understands(unprocessed)) {
|       // Construct and throw MU fault complete with NotUnderstood
|       // headers!
|     }
|   }
|
| This would keep the MU "framework" always happening in the engine, and
| just allow the MR to do whatever work it needs to in order to confirm
| that it can or cannot understand the MU headers that are specifically
| not processed already.
|
| Would this alternate be ok with folks?
|
| --Glen
|
| Nikhil V Thaker wrote:
|>
|> Thanks Glen for the input. I will incorporate your recommendations and
|> attach a new patch to JIRA.
|>
|> Nikhil Thaker
|> office: 512 838 9964
|> nvthaker@us.ibm.com
|>
|>
|> *Jeff Barrett/Austin/IBM@IBMUS*
|>
|> 03/05/2008 01:57 PM
|> Please respond to
|> axis-dev@ws.apache.org
|>
|>
|>
|> To
|>     axis-dev@ws.apache.org
|> cc
|>
|> Subject
|>     Re: [axis2] [proposal] JIRA AXIS2-3568
|>
|>
|>
|>
|>
|>
|>
|>
|> Looks good to me!
|>
|> +1
|>
|> Thanks,
|> Jeff
|>
|> IBM Software Group - WebSphere Web Services Development
|> Phone: 512-838-4587 or Tie Line 678-4587
|> Internet e-mail and Sametime ID: barrettj@us.ibm.com
|>
|>
|>
|> Glen Daniels <glen@thoughtcraft.com>
|> 03/05/2008 12:37 PM
|> Please respond to
|> axis-dev@ws.apache.org
|>
|>
|> To
|> axis-dev@ws.apache.org
|> cc
|>
|> Subject
|> Re: [axis2] [proposal] JIRA AXIS2-3568
|>
|>
|>
|>
|>
|>
|> I'm basically fine with this, since the default MU check happens right
|> before the call to the MessageReceiver anyway.  However, I don't like
|> the "MessageReceiverExtension" name - it's not at all informative IMHO.
|>  How about "MustUnderstandChecker"?  And rather than having the engine
|> do both an instanceof and a method call, can we just do the instanceof?
|>
|>   if (!receiver instanceof MustUnderstandChecker) {
|>     checkMustUnderstand(msgContext);
|>   }
|>   // Just call the MR - if we didn't do the check above,
|>   // you're on your own!
|>
|> Then we make AxisEngine.checkMustUnderstand() public and let the
|> JAXWSMessageReceiver decide whether or not to call it in its receive().
|>
|> Sound OK?
|>
|> --Glen
|>
|> David Illsley wrote:
|>  > This seems like quite a clean solution.
|>  > +1
|>  >
|>  > David
|>  >
|>  > On Wed, Mar 5, 2008 at 10:59 AM, Nikhil V Thaker
|>  > <nikhil.v.thaker@us.ibm.com> wrote:
|>  >> I would like to propose a change to handle certain situations in
|> jaxws
|> where
|>  >> we need to postpone the must understand header check from the
|> AxisEngine to
|>  >> the MessageReceiver. For example, in case of jaxws handler, an
|> application
|>  >> can choose to implement getHeaders() and choose to add valid header
|> qnames
|>  >> in that implementation. A mustUnderstand validation needs to
|> happen for
|> this
|>  >> scenario as described in section 10.2.1 of jaxws specification, in
|> this
|>  >> situation if the jaxws handlers are not loaded, the must understand
|> checks
|>  >> has to be postponed from AxisEngine until the handler are loaded and
|>  >> available in jaxws implementation.
|>  >>
|>  >> Currently all the must understand processing happens in AxisEngine's
|>  >> receive() method, I would like to provide a facility in AxisEngine
|> code
|>  >> where we can choose to delegate MustUnderstand Check to a Message
|> Receiver.
|>  >> I would like to propose addition of a new interface called
|>  >> MessageReceiverExtension in Kernel module which has a method
|>  >> isMustUnderstandCheckPostponed, this new interface will be
|> implemented
|> by
|>  >> JAXWSMessageReceiver and will help in making the runtime decision to
|>  >> postpone must understand check in AxisEngine code.
|>  >>
|>  >> I had made this proposal back in October 08 and here's the link to
|> that
|>  >> email, http://markmail.org/message/zzqgh535slhpmkbz this email has
|> the
|>  >> attachment for original patch. Here is the link to the JIRA issue
|>  >> https://issues.apache.org/jira/browse/AXIS2-3568
|>  >>
|>  >> Nikhil Thaker
|>  >>  office: 512 838 9964
|>  >>  nvthaker@us.ibm.com
|>  >
|>  >
|>  >
|>
|> ---------------------------------------------------------------------
|> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
|> For additional commands, e-mail: axis-dev-help@ws.apache.org
|>
|>
|>
|>
|> ---------------------------------------------------------------------
|> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
|> For additional commands, e-mail: axis-dev-help@ws.apache.org
|>
|>
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
| For additional commands, e-mail: axis-dev-help@ws.apache.org
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)

iD8DBQFHz1VGgNg6eWEDv1kRAvakAJwK35zffUQirNdv4155vKDH6syu9gCguU8E
ZuX09kQ3X8eiCe3qm00+PEU=
=bhPV
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org