cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kid_79 <chicc...@hotmail.com>
Subject Re: CXF and Attachment
Date Mon, 27 Jul 2009 15:18:42 GMT

Hi Dan,
if in my app I set a org.apache.cxf.io.CachedOutputStream.Threshold = 102400
(100kb for example) it works.

But in my app, if I want to disable a schema validation and to set mtom =
false in my service without setting Threshold, it not works (file's size =
0). 
These are a different.

In my test case that it works I have:
Endpoint ep = Endpoint.publish(address, implementor);
Binding binding = ep.getBinding();
((SOAPBinding) binding).setMTOMEnabled(false);

Map<String, Object> properties = ep.getProperties();
if (properties == null) {
   properties = new Hashtable<String, Object>();
}
properties.put("schema-validation-enabled", "false");
ep.setProperties(properties);

while in my app I have:

EndpointImpl ep= (EndpointImpl) Endpoint.create(
javax.xml.ws.soap.SOAPBinding.SOAP11HTTP_MTOM_BINDING, implementor);
//add interceptors
ep.getInInterceptors().add(new SAAJInInterceptor());
ep.getInInterceptors().add(new RequestInterceptor());
ep.getOutInterceptors().add(new SAAJOutInterceptor());
ep.getOutInterceptors().add(new ResponseInterceptor());
ep.getOutFaultInterceptors().add(new ErrorInterceptor());

ep.setWsdlLocation(wsdlpath);
ep.publish(address);
Binding binding = ep.getBinding();
((SOAPBinding) binding).setMTOMEnabled(false);

Map<String, Object> properties = ep.getProperties();
if (properties == null) {
   properties = new Hashtable<String, Object>();
}
properties.put("schema-validation-enabled", "false");
ep.setProperties(properties);

Where is it wrong?


