Hi
> Am 11.07.2015 um 19:44 schrieb Tilman Hausherr <thaush...@t-online.de>:
>
> Yesterday user Roberto had a problem where a file wasn't saved with
> encryption. The cause turned out to be that he had called
>
> setAllSecurityToBeRemoved(true)
>
> and then
>
> protect(...)
>
> I didn't find it by looking at his code, only after debugging in save().
>
> Although the javadoc of both calls is clear, I see a risk that this happens
> again, e.g. when people combine existing code.
>
> What should be do? Options:
>
> 1. nothing
> 2. mention the risk in javadoc
> 3. if allSecurityToBeRemoved is true in protect(), call LOG.warn("call
> setAllSecurityToBeRemoved(false) before saving or file won't be encrypted");
> 4. if allSecurityToBeRemoved is true in protect(), throw an
> IllegalStateException
> 5. set allSecurityToBeRemoved to false when protect() is called
>
> I'm for options 3 or 4.
I'd go for option 5 together with a warning as the call to protect() shows the
intention and add that to the javadocs.
BR
Maruan
>
> Tilman
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
> For additional commands, e-mail: dev-h...@pdfbox.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
