Camel
  1. Camel
  2. CAMEL-1537 Predicate for validation
  3. CAMEL-1276

Add validation feature to Camel framework in order to validate data linked/binded to POJO

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: 2.3.0
    • Component/s: None
    • Labels:
      None

      Description

      With bindy, jaxb and probably other binding frameworks, it would be interesting to have a validate option in camel that we can use in combination with by example unmarshall

      from(uri)
      .unmarshall(bindy or jaxb or ArtixDS or ...)
      .validate(nonblocking)
      .to())

      The purpose of this feature will be to :

      • verify mandatory fields/properties of POJO,
      • apply business rules on the data received,
      • ...

      Ex, in an csv record, the order n° field is mandatory and the order type must be equal to N for new order, C for cancel or U for update.

      Remarks :

      • One parameter that we can provide to the validation method could be "block or non block" to generate an array list of errors without creating an error in the application. This option is interesting because it allows to keep the POJO and save though Hibernate/Ibatis the data in the database and to send a report to the issuer to inform it about the errors found in the CSV, fixedlength, ... files received
      • Spring 3 who will provide validation support through annotation could be a good candidate.

        Activity

        Hide
        Claus Ibsen added a comment -

        Closing all resolved tickets from 2010 or older

        Show
        Claus Ibsen added a comment - Closing all resolved tickets from 2010 or older
        Hide
        Christian Müller added a comment -

        Claus, Charles,

        I like this DSL (may be with some additional parameters for the validate method as Charles described)

        from("foo")
        .unmarshall(jaxb)
        .validate()
        .to("bar")
        

        more than the DSL you have to use, if the bean validator is a separate component as described by me in CAMEL-2565

        from("foo")
        .unmarshall(jaxb)
        .to("bean-validator://x")
        .to("bar")
        

        If this features is based on JSR 303 (what is my preference), I think we introduce new dependencies into camel-core to:

        • javax.validation/validation-api
        • org.hibernate/hibernate-validator

        I'm right? Do you think this is ok?

        And sure, the "validate" method should also be validate against an XML schema, if the body is a string, document, ...
        and may be against a regular expression, if the content is a CSV or fixed length record...

        How to report validation failures:
        One possibility is to throw an exception (with the failure reason in it) which the user has to handle.
        A second possibility is to flag the exchange as failed (what the user can check with 'exchange.isFailed()') and provide the failure reason in an exchange property.
        The third possibility is like the second, but we flag the out message as fault (what the user can check with 'exchange.getOut().isFault()') and provide the failure reason in an out header.

        What do you think?

        In the mean time, I play a little bit with the ProcessorDefinitions and the DSL...

        Show
        Christian Müller added a comment - Claus, Charles, I like this DSL (may be with some additional parameters for the validate method as Charles described) from( "foo" ) .unmarshall(jaxb) .validate() .to( "bar" ) more than the DSL you have to use, if the bean validator is a separate component as described by me in CAMEL-2565 from( "foo" ) .unmarshall(jaxb) .to( "bean-validator: //x" ) .to( "bar" ) If this features is based on JSR 303 (what is my preference), I think we introduce new dependencies into camel-core to: javax.validation/validation-api org.hibernate/hibernate-validator I'm right? Do you think this is ok? And sure, the "validate" method should also be validate against an XML schema, if the body is a string, document, ... and may be against a regular expression, if the content is a CSV or fixed length record... How to report validation failures: One possibility is to throw an exception (with the failure reason in it) which the user has to handle. A second possibility is to flag the exchange as failed (what the user can check with 'exchange.isFailed()') and provide the failure reason in an exchange property. The third possibility is like the second, but we flag the out message as fault (what the user can check with 'exchange.getOut().isFault()') and provide the failure reason in an out header. What do you think? In the mean time, I play a little bit with the ProcessorDefinitions and the DSL...
        Hide
        Charles Moulliard added a comment -

        In fact Spring 3 will implement Hibernate Validator which is a expert group member of JSR 303 (Bean Validation)

        Show
        Charles Moulliard added a comment - In fact Spring 3 will implement Hibernate Validator which is a expert group member of JSR 303 (Bean Validation)

          People

          • Assignee:
            Christian Müller
            Reporter:
            Charles Moulliard
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development