Hi Glen!
Nice to hear from you !!
> I hope you don't mind my stepping in - you seem to be doing
> just fine on your own though... :)
"stepping in"? - No, I think that you are also the leading cast
in this thread. That's warmly welcomed any time. :-)
>> 2) Without the execution of the registered JAX-RPC handlers,
>> we never know whether all MU headers are processable or not.
>
> Actually, it's even worse than that. There doesn't seem to be a
> JAX-RPC API for marking a header as processed... so if you're
> programming strictly in JAX-RPC, I don't see how you can get this
> working at all.
>
> That said, I think we should focus on getting the Axis mechanism
> for this as clean and functional as possible, then take JAX-RPC
> issues up with the JAX-RPC group (I'm a member, as is Russell
> Butek who used to work a lot on Axis).
Sure, I know you're a member of JAX-RPC (JSR-101) Expert Group,
not an ordinary member. And I'm also doing paperwork to join the
group as a member.
Because I'd like to have a direct connection to the Expert Group.
A couple of weeks ago, as you may know, I sent a question to them
with mediation by Roberto Chinnici who is the specification lead
of JSR 224 (JAX-RPC 2.0). But, I've never received any response.
Anyway, I agree with you that Axis handler has advantages of
extensibility and easy to update, because we are Axis committer.
At the same time, I hate a version fork on "Handler Architecture".
(i.e. - Axis Handler - vs. - JAX-RPC Handler -)
Please note I don't want to make a denial of "Axis Handler",
I just want to assist users of JAX-RPC Handler on Axis with
my humble contributions.
> While this would work, I don't like the fact that it provides
> another place where configuration and code can get out of sync.
> The code of a given Handler is the final arbiter of which headers
> it can process and which ones it can't - so I think the code
> should be responsible for filling in the engine's registry.
> This is why we have the canHandleBlock() API, and that can be
> used (for Axis handlers) to do what we need. For JAX-RPC handlers,
> I agree a separate mechanism is needed, and maybe we can do a
> simplified version of what you suggest for JAX-RPC HandlerChains.
> But I don't think this should be the default way of dealing with
> the problem.
I'd noticed the sync problem, before I sent the last mail.
How do you strictly clear the problem ? It's very difficult,
even if you add any APIs to Axis handlers.
That's like as the Serializable problems on Java language.
If an object implements the Serializable interface, the object
must be serializable. "No". - The Serializable interface is
a Marker Interface which doesn't actually define any fields.
If we define a new Marker Interface to indicate a capability
for MU headers, it won't enough to know an implementation is
really implement the capability.
Thus, I proposed the XML configuration based architecture.
Thanks,
Toshi (Toshiyuki Kimura) <[EMAIL PROTECTED]>
R&D Headquarters
NTT DATA Corporation