Kid_79 wrote:
> 
> Thanks Dan,
> I hope that a JAXB folk fix this problem.
> I set a org.apache.cxf.io.CachedOutputStream.Threshold parameter. It's
> right or I must set a attachment-memory-threshold properties!
> 
> 
> 
> dkulp wrote:
>> 
>> On Fri July 24 2009 12:53:50 pm Kid_79 wrote:
>>> Hi Dan,
>>> I used this your code in my client and I have solved a problem for
>>> testByteArray example. It works.
>>>
>>> Now I have only problem with testDataHandler service.
>>> In DataHandler service, I understand that the problem is a schema
>>> validation bug in jaxb.
>>> What should I do?
>> 
>> Until JAXB folks fix it, I'm not sure what CAN be done other than to turn
>> off 
>> schema validation if you use DataHandlers in your service.  :-(
>> 
>> Actually, what MAY work is to configure the memory threshold to something 
>> huge.   Set the property: 
>> "attachment-memory-threshold"
>> to something larger (number of bytes) than any attachment you'll get and
>> it 
>> will keep it in memory which I THINK will work around the jaxb problem.   
>> Obviously that ends up using a lot more memory though.   :-(
>> 
>> Dan
>> 
>> 
>>>
>>> Thanks.
>>>
>>> dkulp wrote:
>>> > I'd need to see the full test case.  Can you zip it up and send it to
>>> me
>>> > privately.  (the list will probably strip the attachment)   If I
>>> update
>>> > the
>>> > mtom demo with your stuff below, I see exactly what I expect.   The
>>> byte
>>> > is
>>> > OK, but the DataHandler is length 0 due to the schema validation bug
>>> in
>>> > jaxb.
>>> >
>>> > The corruption MAY be due to the Client not setting up the byte[]
>>> > properly.
>>> > It's just calling:
>>> > in.read(param.value);
>>> > which may not be reading the full amount.  Try changing it to:
>>> >         int len = in.read(param.value);
>>> >         while (len < fileSize) {
>>> >             len += in.read(param.value, len, (int)(fileSize - len));
>>> >         }
>>> >
>>> >
>>> > Dan
>>> >
>>> > On Thu July 23 2009 12:59:42 pm Kid_79 wrote:
>>> >> Hi Dan,
>>> >> I just run a test case "TestMtomPortType" for testing.
>>> >> My TestMtomPortType_TestMtomPort_Server is:
>>> >>
>>> >> ...
>>> >> Object implementor = new TestMtomPortTypeImpl();
>>> >> String address = "http://localhost:8080/mime-test";
>>> >> Endpoint ep = Endpoint.publish(address, implementor);
>>> >> Binding binding = ep.getBinding();
>>> >> ((SOAPBinding) binding).setMTOMEnabled(true);
>>> >> Map<String, Object> properties = ep.getProperties();
>>> >>
>>> >> if (properties == null) {
>>> >>     properties = new Hashtable<String, Object>();
>>> >> }
>>> >> properties.put("schema-validation-enabled", "true");
>>> >> ep.setProperties(properties);
>>> >> ...
>>> >>
>>> >> MTOM true
>>> >> validation true
>>> >> testByteArray/testDataHandler (services)
>>> >>
>>> >> In the server side I get the attachment (me.bmp image file) and I
>>> save
>>> >> it on file system;
>>> >> When I call the service testDataHandler it works, while in the
>>> service
>>> >> testByteArray file is corrupt although dimension is not zero.
>>> >>
>>> >> After I have saved the file, I have this problem (server side):
>>> >>
>>> >> Received image with mtom enabled from client
>>> >> The image data size is 163166
>>> >> Saved the file
>>> >> 23-Lug-2009 18.14.55 org.apache.cxf.phase.PhaseInterceptorChain
>>> >> doIntercept
>>> >> INFO: Interceptor has thrown exception, unwinding now
>>> >> org.apache.cxf.interceptor.Fault: Could not write attachments.
>>> >> 	at
>>> >>
>>> org.apache.cxf.interceptor.AttachmentOutInterceptor$AttachmentOutEndingI
>>> >>nte rceptor.handleMessage(AttachmentOutInterceptor.java:82) at
>>> >>
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC
>>> >>hai n.java:236) at
>>> >>
>>> org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(Outgoi
>>> >>ngC hainInterceptor.java:74) at
>>> >>
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC
>>> >>hai n.java:236) at
>>> >>
>>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiati
>>> >>onO bserver.java:89) at
>>> >>
>>> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(
>>> >>Jet tyHTTPDestination.java:302) at
>>> >>
>>> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(Jetty
>>> >>HTT PDestination.java:265) at
>>> >>
>>> org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHan
>>> >>dle r.java:70) at
>>> >>
>>> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)
>>> >> at
>>> >>
>>> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandler
>>> >>Col lection.java:206) at
>>> >>
>>> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
>>> >> at
>>> >> org.mortbay.jetty.Server.handle(Server.java:320)
>>> >> 	at
>>> >>
>>> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
>>> >> 	at
>>> >>
>>> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.j
>>> >>ava
>>> >>
>>> >>:842) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:730)
>>> >>
>>> >> 	at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
>>> >> 	at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
>>> >> 	at
>>> >>
>>> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:
>>> >>395 ) at
>>> >>
>>> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.ja
>>> >>va: 450) Caused by: org.mortbay.jetty.EofException
>>> >> 	at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:760)
>>> >> 	at
>>> >>
>>> org.mortbay.jetty.AbstractGenerator$Output.blockForOutput(AbstractGenera
>>> >>tor .java:548) at
>>> >>
>>> org.mortbay.jetty.AbstractGenerator$Output.flush(AbstractGenerator.java:
>>> >>569 ) at
>>>
>>> org.mortbay.jetty.HttpConnection$Output.flush(HttpConnection.java:910)
>>>
>>> >> at
>>> >>
>>> org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:
>>> >>646 ) at
>>> >>
>>> org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:
>>> >>577 ) at
>>> >>
>>> org.apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutpu
>>> >>tSt ream.java:46) at
>>>
>>> javax.activation.DataHandler.writeTo(DataHandler.java:308)
>>>
>>> >> 	at
>>> >>
>>> org.apache.cxf.attachment.AttachmentSerializer.writeAttachments(Attachme
>>> >>ntS erializer.java:153) at
>>> >>
>>> org.apache.cxf.interceptor.AttachmentOutInterceptor$AttachmentOutEndingI
>>> >>nte rceptor.handleMessage(AttachmentOutInterceptor.java:80) ... 18
>>> more
>>> >> Caused by: java.io.IOException: Connessione interrotta dal software
>>> del
>>> >> computer host.
>>> >> 	at sun.nio.ch.SocketDispatcher.write0(Native Method)
>>> >> 	at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:51)
>>> >> 	at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:132)
>>> >> 	at sun.nio.ch.IOUtil.write(IOUtil.java:88)
>>> >> 	at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:329)
>>> >> 	at
>>> org.mortbay.io.nio.ChannelEndPoint.flush(ChannelEndPoint.java:166)
>>> >> 	at
>>> >>
>>> org.mortbay.io.nio.SelectChannelEndPoint.flush(SelectChannelEndPoint.jav
>>> >>a:2 07) at
>>> org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:693)
>>> >> ... 27 more
>>> >> 23-Lug-2009 18.14.55 org.apache.cxf.phase.PhaseInterceptorChain
>>> >> doIntercept
>>> >> INFO: Interceptor has thrown exception, unwinding now
>>> >> org.apache.cxf.interceptor.Fault: Error writing to XMLStreamWriter.
>>> >> 	at
>>> >>
>>> org.apache.cxf.binding.soap.interceptor.Soap11FaultOutInterceptor$Soap11
>>> >>Fau
>>> >>
>>> ltOutInterceptorInternal.handleMessage(Soap11FaultOutInterceptor.java:14
>>> >>9) at
>>> >>
>>> org.apache.cxf.binding.soap.interceptor.Soap11FaultOutInterceptor$Soap11
>>> >>Fau
>>> >>
>>> ltOutInterceptorInternal.handleMessage(Soap11FaultOutInterceptor.java:54
>>> >>)
>>>
>>> at
>>>
>>> >>
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC
>>> >>hai n.java:236) at
>>> >>
>>> org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage
>>> >>(Ab stractFaultChainInitiatorObserver.java:96) at
>>> >>
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC
>>> >>hai n.java:284) at
>>> >>
>>> org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(Outgoi
>>> >>ngC hainInterceptor.java:74) at
>>> >>
>>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC
>>> >>hai n.java:236) at
>>> >>
>>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiati
>>> >>onO bserver.java:89) at
>>> >>
>>> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.serviceRequest(
>>> >>Jet tyHTTPDestination.java:302) at
>>> >>
>>> org.apache.cxf.transport.http_jetty.JettyHTTPDestination.doService(Jetty
>>> >>HTT PDestination.java:265) at
>>> >>
>>> org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHan
>>> >>dle r.java:70) at
>>> >>
>>> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726)
>>> >> at
>>> >>
>>> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandler
>>> >>Col lection.java:206) at
>>> >>
>>> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
>>> >> at
>>> >> org.mortbay.jetty.Server.handle(Server.java:320)
>>> >> 	at
>>> >>
>>> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
>>> >> 	at
>>> >>
>>> org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.j
>>> >>ava
>>> >>
>>> >>:842) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:730)
>>> >>
>>> >> 	at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
>>> >> 	at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
>>> >> 	at
>>> >>
>>> org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:
>>> >>395 ) at
>>> >>
>>> org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.ja
>>> >>va: 450) Caused by: javax.xml.stream.XMLStreamException: Trying to
>>> output
>>>
>>> second
>>>
>>> >> root, <soap:Fault>
>>> >> 	at
>>> >>
>>> com.ctc.wstx.sw.BaseStreamWriter.throwOutputError(BaseStreamWriter.java:
>>> >>147 3) at
>>> >>
>>> com.ctc.wstx.sw.BaseStreamWriter.throwOutputError(BaseStreamWriter.java:
>>> >>148 0) at
>>> >>
>>> com.ctc.wstx.sw.BaseStreamWriter.reportNwfStructure(BaseStreamWriter.jav
>>> >>a:1 508) at
>>> >>
>>> com.ctc.wstx.sw.BaseNsStreamWriter.checkStartElement(BaseNsStreamWriter.
>>> >>jav a:444) at
>>> >>
>>> com.ctc.wstx.sw.SimpleNsStreamWriter.writeStartOrEmpty(SimpleNsStreamWri
>>> >>ter .java:260) at
>>> >>
>>> com.ctc.wstx.sw.BaseNsStreamWriter.writeStartElement(BaseNsStreamWriter.
>>> >>jav a:319) at
>>> >>
>>> org.apache.cxf.binding.soap.interceptor.Soap11FaultOutInterceptor$Soap11
>>> >>Fau
>>> >>
>>> ltOutInterceptorInternal.handleMessage(Soap11FaultOutInterceptor.java:79
>>> >>) ... 21 more
>>> >>
>>> >>
>>> >> If MTOM is false (setMTOMEnabled(false);) the service testDataHandler
>>> >> works
>>> >> (I save a file) and in server side, after I have saved file, I
>>> haven't
>>> >> any
>>> >> error.
>>> >>
>>> >> Thanks
>>> >>
>>> >> dkulp wrote:
>>> >> > Schema validation is turned off by default.   If you aren't
>>> >>
>>> >> specifically
>>> >>
>>> >> > turning it on, then it's not on.   If you are still not getting
the
>>> >> > attachments through, then I'll probably need a test case.
>>> >> >
>>> >> > Dan
>>> >> >
>>> >> > On Thu July 23 2009 9:46:15 am Kid_79 wrote:
>>> >> >> Hi all,
>>> >> >> I try to disable tha validation and MTOM.
>>> >> >>
>>> >> >> In my app I disable this validation in this way:
>>> >> >> EndpointImpl ep = (EndpointImpl) Endpoint.create(
>>> >> >> javax.xml.ws.soap.SOAPBinding.SOAP11HTTP_MTOM_BINDING,
>>> implementor);
>>> >> >>
>>> >> >> ep.getProperties().put("schema-validation-enabled",
>>> Boolean.FALSE);
>>> >> >> ...
>>> >> >> ep.publish(address);
>>> >> >>
>>> >> >> and I set a MTOM a false:
>>> >> >> ((javax.xml.ws.soap.SOAPBinding)binding).setMTOMEnabled(false);
>>> >> >>
>>> >> >> but it's not works too!
>>> >> >>
>>> >> >> What should I do?
>>> >> >>
>>> >> >> I look up a link
>>> >> >> https://jaxb.dev.java.net/issues/show_bug.cgi?id=588, but
>>> >> >> I don't know where I must to modify into my app.
>>> >> >> Can you help me?
>>> >> >>
>>> >> >> Kid_79 wrote:
>>> >> >> > Excuse me,
>>> >> >> > if validation is disabled, can it works!
>>> >> >> > How can I config it?
>>> >> >> >
>>> >> >> > dkulp wrote:
>>> >> >> >> On Fri July 17 2009 3:45:46 am Kid_79 wrote:
>>> >> >> >>> I'm using CXF 2.2.2 and jaxb 2.1!
>>> >> >> >>
>>> >> >> >> Well, if schema validation is on, it's kind of expected.
  Bug
