| Category: | Bug report |
Priority: | Immediate |
Status: | Confirmed |
| Project: | Severity: | Critical |
Resolution: | Reopened |
|
| Component: | Reproducibility: | Always |
Assigned to: |
the textFieldExpression class attribute is not being saved, regardless of what class is chosen in the designer. If I add the attribute by hand, it is removed as soon as I save the jrxml file
24 Comments:
This is really a big problem, because all the formatting for date, longs etc is lost.
You need to roll back as this has made unusable
Also happens with imageExpression. This results in big problems when injecting BufferedImages via report parameters, because they are only processed correctly, when given class attribute is java.awt.Image. Otherwise, a resource seems to be loaded with the String representation of the object as its location. This results in an error like this:
net.sf.jasperreports.engine.JRException: Byte data not found at location : BufferedImage@45e33bb8: type = 5 ColorModel: #pixelBits = 24 numComponents = 3 color space = java.awt.color.ICC_ColorSpace@4965d0e0 transparency = 1 has alpha = false isAlphaPre = false ByteInterleavedRaster: width = 3997 height = 682 #numDataElements 3 dataOff[0] = 2
This is really having a huge impact on developing reports and should be a high priority issue. While for some things you can workaround using an expression to create a string but for say images passed in you have no option to edit the jrxml in a text editor everytime you save it.
Hi guys, this is how JAsperReports works from the version 4.0.1. This is actually a good news, it is no longer necessary set a class for an expression, since JasperReports is able to figure it out what it needs.
On the other side, jrxmls may result incompatible if used with old version of JasperReports. In that case, remember to set the compatibility mode in the options dialog.
Anyway, I always strongly suggest to upgrade JasperReports when possible.
Giulio
The problem is that it isnt detecting the class type correctly. I have numeric fields from a SQL result set that I want to apply formatting to. Unless I manually edit the XML and put the class attribute in, the report doesnt populate properly
To follow to this. I have a jrxml file with all the fields properly defined. If I make a simple change to xml (eg, insert a space then backspace again) and save the file, iReport changes all <textFieldExpression class="java.util.Date"> to <textFieldExpression>.
When I re-open the report, all the text fields are detected as STRING, instead of their correct data type.
this is most definitely a bug
To follow to this. I have a jrxml file with all the fields properly defined. If I make a simple change to xml (eg, insert a space then backspace again) and save the file, iReport changes all <textFieldExpression class="java.util.Date"> to <textFieldExpression>.
When I re-open the report, all the text fields are detected as STRING, instead of their correct data type.
this is most definitely a bug
This also caused me problem, the latest version of iReport (4.1.3) does not save the class for textFieldExpression because it uses compatibility mode of latest JasperReport version (4.x). The latest JasperReport compiler does not need the class in textFieldExpression.
Well, I still use JasperReport 3.5.2 in production system, when I modified .jrxml file using iReport it compiled ok, BUT when deployed to production, it gives compilation error because of "Cannot Cast to String".
Luckily, I found this article and know how to solve it, just set the Tools > Option > General > Compatibility > JasperReports 3.5.2-3.5.3 and that will save the class for textFieldExpression when you save the file.
But, even though as default the compatibility mode is set to latest version, iReport should always save the class. I am sure there are lots of people out there still using old version of JasperReports in their production system and they are not aware of this iReport behaviour.
Please consider to change it in next release.
Simply put, we can't have iReport being intelligent as iReports are uploaded to our Online ERP system and that one tries to compile the report server-side and thus compilation fails.
Please give us the option to always save the textFieldExpression. I'll try to work with the guys who manage the server side
the problem still exists in iReport 4.5.1 (as well as in 4.1.3)
it is a huge problem since it breaks all the formatting, also when deployed to a jasperserver.
i.o.w. it basically makes obsolete all the format properties in iReports and forces you to do the formatting by java code into a String like for example:
new DecimalFormat("#,##0.00").format($F{DecimalData})
a huge step backwards
Like siepaoling said, using compatability mode in Tools > Option > General > Compatibility > JasperReports for 3.7.4 (the latest 3.x version) does work around this problem, but will remove all 4.x functionality from your report everytime uppon saving
No fix at this time (4.5) ?? Please... The problem is realy critical...
If your repport is written in Java (Groovy make the conversion) it won't run !
Reporting the same problem, this needs to be fix pronto. Just upgraded to 4.5.1 from 4.0.2 and reports don't compile when deployed. Not good.
I'm having exactly the same issue. I can't believe this is not fixed yet!!!! it was opened on 09/21/2011 and such a critical issue!!
I need it for bigdecimal formatting and date formatting.
Using 4.7 and this is still a critical issue for me. Let me know if developer need any help with testing.
Thought I'd try iReport 5 even though we have an internal requirement to use JasperReports 3.7.6. Installed it for the first time today. The first thing that I did was set the compatibility mode to 3.7.5. (3.7.6 was not available.) It didn't help. When I saved the report every TextFieldExpression was changed to a java.lang.String. This caused the report to crash in our web application and I had to go through it by hand and make all of the corrections. I would vote that this at least be made to work reliably in compatibility modes.
I'm experiencing the same (big, critical) issue described in comment #16 (compatibility 3.7.5) using the Eclipse plugin. It is enough to click on the source tab to get the XML regenerated and the class attributes deleted/reset (despite the compatibility mode). Showstopper bug.
Very hurting bug. Now I need to change 1154 strings by context(hard to automate this action)in 39 reports to add not stored expression. I am in pain and confusion. And it Is from version 4.0.0 to 5.1.0. There is no alternatives to iReport. Hope Bug will be fixed. Compatibility (with older verion) mode also negates our potentialities.
So has there been a solution for this... ughh. Text is not staying centered for me when I deploy to japserserver
This is not a bug. The class attribute has been deprecated in JasperReports, it is no longer useful. iReport relies on JasperReports to write the jrxml, which at the end of the day is the cause of apparently loosing the class information in (all) the expressions. You experience the problem at run time because you are using an old version of JasperReports in your project, you can avoid any rollback by just upgrading the JasperReports.
You can also verify in iReport that the class is no longer relevant by creating a textfield with the expression "new java.util.Date()" and format it without specifying any class type for the textfield.
So I created a simple report. I placed a static text label in the title. Horizontally alligned it to CENTER... I run the report and it centers just fine in Ireports. I deployed it to jasperserver and it ignores my center allignment. We use to use Ireports 3.1.4 so are you saying that the jasperreportsx.x.x.jar that is being utilized is not the latest one for the upgrade? on Jasperserver?
Just a followup.. we have reports that were developed in Ireports 3.1.4 deployed to a jasperserver that has been upgraded... and the upgraded version supports Ireports 4.5.1... So I installed 4.5.1 and created the report and then deployed to the upgraded jasperserver and that's when I noticed the allignment didn't stick..
I've read through the comments but what we're finding (latest Jasper Reports) is when we create an Excel file, the cell is assuming the value is a string and not a number. The field definition is long or some number but we get that error in Excel. In previous versions, that was handled by specifying the class in the textFieldExpression but not it's deprecated. Is the idea the Excel exporter relies on the <field> class instead?
I'm using 5.5 final version what ever changes i made to report like page size, increasing the text box size all getting vanished back to base template as soon as i save the report. This is too bad.