Logging interceptors and binary payloads
Hi
I'd like to get the Logging interceptors updated to report the 'pure'
binary payload only optionally. Right now I'm working on a demo where an
image payload is uploaded and then returned and I'm finding it difficult
to view through the logs with the binary content being logged.
So I'd like to suggest that only a string 'representing' such a payload
is logged, example:
ID: 41
Response-Code: 200
Content-Type: image/png
Headers: {Date=[Mon, 13 Feb 2012 11:30:40 GMT], Content-Length=[18522]}
Messages: --- Binary Content ---
where --- Binary Content --- replaces the actual 18K binary data.
If really needed showing the binary payload can be enforced by setting a
relevant property. For a start, application/octet-stream and image/*
media types are checked...
I've attached a patch to [1], I'll apply it a bit later on if we agree
it does make sense.
Thanks, Sergey
[1] https://issues.apache.org/jira/browse/CXF-4102
Re: cxf to compile WSDL in eclipse Dynamic Web Project
Pardon the non-answer, but what you're doing looks painful. Why not use Maven to generate your SOAP client[1] (it will handle the dependencies for you) and then Maven's mvn eclipse:eclipse command to import it into your IDE? You can get that done in the 20-30 minutes it would take you to get an answer to the below question anyway. Incidentally, please use the cxf user's mailing list for these questions. The dev list is for internal development of CXF itself. Regards, Glen [1] http://www.jroller.com/gmazza/entry/soap_client_tutorial On 02/13/2012 07:52 AM, Benny wrote: When I try and use the built in /web client/ to build some code out using a WSDL and CXF I get the following errors (see below). I have read other posts and they said I needed to put the Jaxb and jaxws api in the endorsed folder. I added both of those, however I still get the error. I tried literally adding every jar jaxws in the folder and it still didn't work (see screen shot) http://cxf.547215.n5.nabble.com/file/n5479086/Screen_shot_2012-02-13_at_7.51.52_AM.png WSDLToJava Error: java.lang.reflect.UndeclaredThrowableException org.apache.cxf.tools.common.ToolException: java.lang.reflect.UndeclaredThrowableException at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:294) at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:103) at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113) at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:86) at org.apache.cxf.tools.wsdlto.WSDLToJava.main(WSDLToJava.java:184) Caused by: java.lang.reflect.UndeclaredThrowableException at $Proxy45.required(Unknown Source) at com.sun.tools.xjc.generator.bean.field.AbstractField.annotateReference(AbstractField.java:202) at com.sun.tools.xjc.generator.bean.field.AbstractField.annotate(AbstractField.java:161) at com.sun.tools.xjc.generator.bean.field.AbstractListField.generate(AbstractListField.java:129) at com.sun.tools.xjc.generator.bean.field.UntypedListField.(UntypedListField.java:112) at com.sun.tools.xjc.generator.bean.field.UntypedListFieldRenderer.generate(UntypedListFieldRenderer.java:77) at com.sun.tools.xjc.generator.bean.field.DefaultFieldRenderer.generate(DefaultFieldRenderer.java:82) at com.sun.tools.xjc.generator.bean.BeanGenerator.generateFieldDecl(BeanGenerator.java:774) at com.sun.tools.xjc.generator.bean.BeanGenerator.generateClassBody(BeanGenerator.java:555) at com.sun.tools.xjc.generator.bean.BeanGenerator.(BeanGenerator.java:258) at com.sun.tools.xjc.generator.bean.BeanGenerator.generate(BeanGenerator.java:166) at com.sun.tools.xjc.model.Model.generateCode(Model.java:290) at com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.java:283) at com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.java:94) at org.apache.cxf.tools.wsdlto.databinding.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:391) at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.generateTypes(WSDLToJavaContainer.java:591) at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:243) at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:138) at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:286) ... 4 more Caused by: java.lang.NoSuchMethodException: javax.xml.bind.annotation.XmlElementRef.required() at java.lang.Class.getDeclaredMethod(Class.java:1937) at com.sun.codemodel.TypedAnnotationWriter.invoke(TypedAnnotationWriter.java:112) ... 23 more -- View this message in context: http://cxf.547215.n5.nabble.com/cxf-to-compile-WSDL-in-eclipse-Dynamic-Web-Project-tp5479086p5479086.html Sent from the cxf-issues mailing list archive at Nabble.com. -- Glen Mazza Talend Community Coders - coders.talend.com blog: www.jroller.com/gmazza
Re: cxf to compile WSDL in eclipse Dynamic Web Project
Actually it's super easy in Eclipse, no need to jump all over the place and run separate commands to get the WSDL built. Just list the WSDL list what client you want to build it (Axis, Axis2, CXF) and what project you are using. It builds it, and sticks the code right in the project. All with about 3 clicks in a gui. This is of course when/if it works. :) -- View this message in context: http://cxf.547215.n5.nabble.com/Re-cxf-to-compile-WSDL-in-eclipse-Dynamic-Web-Project-tp5479128p5479165.html Sent from the cxf-dev mailing list archive at Nabble.com.
Re: Logging interceptors and binary payloads
Looks OK to me. The only additional suggestion I have is to add the flags to
the @Logging annotation as well to keep that consistent and up to date.
Dan
On Monday, February 13, 2012 11:47:12 AM Sergey Beryozkin wrote:
Hi
I'd like to get the Logging interceptors updated to report the 'pure'
binary payload only optionally. Right now I'm working on a demo where an
image payload is uploaded and then returned and I'm finding it difficult
to view through the logs with the binary content being logged.
So I'd like to suggest that only a string 'representing' such a payload
is logged, example:
ID: 41
Response-Code: 200
Content-Type: image/png
Headers: {Date=[Mon, 13 Feb 2012 11:30:40 GMT], Content-Length=[18522]}
Messages: --- Binary Content ---
where --- Binary Content --- replaces the actual 18K binary data.
If really needed showing the binary payload can be enforced by setting a
relevant property. For a start, application/octet-stream and image/*
media types are checked...
I've attached a patch to [1], I'll apply it a bit later on if we agree
it does make sense.
Thanks, Sergey
[1] https://issues.apache.org/jira/browse/CXF-4102
--
Daniel Kulp
dk...@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Logging interceptors and binary payloads
Hi,
On 13/02/12 15:46, Daniel Kulp wrote:
Looks OK to me. The only additional suggestion I have is to add the flags to
the @Logging annotation as well to keep that consistent and up to date.
Sure, added a 'showBinary' annotation property, set to 'false' by default.
I will also investigate later on how to deal with multipart/* without
having too many temp files created, I thought may be we can get
SequenceInputStream, with some individual InputStreams set to ---
Binary Content---,
thanks, Sergey
Dan
On Monday, February 13, 2012 11:47:12 AM Sergey Beryozkin wrote:
Hi
I'd like to get the Logging interceptors updated to report the 'pure'
binary payload only optionally. Right now I'm working on a demo where an
image payload is uploaded and then returned and I'm finding it difficult
to view through the logs with the binary content being logged.
So I'd like to suggest that only a string 'representing' such a payload
is logged, example:
ID: 41
Response-Code: 200
Content-Type: image/png
Headers: {Date=[Mon, 13 Feb 2012 11:30:40 GMT], Content-Length=[18522]}
Messages: --- Binary Content ---
where --- Binary Content --- replaces the actual 18K binary data.
If really needed showing the binary payload can be enforced by setting a
relevant property. For a start, application/octet-stream and image/*
media types are checked...
I've attached a patch to [1], I'll apply it a bit later on if we agree
it does make sense.
Thanks, Sergey
[1] https://issues.apache.org/jira/browse/CXF-4102
