axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis" <...@us.ibm.com>
Subject Re: writing handlers
Date Fri, 01 Jun 2001 14:18:03 GMT
Everything you mentioned here that might make this a bad idea
or hard could apply to the body itself.  So I don't see what the
problem is - however we solve it for the body would apply to the
header.
As for a use-case - write a header handler.  Would you rather
write something like DebugHandler+DebugHeader or just a simple class
with one method in it?  I know which one is easier to me.
-Dug


"Glen Daniels" <gdaniels@macromedia.com> on 06/01/2001 10:14:44 AM

Please respond to axis-dev@xml.apache.org

To:   <axis-dev@xml.apache.org>
cc:
Subject:  Re: writing handlers



1) Standard RPC bodies (w/sec 5 encoding) have no attributes, whereas many
headers probably will.  Therefore you'll still need a custom deserializer
to
turn your SOAP header into something that can be consumed by your Java code
that doesn't want to understand SOAPEnvelope structure.  XML would be an
exception to this, but then your code will still need to "understand" the
structure.  And what about HREFs?  Would we expect their code to deal with
them?  How?

2) The model now is to have the Handler set the processed bit on any
headers it
deals with.  We'd need to move to a model where each call out to custom
code
that is made for a header marks that header as processed if no exception is
thrown, for instance.  The problem with that is that sometimes you might
have
interrelated headers such that you can't be sure you've "processed" the
first
one until you get the second one.  If you don't have a model for the whole
message, you can't do that easily.  That said, we could certainly pass a
Message to their custom code, but then what's the real difference between
that
and a Handler?

3) It seems like what you're talking about here is a Handler which can
arbitrarily turn Headers into various forms and then dispatch them to some
piece of custom code (determined by options on the Handler, but I'd assume
you'd want to call other methods on the same object that implements your
RPC
service, so that lifecycle/object association issues don't get too hairy).
This is a cool and interesting idea, but IMHO not something that's critical
for
version 1.  I think a lot of the use-cases for header processing won't
easily
fit into this model.

4) I'd like to see some detailed usage scenarios for this.

--Glen

----- Original Message -----
From: "Doug Davis" <dug@us.ibm.com>
To: <axis-dev@xml.apache.org>
Sent: Friday, June 01, 2001 8:55 AM
Subject: writing handlers


> Right now when we think of people processing headers
> we're assuming they'll subclass Handler, but why?
> We've all basically agreed that processing
> a header is really the same thing as processing the
> body so why not allow them to treat it that way?
> (Note: the spec does too)
> Why not allow them to specify the RPCDispatcher
> should be used to process their header and then
> we'll just call their method for them.  Then all
> they need to write is their application logic and
> no SOAP/Axis header processing code.
> Likewise, they may want the header handed to them as
> a block of XML (messaging instead of rpc), like
> the Admin service does.  No Axis/header coded needed
> here either.
> Of course well still allow them to write a handler
> if they want, but for probably 90+% of the cases
> people won't need to import Axis code at all, leaving
> them to focus on their business logic.
> Really this isn't such a radical change, but rather
> how we present the "preferred" way of doing things.
> Not sure, but I think it does require a little bit
> of code changes inside of Axis but I doubt it would
> be very much.
> Thoughts?
> -Dug
>




Mime
View raw message