All, Are there any plans to provide a mechanism where-by clients of DefaultMessageBuilder can set RecursionMode.M_NO_RECURSE as the recursion mode for the underlying MimeTokenStream?
I see that it is possible to set M_RECURSE and M_FLAT, but no way to set M_NO_RECURSE (or M_RAW). M_NO_RECURSE is needed for my current project, as it appears to be the only way to have mime4j provide me with a "getInputStream()" method for entities with a mime type of "message/rfc822" but still behave normally otherwise (I still want recursion to occur for multipart/* parts, for example). As a result, for my project, I had to create my own MessageBuilder implementation (I simply extended DefaultMessageBuilder then overrode the parseMessage method). But then I discovered that the EntityBuilder class, required by MessageBuilders, is declared package-private. So I had to copy and paste the entirety of EntityBuilder from the mime4j sources into my project. That, in turn, has caused my reported unit test coverage to drop significantly, as EntityBuilder is a fairly large class, and worse yet, it doesn't appear to have an associated unit test that I can copy/paste. So now I am facing having to write a unit test for a fairly complex chunk of copied and pasted code that I didn't write, don't maintain, and that I'm not familiar with. The "Default" in the name "DefaultMessageBuilder" seems to imply that clients should be able to implement their own MessageBuilders, but making EntityBuilder package private would appear to make that task exceedingly difficult. It would be nice to have something like a "setNoRecurseMode(boolean)" method on DefaultMessageBuilder itself, or at least for EntityBuilder to be declared public so that clients can create their own MessageBuilders without having to copy and paste code. Should I open a Jira and submit a patch? Or is there a way to do what I need that I'm just not seeing? Thanks! -Rob L
