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]
