axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Barrett <>
Subject Re: [axis2] header processing by !handlers
Date Thu, 28 Jun 2007 18:05:02 GMT
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 , but note that the 1.3 
solution will likely not be pluggable, just workable.


IBM Software Group - WebSphere Web Services Development
Phone: 512-838-4587 or Tie Line 678-4587
Internet e-mail and Sametime ID:

Sanjiva Weerawarana <> 
06/27/2007 07:44 PM
Please respond to


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 

> 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 Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation;
Founder, Chairman & CEO; WSO2, Inc.;
Director; Open Source Initiative;
Member; Apache Software Foundation;
Visiting Lecturer; University of Moratuwa;

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message