Hi, I would stick to system properties, it is the easiest to implement and as the feature is something that only few will be concerned with, it can be non-obvious that this is possible.
Dominik. On Mon, Dec 17, 2018 at 3:48 PM pj.fanning <fannin...@yahoo.com> wrote: > 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 > >
