| Category: | Feature request |
Priority: | Normal |
Status: | Acknowledged |
| Project: | Severity: | Major |
Resolution: | Open |
|
| Component: | Reproducibility: | N/A |
Assigned to: |
Frequently I get an exception filling a subreport from JRFillSubreport.prepare. The exception message usually refers to the subreport's name, but the subreport's object is not available. It would be nice if JRException had a getReport accessor which returned the subreport whose filling caused the exception.
If that was available, I could've extracted the query text which caused the query to fail.
Thanks
| Attachment | Size |
|---|---|
 jasperforge-bug4300-exception-stack-trace.txt | 10.6 KB |
11 Comments:
Hi,
Can you provide us with the exact stack trace you are getting?
Thank you,
Teodor
Attached stacktrace
Hi,
I think what you need to do is simply enable the JR logging for the SQL query executer.
This way you'll see in the logs which queries get executed and figure out why they fail. We are not going to modify the JRException as this exception is not necessarily related to running a report.
Configuring logging for JasperReports should be easy, because JR relies on Commons Logging and if you have log4j in your application already, you probably have log4j config files in there.
I hope this helps.
Teodor
I get the SQL exception, but I don't know which query and parameters it's coming from. That's the whole point. I agree, it probably makes sense to leave JRException alone for a number of reasons, but then derive JRFillException from JRException and add a getReport method which knows about the report being filled. Exception is a sort of an event and typically events know about their source. You already return the subreport's name in the text of the message. It would've been much easier to return the whole subreport object.
And by "easier", I mean "useful"
Hi,
If you enable debug level logging, you'll see JR displays the query text and all the parameter values used when it was executer. I assume this is exactly what you want to see.
There is no reason for you to actually use a debugger and introspect the content of a JRException in order to obtain the same information "the hard way".
Thank you,
Teodor
I am not using a debugger. If I was using a debugger, I could inspect anything. I am writing code which needs to handle the exception. I don't want to "see it", I want to use it.
All you need to do is something generic like
try
{ JRFillSubreport.prepare(report) }
catch (exception e)
{
throw new JRFillException(report, e);
}
instead of
JRFillSubreport.prepare(report) }
catch (exception e)
{
throw new JRException("exception in report " + report.getName(), e);
}
I want flexibility in formatting my own exception message instead of using your message which only contains report name.
Hi,
I gave you a solution that would have enabled you to fix your report queries right away and then move on.
But if you prefer to wait and have this fixed as requested, by all means do.
We have many other request for enhancements pending and it is a matter of priorities. This is by no means major priority for us.
Thank you,
Teodor
Teodor - thanks for your help and taking time to discuss this with me. I understand about priorities.
One more thing:
Adding a report reference to the exception would not be enough for you to be able to retrieve parameter values and other fill context information. A broader exception context would have been required.
So what I'm saying is that the requirement should be refined and the use case extended in order to make sure we do come up with something useful. Again, this would take more time and at least one release cycle.
The proposed log solution would have enabled you to solve your problem with the version you already have on your machine.
Thanks,
Teodor
I already solved my immediate problem, which was to find the source of SQL error. It's already fixed. However, my current problem is that I can't get the sql query of the subreport which generated the exception from the exception. My requirement is to display the report name, the query, and some parameters which generated exception. The parameters are available from the master report parameters, since they are mostly passed down directly to the detail reports. However, calculated parameters would be nice too. So, I guess the exception needs to know about the subreport's parameters as well.