On Mon July 27 2009 4:07:43 am 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!
The CachedOutputStream threshold is fine as well, but that would then apply to
other uses of the CachedOutputStream (like logging) and such. Not normally a
big deal, but setting the attachment-memory-threshold property would just
affect the attachment use of it only.
Dan
>
> 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
> >> >> >> >>> >> >> [email protected]
> >> >> >> >>> >> >> http://www.dankulp.com/blog
> >> >> >> >>> >
> >> >> >> >>> > --
> >> >> >> >>> > Daniel Kulp
> >> >> >> >>> > [email protected]
> >> >> >> >>> > http://www.dankulp.com/blog
> >> >> >> >>
> >> >> >> >> --
> >> >> >> >> Daniel Kulp
> >> >> >> >> [email protected]
> >> >> >> >> http://www.dankulp.com/blog
> >> >> >
> >> >> > --
> >> >> > Daniel Kulp
> >> >> > [email protected]
> >> >> > http://www.dankulp.com/blog
> >> >
> >> > --
> >> > Daniel Kulp
> >> > [email protected]
> >> > http://www.dankulp.com/blog
> >
> > --
> > Daniel Kulp
> > [email protected]
> > http://www.dankulp.com/blog
--
Daniel Kulp
[email protected]
http://www.dankulp.com/blog
