[
https://issues.apache.org/jira/browse/CAMEL-9202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-9202:
-------------------------------
Fix Version/s: 2.17.0
2.16.2
> Flatpack: Body reader never closed
> -----------------------------------
>
> Key: CAMEL-9202
> URL: https://issues.apache.org/jira/browse/CAMEL-9202
> Project: Camel
> Issue Type: Bug
> Components: camel-flatpack
> Affects Versions: 2.14.3
> Reporter: MykhailoVlakh
> Fix For: 2.16.2, 2.17.0
>
> Attachments: patchfile.diff
>
>
> Hello Camel team,
> First of all I want to thank you for all great work you do to provide such a
> powerful tool as Camel. I really enjoy using it in my work.
> Currently I am working on an application that requires delimited and fixed
> width parsing tools and I decided to use Camel Flatpack because we already
> use some other Camel stuff. We use Camel 2.14.3 which is not the latest one
> but forks fine. During my work with Flatpack consumer I found several issues
> and some room for improvements and I decided to share my thoughts/findings
> with you. Our team have plans to migrate to the latest version of Camel in
> near future and we all will be happy if the new version includes
> fixes/improvements that I am goint to suggest.
> The main issue that I found is that flatpack endpoint does not close body
> reader if an exception is thrown during parser creation step. As a result the
> related resource remains opened forever. For example in my cases when PZMAP
> files was missing my data file (csv file) was locked and my file consumer
> ended in endless loop in which it was trying to move a file to .error folder
> but was not able to do this because the file was opened for read.
> Another problem that I noticed is that I cannot use allowShortLines and
> ignoreExtraColumns attributes if my parser uses inline headers from files.
> Flatpack simply ignores them in this case.
> Finally I think that there is some room for improvements:
> * It would be nice to have a possibility to provide PZMAP as a bean via JNDI
> context instead of having to generate a file. This feature will be very
> useful and content parsing should work faster because the XML will be read
> from memory instead of reading it from a file each time you parse some
> content;
> * It would be nice to have a possibility to provide content format as an URI
> attribute instead of using these ugly URI prefixes that we should use right
> now. With such possibility in plase URI will look the same all the time and
> developers won't need to reformat URI differently for different content types.
> I attached a patch file with code fragments and comments to them that
> illustrate my findings/thoughts. Unformtunatelly I don't have enough time to
> provide real fixes and unit tests so please excuse me for this.
> Please let me know if something is unclear or require more details.
> Looking forward for your feedback,
> Mykhailo
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
