For me, this kind of optimisation needs to be configurable. Most users would not need this performance optimisation and would be better off to get the full stack trace.
I would pitch that something like XmlOptions in the XMLBeans project is a useful model. This allows users to choose to override the default behaviour of the lib. It's a little bit prettier than using System properties but it might be a lot of work to wire a PoiOptions class into our APIs, even if we just started with some APIs where we could make use of it. Options include: * Roll out PoiOptions in these evaluation APIs (probably a lot of work and to not break API contracts, we'd need to have to add lots of new methods that take the new class as a param) * Look for the PoiOptions on ThreadLocal so that users can set PoiOptions just on the threads where they want to override the default behaviour * Expose PoiOptions as a static variable eg PoiOptions.getInstance() so that users can update the settings and affect the whole JVM (easiest to write and easiest to use) * Use System variables -- Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
