[Bug 60847] CTPlotArea OOXML type needs a cleaner interface
https://bz.apache.org/bugzilla/show_bug.cgi?id=60847 Alain Fagot Bearez changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #3 from Alain Fagot Bearez --- I understand there are still many chart types that are not yet implemented under the XDDF component in 4.0.0. Many features have been badly and incompletely tested, when tested at all. Anyhow I would appreciate some feedback about the @Beta versions already available and the rough edges that are still present for your experimented use cases. Of special interest would be your "missing nice access for them"... -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
[GitHub] poi pull request #125: fix for Bug 60509
GitHub user Alain-Bearez opened a pull request: https://github.com/apache/poi/pull/125 fix for Bug 60509 https://bz.apache.org/bugzilla/show_bug.cgi?id=60509 All the code was provided by Guillaume de GENTILE in https://bz.apache.org/bugzilla/show_bug.cgi?id=54470, only waiting for the XDDF package to be ready, since 2015. You can merge this pull request into a Git repository by running: $ git pull https://github.com/cuali/poi bug-60509 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/poi/pull/125.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #125 commit 33fc3ec972f790e9c78d43f5e86aa059f2451bfe Author: Alain FAGOT BEAREZ Date: 2018-09-26T21:05:01Z extract valuable code from 54470 submitted patch commit c90c2a2c7d777c9a9047ad73b76f145860f7f53d Author: Alain FAGOT BEAREZ Date: 2018-09-28T01:48:38Z add test for bug 60509 --- - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
Re: "Could not resolve external workbook name" after setupReferencedWorkbooks
I recently got this working, but noticed these points of fragility in doing so with the current released code: 1. If the file names had spaces in them, I had to replace them with "%20" in the map keys passed to setupReferencedWorkbooks(), as that's the value used in the stored formula expressions in my end-user produced workbooks. 2. I had to be very careful to map the exact FormulaEvaluator instances used with each workbook. If the map contained an evaluator instance different than the one doing the evaluating for any expression, I would get the same error you did. 3. I had to call formulaEvaluator.setupReferencedWorkbooks(evaluatorMap) for _every_ evaluator in the map, and again, the map had to reference the exact same evaluator instance as the one having its setup method called. It turns out at first I had several places where new FormulaEvaluator instances were being created, often via workbook.getCreationHelper().createFormulaEvaluator() behind the scenes. This caused no end of grief until I could ensure the same instance was used for a given workbook in a given thread every time. I hope this helps. Any thoughts or patches that might help facilitate documenting how to set it up and perhaps validating setup when calling would be appreciated. I agree this is an area that is lightly documented and easy to encounter problems with complex causes that are hard to trace. On Wed, Sep 26, 2018 at 5:26 PM wimgoe...@gmail.com wrote: > Hello, > > I need to evaluate all the formulas in a workbook which has references to > other workbooks. Based on my findings I found that I had to use > FormulaEvaluator#setupReferencedWorkbooks in order to link all the > workbooks, but that did not work, and still resulted in a RuntimeException > saying "Could not resolve external workbook name 'file.xlsx'. Workbook > environment has not been set up." > > I managed to work around the problem through some hacks with reflection. > > BaseFormulaEvaluator seems to use static members of > CollaboratingWorkbooksEnvironment, which creates instances of > CollaboratingWorkbooksEnvironment. However, these instances seem to be > constructed but not used (see CollaboratingWorkbooksEnvironment.java:75 -- > [new CollaboratingWorkbooksEnvironment(evaluatorsByName, evaluators);]) > > I copied the contents of those methods to create a > CollaboratingWorkbooksEnvironment, and forced it into the > _collaboratingWorkbookEnvironment field of my WorkbookEvaluator instance. > This solved my problem entirely. > > Since this solved my issue I suspect this is a bug, so decided to share it > here in the hopes it may get fixed in the official repository. > > Best regards, > Wim > > - > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > >
[Bug 62768] OPCPackage#close() method is incorrectly synchronized
https://bz.apache.org/bugzilla/show_bug.cgi?id=62768 --- Comment #4 from PJ Fanning --- I'll remove the synchronized keyword -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
[Bug 62768] OPCPackage#close() method is incorrectly synchronized
https://bz.apache.org/bugzilla/show_bug.cgi?id=62768 --- Comment #3 from Danila Galimov --- Yes, I agree, maybe the synchronization should be removed at all, but the classes should be annotated that they are designed to be used in single-thread environment only. I just opened the file and found dummy synchronization which won't work anyway, that's why i reported this. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
[Bug 62768] OPCPackage#close() method is incorrectly synchronized
https://bz.apache.org/bugzilla/show_bug.cgi?id=62768 --- Comment #2 from Dominik Stadler --- I am wondering why we even use synchronization here at all. Our thread-safety guarantee does not allow to use one workbook/doc/item in more than one thread at a time anyway. So this synchronization is not really necessary as we ask our users to perform synchronization at an upper level anyway, if they want to access documents across different threads... Having all of POI fully thread-safe would require many many points of synchronization and would cause a performance penalty for many current power-users. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
[Bug 62768] OPCPackage#close() method is incorrectly synchronized
https://bz.apache.org/bugzilla/show_bug.cgi?id=62768 PJ Fanning changed: What|Removed |Added OS||All Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #1 from PJ Fanning --- https://svn.apache.org/repos/asf/poi/trunk@1842142 -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
[Bug 62768] New: OPCPackage#close() method is incorrectly synchronized
https://bz.apache.org/bugzilla/show_bug.cgi?id=62768
Bug ID: 62768
Summary: OPCPackage#close() method is incorrectly synchronized
Product: POI
Version: 4.0.0-FINAL
Hardware: PC
Status: NEW
Severity: major
Priority: P2
Component: OPC
Assignee: dev@poi.apache.org
Reporter: b...@mail.ru
Target Milestone: ---
Created attachment 36168
--> https://bz.apache.org/bugzilla/attachment.cgi?id=36168=edit
multi-thread runner
There is a code in OPCPackage#close() method, which creates and uses a lock:
ReentrantReadWriteLock l = new ReentrantReadWriteLock();
try {
l.writeLock().lock();
...
} finally {
l.writeLock().unlock();
}
However, it is completely useless since the *new* lock object is always created
for any method execution, thus voiding this lock.
Suggested change - either move l to a class field and initialize it in
constructor, or simply use synchronized section as read/write lock is not
really needed here.
I attached the sample which runs close() method from multiple thread - as you
can see, they are not synchronized with each other.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org
For additional commands, e-mail: dev-h...@poi.apache.org
Re: xmlbeans 3.0.2 release?
+1 Je 2018-09-26 19:54, Javen O'Neal skribis: +1 On Wed, Sep 26, 2018, 14:53 pj.fanning wrote: Should we do an XMLBeans 3.0.2 release? https://issues.apache.org/jira/browse/XMLBEANS-520?jql=project%20%3D%20XMLBEANS%20AND%20fixVersion%20%3D%20%22Version%203.0.2%22 -- 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 - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
