[axis2] IRC conversation re: pluggable MU checking

[Glen Daniels <gl...@thoughtcraft.com>]

Here's today's IRC conversation for the archives.

[10:53] * Now talking in #apache-axis
[10:53] * Topic is 'Axis2 1.3 release discussion'
[10:53] * Set by Deepal on Thu Jun 28 03:41:15
[10:56] <gdaniels> *wave*
[10:57] <barrettj> Howdy Glen
[10:57] <gdaniels> heya Jeff
[10:57] <barrettj> I just responded to your note.  Could you take a 
look, and then we can discuss it here?
[10:57] <gdaniels> yep
[10:57] <barrettj> Thanks.
[10:57] <gdaniels> Hm - I think you're having a somewhat limited view of 
what a Handler does.
[10:58] <gdaniels> handlers can log stuff
[10:58] <gdaniels> handlers can just look at and set properties
[10:58] <gdaniels> handlers can spawn off other messages
[10:58] <gdaniels> etc.
[10:58] <gdaniels> I also think you're stuck on the "processed" flag's name
[10:58] <gdaniels> in reality, the "processed" flag is ONLY used by the 
MU checking logic
[10:59] <gdaniels> thus it's semantic is really "understood" anyway
[10:59] <gdaniels> no?
[10:59] <barrettj> Actually, it seemed like it was a useful semantic in 
that another handler may care if a header had been previously processed.
[11:00] <gdaniels> nobody does that though
[11:00] <barrettj> i.e. I'm a security handler, and somebody already 
marked the header I was expecting as processed.
[11:01] <gdaniels> yup - I can see that, but we don't use it that way. 
Typically that stuff (inter handler coordination) is handled by 
particular MC properties
[11:01] <gdaniels> I do my work, set the "myHandler.result" property to 
whatever value, and then some other handler can see that I've done stuff 
by noticing that value is present
[11:02] <gdaniels> the processed flag is (currently) used precisely to 
indicate if a header was understood
[11:02] <gdaniels> we called it "processed" because Axis (and Axis2) 
tends to have a "do work first then roll back if there was a problem" 
pattern
[11:03] <gdaniels> so since the MU check happens *after* the handlers 
run, we check to see if a header was "processed"
[11:03] <gdaniels> but in fact all "processed" means is that some 
Handler said "ok, I don't want a MU fault to happen on this one because 
I take responsibility for it"
[11:06] <gdaniels> make sense?
[11:07] <barrettj> I understand what you're saying, but I'm not sure I 
agree with that being a better way than the plugin checkers...
[11:08] <barrettj> The plugin checkers are given the list of headers for 
the roles the engine is in...
[11:08] <gdaniels> using what we've got not being better than 
introducing a whole new system of components and callouts?  Seriously?
[11:08] <barrettj> After all the handlers have had a chance to mark 
headers they have processed as processed.
[11:09] <gdaniels> that's the way it works now (before the plugin thing)
[11:09] <gdaniels> except the engine needs a role config mechanism
[11:09] <gdaniels> the engine says "give me all the headers targeted at me"
[11:09] <gdaniels> and then checks the processed bit
[11:10] <gdaniels> thus if anyone has set the processed bit on a header 
"for me", that is considered understood
[11:11] <barrettj> Looking up something ...
[11:11] <gdaniels> ok
[11:11] <gdaniels> in the meanwhile let me quickly summarize again my POV
[11:12] <gdaniels> I really don't like adding another plugin/component 
mechanism because I think it needlessly complicates things that could 
perfectly well (and are in fact) be done by handlers
[11:12] <gdaniels> I would like to see a declarative mechanism added 
too, so that particular QNames can simply be registered to operations, 
for instance
[11:13] <gdaniels> and I think that we clearly need to deal with roles, 
which I think should also both be configurable in services.xml/axis2.xml 
and controllable via an API
[11:13] <barrettj> I agree with roles.
[11:13] <gdaniels> <EOM> :)
[11:15] <barrettj> I don't have the Axiom code handy, does isProcessed 
say it is for mustUnderstand indications?
[11:17] <barrettj> Never mind, I found the code.
[11:17] <gdaniels> you mean in the "JavaDoc"? :)
[11:17] <gdaniels> hahahahahahahahaa
[11:17] <gdaniels> oh dear, sorry
[11:17] <gdaniels> my sarcasm got the best of me.
[11:18] <barrettj> :-)
[11:18] <gdaniels> it actually does, though
[11:18] <gdaniels> on setProcessed()
[11:18] <barrettj> The javadoc for setProcessed says things like "have 
been processed"
[11:19] <gdaniels> but it talks about that specifically in the context 
of MU handling
[11:19] <gdaniels> obviously we could go back and forth on this one in 
terms of interpretation.
[11:19] <gdaniels> I'd rather talk about a) what really happens now, and 
b) what's the RIGHT thing
[11:20] <gdaniels> WRT (a), I don't know of a single use of the 
processed flag in Axis1 or Axis2 that isn't simply about MU
[11:22] <barrettj> If others can plug in handlers, my concern would be 
that they may have interpreted isProcessed as the name implies - that 
the header is processed.
[11:22] <barrettj> If so, then this becomes an API change.
[11:24] <gdaniels> we could certainly ask on axis-user
[11:24] <gdaniels> and I'd be ok with (although wouldn't love) adding 
isUnderstood() as a separate thing
[11:25] <gdaniels> or replacing isProcessed with isUnderstood
[11:25] <gdaniels> which I'd be fine with
[11:26] <barrettj> I thought about adding isUnderstood.
[11:26] <barrettj> The advantage to the plugin is that it is only handed 
the list of headers that are going to be checked.
[11:27] <gdaniels> you mean filtered by roles
[11:27] <barrettj> Yes.  I'm still having trouble with a handler that 
doesn't affect the message at this point doing anything to that message. 
  I like the manipulation of a list that will be checked.
