Re: Throwing EvaluationException slows down evaluation, proposed change: not fill stack trace
Based on my experience, that setting system properties in web applications involves discussions with the web admins, I don't like system properties at all. Although [1] says the opposite, I guess (but haven't tried) that context-param aren't automatically set as system properties. Is [1] true for all major j2ee/web containers? If not, can we use a different approach? e.g. statics set by user code Andi [1] https://www.mkyong.com/web-development/how-to-pass-system-properties-in-web-xml/ -- 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
Re: Throwing EvaluationException slows down evaluation, proposed change: not fill stack trace
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 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 > >
Re: Throwing EvaluationException slows down evaluation, proposed change: not fill stack trace
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
Re: Throwing EvaluationException slows down evaluation, proposed change: not fill stack trace
fixes: 1. *6+ times higer 2. Perhaps even the error message can be omitted because one can get it from the stored ErrorEval. - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
