I build locally from trunk this morning and the results look good:
https://corpora.tika.apache.org/base/reports/poi-5.2.4-vs-5.2.5-reports.tgz
Many thanks, PJ and team!
On Thu, Nov 16, 2023 at 6:46 PM PJ Fanning
wrote:
> The RC will possibly be based on
> https://ci-builds.apache.org/job/POI/jo
The RC will possibly be based on
https://ci-builds.apache.org/job/POI/job/POI-DSL-1.8/1002/ which just
succeeded. I still need to check some other builds but I would expect that if
any more changes are needed that they will be small.
On Thursday 16 November 2023 at 22:59:42 GMT+1, PJ Fanni
The build is not stable at the moment. Looks like there are some build fixes
needed before we can get an RC ready.
On Thursday 16 November 2023 at 22:41:28 GMT+1, Tim Allison
wrote:
I can have regression test results by tomorrow end of the work day Eastern
time if that would be of an
I can have regression test results by tomorrow end of the work day Eastern
time if that would be of any use. I don't know if that works for your
schedule, PJ?
On Thu, Nov 16, 2023 at 3:36 PM PJ Fanning wrote:
> XMLBeans 5.2.0 is being released over the next few hours.
>
> I can update POI to us
XMLBeans 5.2.0 is being released over the next few hours.
I can update POI to use the new XMLBeans version.
I think we can then create an RC1 for POI 5.2.5. I can do this. Maybe tomorrow.
According to Tim Allison, Apache Tika are waiting for this release [1].
The changes are listed here [2].
[
pls enjoy code and wait for sometime. iam OOO.
On Mon, Oct 9, 2023, 5:17 PM PJ Fanning wrote:
> HI everyone,
>
> I think the regression in issue 67579 [1] is serious to warrant a new POI
> release. With that in mind, could we ramp down on changes while we decide
> if we want to release soon.
>
>
Hi,
According to my testing, ALL versions since 3-something did close
InputStream when you use XSSFWorkbook or OPCPackage, so this has been the
established behaviour for quite some time in Apache POI.
The change in ZipPackage in 66584 seems to have caused a close() even if no
exception is thrown,
HSSFWorkbook(InputStream) closes its InputStream. So this is really a mess. So
I guess the best is for XSSFWorkbook to also close its InputStream. We can
document this and warn users that this is the behaviour and that they can work
around it by using something like NoCloseInputStream.
https://
Can I clarify?
You want https://bz.apache.org/bugzilla/show_bug.cgi?id=67579 reverted?
If I interpret the poi-reproduce results correctly, there is a regression from
5.2.3 to 5.2.4 in the stream case.
The behaviour might have changed in 5.2.2 to 5.2.3 migration but it still means
that there is
Hi,
ah, sorry, seems I did not take a close enough look myself until now.
I wanted to be sure what the state was before and how it should be. See the
"reproducer" project at https://github.com/centic9/poi-reproduce and the
resulting summary:
3.17 4.0.0 4.0.1 4.1.0 4.1.1 4.1.2 5.0.0 5.1.0 5.2.0
I cannot reproduce the leaked file handle. This test case does not leak files.
I tested with `lsof -f`. I had a file handle until I closed the xssfWorkbook
but not after.
File file = ...
XSSFWorkbook xssfWorkbook = new XSSFWorkbook(file);
// some Thread.sleep(...) here - use `lsof- f` during thi
I will try to set up some debugging of the File path. I am not convinced that
the ZipPackage InputStream changes affect the behaviour when you provide a File
instead. The code handles Files and InputStreams differently.
On Wednesday 25 October 2023 at 07:24:52 IST, Dominik Stadler
wrote:
Hi,
We now leave open file-handles whenever the constructor for "File" is used
in ZipPackage. Not sure if the background Java support for closing stale
file-handles will capture those or if we will see "too many open files" in
large environments.
Can we only wrap the stream in NoCloseStream when
Are we in a position to proceed with a 5.2.5 RC1?
On 2023/10/16 10:23:42 Tim Allison wrote:
> This just bit us on Tika:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=67767
>
> The fix is easy. I can patch it today. It would be great to get it into
> 5.2.5. I'm sorry that I didn't catch it d
This just bit us on Tika:
https://bz.apache.org/bugzilla/show_bug.cgi?id=67767
The fix is easy. I can patch it today. It would be great to get it into
5.2.5. I'm sorry that I didn't catch it during the earlier regression
tests...my fault.
On Sun, Oct 15, 2023 at 4:34 PM Dominik Stadler
wrote:
Only a small fraction of the tests using try-with-resources. So it is just
possible that there are some bad tests that don't close the resources
explicitly.
On Sunday 15 October 2023 at 21:34:52 IST, Dominik Stadler
wrote:
Hi,
I use file-leak-detector when running tests locally, th
Hi,
I use file-leak-detector when running tests locally, this shows any
left-over file-handles when running tests via the IDE.
See https://github.com/jenkinsci/lib-file-leak-detector
If you clone the latest version and build the tool locally via Maven, you
can add something like the following in
Thanks Dominik for the feedback. The probable breaking change was:
https://svn.apache.org/viewvc/poi/trunk/poi-ooxml/src/main/java/org/apache/poi/openxml4j/opc/ZipPackage.java?r1=1909467&r2=1909466&pathrev=1909467
There have been some more changes, eg using java.nio.files.File to create
InputSt
Hi,
FYI, the current fix for not closing streams also does not close any stream
opened via a "File" parameter, so we are introducing many unclosed
resources via this change at the moment.
Can we solve this somehow differently? Maybe cleanly revert the change
which introduced it?
Thanks... Domini
HI everyone,
I think the regression in issue 67579 [1] is serious to warrant a new POI
release. With that in mind, could we ramp down on changes while we decide if we
want to release soon.
I can do this one again unless someone else wants to do it.
Regards,
PJ
[1] https://bz.apache.org/bugzil
20 matches
Mail list logo
