Gretchen Moran - 14/Mar/08 11:23 AM I looke dinto this.. there is a mismatch between the method names: the API method is "setxValueColumn()", but Report Designer is looking for "setXValueColumn()". This is important, as beans (which the report charts are) use reflection for method invokation. Have these charts ever worked? I assume they did, so I can't be sure where this change weas introduced, but shouoldn't be a terribly difficult fix, oncwe someone figures out why and when it broke.

Ravi Hasija - 18/Apr/08 11:19 AM - edited I have verified this with Thomas that the report designer branch 1.7 works, but the error happens in the trunk. The reporting engine works with XYSeriesCollectorFunction class, but the trunk report designer does not. To summarize PRD 1.7 is working and we need to find out why PRD trunk doesn't.

Kurtis Cruzada - 23/Apr/08 09:29 AM Based on Ravi's feedback, moved the issue to 1.8 only .

Thomas Morgner - 02/May/08 03:44 PM As I found out (painfully in a very embarrasing situation) this bug also affects 1.7-M1 of the report-designer. I tracked this bug down to a sequence of code where the RD uses CG-Lib (a Java-Assember) to produce a derived class that then breaks everything. Actually, this whole process is strange and the derived classes generated by RD are no valid functions anymore (in the sense of being usable in the reporting engine. The generated code makes way to many assumptions that do not hold true in the real world to be sensible). For now, I'm going to fix the function-wrapper-generation; for RD 2.0 we will completely throw out that part of the code as it is black magic and not engineering ..

Thomas Morgner - 03/May/08 10:26 AM After digging deeper into that (and after having to use a Java DISASSEMBLER! because of the weird gode generation going on) I traced it down to: (1) The Report-Designer generates a Wrapper-Function does does not use the getter/setter methods from the original bean-info object. Therefore the generated getters and setters do not match and the resulting merged bean-info between the original and the generated class will no longer work. Fixed by passing the getter and setter names around. This is only a temporary fix, as this schema can break elsewhere. The full fix is not to use magic like code generations and to use real-world approach. (2) The Report-Designer also generates a BeanInfo object that is broken (as the referenced getter and setter method are not there). The beast swallows all exceptions and thus no one notices that the bean-info object is broken. For that reason, the ChartEditor is also broken (as this one uses a different kind of magic to work with the magic from the generated beans/beanInfo classes. The xy(z)-Functions were obviously broken, as the dialog did not show any grouping and missed a couple of properties. Therefore I can say, that charts relying on the XY(Z)-DataCollector never worked. They were never used in any of the demos either, so chances are high that no one ever used them (or tried to use them) at all. (3) The XYLineChartExpression uses java.awt.Font properties. These property-types have no parser/writer inside the reporting engine and therefore they were never usable in any of the XML report definitions of the reporting engine. Again a indicator for the fact that this part of the charting never worked.

Thomas Morgner - 03/May/08 11:27 AM The chart-expressions seem to happily introduce new parameter types (like the Chart's RECTANGLE_EDGE). The reporting engine cannot handle that and I will not include handlers as they start to build up a dependency on the JFreeChart project for no reason other than lazy programming inside the chart expressions. Fix the expressions or add a manual string-property for these unsupported properties.