I've rewritten StringEscapeUtils by putting a mini-framework underneath it:
https://issues.apache.org/jira/browse/LANG-505 On the one hand, Lang has not been a place for frameworks. On the other hand, StringEscapeUtils has repeatedly shown a need to be much more pluggable and not tie the user into a particular way of working. We have bugs that are really different requirements. In essence the design is very similar to Entities, but taken a step further. This will also resolve the "Make Entities public" ticket/todo if that's still open. Other tickets can then be resolved by letting the users cheaply implement their own utility method on top of our code, or adding an alternative to Lang. StringEscapeUtils itself will probably get an API change anyway - escapeSql needs deleting imo. It needs escapeHtml32, 40, 50 variants, and escapeXml10, 11 variants. Or people need to be encouraged to call something like StringEscapeUtils.escape(Entities.XML_1_1_ESCAPE) and maybe the various escapeHtml type methods go away. Anyway... any opinions very much appreciated. Otherwise I'll keep hacking on things :) Hen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org