[ https://issues.apache.org/jira/browse/CAMEL-9202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14948864#comment-14948864 ]
MykhailoVlakh commented on CAMEL-9202: -------------------------------------- Please note that the provided code changes are just for illustration of the found issues and you should not expect to compile and run this code. > 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 > 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)