[
https://issues.apache.org/jira/browse/CAMEL-11932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16237410#comment-16237410
]
Marcin Domanski commented on CAMEL-11932:
-----------------------------------------
I agree, still I wouldn't leave it as is as current documentation suggests it
is implemented differently. I would either:
A) do a quick fix to the documentation stating that for marshaling you can
configure it and for un-marshaling you have to stick with defaults which is to
accept any mix of newline characters as line separator (including also NEL and
unicode line/paragraph separator)
B) introduce separate annotation properties that will allow us to set it up
independently and stick with current defaults for un-marshaling.
Of course option A) will not help in my use case, but at least it would be
clear for the other developers.
> For fixed length records crlf field is not honored during un-marshaling
> ------------------------------------------------------------------------
>
> Key: CAMEL-11932
> URL: https://issues.apache.org/jira/browse/CAMEL-11932
> Project: Camel
> Issue Type: Improvement
> Components: camel-bindy
> Affects Versions: 2.19.3
> Reporter: Marcin Domanski
> Priority: Minor
>
> Reading documentation [here|http://camel.apache.org/bindy.html] you can find
> that there is a {{@FixedLengthRecord.clrf}} annotation parameter described as:
> bq. optional - possible values = WINDOWS,UNIX,MAC, or custom; default value =
> WINDOWS - allow to define the carriage return character to use. If you
> specify a value other than the three listed before, the value you enter
> (custom) will be used as the CRLF character(s)
> Unfortunately it seems that this is honored only for marshaling, as for
> un-marshaling in {{BindyFixedLengthDataFormat.unmarshal()}}
> java.util.Scanner.nextLine() is used. This implementation ignores the crlf
> parameter during un-marshaling.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
