Bug 1066350

Hi Keith,

our release date comes closer. When do you think can we expect a fix for the camel xsd validation bug? I don't wanna go live with the replaced jar, since we don't know if it has other negative impacts.

Thanks
Yusuf

Hi Yusuf,

GSS will begin helping with this case.  Thanks for the reproducer.

Please let us know if 8 weeks out is too late to help you.  (This BZ is now part of a scheduled 'Roll up' patch we will release around that timeframe.)   If we need to, we may be able to produce a "One off" fix faster but this will be a temporary measure.

Please let us know more about your timing needs.

Regards,

Rick

Created attachment 883805 [details]
how to apply SwitchYard Message Validator

Hi Yusuf,

I found a bug around camel validator on camel JIRA:
https://issues.apache.org/jira/browse/CAMEL-6013

So I tried it against SwitchYard 2.0.0-SNAPSHOT which is using camel-2.12.2, but then I hit another existing bug:
https://issues.apache.org/jira/browse/CAMEL-7036

For now, I would recommend using SwitchYard Message Validator instead. Please take a look at attached diff and following doc.
https://docs.jboss.org/author/display/SWITCHYARD/XML+Validator

Apparently we hit this bug which is fixed at camel-2.10.7:
https://issues.apache.org/jira/browse/CAMEL-6538
https://github.com/apache/camel/commit/9ac5de93ed794aeb38f499c471967b316adb21d4

Yusuf, could you try if you can get around this bug with specifying "classpath:" prefix?
>>>
    .validator("validator:classpath:canonical.xsd")
<<<

I'll try it as well once I setup FSW6 (now downloading...).

I tried the "classpath:"prefix and didn't work. But instead of that, it was deployed successfully if I just created src/main/resources/xsd directory and moved all XSDs into the directory. Then adjust the JavaDSLBuilder like this:
.validator("validator:xsd/canonical.xsd")

Basically this CAMEL-6538 is caused by the XSD which is located at root directory of the classpath, so creating directory and move into it avoid the issue.

But then, I hit CAMEL-7036 again, even on FSW6.0:
https://issues.apache.org/jira/browse/CAMEL-7036

So I think the patch we really need to get this work is a backport for the CAMEL-7036.
https://github.com/apache/camel/commit/300ecab4fa18c8988335a393eeb0b2302ff6f1c9

Created attachment 883939 [details]
patched camel-core jar (2.10.0.redhat-60024+CAMEL-7036)

OK, confirmed it works once I cherry-pick the commit for CAMEL-7036 (c14b4f380d20f29330cc30ac6e2c49f04c23d256) on top of camel-2.10.0.redhat-60024

Please don't forget to move all XSDs into subdirectory before trying.

Hey Rick,

our initial release plan was
QA:    2014/04/14
Stage: 2014/04/28
Prod:  2014/05/05

But we found an issue in A-MQ 6.0 which will be fixed in 6.1. I think we will postpone the push by 2 weeks when we assume that A-MQ will released during Red Hat Summit.

Thanks
Yusuf

Hi Yusuf,

Great, thanks for that information.

