You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Doug Davis <du...@us.ibm.com> on 2001/05/11 01:20:01 UTC
DebugHeader
Glen,
Could you explain the purpose of the DebugHeader class? If I want
to write code to handle a new header (ie. the debug header) I thought
I would write a DebugHandler not a DebugHeader - do people really
need to write both?
-Dug
Re: DebugHeader
Posted by Glen Daniels <gd...@macromedia.com>.
Hi Doug:
When I was building the system I didn't really want to get into the issues
involved in making the Handler architecture be the same as the Deserializer
architecture. So I set it up so that the header content gets parsed into
SOAPHeaders, each of which has the usual info (is it mustUnderstand, actor,
etc..) and an ElementRecorder to hold the XML. The DebugHeader is an
example of subclassing this to do deserialization on the fly so as not to
keep the SAX events kicking around, but it's still purely data.
You're right that it would be cool to just write a Handler which parses and
processes at the same time, and be done with it. This would work great for
the "jukebox" case, where you can just call Handlers as you're parsing the
XML. For the case where you have an explicitly ordered chain of Handlers,
though, you might not want that behavior. It still might be nice to
deserialize the XML into Java, though, but not actually process it yet.
That's kind of where I was going with the DebugHeader. I'm not sure if it's
true that in the majority of cases deserialization and processing go hand in
hand.
A way to do this might be to define Handlers as Deserializers, but also give
them a process() method which tells them to actually DO whatever it is they
need to do. So a Handler for a transaction header, for instance, might
catch SAX events and deserialize a transaction-id out of the XML, but it
wouldn't actually call the transaction coordinator to join that transaction
(or mark the header as 'processed', for that matter) until someone called
the process() method.
On another related note, you might want a given Handler to implement an
extension which uses more than one header, so having multiple deserializers
and only one actual Handler might make sense...
I'd like to rip through some use cases for varying ways to look at this
stuff and see if we can come up with a good model that works for all cases.
--Glen
----- Original Message -----
From: "Doug Davis" <du...@us.ibm.com>
To: <ax...@xml.apache.org>
Sent: Thursday, May 10, 2001 7:20 PM
Subject: DebugHeader
> Glen,
> Could you explain the purpose of the DebugHeader class? If I want
> to write code to handle a new header (ie. the debug header) I thought
> I would write a DebugHandler not a DebugHeader - do people really
> need to write both?
> -Dug
>
Re: DebugHeader
Posted by Glen Daniels <gd...@macromedia.com>.
Hm - dunno why my mailer sent that twice... sorry.
----- Original Message -----
From: "Glen Daniels" <gd...@macromedia.com>
To: <ax...@xml.apache.org>
Sent: Thursday, May 10, 2001 8:34 PM
Subject: Re: DebugHeader
> Hi Doug:
>
> When I was building the system I didn't really want to get into the issues
> involved in making the Handler architecture be the same as the
Deserializer
> architecture. So I set it up so that the header content gets parsed into
> SOAPHeaders, each of which has the usual info (is it mustUnderstand,
actor,
> etc..) and an ElementRecorder to hold the XML. The DebugHeader is an
> example of subclassing this to do deserialization on the fly so as not to
> keep the SAX events kicking around, but it's still purely data.
>
> You're right that it would be cool to just write a Handler which parses
and
> processes at the same time, and be done with it. This would work great
for
> the "jukebox" case, where you can just call Handlers as you're parsing the
> XML. For the case where you have an explicitly ordered chain of Handlers,
> though, you might not want that behavior. It still might be nice to
> deserialize the XML into Java, though, but not actually process it yet.
> That's kind of where I was going with the DebugHeader. I'm not sure if
it's
> true that in the majority of cases deserialization and processing go hand
in
> hand.
>
> A way to do this might be to define Handlers as Deserializers, but also
give
> them a process() method which tells them to actually DO whatever it is
they
> need to do. So a Handler for a transaction header, for instance, might
> catch SAX events and deserialize a transaction-id out of the XML, but it
> wouldn't actually call the transaction coordinator to join that
transaction
> (or mark the header as 'processed', for that matter) until someone called
> the process() method.
>
> On another related note, you might want a given Handler to implement an
> extension which uses more than one header, so having multiple
deserializers
> and only one actual Handler might make sense...
>
> I'd like to rip through some use cases for varying ways to look at this
> stuff and see if we can come up with a good model that works for all
cases.
>
> --Glen
>
> ----- Original Message -----
> From: "Doug Davis" <du...@us.ibm.com>
> To: <ax...@xml.apache.org>
> Sent: Thursday, May 10, 2001 7:20 PM
> Subject: DebugHeader
>
>
> > Glen,
> > Could you explain the purpose of the DebugHeader class? If I want
> > to write code to handle a new header (ie. the debug header) I thought
> > I would write a DebugHandler not a DebugHeader - do people really
> > need to write both?
> > -Dug
> >
>
Re: DebugHeader
Posted by Glen Daniels <gd...@macromedia.com>.
Hi Doug:
When I was building the system I didn't really want to get into the issues
involved in making the Handler architecture be the same as the Deserializer
architecture. So I set it up so that the header content gets parsed into
SOAPHeaders, each of which has the usual info (is it mustUnderstand, actor,
etc..) and an ElementRecorder to hold the XML. The DebugHeader is an
example of subclassing this to do deserialization on the fly so as not to
keep the SAX events kicking around, but it's still purely data.
You're right that it would be cool to just write a Handler which parses and
processes at the same time, and be done with it. This would work great for
the "jukebox" case, where you can just call Handlers as you're parsing the
XML. For the case where you have an explicitly ordered chain of Handlers,
though, you might not want that behavior. It still might be nice to
deserialize the XML into Java, though, but not actually process it yet.
That's kind of where I was going with the DebugHeader. I'm not sure if it's
true that in the majority of cases deserialization and processing go hand in
hand.
A way to do this might be to define Handlers as Deserializers, but also give
them a process() method which tells them to actually DO whatever it is they
need to do. So a Handler for a transaction header, for instance, might
catch SAX events and deserialize a transaction-id out of the XML, but it
wouldn't actually call the transaction coordinator to join that transaction
(or mark the header as 'processed', for that matter) until someone called
the process() method.
On another related note, you might want a given Handler to implement an
extension which uses more than one header, so having multiple deserializers
and only one actual Handler might make sense...
I'd like to rip through some use cases for varying ways to look at this
stuff and see if we can come up with a good model that works for all cases.
--Glen
----- Original Message -----
From: "Doug Davis" <du...@us.ibm.com>
To: <ax...@xml.apache.org>
Sent: Thursday, May 10, 2001 7:20 PM
Subject: DebugHeader
> Glen,
> Could you explain the purpose of the DebugHeader class? If I want
> to write code to handle a new header (ie. the debug header) I thought
> I would write a DebugHandler not a DebugHeader - do people really
> need to write both?
> -Dug
>