Struts 2
  1. Struts 2
  2. WW-2333

ValueStackDataSource implementation leads to class cast exceptions

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0.11
    • Fix Version/s: 3.0
    • Component/s: Plugin - JasperReports
    • Labels:
      None

      Description

      Assume you have a class Foo that has a Collection of Bar's. Without using Struts, the expected behavior of a report that takes Foo's as input is, that a reference $F

      {bar}

      returns a java.util.Collection (of Bar's). However, this will not be the case when using the ValueStackDataSource implementation; an instance of ValueStackDataSource is returned instead of a collection. If the method "getFieldValue" gets called, it checks if the field value is iteratable (which is true for collections) and then returns a new ValueStackDataSource instead of the field value itself. I assume that this behavior breaks many reports.

        Activity

        Hide
        Ted Husted added a comment -

        Setting to future pending a patch.

        Show
        Ted Husted added a comment - Setting to future pending a patch.
        Hide
        Jeff Brown added a comment -

        Certainly breaks anything but the simplest Javabean-based reports. Any word on when a patch will be available?

        Show
        Jeff Brown added a comment - Certainly breaks anything but the simplest Javabean-based reports. Any word on when a patch will be available?
        Hide
        Dave Newton added a comment -

        I suspect the original implementation was meant as a convenience: rather than creating a collection and forcing the report developer to create the data source from it the source is created automatically. It actually makes writing new reports a bit easier.

        I hesitate to just remove this feature as people using the Jasper plugin may be relying on this behavior (I am, anyway). We could add a flag that controls this, I suppose; would that satisfy people?

        Show
        Dave Newton added a comment - I suspect the original implementation was meant as a convenience: rather than creating a collection and forcing the report developer to create the data source from it the source is created automatically. It actually makes writing new reports a bit easier. I hesitate to just remove this feature as people using the Jasper plugin may be relying on this behavior (I am, anyway). We could add a flag that controls this, I suppose; would that satisfy people?
        Hide
        Jeff Brown added a comment -

        Understand the convenience method, but since it does not adhere to the expected Java behavior, reports must be tailored specifically for Struts2 and would not work correctly when run from other frameworks or clients - for example iReport.

        A flag is probably the way to go because it needs to be somewhat backwardly compatible no matter what. I would vote for the default behavior following the expected Java behavior of a Collection returning a Collection and the flag would cause it to return a ValueStackDataSource if desired for convenience. But, if you feel strongly the other way for seamless backward compatibility, I understand.

        Show
        Jeff Brown added a comment - Understand the convenience method, but since it does not adhere to the expected Java behavior, reports must be tailored specifically for Struts2 and would not work correctly when run from other frameworks or clients - for example iReport. A flag is probably the way to go because it needs to be somewhat backwardly compatible no matter what. I would vote for the default behavior following the expected Java behavior of a Collection returning a Collection and the flag would cause it to return a ValueStackDataSource if desired for convenience. But, if you feel strongly the other way for seamless backward compatibility, I understand.
        Hide
        Ben Morgan added a comment -

        As I understand it, to view collections in a standalone iReport, you would need to perform the extra work of creating a JRDataSource implementation as a source for a subreport to view Collection properties of a JavaBean.

        A report for Struts2 does not need to do this, as the ValueStackDataSource does the lifting for you by creating a JRDataSource for any Iterable property.

        So any report with a subreport on a collection that works for standalone iReport, will also work for Struts2 - the ValueStackDataSource doesn't recognise the JRDataSource property and just passes it through unaffected. The opposite is not true, however, I feel that taking this away, forces Struts2 developers to make reports usable in standalone iReport, where some simply don't need that functionality.

        Show
        Ben Morgan added a comment - As I understand it, to view collections in a standalone iReport, you would need to perform the extra work of creating a JRDataSource implementation as a source for a subreport to view Collection properties of a JavaBean. A report for Struts2 does not need to do this, as the ValueStackDataSource does the lifting for you by creating a JRDataSource for any Iterable property. So any report with a subreport on a collection that works for standalone iReport, will also work for Struts2 - the ValueStackDataSource doesn't recognise the JRDataSource property and just passes it through unaffected. The opposite is not true, however, I feel that taking this away, forces Struts2 developers to make reports usable in standalone iReport, where some simply don't need that functionality.
        Hide
        Dave Newton added a comment -

        If you attempt to create, say, a JRBeanCollectionDataSource from an iterable action property, the subreport will fail--you must pass the property through as-is, as the plugin will have done the conversion already. This makes reports containing subreports unusable outside of S2. This is a Bad Thing, as people with a large assortment of reports don't want to, and shouldn't have to, go in and modify all their reports (and, in turn, make them unusable outside of S2).

        Show
        Dave Newton added a comment - If you attempt to create, say, a JRBeanCollectionDataSource from an iterable action property, the subreport will fail--you must pass the property through as-is, as the plugin will have done the conversion already. This makes reports containing subreports unusable outside of S2. This is a Bad Thing, as people with a large assortment of reports don't want to, and shouldn't have to, go in and modify all their reports (and, in turn, make them unusable outside of S2).
        Hide
        Ben Morgan added a comment -

        I'm with you now. I was under the (incorrect) impression, that subreports in standalone reports require a property of type JRDataSource to be passed, rather than the simpler way of wrapping a java.util.Collection with a JRDataSource. My apologies for wasting your time.

        I agree with the flag approach.

        Show
        Ben Morgan added a comment - I'm with you now. I was under the (incorrect) impression, that subreports in standalone reports require a property of type JRDataSource to be passed, rather than the simpler way of wrapping a java.util.Collection with a JRDataSource. My apologies for wasting your time. I agree with the flag approach.
        Hide
        Dave Newton added a comment -

        I'm not sure what you said there.

        All I know is that there have been reports of non-S2 reports failing because of the conversion/wrapping/whatever of action properties that are collections. (And my first S2-only report w/ subreports failed because I didn't know the S2 result type "helped" me by creating it.)

        Show
        Dave Newton added a comment - I'm not sure what you said there. All I know is that there have been reports of non-S2 reports failing because of the conversion/wrapping/whatever of action properties that are collections. (And my first S2-only report w/ subreports failed because I didn't know the S2 result type "helped" me by creating it.)

          People

          • Assignee:
            Unassigned
            Reporter:
            Thorsten Schäfer
          • Votes:
            2 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:

              Development