[jira] [Updated] (CAMEL-5958) Bindy ignores bean class type

["Luca Burgazzoli (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-5958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Luca Burgazzoli updated CAMEL-5958:
-----------------------------------

          Component/s: camel-bindy
          Description: 
It looks like camel-bindy does not take into account the class specified in the method:

    bindy(BindyType.Csv, MyCamelBeans.TEST.class)

I have class MyCamelBeans which includes several "bindies" among which I have a really simple MyCamelBeans.TEST:

    class MyCamelBeans {
        @CsvRecord(separator=";",isOrdered=true)
        public static final class TEST {
            @DataField(trim=true,pos=  1) public String tradingDate;
            @DataField(trim=true,pos=  2) public String isinCode;
        }

        ... some other @CsvRecord ....
    }

I also have some @FixedLengthRecord classes defined in the same package.
If I run the following route:

    from("file:data/test?noop=true&idempotent=true&fileName=test.csv&delay=60000")
        .split(body(String.class).tokenize("\n")).streaming()
        .unmarshal().bindy(BindyType.Csv, MyCamelBeans.TEST.class)
        .to("log:DS?level=INFO&showHeaders=true");

Camel (2.10.3) fails with an NPE:

    java.lang.NullPointerException
            at org.apache.camel.dataformat.bindy.BindyCsvFactory.setDefaultValuesForFields(BindyCsvFactory.java:583)
            at org.apache.camel.dataformat.bindy.BindyCsvFactory.bind(BindyCsvFactory.java:230)

if I remove the other bindies, camel-bindy works as expected. 

Looking at the code, I've found that in BindyAbstractFactory.java :

    /**
     * method uses to initialize the model representing the classes who will
     * bind the data. This process will scan for classes according to the
     * package name provided, check the annotated classes and fields.
     *
     * @throws Exception
     */
    public void initModel() throws Exception {
        // Find classes defined as Model
        if (packageNames != null)  {
            initModelClasses(this.packageNames);
        } else if (type != null) {
            // use the package name from the type as it may refer to types in the same package
            String pckName = type.getPackage().getName();
            initModelClasses(pckName);
        } else {
            throw new IllegalArgumentException("Either packagenames or type should be configured");
        }
    }

Looks like bindy scan the package even a class has been specified. 


Accordin to Claus, bindy needs to be refactored so it
- requires the class type (no more packages)
- uses the class type as root model
- ... and initializes the model from the root, and follow and
references to other classes (if the root has childs)

This avoids picking up any other models.
And we would know to marshal/unmarshal based on the root. 

             Priority: Minor  (was: Major)
    Affects Version/s: 2.10.3
              Summary: Bindy ignores bean class type  (was: bindy ignores bean class type)
    
> Bindy ignores bean class type
> -----------------------------
>
>                 Key: CAMEL-5958
>                 URL: https://issues.apache.org/jira/browse/CAMEL-5958
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-bindy
>    Affects Versions: 2.10.3
>            Reporter: Luca Burgazzoli
>            Priority: Minor
>
> It looks like camel-bindy does not take into account the class specified in the method:
>     bindy(BindyType.Csv, MyCamelBeans.TEST.class)
> I have class MyCamelBeans which includes several "bindies" among which I have a really simple MyCamelBeans.TEST:
>     class MyCamelBeans {
>         @CsvRecord(separator=";",isOrdered=true)
>         public static final class TEST {
>             @DataField(trim=true,pos=  1) public String tradingDate;
>             @DataField(trim=true,pos=  2) public String isinCode;
>         }
>         ... some other @CsvRecord ....
>     }
> I also have some @FixedLengthRecord classes defined in the same package.
> If I run the following route:
>     from("file:data/test?noop=true&idempotent=true&fileName=test.csv&delay=60000")
>         .split(body(String.class).tokenize("\n")).streaming()
>         .unmarshal().bindy(BindyType.Csv, MyCamelBeans.TEST.class)
>         .to("log:DS?level=INFO&showHeaders=true");
> Camel (2.10.3) fails with an NPE:
>     java.lang.NullPointerException
>             at org.apache.camel.dataformat.bindy.BindyCsvFactory.setDefaultValuesForFields(BindyCsvFactory.java:583)
>             at org.apache.camel.dataformat.bindy.BindyCsvFactory.bind(BindyCsvFactory.java:230)
> if I remove the other bindies, camel-bindy works as expected. 
> Looking at the code, I've found that in BindyAbstractFactory.java :
>     /**
>      * method uses to initialize the model representing the classes who will
>      * bind the data. This process will scan for classes according to the
>      * package name provided, check the annotated classes and fields.
>      *
>      * @throws Exception
>      */
>     public void initModel() throws Exception {
>         // Find classes defined as Model
>         if (packageNames != null)  {
>             initModelClasses(this.packageNames);
>         } else if (type != null) {
>             // use the package name from the type as it may refer to types in the same package
>             String pckName = type.getPackage().getName();
>             initModelClasses(pckName);
>         } else {
>             throw new IllegalArgumentException("Either packagenames or type should be configured");
>         }
>     }
> Looks like bindy scan the package even a class has been specified. 
> Accordin to Claus, bindy needs to be refactored so it
> - requires the class type (no more packages)
> - uses the class type as root model
> - ... and initializes the model from the root, and follow and
> references to other classes (if the root has childs)
> This avoids picking up any other models.
> And we would know to marshal/unmarshal based on the root. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira