Sounds good.
+1
David
On 02/07/07, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
+1 from me.
-- dims
On 7/2/07, R J Scheuerle Jr <[EMAIL PROTECTED]> wrote:
>
>
> Thanks Jeff,
>
> Sound like a good plan to me.
>
> Rich Scheuerle
>
> Jeff Barrett/Austin/[EMAIL PROTECTED] 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: [EMAIL PROTECTED]
> > ----- Forwarded by Jeff Barrett/Austin/IBM on 07/02/2007 01:14 PM -----
> >
> > Jeff Barrett/Austin/IBM
> > 06/28/2007 01:05 PM
> >
> > To
> > [email protected]
> > 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: [EMAIL PROTECTED]
> >
> >
> >
> > Sanjiva Weerawarana <[EMAIL PROTECTED]>
> > 06/27/2007 07:44 PM
> > Please respond to
> > [email protected]
> >
> >
> > To
> > [email protected]
> > 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:
> [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
--
Davanum Srinivas :: http://davanum.wordpress.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
David Illsley - IBM Web Services Development
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
