On 8/9/07, Gert Vanthienen <[EMAIL PROTECTED]> wrote: > > > Guillaume Nodet wrote: > > You mean a file based implementation of servicemix-audit ? > > See > > http://incubator.apache.org/servicemix/dist/servicemix-3.1-incubating/site/core/servicemix-audit/apidocs/org/apache/servicemix/jbi/audit/AuditorMBean.html > > > Yes, my first comment was exactly that: using an auditor for archiving > the files. This isn't the best solution for this particular issue, but > it still might be a worthwhile addition to ServiceMix. We still need to > find a good way to avoid having to load entire messages into memory > however. Anybody has any good suggestions for solving that?
I think a TeeInputStream should work perfectly. I guess this would be the best option for very large files (it would avoid reading the whole file twice). > > I think we should only backport bug fixes, do you ? > > But I'm open to discuss that, especially given the long release cycle > > we have (we really need to do something about that, btw). > > > That's exactly why I was asking. I think these branches are great for > doing bug fixes on an existing release, but I agree we should try to > avoid it for new features. What is holding us back to shorten the > release cycle (or even time-boxing it)? I'm trying to build a tool to > regenerate the legal files, so we can already avoid the pain of checking > those 'manually' every time. Is there anything else? > Nothing, really. I'd like the new endpoints for http and jms be finished, but nothing else. However it may be worth waiting for the board meeting (one or two weeks) so that we can remove the incubation disclaimers and have a release that we can put on maven public repositories. Wdyt? -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/
