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 Jeff Barrett <ba...@us.ibm.com> on 2007/07/02 20:34:34 UTC
mustUnderstand header proposal for 1.3 for Fw: [axis2] header processing by
!handlers
Hi All,
I think for 1.3, the JAXWS handler hack will work. Here's my proposal for
1.3 which removes the new API from AxisOperation added in revision 549924
and has a minimal effect on the JAXWS code that is doing the
mustUnderstand validation for SEI header parameters:
1) In modules/kernel, remove the following methods from AxisOperation:
registerUnderstoodHeaderQNames(QName) and getUnderstoodHeaderQNames().
This removes the new API that Sanjiva was concerned about.
2) In modules/metadata, change OperationDesc from using the above
AxisOperation methods to instead set a property on the AxisOperation to
contain the QNames for header parameters.
3) In modules/jaxws, add a new JAXWS handler which will look on the
AxisOperation for the property set in (2) and if found it will mark any
headers with the associated QNames as processed.
4) In modules/kernel AxisEngine, remove the understood-header-processing
logic from checkMustUnderstand and change it back to simply checking for
any headers that are marked mustUnderstand bur are not marked processed.
I will not update axis2.xml to include the handler in (3); that can be
done systems that are integrating Axis2 and JAXWS (such as Geronimo).
For post-1.3, I have a proposal for extensible, pluggable
mustUnderstand-header-validation that solves all the problems we were
discussing, including allowing higher level components to participate in
mustUnderstand checking. I will be sending out that post 1.3 proposal
later on.
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
----- Forwarded by Jeff Barrett/Austin/IBM on 07/02/2007 01:14 PM -----
Jeff Barrett/Austin/IBM
06/28/2007 01:05 PM
To
axis-dev@ws.apache.org
cc
Subject
Re: [axis2] header processing by !handlers
Hi All,
Thanks for all the feedback. I think we need to break this up into two
different threads of discussion:
- What to do in 1.3 (so there are no API changes)
- How to fix this correctly in post 1.3 for all the scenarios (which will
include API changes for headers and roles, plugability, and such)
I'll start a new thread for the post 1.3 discussion.
For the 1.3 discussion, I agree with David Illsley's observation that the
JAXWS-handler approach and marking headers as "processed" even though they
have not been is a "hack". But I also understand Sanjiva's concern about
introducing an API that doesn't necessarily solve all the problems this
close to 1.3. So, I'm thinking through if the JAXWS handler hack will
solve the specific issues my commit (and a few subsequent changes based on
it) was addressing. Assuming it will, I'll post a description of how I
intend to refactor it to remove the API introduced on AxisOperation. This
refactoring will be done under
https://issues.apache.org/jira/browse/AXIS2-2853 , but note that the 1.3
solution will likely not be pluggable, just workable.
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
Sanjiva Weerawarana <sa...@opensource.lk>
06/27/2007 07:44 PM
Please respond to
axis-dev@ws.apache.org
To
axis-dev@ws.apache.org
cc
Subject
Re: [axis2] header processing by !handlers
Glen Daniels wrote:
>
> So we're not going to support <soap:header> in 1.3 either then - or at
> least not completely, in that if someone actually sends us one of the
> headers they specified in the WSDL with MU switched on, we'll barf?
Hmm. Yes I think this is what I'm saying. I believe that's been the case
since Axis1 days right?
> If you're vetoing a commit (which it sounds like you are?), fire away
> with the -1s! However... I'm not entirely sure that "adding a feature
> without discussion" is sufficient technical justification for a -1,
> though. If we were doing review-then-commit, sure, but we're doing
> commit-then-review. What do you think?
I was talking about vetoing a commit on the basis that its not the right
solution and that a better solution needs more fundamental design. I was
avoiding doing it and suggesting that we don't do this feature at this
point.
> Not sure exactly what the right thing here is, but I think I'd prefer to
> leave it in in some form rather than having JAXWS rely on a
> Handler-based mechanism....
Problem is "some form" is not a good model because whatever we put in is
permanent and this is a key API that'd touch a lot including codegen. If
JAX-WS rely on a handler based mechanism for now I'd rather let get go and
talk thru some of the scenarios and figure out the right solution (which
is very likely along the path you suggested).
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
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: mustUnderstand header proposal for 1.3 for Fw: [axis2] header
processing by !handlers
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Thanks Jeff .. +1.
Sanjiva.
Jeff Barrett wrote:
> Hi All,
>
> I think for 1.3, the JAXWS handler hack will work. Here's my proposal for
> 1.3 which removes the new API from AxisOperation added in revision 549924
> and has a minimal effect on the JAXWS code that is doing the
> mustUnderstand validation for SEI header parameters:
>
> 1) In modules/kernel, remove the following methods from AxisOperation:
> registerUnderstoodHeaderQNames(QName) and getUnderstoodHeaderQNames().
> This removes the new API that Sanjiva was concerned about.
>
> 2) In modules/metadata, change OperationDesc from using the above
> AxisOperation methods to instead set a property on the AxisOperation to
> contain the QNames for header parameters.
>
> 3) In modules/jaxws, add a new JAXWS handler which will look on the
> AxisOperation for the property set in (2) and if found it will mark any
> headers with the associated QNames as processed.
>
> 4) In modules/kernel AxisEngine, remove the understood-header-processing
> logic from checkMustUnderstand and change it back to simply checking for
> any headers that are marked mustUnderstand bur are not marked processed.
>
> I will not update axis2.xml to include the handler in (3); that can be
> done systems that are integrating Axis2 and JAXWS (such as Geronimo).
>
> For post-1.3, I have a proposal for extensible, pluggable
> mustUnderstand-header-validation that solves all the problems we were
> discussing, including allowing higher level components to participate in
> mustUnderstand checking. I will be sending out that post 1.3 proposal
> later on.
>
> 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
> ----- Forwarded by Jeff Barrett/Austin/IBM on 07/02/2007 01:14 PM -----
>
> Jeff Barrett/Austin/IBM
> 06/28/2007 01:05 PM
>
> To
> axis-dev@ws.apache.org
> cc
>
> Subject
> Re: [axis2] header processing by !handlers
>
>
>
>
>
> Hi All,
>
> Thanks for all the feedback. I think we need to break this up into two
> different threads of discussion:
> - What to do in 1.3 (so there are no API changes)
> - How to fix this correctly in post 1.3 for all the scenarios (which will
> include API changes for headers and roles, plugability, and such)
>
> I'll start a new thread for the post 1.3 discussion.
>
> For the 1.3 discussion, I agree with David Illsley's observation that the
> JAXWS-handler approach and marking headers as "processed" even though they
> have not been is a "hack". But I also understand Sanjiva's concern about
> introducing an API that doesn't necessarily solve all the problems this
> close to 1.3. So, I'm thinking through if the JAXWS handler hack will
> solve the specific issues my commit (and a few subsequent changes based on
> it) was addressing. Assuming it will, I'll post a description of how I
> intend to refactor it to remove the API introduced on AxisOperation. This
> refactoring will be done under
> https://issues.apache.org/jira/browse/AXIS2-2853 , but note that the 1.3
> solution will likely not be pluggable, just workable.
>
> 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
>
>
>
> Sanjiva Weerawarana <sa...@opensource.lk>
> 06/27/2007 07:44 PM
> Please respond to
> axis-dev@ws.apache.org
>
>
> To
> axis-dev@ws.apache.org
> cc
>
> Subject
> Re: [axis2] header processing by !handlers
>
>
>
>
>
>
> Glen Daniels wrote:
>> So we're not going to support <soap:header> in 1.3 either then - or at
>> least not completely, in that if someone actually sends us one of the
>> headers they specified in the WSDL with MU switched on, we'll barf?
>
> Hmm. Yes I think this is what I'm saying. I believe that's been the case
> since Axis1 days right?
>
>> If you're vetoing a commit (which it sounds like you are?), fire away
>> with the -1s! However... I'm not entirely sure that "adding a feature
>> without discussion" is sufficient technical justification for a -1,
>> though. If we were doing review-then-commit, sure, but we're doing
>> commit-then-review. What do you think?
>
> I was talking about vetoing a commit on the basis that its not the right
> solution and that a better solution needs more fundamental design. I was
> avoiding doing it and suggesting that we don't do this feature at this
> point.
>
>> Not sure exactly what the right thing here is, but I think I'd prefer to
>
>> leave it in in some form rather than having JAXWS rely on a
>> Handler-based mechanism....
>
> Problem is "some form" is not a good model because whatever we put in is
> permanent and this is a key API that'd touch a lot including codegen. If
> JAX-WS rely on a handler based mechanism for now I'd rather let get go and
>
> talk thru some of the scenarios and figure out the right solution (which
> is very likely along the path you suggested).
>
> Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: mustUnderstand header proposal for 1.3 for Fw: [axis2] header processing by !handlers
Posted by David Illsley <da...@gmail.com>.
Sounds good.
+1
David
On 02/07/07, Davanum Srinivas <da...@gmail.com> wrote:
> +1 from me.
>
> -- dims
>
> On 7/2/07, R J Scheuerle Jr <sc...@us.ibm.com> wrote:
> >
> >
> > Thanks Jeff,
> >
> > Sound like a good plan to me.
> >
> > Rich Scheuerle
> >
> > Jeff Barrett/Austin/IBM@IBMUS wrote on 07/02/2007 01:34:34 PM:
> >
> > > Hi All,
> > >
> > > I think for 1.3, the JAXWS handler hack will work. Here's my proposal
> > for
> > > 1.3 which removes the new API from AxisOperation added in revision 549924
> > > and has a minimal effect on the JAXWS code that is doing the
> > > mustUnderstand validation for SEI header parameters:
> > >
> > > 1) In modules/kernel, remove the following methods from AxisOperation:
> > > registerUnderstoodHeaderQNames(QName) and
> > getUnderstoodHeaderQNames().
> > > This removes the new API that Sanjiva was concerned about.
> > >
> > > 2) In modules/metadata, change OperationDesc from using the above
> > > AxisOperation methods to instead set a property on the AxisOperation to
> > > contain the QNames for header parameters.
> > >
> > > 3) In modules/jaxws, add a new JAXWS handler which will look on the
> > > AxisOperation for the property set in (2) and if found it will mark any
> > > headers with the associated QNames as processed.
> > >
> > > 4) In modules/kernel AxisEngine, remove the understood-header-processing
> > > logic from checkMustUnderstand and change it back to simply checking for
> > > any headers that are marked mustUnderstand bur are not marked processed.
> > >
> > > I will not update axis2.xml to include the handler in (3); that can be
> > > done systems that are integrating Axis2 and JAXWS (such as Geronimo).
> > >
> > > For post-1.3, I have a proposal for extensible, pluggable
> > > mustUnderstand-header-validation that solves all the
> > problems we were
> > > discussing, including allowing higher level components to participate in
> > > mustUnderstand checking. I will be sending out that post 1.3 proposal
> > > later on.
> > >
> > > 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
> > > ----- Forwarded by Jeff Barrett/Austin/IBM on 07/02/2007 01:14 PM -----
> > >
> > > Jeff Barrett/Austin/IBM
> > > 06/28/2007 01:05 PM
> > >
> > > To
> > > axis-dev@ws.apache.org
> > > cc
> > >
> > > Subject
> > > Re: [axis2] header processing by !handlers
> > >
> > >
> > >
> > >
> > >
> > > Hi All,
> > >
> > > Thanks for all the feedback. I think we need to break this up into two
> > > different threads of discussion:
> > > - What to do in 1.3 (so there are no API changes)
> > > - How to fix this correctly in post 1.3 for all the scenarios (which will
> > > include API changes for headers and roles, plugability, and such)
> > >
> > > I'll start a new thread for the post 1.3 discussion.
> > >
> > > For the 1.3 discussion, I agree with David Illsley's observation that the
> > > JAXWS-handler approach and marking headers as "processed" even though
> > they
> > > have not been is a "hack". But I also understand Sanjiva's concern about
> > > introducing an API that doesn't necessarily solve all the problems this
> > > close to 1.3. So, I'm thinking through if the JAXWS handler hack will
> > > solve the specific issues my commit (and a few subsequent changes based
> > on
> > > it) was addressing. Assuming it will, I'll post a description of how I
> > > intend to refactor it to remove the API introduced on AxisOperation.
> > This
> > > refactoring will be done under
> > > https://issues.apache.org/jira/browse/AXIS2-2853 , but
> > note that the 1.3
> > > solution will likely not be pluggable, just workable.
> > >
> > > 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
> > >
> > >
> > >
> > > Sanjiva Weerawarana <sa...@opensource.lk>
> > > 06/27/2007 07:44 PM
> > > Please respond to
> > > axis-dev@ws.apache.org
> > >
> > >
> > > To
> > > axis-dev@ws.apache.org
> > > cc
> > >
> > > Subject
> > > Re: [axis2] header processing by !handlers
> > >
> > >
> > >
> > >
> > >
> > >
> > > Glen Daniels wrote:
> > > >
> > > > So we're not going to support <soap:header> in 1.3 either then - or at
> > > > least not completely, in that if someone actually sends us one of the
> > > > headers they specified in the WSDL with MU switched on, we'll barf?
> > >
> > > Hmm. Yes I think this is what I'm saying. I believe that's been the case
> > > since Axis1 days right?
> > >
> > > > If you're vetoing a commit (which it sounds like you are?), fire away
> > > > with the -1s! However... I'm not entirely sure that "adding a feature
> > > > without discussion" is sufficient technical justification for a -1,
> > > > though. If we were doing review-then-commit, sure, but we're doing
> > > > commit-then-review. What do you think?
> > >
> > > I was talking about vetoing a commit on the basis that its not the right
> > > solution and that a better solution needs more fundamental design. I was
> > > avoiding doing it and suggesting that we don't do this feature at this
> > > point.
> > >
> > > > Not sure exactly what the right thing here is, but I think I'd prefer
> > to
> > >
> > > > leave it in in some form rather than having JAXWS rely on a
> > > > Handler-based mechanism....
> > >
> > > Problem is "some form" is not a good model because whatever we put in is
> > > permanent and this is a key API that'd touch a lot including codegen. If
> > > JAX-WS rely on a handler based mechanism for now I'd rather let get go
> > and
> > >
> > > talk thru some of the scenarios and figure out the right solution (which
> > > is very likely along the path you suggested).
> > >
> > > Sanjiva.
> > > --
> > > Sanjiva Weerawarana, Ph.D.
> > > Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> > > Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> > > Director; Open Source Initiative; http://www.opensource.org/
> > > Member; Apache Software Foundation; http://www.apache.org/
> > > Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
> > >
> > >
> > ---------------------------------------------------------------------
> > > 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
> > >
> >
>
>
> --
> Davanum Srinivas :: http://davanum.wordpress.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-dev-help@ws.apache.org
>
>
--
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: mustUnderstand header proposal for 1.3 for Fw: [axis2] header processing by !handlers
Posted by Davanum Srinivas <da...@gmail.com>.
+1 from me.
-- dims
On 7/2/07, R J Scheuerle Jr <sc...@us.ibm.com> wrote:
>
>
> Thanks Jeff,
>
> Sound like a good plan to me.
>
> Rich Scheuerle
>
> Jeff Barrett/Austin/IBM@IBMUS wrote on 07/02/2007 01:34:34 PM:
>
> > Hi All,
> >
> > I think for 1.3, the JAXWS handler hack will work. Here's my proposal
> for
> > 1.3 which removes the new API from AxisOperation added in revision 549924
> > and has a minimal effect on the JAXWS code that is doing the
> > mustUnderstand validation for SEI header parameters:
> >
> > 1) In modules/kernel, remove the following methods from AxisOperation:
> > registerUnderstoodHeaderQNames(QName) and
> getUnderstoodHeaderQNames().
> > This removes the new API that Sanjiva was concerned about.
> >
> > 2) In modules/metadata, change OperationDesc from using the above
> > AxisOperation methods to instead set a property on the AxisOperation to
> > contain the QNames for header parameters.
> >
> > 3) In modules/jaxws, add a new JAXWS handler which will look on the
> > AxisOperation for the property set in (2) and if found it will mark any
> > headers with the associated QNames as processed.
> >
> > 4) In modules/kernel AxisEngine, remove the understood-header-processing
> > logic from checkMustUnderstand and change it back to simply checking for
> > any headers that are marked mustUnderstand bur are not marked processed.
> >
> > I will not update axis2.xml to include the handler in (3); that can be
> > done systems that are integrating Axis2 and JAXWS (such as Geronimo).
> >
> > For post-1.3, I have a proposal for extensible, pluggable
> > mustUnderstand-header-validation that solves all the
> problems we were
> > discussing, including allowing higher level components to participate in
> > mustUnderstand checking. I will be sending out that post 1.3 proposal
> > later on.
> >
> > 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
> > ----- Forwarded by Jeff Barrett/Austin/IBM on 07/02/2007 01:14 PM -----
> >
> > Jeff Barrett/Austin/IBM
> > 06/28/2007 01:05 PM
> >
> > To
> > axis-dev@ws.apache.org
> > cc
> >
> > Subject
> > Re: [axis2] header processing by !handlers
> >
> >
> >
> >
> >
> > Hi All,
> >
> > Thanks for all the feedback. I think we need to break this up into two
> > different threads of discussion:
> > - What to do in 1.3 (so there are no API changes)
> > - How to fix this correctly in post 1.3 for all the scenarios (which will
> > include API changes for headers and roles, plugability, and such)
> >
> > I'll start a new thread for the post 1.3 discussion.
> >
> > For the 1.3 discussion, I agree with David Illsley's observation that the
> > JAXWS-handler approach and marking headers as "processed" even though
> they
> > have not been is a "hack". But I also understand Sanjiva's concern about
> > introducing an API that doesn't necessarily solve all the problems this
> > close to 1.3. So, I'm thinking through if the JAXWS handler hack will
> > solve the specific issues my commit (and a few subsequent changes based
> on
> > it) was addressing. Assuming it will, I'll post a description of how I
> > intend to refactor it to remove the API introduced on AxisOperation.
> This
> > refactoring will be done under
> > https://issues.apache.org/jira/browse/AXIS2-2853 , but
> note that the 1.3
> > solution will likely not be pluggable, just workable.
> >
> > 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
> >
> >
> >
> > Sanjiva Weerawarana <sa...@opensource.lk>
> > 06/27/2007 07:44 PM
> > Please respond to
> > axis-dev@ws.apache.org
> >
> >
> > To
> > axis-dev@ws.apache.org
> > cc
> >
> > Subject
> > Re: [axis2] header processing by !handlers
> >
> >
> >
> >
> >
> >
> > Glen Daniels wrote:
> > >
> > > So we're not going to support <soap:header> in 1.3 either then - or at
> > > least not completely, in that if someone actually sends us one of the
> > > headers they specified in the WSDL with MU switched on, we'll barf?
> >
> > Hmm. Yes I think this is what I'm saying. I believe that's been the case
> > since Axis1 days right?
> >
> > > If you're vetoing a commit (which it sounds like you are?), fire away
> > > with the -1s! However... I'm not entirely sure that "adding a feature
> > > without discussion" is sufficient technical justification for a -1,
> > > though. If we were doing review-then-commit, sure, but we're doing
> > > commit-then-review. What do you think?
> >
> > I was talking about vetoing a commit on the basis that its not the right
> > solution and that a better solution needs more fundamental design. I was
> > avoiding doing it and suggesting that we don't do this feature at this
> > point.
> >
> > > Not sure exactly what the right thing here is, but I think I'd prefer
> to
> >
> > > leave it in in some form rather than having JAXWS rely on a
> > > Handler-based mechanism....
> >
> > Problem is "some form" is not a good model because whatever we put in is
> > permanent and this is a key API that'd touch a lot including codegen. If
> > JAX-WS rely on a handler based mechanism for now I'd rather let get go
> and
> >
> > talk thru some of the scenarios and figure out the right solution (which
> > is very likely along the path you suggested).
> >
> > Sanjiva.
> > --
> > Sanjiva Weerawarana, Ph.D.
> > Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> > Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> > Director; Open Source Initiative; http://www.opensource.org/
> > Member; Apache Software Foundation; http://www.apache.org/
> > Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
> >
> >
> ---------------------------------------------------------------------
> > 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
> >
>
--
Davanum Srinivas :: http://davanum.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
Re: mustUnderstand header proposal for 1.3 for Fw: [axis2] header
processing by !handlers
Posted by R J Scheuerle Jr <sc...@us.ibm.com>.
Thanks Jeff,
Sound like a good plan to me.
Rich Scheuerle
Jeff Barrett/Austin/IBM@IBMUS wrote on 07/02/2007 01:34:34 PM:
> Hi All,
>
> I think for 1.3, the JAXWS handler hack will work. Here's my proposal
for
> 1.3 which removes the new API from AxisOperation added in revision 549924
> and has a minimal effect on the JAXWS code that is doing the
> mustUnderstand validation for SEI header parameters:
>
> 1) In modules/kernel, remove the following methods from AxisOperation:
> registerUnderstoodHeaderQNames(QName) and getUnderstoodHeaderQNames().
> This removes the new API that Sanjiva was concerned about.
>
> 2) In modules/metadata, change OperationDesc from using the above
> AxisOperation methods to instead set a property on the AxisOperation to
> contain the QNames for header parameters.
>
> 3) In modules/jaxws, add a new JAXWS handler which will look on the
> AxisOperation for the property set in (2) and if found it will mark any
> headers with the associated QNames as processed.
>
> 4) In modules/kernel AxisEngine, remove the understood-header-processing
> logic from checkMustUnderstand and change it back to simply checking for
> any headers that are marked mustUnderstand bur are not marked processed.
>
> I will not update axis2.xml to include the handler in (3); that can be
> done systems that are integrating Axis2 and JAXWS (such as Geronimo).
>
> For post-1.3, I have a proposal for extensible, pluggable
> mustUnderstand-header-validation that solves all the problems we were
> discussing, including allowing higher level components to participate in
> mustUnderstand checking. I will be sending out that post 1.3 proposal
> later on.
>
> 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
> ----- Forwarded by Jeff Barrett/Austin/IBM on 07/02/2007 01:14 PM -----
>
> Jeff Barrett/Austin/IBM
> 06/28/2007 01:05 PM
>
> To
> axis-dev@ws.apache.org
> cc
>
> Subject
> Re: [axis2] header processing by !handlers
>
>
>
>
>
> Hi All,
>
> Thanks for all the feedback. I think we need to break this up into two
> different threads of discussion:
> - What to do in 1.3 (so there are no API changes)
> - How to fix this correctly in post 1.3 for all the scenarios (which will
> include API changes for headers and roles, plugability, and such)
>
> I'll start a new thread for the post 1.3 discussion.
>
> For the 1.3 discussion, I agree with David Illsley's observation that the
> JAXWS-handler approach and marking headers as "processed" even though
they
> have not been is a "hack". But I also understand Sanjiva's concern about
> introducing an API that doesn't necessarily solve all the problems this
> close to 1.3. So, I'm thinking through if the JAXWS handler hack will
> solve the specific issues my commit (and a few subsequent changes based
on
> it) was addressing. Assuming it will, I'll post a description of how I
> intend to refactor it to remove the API introduced on AxisOperation.
This
> refactoring will be done under
> https://issues.apache.org/jira/browse/AXIS2-2853 , but note that the 1.3
> solution will likely not be pluggable, just workable.
>
> 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
>
>
>
> Sanjiva Weerawarana <sa...@opensource.lk>
> 06/27/2007 07:44 PM
> Please respond to
> axis-dev@ws.apache.org
>
>
> To
> axis-dev@ws.apache.org
> cc
>
> Subject
> Re: [axis2] header processing by !handlers
>
>
>
>
>
>
> Glen Daniels wrote:
> >
> > So we're not going to support <soap:header> in 1.3 either then - or at
> > least not completely, in that if someone actually sends us one of the
> > headers they specified in the WSDL with MU switched on, we'll barf?
>
> Hmm. Yes I think this is what I'm saying. I believe that's been the case
> since Axis1 days right?
>
> > If you're vetoing a commit (which it sounds like you are?), fire away
> > with the -1s! However... I'm not entirely sure that "adding a feature
> > without discussion" is sufficient technical justification for a -1,
> > though. If we were doing review-then-commit, sure, but we're doing
> > commit-then-review. What do you think?
>
> I was talking about vetoing a commit on the basis that its not the right
> solution and that a better solution needs more fundamental design. I was
> avoiding doing it and suggesting that we don't do this feature at this
> point.
>
> > Not sure exactly what the right thing here is, but I think I'd prefer
to
>
> > leave it in in some form rather than having JAXWS rely on a
> > Handler-based mechanism....
>
> Problem is "some form" is not a good model because whatever we put in is
> permanent and this is a key API that'd touch a lot including codegen. If
> JAX-WS rely on a handler based mechanism for now I'd rather let get go
and
>
> talk thru some of the scenarios and figure out the right solution (which
> is very likely along the path you suggested).
>
> Sanjiva.
> --
> Sanjiva Weerawarana, Ph.D.
> Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
> Director; Open Source Initiative; http://www.opensource.org/
> Member; Apache Software Foundation; http://www.apache.org/
> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/
>
> ---------------------------------------------------------------------
> 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
>