On Oct 9, 2012, at 10:17 AM, [email protected] wrote:

> Sorry - I submitted the patch to implement
> https://issues.apache.org/jira/browse/CXF-3813. My patch did not include
> all the changes it should have specifically in this case the jaxb schema
> validadation hack interceptor.
> 
> So I was suggesting I need to provide a revised patch to cxf to compete the
> work I contributed to cxf-3813

Oi.  Yea.   I likely should have caught this as well.

My quick list:
rt/bindings/soap/src/main/java/org/apache/cxf/binding/soap/interceptor/ReadHeadersInterceptor.java
rt/bindings/soap/src/main/java/org/apache/cxf/binding/soap/interceptor/SoapHeaderInterceptor.java
rt/databinding/aegis/src/main/java/org/apache/cxf/aegis/databinding/AegisSchemaValidationInInterceptor.java
rt/databinding/jaxb/src/main/java/org/apache/cxf/jaxb/attachment/JAXBAttachmentSchemaValidationHack.java
rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/interceptors/WrapperClassOutInterceptor.java

Might be others as well.

Dan



> 
> Hope that makes sense.
> 
> And I failed to
> On Oct 9, 2012 11:53 PM, "Glen Mazza" <[email protected]> wrote:
> 
>> I'm confused whether the problem is with CXF or with your project, you
>> seem to suggest the latter but your submission of patches to us indicates
>> to former -- or are those patches just for the sample project you're
>> supplying to us?
>> 
>> Glen
>> 
>> On 10/09/2012 08:37 AM, Jason Pell wrote:
>> 
>>> I realise there are probably other classes I will need to check out
>>> too.  Something I should have done originally.  I have to clean up my
>>> own mess now :-) and provide a patch which will update all the other
>>> classes which currently look for a value of 'true', that really need
>>> to be looking for an annotation of IN, OUT or BOTH.
>>> 
>>> what a pain
>>> 
>>> On Tue, Oct 9, 2012 at 11:27 PM, Jason Pell <[email protected]> wrote:
>>> 
>>>> found the problem I think - an incomplete implementation of the Schema
>>>> Validation feature by yours truly :-(
>>>> 
>>>> So if you use anything other than 'true' or 'false' for the
>>>> schema-validation-enabled property the bug appears.  The
>>>> JAXBAttachmentSchemaValidation**Hack will need to be updated.  I will
>>>> update the jira and submit patches to resolve
>>>> this issue.
>>>> 
>>>> On Tue, Oct 9, 2012 at 11:07 PM, Jason Pell <[email protected]> wrote:
>>>> 
>>>>> https://issues.apache.org/**jira/browse/CXF-4551<https://issues.apache.org/jira/browse/CXF-4551>
>>>>> 
>>>>> Project that demonstrated problem attached.  Sorry its not in a unit
>>>>> test.  There is a FileUploadServiceInvoker which invokes a spring
>>>>> context.  You can then use the src/test/resources soapui project to
>>>>> see the problem.
>>>>> 
>>>>> Basically if the Size returned is ZERO - thats a problem.  It should
>>>>> equal the size of the file uploaded.
>>>>> 
>>>>> I am more than happy to be told I am a knob and I am trying to access
>>>>> toe attachments in the wrong way - I even hope that's the case.  I
>>>>> have tried all sorts of things to get it to work.
>>>>> 
>>>>> I keep coming back to the fact that no matter the size of the
>>>>> attachment it works fine if schema validation is disabled.  There must
>>>>> be something in the schema validation code which is clearing out the
>>>>> attachment?
>>>>> 
>>>>> On Tue, Oct 9, 2012 at 10:48 PM, Jason Pell <[email protected]> wrote:
>>>>> 
>>>>>> even more interesting is that if I disable my ws-policy rules I can't
>>>>>> get any size attachment to work.
>>>>>> 
>>>>>> I tried a 1 byte file, a 1k file nothing, can't read the file at all.
>>>>>> 
>>>>>> I tried DataHandler.getInputStream()
>>>>>> 
>>>>>> I tried a fancy get attachment data source method:
>>>>>> 
>>>>>>         private AttachmentDataSource getAttachmentDataSource(**DataSource
>>>>>> ds) {
>>>>>>                 if (ds instanceof LazyDataSource) {
>>>>>>                         ds = ((LazyDataSource) ds).getDataSource();
>>>>>>                 }
>>>>>> 
>>>>>>                 if (ds instanceof AttachmentDataSource) {
>>>>>>                         return (AttachmentDataSource) ds;
>>>>>>                 }
>>>>>>                 return null;
>>>>>>         }
>>>>>> 
>>>>>> Nothing!
>>>>>> 
>>>>>> On Tue, Oct 9, 2012 at 10:09 PM, Jason Pell <[email protected]>
>>>>>> wrote:
>>>>>> 
>>>>>>> heap size of 1024 does not help, so I would say its a bug.  I will put
>>>>>>> together a test project that demonstrates the problem and post a jira
>>>>>>> 
>>>>>>> On Tue, Oct 9, 2012 at 10:07 PM, Jason Pell <[email protected]>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Ok - so I used dd and
>>>>>>>> 
>>>>>>>> dd if=/dev/zero of=myfile bs=1 count=102400
>>>>>>>> 
>>>>>>>> This works :-)
>>>>>>>> 
>>>>>>>> dd if=/dev/zero of=myfile bs=1 count=102401
>>>>>>>> 
>>>>>>>> This does not
>>>>>>>> 
>>>>>>>> I will increase my heap space to ensure its not that.
>>>>>>>> 
>>>>>>>> On Tue, Oct 9, 2012 at 10:04 PM, Glen Mazza <[email protected]>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> It's not bizarre, it's just additional components are activated
>>>>>>>>> with schema
>>>>>>>>> validation, and it's either the size of the data or the contents of
>>>>>>>>> the data
>>>>>>>>> that is causing those additional components to go haywire.  It's
>>>>>>>>> good you're
>>>>>>>>> testing this for us; hopefully it's a bug we can fix (and not a
>>>>>>>>> memory/JDK
>>>>>>>>> issue.)
>>>>>>>>> 
>>>>>>>>> Glen
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 10/09/2012 06:57 AM, Jason Pell wrote:
>>>>>>>>> 
>>>>>>>>>> I will do that - however the bizarre thing is that its fine when
>>>>>>>>>> schema validation is disabled.  Also the content of the file is
>>>>>>>>>> streamed out when cxf:logging is enabled.  I can see that its
>>>>>>>>>> saved to
>>>>>>>>>> a temporary file.
>>>>>>>>>> 
>>>>>>>>>> On Tue, Oct 9, 2012 at 9:47 PM, Glen Mazza <[email protected]>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Link #45 has my MTOM tutorial, in case it's the way you're coding
>>>>>>>>>>> (also
>>>>>>>>>>> shows how to use Metro if you need a comparison), and link #34
>>>>>>>>>>> shows how
>>>>>>>>>>> you
>>>>>>>>>>> can debug a client and/or web service provider using Eclipse:
>>>>>>>>>>> http://www.jroller.com/gmazza/**entry/blog_article_index<http://www.jroller.com/gmazza/entry/blog_article_index>
>>>>>>>>>>> 
>>>>>>>>>>> To rule out the problem being the large filesize (as opposed to
>>>>>>>>>>> just some
>>>>>>>>>>> quirk in the data causing CXF to go haywire), you might want to
>>>>>>>>>>> split
>>>>>>>>>>> that
>>>>>>>>>>> 4MB into 2 - 2MB transmissions, and if the problem occurs in only
>>>>>>>>>>> one of
>>>>>>>>>>> the
>>>>>>>>>>> two transmissions, divide the problematic transmission into two
>>>>>>>>>>> (and so
>>>>>>>>>>> on)
>>>>>>>>>>> until you zero in on what is causing the problem.  Offhand, I
>>>>>>>>>>> would guess
>>>>>>>>>>> it's a filesize matter though.
>>>>>>>>>>> 
>>>>>>>>>>> HTH,
>>>>>>>>>>> Glen
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On 10/09/2012 06:12 AM, Jason Pell wrote:
>>>>>>>>>>> 
>>>>>>>>>>>> Hi,
>>>>>>>>>>>> 
>>>>>>>>>>>> If I upload a file 75k in size with Schema Validation enabled
>>>>>>>>>>>> everything
>>>>>>>>>>>> works.
>>>>>>>>>>>> If I upload a file 4 MB in size with Schema Validation enabled -
>>>>>>>>>>>> I
>>>>>>>>>>>> don't get any errors but the DataHandler.getInputStream is empty
>>>>>>>>>>>> If I upload a file 4 MB in size with Schema Validation DISABLED
>>>>>>>>>>>> - I
>>>>>>>>>>>> get my input stream as expected.
>>>>>>>>>>>> 
>>>>>>>>>>>> I am going to have a look at this myself but any pointers would
>>>>>>>>>>>> be
>>>>>>>>>>>> greatly appreciated
>>>>>>>>>>>> 
>>>>>>>>>>>> I am running against latest trunk maven deps (2.7.0-SNAPSHOT)
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> Glen Mazza
>>>>>>>>>>> Talend Community Coders - coders.talend.com
>>>>>>>>>>> blog: www.jroller.com/gmazza
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Glen Mazza
>>>>>>>>> Talend Community Coders - coders.talend.com
>>>>>>>>> blog: www.jroller.com/gmazza
>>>>>>>>> 
>>>>>>>>> 
>> 
>> --
>> Glen Mazza
>> Talend Community Coders - coders.talend.com
>> blog: www.jroller.com/gmazza
>> 
>> 

-- 
Daniel Kulp
[email protected] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Reply via email to