Davanum Srinivas wrote:
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 :( :(
This didn't make sense to me at first - I just spoke to dims on IM,
where he explained that there's some bizarre reason that they can only
cross the container boundary into the EJB container (inside which lies
the only source of handler/MU information) once, not twice. So an
approach which would first gather info and then separately receive()
can't work.
So, considering this is just for JAXWS, we can avoid exposing an
explicit plug point like a new interface, and we can just check if the
MessageReceiver's class name is "JAXWSMessageReceiver"... then don't do
the check in AxisEngine.receive() if so.
I'd rather do this than expose a potentially mis-usable plugpoint, I
think....
Sorry about the waffling. :)
--Glen
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
|> [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]
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
iD8DBQFHz1VGgNg6eWEDv1kRAvakAJwK35zffUQirNdv4155vKDH6syu9gCguU8E
ZuX09kQ3X8eiCe3qm00+PEU=
=bhPV
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
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]
