You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Nikhil V Thaker <ni...@us.ibm.com> on 2008/03/05 17:59:11 UTC
[axis2] [proposal] JIRA AXIS2-3568
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
Re: [axis2] [proposal] JIRA AXIS2-3568
Posted by Deepal jayasinghe <de...@gmail.com>.
Glen Daniels wrote:
> 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?
To be honest I hate doing API changes now :) , so I am sorry I do not
like to add a new method to MR interface.
Thank you,
Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] [proposal] JIRA AXIS2-3568
Posted by Glen Daniels <gl...@thoughtcraft.com>.
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
> |> 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 <gl...@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
> |> > <ni...@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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] [proposal] JIRA AXIS2-3568
Posted by Davanum Srinivas <da...@gmail.com>.
-----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 <gl...@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
|> > <ni...@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
Re: [axis2] [proposal] JIRA AXIS2-3568
Posted by Nikhil V Thaker <ni...@us.ibm.com>.
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
nvthaker@us.ibm.com
Glen Daniels <gl...@thoughtcraft.com>
03/05/2008 07:41 PM
Please respond to
axis-dev@ws.apache.org
To
axis-dev@ws.apache.org
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
> 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 <gl...@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
> > <ni...@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
Re: [axis2] [proposal] JIRA AXIS2-3568
Posted by Glen Daniels <gl...@thoughtcraft.com>.
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 <gl...@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
> > <ni...@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
Re: [axis2] [proposal] JIRA AXIS2-3568
Posted by Nikhil V Thaker <ni...@us.ibm.com>.
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 <gl...@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
> <ni...@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
Re: [axis2] [proposal] JIRA AXIS2-3568
Posted by Jeff Barrett <ba...@us.ibm.com>.
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 <gl...@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
> <ni...@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
Re: [axis2] [proposal] JIRA AXIS2-3568
Posted by Glen Daniels <gl...@thoughtcraft.com>.
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
> <ni...@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
Re: [axis2] [proposal] JIRA AXIS2-3568
Posted by Davanum Srinivas <da...@gmail.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
+1 from me.
Dustin Amrhein wrote:
| +1
|
| Dustin Amrhein
|
| David Illsley <da...@gmail.com> wrote: This seems like quite a clean solution.
| +1
|
| David
|
| On Wed, Mar 5, 2008 at 10:59 AM, Nikhil V Thaker
| 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
|
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
iD8DBQFHzuC+gNg6eWEDv1kRAmCNAKC34fuqCTAANC13H9RkHeC5iQpeuwCfXUfs
LaXRXcHFPHwBzhzxiAFsoyY=
=zbYs
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] [proposal] JIRA AXIS2-3568
Posted by Dustin Amrhein <da...@yahoo.com>.
+1
Dustin Amrhein
David Illsley <da...@gmail.com> wrote: This seems like quite a clean solution.
+1
David
On Wed, Mar 5, 2008 at 10:59 AM, Nikhil V Thaker
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
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
Re: [axis2] [proposal] JIRA AXIS2-3568
Posted by David Illsley <da...@gmail.com>.
This seems like quite a clean solution.
+1
David
On Wed, Mar 5, 2008 at 10:59 AM, Nikhil V Thaker
<ni...@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
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] [proposal] JIRA AXIS2-3568
Posted by Davanum Srinivas <da...@gmail.com>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Deepal,
Please catch me on IM, i will walk thru the scenario again, i think you may have missed a few points in the JIRA and the
email thread.
thanks,
dims
Deepal jayasinghe 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.
| Well I am not going to agree on this , since MR is something that people
| can write and plug so adding must understand checking into custom code
| is not a good idea. Any way must understand checking happen just before
| calling the MR ,so to solve the problem you can add a handler just
| before the MR and do you logic processing. So I am not going to +1 for
| this change.
|> 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.
| We can easily fixed this by adding a handler as I mention above , so we
| do not need this new Interface.
|
|
| Thank you,
| Deepal
|
| ---------------------------------------------------------------------
| 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)
iD8DBQFH0UiHgNg6eWEDv1kRAs/kAJ9jWBod6k50KXMh+Rfa0I0jHn0g/gCeMSUB
8zgdEhqfGo8XREasibH/Qqo=
=xBh/
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: [axis2] [proposal] JIRA AXIS2-3568
Posted by Deepal jayasinghe <de...@gmail.com>.
>
> 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.
Well I am not going to agree on this , since MR is something that people
can write and plug so adding must understand checking into custom code
is not a good idea. Any way must understand checking happen just before
calling the MR ,so to solve the problem you can add a handler just
before the MR and do you logic processing. So I am not going to +1 for
this change.
> 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.
We can easily fixed this by adding a handler as I mention above , so we
do not need this new Interface.
Thank you,
Deepal
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org