>>> is
>>> >> >> >> logged: https://jaxb.dev.java.net/issues/show_bug.cgi?id=588
>>> >> >> >>
>>> >> >> >> If schema validation isn't turned on, any way to create
a test
>>> >> >> >> case
>>> >> >>
>>> >> >> and
>>> >> >>
>>> >> >> >> attach
>>> >> >> >> to a JIRA?
>>> >> >> >>
>>> >> >> >> Dan
>>> >> >> >>
>>> >> >> >>> Kid
>>> >> >> >>>
>>> >> >> >>> dkulp wrote:
>>> >> >> >>> > On Thu July 16 2009 6:52:55 am Kid_79 wrote:
>>> >> >> >>> >> However, for attachments greater 64k,
I can not retrieve
>>> the
>>> >> >> >>> >> content, the file has a size 0k.
>>> >> >> >>> >> What is the problem?
>>> >> >> >>> >>
>>> >> >> >>> >> Does CXF delete temporary files automatically?
>>> >> >> >>> >
>>> >> >> >>> > What version of CXF and do you have Schema
validation turned
>>> >> >> >>> > on?
>>> >> >> >>>
>>> >> >> >>> There
>>> >> >> >>>
>>> >> >> >>> > is a
>>> >> >> >>> > bug in JAXB that is consuming the streams
during schema
>>> >> >> >>> > validation.
>>> >> >> >>>
>>> >> >> >>> When
>>> >> >> >>>
>>> >> >> >>> > the
>>> >> >> >>> > stream is fully consumed, the file is deleted.
>>> >> >> >>> >
>>> >> >> >>> > Dan
>>> >> >> >>> >
>>> >> >> >>> >> Kid_79 wrote:
>>> >> >> >>> >> > Ok,
>>> >> >> >>> >> > thanks for your answer.
>>> >> >> >>> >> > Where can I configure threshold
and temporary file path?
>>> >> >> >>> >> >
>>> >> >> >>> >> > dkulp wrote:
>>> >> >> >>> >> >> On Wed July 15 2009 12:59:32
pm Kid_79 wrote:
>>> >> >> >>> >> >>> Does cxf save attachments
in temporary files?
>>> >> >> >>> >> >>
>>> >> >> >>> >> >> It depends.  :-)
>>> >> >> >>> >> >>
>>> >> >> >>> >> >> In SOME cases, it doesn't need
to save them anywhere. 
>>> For
>>> >> >> >>>
>>> >> >> >>> example,
>>> >> >> >>>
>>> >> >> >>> >> >> if there
>>> >> >> >>> >> >> is just a single attachment
that is passed in as a
>>> param,
>>> >> >> >>> >> >> we
>>> >> >>
>>> >> >> can
>>> >> >>
>>> >> >> >>> >> >> directly stream it off the wire.
  No saving needed.
