axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From R J Scheuerle Jr <sc...@us.ibm.com>
Subject Re: mustUnderstand header proposal for 1.3 for Fw: [axis2] header processing by !handlers
Date Mon, 02 Jul 2007 18:54:43 GMT





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 <sanjiva@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
>
Mime
View raw message