[11:28] <barrettj> I also like that it plugs in after all the handlers 
have run and had a crack at the message.
[11:28] <gdaniels> this is a somewhat tricky area to think about, in 
that it depends on interpretation
[11:29] <gdaniels> to me, setting processed (the way it is now, which 
I'm asserting == isUnderstood) doesn't really change the message
[11:29] <gdaniels> of course it does change the state, but not like 
changing the data
[11:29] <gdaniels> it just flips a "yes I understand this" bit
[11:30] <gdaniels> and I see no problem at all with a component 
collaborating with another component down the line - it sets the bit 
because it knows the other component understands the header
[11:30] <gdaniels> back to roles - we need to deal with that anyway
[11:30] <barrettj> We agree on that :-)
[11:30] <barrettj> Just not how to implement it.
[11:31] <gdaniels> we need to make all the modules role-sensitive at 
some point
[11:32] <dims> hi all
[11:32] <gdaniels> i.e. I want to be able to deploy Rampart such that it 
only runs for headers targeted at "http://roles.com/securityManager"
[11:32] <gdaniels> hey dims!
[11:33] <barrettj> Howdy dims.
[11:33] <gdaniels> (please read back in your buffer to catch up if 
interested :))
[11:33] <dims> reading
[11:34] <dims> gdaniels: getting my head straight...is there an 
alternate proposal on the table?
[11:34] <dims> i can understand "this is not the right way to do it"
[11:35] <dims> we need something we can get out for 1.3 (or 1.3+delta) 
which serves the JAXWS use case.
[11:36] <dims> anything that serves that purpose, gets my vote
[11:36] <gdaniels> alternate proposal is essentially "use Handlers" and 
I would also propose putting back the very simple and IMHO appropriate 
declarative API on AxisOperation that Jeff had before
[11:37] <gdaniels> putting a Handler right before the MessageReceiver 
can do the same thing (in fact it's more flexible) as YACPA
[11:37] <barrettj> Declarative API doesn't solve all the use cases, though.
[11:37] <dims> gdaniels: did you see the dynamic use case that jeff 
outlined? nothing is known till the service is deployed
[11:37] <dims> yep
[11:38] <dims> if we can get CTS passing with that new proposed code, i 
am all for it
[11:38] <dims> but IMHO, it's not enough for all use cases
[11:38] <dims> in JAXWS
[11:38] <barrettj> Because the plugins only get the headers for the 
current roles, it actually solves another issue in JAXWS CTS.
[11:39] <dims> gdaniels: seen the TransportResolver YACPA?
[11:39] <gdaniels> we need to solve that issue ANYWAY
[11:39] <barrettj> That is, with the plugin checkers, I think we will 
solve all the JAXWS compliance issues, and we solve the dynamic use case.
[11:40] <gdaniels> Let's go through the dynamic use case, ok?
[11:40] <gdaniels> Jeff, can you walk us through it?
[11:40] <barrettj> Sure ...
[11:40] <gdaniels> Then we can both propose solutions
[11:41] <barrettj> Axis2 is plugged in as the engine for a higher level 
component.  I think David Illsley mentioned an ESB.  There are others.
[11:41] <gdaniels> ok
[11:41] <gdaniels> for that one, you're interested in something that 
says "don't do MU checking because I'll handle it"
[11:41] <gdaniels> right?
[11:41] <gdaniels> (i.e. "everything is understood")
[11:43] <gdaniels> ?
[11:43] <barrettj> Yes.  Although having the flexibility to say not 
remove certain headers (e.g. security) that you know should be processed 
by middleware components would be better.
[11:44] <barrettj> And, not effecting headers outside the role the 
engine is acting is would be best.
[11:44] <gdaniels> Let me state this clearly - we need to solve the role 
problem regardless
[11:44] <gdaniels> there are certain roles that Axis2 is acting in at 
any given time
[11:44] <gdaniels> and typically ONLY headers targeted at those roles 
should be affected by any of thig
[11:44] <gdaniels> this
[11:45] <gdaniels> we ALREADY work this way but only for 
next/ultimateDestination - there's not a way to configure other roles yet
[11:45] <barrettj> Yup
[11:45] <gdaniels> actually let me amend that - we work that way when MU 
checking
[11:45] <barrettj> Given the mustHeader checks
[11:45] <barrettj> Exactly.
[11:46] <gdaniels> it's up to the individual Handlers to get headers in 
a role-sensitive way
[11:46] <gdaniels> the problem there is that Axiom doesn't know about 
MessageContexts
[11:46] <barrettj> By pluggin in directly to the mustUnderstand checks, 
we get exactly the headers the engine thinks it needs to check.
[11:46] <gdaniels> so there isn't an easy place to just drop in a list 
of active roles
[11:46] <gdaniels> no, Jeff, I'm talking about actual processing of the 
headers
[11:46] <gdaniels> the MU check already works this way
[11:47] <barrettj> I understand that.  I'm saying by plugging directly 
into the mustUnderstand processing, we check only the headers the engine 
will be checking.
[11:48] <barrettj> It is a larger issue of having handlers/modules work 
with roles I think.  One that I agree needs to be done.
[11:48] <gdaniels> ok
[11:48] <gdaniels> so back to the problem
[11:49] <gdaniels> writing a Handler that would mark the processed bit 
on all headers targeted to us is trivial
[11:49] <dims> gdaniels: can we add a handler on the fly w/o writing a 
module?
[11:49] <gdaniels> dangerous (because I think it's a weird use case), 
but trivial
[11:51] <gdaniels> dims: I believe you need a module, but it should be 
easy to write a mostly-static one
[11:52] <dims> from what i understand the alternative involves writing a 
JAXWS specific mar, which deploys handlers depending on the service in 
question and marks the headers
[11:52] <dims> guess we need to get rid of TransportResolver too then
[11:52] <gdaniels> ok don't let's go too far afield :)
[11:53] <dims> let's look at the code that was checked in - 
http://svn.apache.org/viewvc?view=rev&revision=556761
[11:53] <gdaniels> let's focus on the JAXWS specific case for a minute, 
not the understand-everything one?
[11:53] <gdaniels> hang on dims
[11:53] <gdaniels> before we go there I want to understand the specific 
use-case we're trying to solve
[11:53] <gdaniels> I thought it was about generated operations dealing 
with headers
[11:54] <gdaniels> i.e. this AxisOperation understands the 
"ns:headerArg" header
[11:55] <barrettj> Not necessarily.
[11:55] <barrettj> It is a
[11:55] <barrettj> ... way to say this header will be processed later ...
[11:55] <gdaniels> that's a little generic
[11:56] <gdaniels> can we have an actual use-case?
[11:56] <dims> gdaniels: you can deploy jaxws specific handlers
[11:56] <barrettj> In the JAXWS case, for example, a header paramater is 
considered understood if any method (i.e. operation) on the SEI has that 
header paramater...
[11:56] <gdaniels> um...
[11:56] <barrettj> It doesn't matter if that is the operation currently 
being invoked.
[11:56] <gdaniels> WHAT?
[11:56] <barrettj> I know ... it is wierd.
[11:56] <gdaniels> !!!!!!!!!!!!!!!!!!!!!!!
[11:56] <barrettj> But that is what it is per the spec.
[11:57] <gdaniels> you are freaking kidding me.
[11:57] <barrettj> Nope.
[11:57] <gdaniels> so what happens to that header
[11:57] <barrettj> Fair question.
[11:57] <gdaniels> when it arrives on the operation without the argument 
corresponding to it
[11:57] <gdaniels> are you sure about the spec being this way?
[11:57] <barrettj> We went down this road already to no avail.
[11:58] <barrettj> I am absoutely postive.
[11:58] <gdaniels> I am stunned.  That is totally farked.
[11:58] <barrettj> No argument from me.
[11:58] <gdaniels> nice subversion of the SOAP model there
[11:58] <barrettj> I had the same reaction.
[11:59] <dims> gdaniels: hehe
[11:59] <gdaniels> why didn't they just say "JAXWS should never send MU 
faults no matter what"
[11:59] <barrettj> :-)
[11:59] <gdaniels> a client sends a header that says it's REQUIRED, and 
JAXWS ignores it.
[11:59] <gdaniels> I'm sorry I'll compose myself here.
[11:59] <gdaniels> Frak.
[11:59] <gdaniels> wow.
[11:59] <barrettj> Take a few deep breaths :-)
[12:00] <gdaniels> ok, so.  In the context of this STUNNINGLY STUPID 
architecture, we can still solve the problem
[12:00] <gdaniels> we're talking about a QName understood by a service, 
not by an operation
[12:00] <gdaniels> that's all
[12:00] <gdaniels> right?
[12:01] <barrettj> Essentially yes.  We are talking about a JAXWS 
service knowing that it needs to check the operations for header params.
[12:01] <gdaniels> we're talking about generated code here
[12:01] <gdaniels> so at codegen time you know everything about the 
headers which will be understood, yes?
[12:02] <gdaniels> (i.e. <soap:header> in the WSDL)
[12:02] <barrettj> I'm confused.  There doesn't have to be WSDL; could 
just be annotations.
[12:02] <dims> gdaniels: think annotations
[12:02] <dims> yep
[12:02] <barrettj> Yeah, what dims said :-)
[12:02] <gdaniels> ok
[12:02] <gdaniels> but we know it once the service is deployed
[12:03] <dims> gdaniels: wanna read the section 10.2.1 of the spec?
[12:04] <gdaniels> do I have to?
[12:04] <dims> 
http://jcp.org/aboutJava/communityprocess/mrel/jsr224/index2.html
[12:04] <dims> 2nd link
[12:04] <dims> its about 1/2 page
[12:04] * Retrieving #apache-axis modes...
[12:05] <dims> if you don't mind, i think it will help
[12:06] <dims> another dynamic example is custom handlers added on the 
fly by users
[12:06] <dims> each handler can have getHeaders()
[12:07] <dims> which returns QName's
[12:07] <gdaniels> and how do those Handlers get plugged in to Axis2?
[12:07] <gdaniels> (my apologies for not reading the jaxws codebase more 
thoroughly)
[12:07] <dims> they are behind the JAXWSMessageReceiver
[12:08] <dims> no modules if that's waht you mean
[12:09] <gdaniels> so IIRC Jeff already had a solution where a JAXWS 
specific Handler would get deployed before the MR, and that would call 
into JAXWS to do the checks and set the appropriate processed bits
[12:12] <barrettj> Yes, although there were other issus with 
actor/roles, which required a change in AxisEngine to the mustUnderstand 
processing as I recall.  Having only the headers that would be checked 
passed into a JAXWS plugin solved the issue.
[12:13] <gdaniels> well wait
[12:13] <gdaniels> that's a separate issue
[12:13] <gdaniels> roles
[12:13] <gdaniels> if you had RolePlayer MessageContext.getCurrentRoles()...
[12:13] <gdaniels> you could write a handler that says
[12:13] <gdaniels>  envelope.getHeadersForRole(msgContext.getCurrentRoles())
[12:14] <gdaniels> (apologies if I misremembered the API but something 
like that)
[12:14] <gdaniels> right?
[12:15] <gdaniels> sorry 
envelope.getHeader().getHeadersToProcess(msgContext.getCurrentRoles())
[12:15] <barrettj> Yes.  The handler could do the same thing as 
AxisEngine.checkMustUnderstand
[12:15] <dims> gdaniels: i
[12:15] <gdaniels> which, arguably, it should be doing anyway
[12:15] <dims> gdaniels: i'd like to take one more angle to look at
[12:15] <dims> can we?
[12:16] <gdaniels> i.e. Handlers in general should be able to respect 
whatever roles the engine is configured to act in
[12:16] <gdaniels> dims: shoot
[12:16] <dims> let's look at the checkin... 
http://svn.apache.org/viewvc?view=rev&revision=556761
[12:16] <dims> does it do too much or does too little
[12:17] <gdaniels> IMO it does too much - it adds another mechanism for 
configuring and plugging in components which I feel is unnecessary and 
confusing
[12:17] <dims> is the objection to the new interface? interface 
SOAPMustUnderstandHeaderChecker
[12:17] <dims> gdaniels: how many people are going to use it?
[12:17] <gdaniels> the new interface, the axis2.xml configuration 
involved, etc
[12:17] <gdaniels> dims: no way to answer that
[12:18] <dims> who ever is taking the effort to override mu can read the 
code
[12:18] <dims> which they will end up doing
[12:18] <dims> this is not for a java beginner who runs wsdl2java
[12:18] <gdaniels> but it's there
[12:18] <gdaniels> therefore people may use it
[12:18] <dims> yes, and it can be used and it works for the use case(s)
[12:18] <gdaniels> or at the very least someone trying to understand the 
whole system will have yet another thing to read about
[12:19] <gdaniels> in our oh-so-comprehensive docs :)
[12:19] <gdaniels> Wouldn't it be better to just fix and document how we 
deal with roles in general, and also clearly document the isProcessed() 
flag?
[12:20] <gdaniels> then the only thing we need to add is the thing we 
ACTUALLY need to add, which is the role configuration APIs
[12:20] <gdaniels> Axis2 is already too big with too many moving parts
[12:20] <gdaniels> (IMO of course)
[12:21] <dims> IMHO, if jeff has enough test cases, that's enough for me 
to keep it going. i
[12:21] <gdaniels> So let me toss this back - Jeff, knowing what you 
know now about getHeadersToProcess(), you could get the JAXWS stuff 
working by using the Handler, right?
[12:21] <dims> 'd +1  clearly document the isProcessed() flag
[12:24] <dims> gdaniels: the G integration code is not set up to deal 
with modules :(
[12:24] <gdaniels> dims: sorry, what does that mean?
[12:24] <dims> means, right now i can't add rampart mar
[12:24] <dims> for example
[12:25] <gdaniels> ok
[12:25] <dims> so if we can add a handler dynamically w/o adding a 
module. Am all for it
[12:25] <gdaniels> well, adding a module doesn't necessarily mean a mar
[12:25] <gdaniels> you can programatically build a simple module with 
one HandlerDescription
[12:25] <gdaniels> and just do it in code
[12:26] <dims> if you think Axis2 class loaders are crazy, you need to 
visit G class loading hierarchy
[12:26] <gdaniels> hehehe
[12:26] <gdaniels> I *really* don't like this for now, and if we put it 
in we are stuck with it.
[12:27] <dims> is adding the interface tying us down? should we just do 
reflection?
[12:27] <gdaniels> On the other hand if we can do with a Handler for 
now, we CAN always add this kind of mechanism in later.
[12:27] <dims> gdaniels: we are talking about making changes to pass 2 TCK's
[12:28] <dims> and Jeff doesn't even have access to the one that he has 
to pass :)
[12:28] <gdaniels> *rolls eyes skyward*
[12:28] <barrettj> That makes it fun, let me tell you :-)
[12:28] <dims> it's like blind men and the elephant :)
[12:29] <gdaniels> again let me ask - this is doable with a Handler as 
long as the roles are respected, right?
[12:30] <dims> it's just code...i guess yes, we will end up tweaking it 
till we get it right. definitely post 1.3.
[12:30] <dims> tjat
[12:30] <dims> that's why i was asking if we should "hide" the pluggability
[12:30] <barrettj> Doable as a handler for JAXWS using the getRoles - 
probably.  But that doesn't mean I agree with that approach.
[12:31] <gdaniels> I understand that Jeff
[12:31] <gdaniels> but I don't agree with adding the plugin stuff
[12:31] <gdaniels> and it seems like if you can get it done for now with 
a Handler, that solves the problem and then we can continue the discussion
[12:32] <gdaniels> I think it's valuable conversation to have and we 
certainly need to get the role processing more fleshed out too
[12:32] <dims> ok, then we are dead in the water for G
[12:32] <gdaniels> dims: what?
[12:32] <dims> gdaniels: i will tell them to go ahead with their G 2.0 
release w/o Axis2 certification
[12:32] <gdaniels> dims: why?
[12:33] <gdaniels> pls explain
[12:33] <dims> because we can't get modules working in the short term
[12:33] <gdaniels> what do you mean can't get modules working exactly?
[12:33] <dims> they can get around to it when they want to.
[12:33] <dims> we can define what we will provide when we provide it
[12:33] <dims> and they can pick it up later for G 2.1 or whatever
[12:33] <gdaniels> what is the problem with modules
[12:34] <barrettj> dims: can the handler just be added to one of the phases?
[12:35] <dims> barrettj: let's re-think...we have to define the new 
API's for roles, then you have to do the code, then pass the stand alone 
tck, then i have to work with Jarek to integrate with G
[12:35] <gdaniels> right, Jeff.  Dims, keep in mind I'm discussing doign 
this programattically
[12:35] <dims> can't do it in the short time frame.
[12:35] <gdaniels> what time frame?
[12:36] <dims> G 2.0
[12:36] <gdaniels> ...
[12:36] <gdaniels> which is?
[12:37] <dims> they have to start running full TCK tests on 20th to be 
able to release by end of month
[12:37] <dims> takes days to run the full tck harness
[12:37] <dims> and always runs into glitches
[12:37] <barrettj> Yup.
[12:38] <gdaniels> Look at it this way.  If Jeff has this working now 
with the plugin, I can pretty much guarantee we can get it working with 
a Handler within a day or so.
[12:38] <dims> m2 sucks!
[12:38] <gdaniels> I'm happy to help out, since I'm clearly the sticky 
wheel here.
[12:38] <barrettj> Let me make sure I understand what this handler is 
going to do...
[12:38] <dims> you guys decide what to do next and drop a note on 
axis-dev please.
[12:38] <gdaniels> But I really do feel strongly about this and haven't 
YET heard enough to change my take on it.
[12:39] <dims> i gotta run
[12:39] <barrettj> Ok.
[12:39] <gdaniels> ok dims
[12:39] <dims> since the -1 is from glen, that needs resolution
[12:39] <dims> and jeff is the committer in question.
[12:39] <dims> so it ends with either jeff reverting the patch or both 
agreeing on a solution
[12:39] <gdaniels> good thing we're both on this here IRC channel, then, 
eh? :)
[12:39] <dims> G 2.0 timeline is of no relevenence
[12:40] <gdaniels> I'm all for a quick solution
[12:40] <dims> you guys do what is right. i will inform others of the 
"situation" and they can do what they want
[12:40] <dims> that's not our problem.
[12:40] <dims> ok?
[12:40] <gdaniels> I don't think this should cause too many schedule 
woes, dims.
[12:41] <gdaniels> we can get this running pretty fast either way IMO
[12:41] <barrettj> dims: ok.
[12:41] <dims> can i head out now? please :)
[12:41] <gdaniels> go go go
[12:41] <barrettj> bye. go. thanks. :-)
[12:41] <gdaniels> Jeff, back to your q
[12:42] <gdaniels> Does JAXWS have a list of roles it needs to respect?
[12:42] <barrettj> Yup...
[12:42] <barrettj> Let me outline it here.
[12:42] <dims> bye for now. i'll keep the window open.
[12:42] <barrettj> (1) we add a new handler in some phase in axis2.xml
[12:42] <barrettj> (2) That handler will use the RolePlayer to get the 
current roles just as AxisEngine.checkMustUnderstand is doing
[12:42] <barrettj> We're not adding any more role support right now.
[12:42] <gdaniels> ok
[12:43] <gdaniels> +1
[12:43] <barrettj> It isn't needed for CTS I believe, just NEXT and 
ULTIMATE RECEIVER.
[12:43] <gdaniels> perfect
[12:43] <gdaniels> if it's just next/UR, you don't even need a RolePlayer
[12:43] <barrettj> (3) the handler will run the list of headers from 
RolePlayer looking for QNames it understands
[12:43] <gdaniels> since the default one does that
[12:43] <barrettj> Ok; I'll copy the code from 
AxisEngine.checkMustUnderstand, whatever it is doing.
[12:44] <barrettj> Passing a null I think.
[12:44] <gdaniels> exactly
[12:44] <barrettj> That is public API I can get to, right?
[12:44] <gdaniels> yep
[12:44] <gdaniels> getEnvelope().getHeader().getHeadersToProcess(null)
[12:44] <barrettj> (3a) For each header QName the jaxws handler 
understands, it will mark SOAPHeaderBlock.setProcessed
[12:45] <barrettj> (3b) It will get that list of understood QNames off 
of options on the AxisOperations under the AxisService (the plugin would 
have done that too)
[12:46] <barrettj> I think that's it.
[12:46] <barrettj> Thoughts?
[12:47] <gdaniels> that sounds right
[12:49] <barrettj> alright.
[12:49] <gdaniels> is that OK with you for at least an interim solution?
[12:50] <gdaniels> I'm great with continuing the discussion and perhaps 
doing something else post-1.3
[12:51] * Disconnected
Session Close: Tue Jul 17 13:02:28 2007

Session Start: Tue Jul 17 13:03:00 2007
Session Ident: #apache-axis
[13:03] * Now talking in #apache-axis
[13:03] * Topic is 'Axis2 1.3 release discussion'
[13:03] * Set by Deepal on Thu Jun 28 03:41:15
[13:03] <GlenD> sorry, got booted
[13:03] <GlenD> last thing I saw was your summary and my saying hope 
you're ok with this interim solution
[13:05] <barrettj> I said: If it passes the compliance test, then it is 
an OK interim solution.
[13:05] <GlenD> :)
[13:05] <GlenD> +1
[13:06] <GlenD> if you want any help building/coding/testing, let me know?
[13:06] <barrettj> Thanks, will do.
[13:07] <GlenD> Very much appreciate the conversation and the work, 
Jeff.  Thanks.
[13:09] <barrettj> Thanks.

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org