+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]
