I'm a little bit confused. I had a look to the gzip interceptor in cxf 2.1.2. I noticed that you don't use an "ending" interceptor anymore for the GzipOutInterceptor but for the GzipInInterceptor. Why? Why do you have to use an "ending" interceptor for the InInterceptor?
Thanks Oliver -----Ursprüngliche Nachricht----- Von: Wulff, Oliver [mailto:[EMAIL PROTECTED] Gesendet: Di 30.09.2008 16:29 An: [email protected]; [email protected] Betreff: AW: StreamInterceptor in configuration_interceptor When I compare your proposal and Dan's current implementation both use the cached stream approach, isn't it? A difference is that Dan's implementation makes use of the reentrance feature of CXF. But why do you use the CachedOutputStream at all and store the original in the message context? Thanks for clarification Oliver -----Ursprüngliche Nachricht----- Von: Ian Roberts [mailto:[EMAIL PROTECTED] Gesendet: Di 30.09.2008 13:40 An: [email protected] Betreff: Re: StreamInterceptor in configuration_interceptor Wulff, Oliver wrote: > Hi Dan > > I need full access to the message but I want to transform and update the > message before it is parsed by the corresponding soap parser. > > I've done the following in which case the client blocks. If I uncomment the > line where I close the steam os, the client doesn't block but an empty > message is sent to the server: Take a look at the patch attached to https://issues.apache.org/jira/browse/CXF-1387. This is my original version of a GZIP interceptor which uses cached streams to do its work (the version Dan committed to the trunk used a streaming technique instead). You can ignore the gzip-specific stuff, but the principle is that rather than doing everything in one interceptor I have a main interceptor in the PREPARE_SEND phase that replaces the OutputStream on the message with a CachedOutputStream, but remembers the original output stream. The main interceptor adds another interceptor to the chain in the PREPARE_SEND_ENDING phase that retrieves the two streams (cached and original), transforms and writes the cached stream to the original one and finally puts the original output stream back on the message. Main interceptor: private EndingInterceptor ending = new EndingInterceptor(); handleMessage(message) { OutputStream os = message.getContent(OutputStream.class); message.put(ORIGINAL_OUTPUT_STREAM_KEY, os); CachedOutputStream cs = new CachedOutputStream(); message.setContent(OutputStream.class, cs); message.getInterceptorChain().add(ending); } Ending interceptor: handleMessage(message) { CachedOutputStream cs = (CachedOutputStream)message.getContent(OutputStream.class); cs.flush(); OutputStream originalOutput = (OutputStream)message.get(ORIGINAL_OUTPUT_STREAM_KEY); // write transformed message to originalOutput cs.close(); originalOutput.flush(); message.setContent(OutputStream.class, originalOutput); } > String processingMsg = new String(csnew.getBytes()); > String processedMsg = transform(processingMsg); > > ByteArrayOutputStream encOutput = new ByteArrayOutputStream(); > byte[] date = encryptedMessage.getBytes(); Be very, very careful about character encodings if you're doing this kind of thing... Ian -- Ian Roberts | Department of Computer Science [EMAIL PROTECTED] | University of Sheffield, UK
