Report files not closed

Do you have a sample project that reproduces the issue?

I think I noticed this a while back as well, but I didn't get around to actually checking out why this happens. I have created a sample project that shows the problem, however this is only noticeable in Windows since open files cannot be deleted in Windows, but this is possible in Linux (if your directory is on nfs you may get leftover nfs files for the open delete files).

this is basically a project created with the simple archetype plus a main class that calls the run method and waits.
If you run the test and then try to delete the files in the target/jbehave in Windows, the java process has the files locked and they are only released when the jvm exits.
It may be possible to observe the open files with lsof in Linux, I haven't tried that since I not have a Linux machine available right now.

Thanks for attaching the sample Alexander.

haven't had time to look at the actual problem though

I guess PrintStreamOutput needs a close() method that closes the PrintStream that is called when a report is finished.
Or the StoryReporter interface needs a finish or close method that is called to close the Stream if there is one.

Does anybody have an idea how to generically check for open files?

I guess it would be possible in this case to create a subclass of FilePrintStreamFactory that gives out a PrintStream that can be checked if it was closed, but I wonder how this could be solved in general.

If I wanted to look into this, where would I start? I mean where are the files that are being written actually opened?

The report files are created by FilePrintStreamFactory.createPrintStream(), which is called when the respective Format is processed in StoryReporterBuilder
the main problem is finding the point where the PrintStream could be closed and then finding the PrintStreams that should actually be closed.
I started trying to implement a close() method for each StoryReporter that takes care of closing the PrintStream and passing the close call to the delegate reporter etc. This does not yet work correctly, until now I can close the Before and After report files.

However the report files are still open, so they are apparently opened later in the code again and these streams are not closed either (i.e. each open file is leaked more than once). I haven't found out where this happens yet.

They should be closed in the afterStory(boolean givenStory) method of the PrintStreamOuput.

Have a look at the TemplateableOutput - it does something similar.

thanks, that takes care of a few open files, but there are still some leaks.
I will look a bit further.

Fixed JBEHAVE-848: Report files not closed

added close() calls to afterStory in PrintStreamOutput and to a few Writers that were not closed.
And changed a few calls that where constructing streams as a parameter to IOUtils.toString.

https://github.com/alexlehm/jbehave-core/commit/31000d962e0382bca6dddfebe8b7ccb2fb5009ba

I should add that of course I'm not sure if I caught all files, however I checked that test program doesn't have files open.

The changes do not contain any unit tests since I am still not sure how to test this, maybe I can add some later.

Patch pulled. Added a custom IOUtils class for JBehave to collect methods with close option.

Pushed new 3.8-SNAPSHOT release.

Pascal, can you please test snapshot? If working we'll cut the 3.7.4 release.

I thought about extracting the method as well but didn't get around to doing it yet.
To be completely correct, the close method should be in a finally block, in case of an IOException otherwise the file will remain open (I can add that, if you like)

On a side note, I think calling the class IOUtils as well is not good since it makes the methods from the other class available only by complete package name, maybe the class could be called IOUtils2 ?

If there is an IOException, I'm not sure it would be closable anyway. And in any case, the exception is handled upstream. Let's deal with this when there is a more concrete scenario to satisfy.

As for the name of the class, there are plenty IOUtils around in several libs. The users will choose the one that they need (and if need be use the full package name). I don't like xxx2 names. They don't mean anything. Also, this IOUtils is intended for internal use, as a replacement for the commons-io one. Most likely, you won't be using it in conjunction with commons-io.

I think it might be closable, depending on when the exception happened (in most cases the exception will be something like file not found or permission denied in that case the file is not open anyway), I agree that this is not a likely scenario, this is not a real problem in our case. (FindBugs sometimes complains about missing close statements in case of exception, with our source code only in TemplateableViewGenerator line 366)

As for the class name, you are right, no argument.

If you want to provide a patch to close in a finally clause, by all means do.

But let's unit test the IOUtils methods with the occasion.

I'll take a look at it tomorrow Tuesday.

I confirm that this is now working for me.