After Updating to PrimeFaces 13 PDF Viewer Displays Same Report Repeatedly

[NCIDevRonR]

I have a report generation and viewing sequence which has worked flawlessly in PrimeFaces 6 for years in production. Upon updating to PrimeFaces 13, the last part of the sequence is now broken, and I'm not sure what to change to get it working again.

The user clicks a button to generate the report after selecting the criteria. The Jasper Reports code generates the report, and I can verify this by viewing the named and timestamped report files produced on the server.

After the report is generated, a new streaming PDF object is created for the report just requested, and an onscreen "poll" object downloads the just-created streaming object into the screen's PDF viewer.

The PDF viewer appears, and displays the requested report for the user, then the user clicks a button to close the PDF viewer.

What has changed since we've updated to PrimeFaces 13 is if the user requests a succession of different report types and criteria, although each requested report is generated on the back-end, only the first requested report displays each time, whereas in PrimeFaces 6, each requested report is generated and displayed in turn.

I'm including a sizeable amount of code here to show how the entire sequence is set up to behave, including a call to the new DefaultStreamedContent.builder() which replaced the parameterized constructor. Looking at this, does anything jump out at you as a possible cause for why the PDF viewer only shows the first generated report repeatedly in PrimeFaces 13? Can anyone recommend a way to get the PDF viewer to display each generated report in turn, as it does in PrimeFaces 6?
Issue with Jasper Reports-20230915.txt

[melloware]

Can you post your Controller code that does the DefaultStreamedContent.builder() so we can see? What scope is it?

[NCIDevRonR]

Thank you for looking at this with me. I'm checking most of your changes into my repo for this reproducer as a step in the right direction, but I do have an observation and a question:

You have replaced my full-sized PDF viewer dialog with an in-line mini PDF viewer, which I don't think would work for our users. They see the PDF viewer dialog after they have specified their report criteria in another dialog they see first. The dialog, size and format, make it easy to read and to page through each detailed report. Also several concurrent users can be requesting variations of the same report at once, hence the timestamps in the filenames.

Was it a matter of preference to switch to the main-window mini-viewer, or was there no way to make the full-sized PDF viewer dialog show the last requested report the same way your new inline viewer does? (I tried changing the "cache" setting of my dialog-based PDF viewer to 'false' to match yours, and it didn't resolve the issue.)

[melloware]

I only did that to make my repeated testing easier to show you that the PDF can work work fine. I wanted to make a "Minimum Viable Reproducer" so I cut out a lot of your moving parts. Its always best to show as simple as possible the issue.

[NCIDevRonR]

Ok, but I still have a problem, albeit a somewhat smaller problem thanks to your fix. I have incorporated said fix into another commit to my reproducer repo, so that the PDF viewer resides once again inside my dialog. Whereas your inline PDF viewer updated when the user clicked the "Display" button, my dialog-based PDF viewer seems to appear in a pre-form-update state. If I click "refresh" before selecting another listing to display, the correct listing always displays. Is there a way to accomplish this screen refresh programmatically so the dialog always displays the requested listing?

[melloware]

Yes in the Java side you can do PrimeFaces.current().ajax().update("yourForm") or whatever you want to update which should probably be your dialog guts?

[NCIDevRonR]

Cool! This resolves my issue (at least in the reproducer). I have updated the repo with this last fix, and am prepared to consider this case closed. Thanks for your help.