Did we ever get a proper support ticket opened up (with Dave Carmichael)?
The reason I ask is that we can use that to monitor and track this BZ.  (BZs don't carry reminders, SLAs, etc.  So they can slip through the cracks more easily.)  Please try to get one of those so we can better track this, we'll have some coordination to do.

About that coordination..... it seems the timeframe will dictate that we should adapt Tomo's fix (referenced above) as a One-off.  (Because it will be available in time, the Roll up that will include this fix will not.)  So I think what we'll need to do:

- Get QE to validate Tomo's fix
- Have you validate Tomo's fix
- If both of these check out, you go with that fix for your Roll out
- Later, we add this to FSW Roll up 2 (as described earlier)
- Roll up 2 goes through QE, with other patches
- When Roll up 2 is available, you can upgrade to it and no longer have a One-off environment

Please consider, offer your thoughts.  It is going to be best if you can upgrade when the 'official' patch is available with the Roll up, else you won't have a way to consume CVEs, other bug fixes, etc.

I'll start talking to QE about checking this as a One-off.

Thanks,

Rick

Rick,

I will definitely review Tomo's fix. One thing I don't like is the requirement to move all xsd's into a subdirectory. This would require some changes on our side.
Why can we not apply same logic from camel-core-2.10.0.jar where it is working like expected?

Btw, I created the case
https://access.redhat.com/support/cases/01066931/

Thanks
Yusuf

Created attachment 884298 [details]
patched camel-core jar (2.10.0.redhat-60024+CAMEL-7036+CAMEL-6538)

Attaching a patched camel-core jar - cherry-picked following two commits on top of 2.10.0.redhat-60024. I tested it with the testcase and it works without moving XSDs into subdir.

==========================================================
commit 3dfaa78468819ca340c5943db5d932d05b598aa2
Author: Claus Ibsen <davsclaus>
Date:   Thu Jul 11 10:55:12 2013 +0200

    CAMEL-6538: NPE in validator component if no classpath prefix

commit 81a66870d70c993e2de00b9bf14f562c7caf080e
Author: Willem Jiang <willem.jiang>
Date:   Wed Dec 4 12:51:50 2013 +0800

    CAMEL-7036 Fixed the issue of Camel XSD validation not working with apache xerces

Hi Tomo,

your latest library with CAMEL-6538 and CAMEL-7036 works.
Will this fix be part of FSW 6.1?

Thank you very much for your help and for your support!
Yusuf

Thanks a lot Rick

Rick - you asked that FSW QE run Camel regression tests on this - to verify that no new issues are introduced - will you re-open the bz and assign it to QE?

Thanks for that note, Len.

As requested:  Please validate Camel through regular regression tests.  Our customer (Yusuf) has validated the broken use case, so we are confident this part works.  Let's just give it a look to make sure nothing else about Camel broke with this one.

Thanks!

Rick

P.S.  For posterity:  This BZ has been cloned to another BZ which will push this change into FSW 6.1.  So Yusuf (and other customers) can upgrade at 6.1 time to get away from a "One off" environment.

We applied the patched jar (2.10.0.redhat-60024+CAMEL-7036+CAMEL-6538) and are now seeing further issues.

We have a camel DSL route where we take a domain object, marshall it, and then validate that it conforms to an XSD. This is now throwing an exception:
java.lang.IllegalArgumentException: Source parameter of type 'javax.xml.transform.stax.StAXSource' is not accepted by this validator.
         at org.apache.xerces.jaxp.validation.ValidatorImpl.validate(Unknown Source)
         at org.apache.camel.processor.validation.ValidatingProcessor.process(ValidatingProcessor.java:126)
         at org.apache.camel.impl.ProcessorEndpoint.onExchange(ProcessorEndpoint.java:101)
         at org.apache.camel.impl.ProcessorEndpoint$1.process(ProcessorEndpoint.java:71)
         at org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61)
         at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)
         at org.apache.camel.processor.SendProcessor$2.doInAsyncProducer(SendProcessor.java:122)
         at org.apache.camel.impl.ProducerCache.doInAsyncProducer(ProducerCache.java:298)
         at org.apache.camel.processor.SendProcessor.process(SendProcessor.java:117)

This issue does not exist in the camel-core-2.10.0.jar mentioned above.

The attached test case could be modified to reproduce (simply unmarshall/marshall before validation).

Thanks,
Kevin

According to this JIRA, StAXSource is not supported on EAP6.1:
https://issues.jboss.org/browse/JBEAP-41

Could you just use StreamSource or something instead of StAXSource?

Maybe adding <convertBodyTo type="javax.xml.transform.stream.StreamSource"/> right before the validator. Please provide a reproducer if it doesn't work.

this BZ was reproduced and verified to be fixed, tested with QA integration testsuite - PASS (no regression seen)

a9a774354cb3ce7598d883b0c970d2c6 camel-core-2.10.0.redhat-60024.jar

Created attachment 887197 [details]
Packaged patch for BZ1066350, this artifact for upload to CSP

Please upload this patch to the CSP.  Thank you!

https://access.redhat.com/jbossnetwork/restricted/softwareDetail.html?softwareId=29363&product=jboss.fuse.serviceworks&version=6.0.0&downloadType=patches

per RT 290280
https://engineering.redhat.com/rt/Ticket/Display.html?id=290280