I've just committed a bunch of fixes to the Attachment handling code which 
SHOULD work around the JAXB bug.   With JAXB, when doing schema-validation, we 
now buffer and then lock the temp file during the validation and restore at 
the end.   That allows the attachments to work with schema-validation.   It 
would be great if you could test that.

Dan


On Mon July 27 2009 11:18:42 am Kid_79 wrote:
> 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$AttachmentOutEnding
> >>>I
> >>>
> >>> >>nte rceptor.handleMessage(AttachmentOutInterceptor.java:82) at
> >>>
> >>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptor
> >>>C
> >>>
> >>> >>hai n.java:236) at
> >>>
> >>> org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(Outgo
> >>>i
> >>>
> >>> >>ngC hainInterceptor.java:74) at
> >>>
> >>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptor
> >>>C
> >>>
> >>> >>hai n.java:236) at
> >>>
> >>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiat
> >>>i
> >>>
> >>> >>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(Jett
> >>>y
> >>>
> >>> >>HTT PDestination.java:265) at
> >>>
> >>> org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHa
> >>>n
> >>>
> >>> >>dle r.java:70) at
> >>>
> >>> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726
> >>>)
> >>>
> >>> >> at
> >>>
> >>> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandle
> >>>r
> >>>
> >>> >>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.j
> >>>a
> >>>
> >>> >>va: 450) Caused by: org.mortbay.jetty.EofException
> >>> >>        at org.mortbay.jetty.HttpGenerator.flush(HttpGenerator.java:760)
> >>> >>        at
> >>>
> >>> org.mortbay.jetty.AbstractGenerator$Output.blockForOutput(AbstractGener
> >>>a
> >>>
> >>> >>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(AbstractWrappedOutp
> >>>u
> >>>
> >>> >>tSt ream.java:46) at
> >>>
> >>> javax.activation.DataHandler.writeTo(DataHandler.java:308)
> >>>
> >>> >>        at
> >>>
> >>> org.apache.cxf.attachment.AttachmentSerializer.writeAttachments(Attachm
> >>>e
> >>>
> >>> >>ntS erializer.java:153) at
> >>>
> >>> org.apache.cxf.interceptor.AttachmentOutInterceptor$AttachmentOutEnding
> >>>I
> >>>
> >>> >>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.ja
> >>>v
> >>>
> >>> >>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$Soap1
> >>>1
> >>>
> >>> >>Fau
> >>>
> >>> ltOutInterceptorInternal.handleMessage(Soap11FaultOutInterceptor.java:1
> >>>4
> >>>
> >>> >>9) at
> >>>
> >>> org.apache.cxf.binding.soap.interceptor.Soap11FaultOutInterceptor$Soap1
> >>>1
> >>>
> >>> >>Fau
> >>>
> >>> ltOutInterceptorInternal.handleMessage(Soap11FaultOutInterceptor.java:5
> >>>4
> >>>
> >>> >>)
> >>>
> >>> at
> >>>
> >>>
> >>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptor
> >>>C
> >>>
> >>> >>hai n.java:236) at
> >>>
> >>> org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessag
> >>>e
> >>>
> >>> >>(Ab stractFaultChainInitiatorObserver.java:96) at
> >>>
> >>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptor
> >>>C
> >>>
> >>> >>hai n.java:284) at
> >>>
> >>> org.apache.cxf.interceptor.OutgoingChainInterceptor.handleMessage(Outgo
> >>>i
> >>>
> >>> >>ngC hainInterceptor.java:74) at
> >>>
> >>> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptor
> >>>C
> >>>
> >>> >>hai n.java:236) at
> >>>
> >>> org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiat
> >>>i
> >>>
> >>> >>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(Jett
> >>>y
> >>>
> >>> >>HTT PDestination.java:265) at
> >>>
> >>> org.apache.cxf.transport.http_jetty.JettyHTTPHandler.handle(JettyHTTPHa
> >>>n
> >>>
> >>> >>dle r.java:70) at
> >>>
> >>> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:726
> >>>)
> >>>
> >>> >> at
> >>>
> >>> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandle
> >>>r
> >>>
> >>> >>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.j
> >>>a
> >>>
> >>> >>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.ja
> >>>v
> >>>
> >>> >>a:1 508) at
> >>>
> >>> com.ctc.wstx.sw.BaseNsStreamWriter.checkStartElement(BaseNsStreamWriter
> >>>.
> >>>
> >>> >>jav a:444) at
> >>>
> >>> com.ctc.wstx.sw.SimpleNsStreamWriter.writeStartOrEmpty(SimpleNsStreamWr
> >>>i
> >>>
> >>> >>ter .java:260) at
> >>>
> >>> com.ctc.wstx.sw.BaseNsStreamWriter.writeStartElement(BaseNsStreamWriter
> >>>.
> >>>
> >>> >>jav a:319) at
> >>>
> >>> org.apache.cxf.binding.soap.interceptor.Soap11FaultOutInterceptor$Soap1
> >>>1
> >>>
> >>> >>Fau
> >>>
> >>> ltOutInterceptorInternal.handleMessage(Soap11FaultOutInterceptor.java:7
> >>>9
> >>>
> >>> >>) ... 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

Reply via email to