>>> >> >> >>> >> >>
>>> >> >> >>> >> >> If the attachments are small
(default is 64K, but
>>> >> >>
>>> >> >> controllable),
>>> >> >>
>>> >> >> >>> we
>>> >> >> >>>
>>> >> >> >>> >> also
>>> >> >> >>> >>
>>> >> >> >>> >> >> just
>>> >> >> >>> >> >> keep them in memory.   However,
if they exceed that
>>> >>
>>> >> threshold,
>>> >>
>>> >> >> >>> then
>>> >> >> >>>
>>> >> >> >>> >> yes,
>>> >> >> >>> >>
>>> >> >> >>> >> >> we
>>> >> >> >>> >> >> dump them into temp files.
>>> >> >> >>> >> >>
>>> >> >> >>> >> >> Does that answer the question?
>>> >> >> >>> >> >> --
>>> >> >> >>> >> >> Daniel Kulp
>>> >> >> >>> >> >> dkulp@apache.org
>>> >> >> >>> >> >> http://www.dankulp.com/blog
>>> >> >> >>> >
>>> >> >> >>> > --
>>> >> >> >>> > Daniel Kulp
>>> >> >> >>> > dkulp@apache.org
>>> >> >> >>> > http://www.dankulp.com/blog
>>> >> >> >>
>>> >> >> >> --
>>> >> >> >> Daniel Kulp
>>> >> >> >> dkulp@apache.org
>>> >> >> >> http://www.dankulp.com/blog
>>> >> >
>>> >> > --
>>> >> > Daniel Kulp
>>> >> > dkulp@apache.org
>>> >> > http://www.dankulp.com/blog
>>> >
>>> > --
>>> > Daniel Kulp
>>> > dkulp@apache.org
>>> > http://www.dankulp.com/blog
>> 
>> -- 
>> Daniel Kulp
>> dkulp@apache.org
>> http://www.dankulp.com/blog
>> 
>> 
> 
> 

-- 
View this message in context: http://www.nabble.com/CXF-and-Attachment-tp24502056p24682498.html
Sent from the cxf-user mailing list archive at Nabble.com.


Mime
View raw message