You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@xml.apache.org by Wouter Cloetens <wc...@raleigh.ibm.com> on 2000/11/18 11:43:44 UTC
Transport hook extension problems :-(
I'm seeing some serious problems while trying to fit the transport hook
patch with my attachment patch.
In my patch, I've separated ServerHTTPUtils into a generic,
transport-independent, ServerUtils and an HTTP-specific subclass,
ServerUtils. I've also created a transport-independent ServerResponse
class. One reason is that this is a step towards independence from
HTTP, another reason is that it has become too complex in the
multipart/mime world to handle the content yourself and pass it on to
the XML parser. There are now alternative scenarios (multipart or
single-part request, multipart or single-part response).
So the envelope is no longer exposed to the servlet. The transport hook
extension, however, treats the request and response content as the XML
SOAP envelope, which is no longer true. So it needs to be moved into my
ServerUtils and ServerResponse.
The following issues bother me though:
- In the RPCRouter servlet's init() method, Properties.setProperty() is
used, which I guess only works on Java 2. Properties.put() will work on
Java 1.1 too.
- In the RPCRouter servlet's init() method, a problem is printed to
System.err, instead of throwing a servlet init exception. The
createObject() method is full of System.err.printlns.
Same problem in doPost() at the editIncoming() and editOutgoing()
locations - exceptions from the EnvelopeEditor are handled by printing
the stack trace on stderr and then issuing a return(!!!).
- The TRANSPORT_HOOK_EXTENSION is private to RPCRouterServlet. It
should be moved to somewhere global (e.g. Constants) so I can access it
from other, transport-independent classes.
- Is there a reason why this envelope editor functionality is
implemented at a transport level, by handling the XML content (as
bytes), rather than handling the SOAP Envelope after it's been parsed
into a DOM tree?
I'm having some trouble understanding the purpose here... I'm looking
at the need to severely change the transport hook implementation, and
I'd rather not do that without being able to judge what the right way
to do this is.
I think that in the mean time, I'll pull out the transport hook changes
and post the first version of attachment support without it. It will be
easy to put it in after you can see the changes to the servlet(s) and
the reorganisation of ServerHTTPUtils.
bfn, Wouter
--
http://www.workspot.net/~zombie/soap/
My opinions are irrelevant. They will be assimilated by my employer.
Re: Transport hook extension problems :-(
Posted by Ryo Neyama <ne...@trl.ibm.co.jp>.
Wouter,
From: "Wouter Cloetens" <wc...@raleigh.ibm.com>
Subject: Transport hook extension problems :-(
Date: Sat, 18 Nov 2000 15:43:44 +0500
> I'm seeing some serious problems while trying to fit the transport hook
> patch with my attachment patch.
> In my patch, I've separated ServerHTTPUtils into a generic,
> transport-independent, ServerUtils and an HTTP-specific subclass,
> ServerUtils.
The last "ServerUtils" is "ServerHTTPUtils" correctly, isn't it?
> I've also created a transport-independent ServerResponse
> class. One reason is that this is a step towards independence from
> HTTP, another reason is that it has become too complex in the
> multipart/mime world to handle the content yourself and pass it on to
> the XML parser. There are now alternative scenarios (multipart or
> single-part request, multipart or single-part response).
> So the envelope is no longer exposed to the servlet. The transport hook
> extension, however, treats the request and response content as the XML
> SOAP envelope, which is no longer true. So it needs to be moved into my
> ServerUtils and ServerResponse.
As you may know, you can switch on/off the transport hook extension
with the system parameter TRASNPORT_HOOK_EXTENSION. So, when you make
the Apache SOAP engine to handle multipart/mime, you can just switch
off the extension.
Also, the hook extension does not depdends on any kind of wire-level
format. It can be multipart/mime format as well as a raw XML
string. Therefore, you can add a envelope editor which knows about
multipart/mime format if you want.
> The following issues bother me though:
>
> - In the RPCRouter servlet's init() method, Properties.setProperty() is
> used, which I guess only works on Java 2. Properties.put() will work on
> Java 1.1 too.
Ok. I'll change the code so that it uses Properties.put() instead of
Properties.setProperty().
> - In the RPCRouter servlet's init() method, a problem is printed to
> System.err, instead of throwing a servlet init exception. The
> createObject() method is full of System.err.printlns.
> Same problem in doPost() at the editIncoming() and editOutgoing()
> locations - exceptions from the EnvelopeEditor are handled by printing
> the stack trace on stderr and then issuing a return(!!!).
I'll fix the problem.
> - The TRANSPORT_HOOK_EXTENSION is private to RPCRouterServlet. It
> should be moved to somewhere global (e.g. Constants) so I can access it
> from other, transport-independent classes.
Ok.
> - Is there a reason why this envelope editor functionality is
> implemented at a transport level, by handling the XML content (as
> bytes), rather than handling the SOAP Envelope after it's been parsed
> into a DOM tree?
Because Envelope class is not a DOM tree to be exact. With the
Envelope, we cannot use the various XML tools that provide
DOM/SAX-like API.
> I'm having some trouble understanding the purpose here... I'm looking
> at the need to severely change the transport hook implementation, and
> I'd rather not do that without being able to judge what the right way
> to do this is.
> I think that in the mean time, I'll pull out the transport hook changes
> and post the first version of attachment support without it. It will be
> easy to put it in after you can see the changes to the servlet(s) and
> the reorganisation of ServerHTTPUtils.
Please don't pull out the transport hook. I think I was able to get an
endorsement to it from this Apache SOAP community. Let's discuss how
our two implementation can be included together.
Regards,
Ryo Neyama @ IBM Research, Tokyo Research Laboratory
Internet Technology
neyama@trl.ibm.co.jp
Re: Transport hook extension problems :-(
Posted by Ryo Neyama <ne...@trl.ibm.co.jp>.
Wouter,
From: "Wouter Cloetens" <wc...@raleigh.ibm.com>
Subject: Transport hook extension problems :-(
Date: Sat, 18 Nov 2000 15:43:44 +0500
> I'm seeing some serious problems while trying to fit the transport hook
> patch with my attachment patch.
> In my patch, I've separated ServerHTTPUtils into a generic,
> transport-independent, ServerUtils and an HTTP-specific subclass,
> ServerUtils.
The last "ServerUtils" is "ServerHTTPUtils" correctly, isn't it?
> I've also created a transport-independent ServerResponse
> class. One reason is that this is a step towards independence from
> HTTP, another reason is that it has become too complex in the
> multipart/mime world to handle the content yourself and pass it on to
> the XML parser. There are now alternative scenarios (multipart or
> single-part request, multipart or single-part response).
> So the envelope is no longer exposed to the servlet. The transport hook
> extension, however, treats the request and response content as the XML
> SOAP envelope, which is no longer true. So it needs to be moved into my
> ServerUtils and ServerResponse.
As you may know, you can switch on/off the transport hook extension
with the system parameter TRASNPORT_HOOK_EXTENSION. So, when you make
the Apache SOAP engine to handle multipart/mime, you can just switch
off the extension.
Also, the hook extension does not depdends on any kind of wire-level
format. It can be multipart/mime format as well as a raw XML
string. Therefore, you can add a envelope editor which knows about
multipart/mime format if you want.
> The following issues bother me though:
>
> - In the RPCRouter servlet's init() method, Properties.setProperty() is
> used, which I guess only works on Java 2. Properties.put() will work on
> Java 1.1 too.
Ok. I'll change the code so that it uses Properties.put() instead of
Properties.setProperty().
> - In the RPCRouter servlet's init() method, a problem is printed to
> System.err, instead of throwing a servlet init exception. The
> createObject() method is full of System.err.printlns.
> Same problem in doPost() at the editIncoming() and editOutgoing()
> locations - exceptions from the EnvelopeEditor are handled by printing
> the stack trace on stderr and then issuing a return(!!!).
I'll fix the problem.
> - The TRANSPORT_HOOK_EXTENSION is private to RPCRouterServlet. It
> should be moved to somewhere global (e.g. Constants) so I can access it
> from other, transport-independent classes.
Ok.
> - Is there a reason why this envelope editor functionality is
> implemented at a transport level, by handling the XML content (as
> bytes), rather than handling the SOAP Envelope after it's been parsed
> into a DOM tree?
Because Envelope class is not a DOM tree to be exact. With the
Envelope, we cannot use the various XML tools that provide
DOM/SAX-like API.
> I'm having some trouble understanding the purpose here... I'm looking
> at the need to severely change the transport hook implementation, and
> I'd rather not do that without being able to judge what the right way
> to do this is.
> I think that in the mean time, I'll pull out the transport hook changes
> and post the first version of attachment support without it. It will be
> easy to put it in after you can see the changes to the servlet(s) and
> the reorganisation of ServerHTTPUtils.
Please don't pull out the transport hook. I think I was able to get an
endorsement to it from this Apache SOAP community. Let's discuss how
our two implementation can be included together.
Regards,
Ryo Neyama @ IBM Research, Tokyo Research Laboratory
Internet Technology
neyama@trl.ibm.co.jp