Glenn - This is very close to what we have in the patch. In the patch we only push faulty Header QNames as a list to perform mustUnderstand check later on. The difference here is that in the current solution we don't do the MU check in MessageReceiverExtension (MustUndertandChecker from previous note) but use MRE to only make a decision if we want to pospone the check on faulty HeaderNames. We then trigger the MU check on faulty QNames from EndpointController after handler getHeaders() is invoked.
If we want to implement this solution, then I rather use MessageReceiverExtension just to make decision if we want to pospone the MU check and trigger the check after the Handler's have provided new header qNames i.e after invocation of getHeaders(). This means we always do MU check in AxisEngine.receive() and if there are faulty headers we check them after Handlers are invoked as per JAXWS specification. Make sense? Nikhil Thaker office: 512 838 9964 [EMAIL PROTECTED] Glen Daniels <[EMAIL PROTECTED]> 03/05/2008 07:41 PM Please respond to [email protected] To [email protected] cc Subject Re: [axis2] [proposal] JIRA AXIS2-3568 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 > [EMAIL PROTECTED] > > > *Jeff Barrett/Austin/[EMAIL PROTECTED] > > 03/05/2008 01:57 PM > Please respond to > [email protected] > > > > To > [email protected] > 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: [EMAIL PROTECTED] > > > > Glen Daniels <[EMAIL PROTECTED]> > 03/05/2008 12:37 PM > Please respond to > [email protected] > > > To > [email protected] > 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 > > <[EMAIL PROTECTED]> 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 > >> [EMAIL PROTECTED] > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
