GeoServer
  1. GeoServer
  2. GEOS-3746

OpenLayers Preview causes exception

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: 2.0.1
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:
      Ubuntu karmic 9.10 server, Tomcat 6.
    • Number of attachments :
      2

      Description

      When previewing a raster layer, arcgrid, etc. in version 2.0.1 the rendered image shows an exception trace, rather than the map. I tried to replicate this bug in version 2.0.0, but the bug does not appear to effect v2.

      Prior to the exception trace, the log shows:

      2009-12-29 14:24:48,702 WARN [org.geoserver.we] - Unable to find resource: format.wfs.OGR-CSV for component: [class=org.geoserver.web.demo.MapPreviewPage]

      for most formats installed on my geoserver, this may or may not be relevant. The trace is attached.

        Activity

        Hide
        James Nicolson added a comment - - edited

        This appears to be a problem with geotools rather than geoserver.

        Show
        James Nicolson added a comment - - edited This appears to be a problem with geotools rather than geoserver.
        Hide
        James Nicolson added a comment -

        This issue can be resolved by applying the attached patch to StreamingRenderer in geotools (@revision 34584) modules/library/render/src/main/java/org/geotools/renderer/lite.

        Show
        James Nicolson added a comment - This issue can be resolved by applying the attached patch to StreamingRenderer in geotools (@revision 34584) modules/library/render/src/main/java/org/geotools/renderer/lite.
        Hide
        James Nicolson added a comment -

        Instead of setting

        length = 0;

        in the else-case of the patch this should be replaced with

        coverage = (GridCoverage2D) reader.read(new GeneralParameterValue[]

        { readGG }

        );

        the if-block in the original code:

        if (length > 0)

        should be moved inside the patch if-statement:

        if (params instanceof GeneralParameterValue[])

        This would improve the robustness of the patch.

        Show
        James Nicolson added a comment - Instead of setting length = 0; in the else-case of the patch this should be replaced with coverage = (GridCoverage2D) reader.read(new GeneralParameterValue[] { readGG } ); the if-block in the original code: if (length > 0) should be moved inside the patch if-statement: if (params instanceof GeneralParameterValue[]) This would improve the robustness of the patch.
        Hide
        Andrea Aime added a comment -

        I have plenty of raster data and never seen this issue... what is special with your coverages?
        Wait, is this the case of a GeoServer with the app-schema extensions installed?
        Not sure if the issue was every fixed though, but this patch would have just hidden the issue: a properly setup coverage will always return a GeneralParameterValue[], if that does not happen we have a bug elsewhere (in the property accessors in particular)

        Show
        Andrea Aime added a comment - I have plenty of raster data and never seen this issue... what is special with your coverages? Wait, is this the case of a GeoServer with the app-schema extensions installed? Not sure if the issue was every fixed though, but this patch would have just hidden the issue: a properly setup coverage will always return a GeneralParameterValue[], if that does not happen we have a bug elsewhere (in the property accessors in particular)
        Hide
        Andrea Aime added a comment -

        Cc'ed also Ben. Ben, do you recognize this one as an issue caused by app-schema property accessors? I think there was a discussion about coverages not working with app-schema installed some time ago but I can't quite recall the details.

        Show
        Andrea Aime added a comment - Cc'ed also Ben. Ben, do you recognize this one as an issue caused by app-schema property accessors? I think there was a discussion about coverages not working with app-schema installed some time ago but I can't quite recall the details.
        Hide
        Ben Caradoc-Davies added a comment - - edited

        Andrea, you are thinking of GEOS-3525 (fixed a while ago), which caused WMS to fail on some platforms if app-schema was installed: "The problem is caused by warring jxpath NodePointerFactory implementations that are registered in both xsd-core and app-schema. Factory priority depends on SPI load order (classpath), hence the apparent randomness in reproducing the problem across platforms and releases (default Eclipse classpath never shows this error). The workaround is to add extra type guards to app-schema AttributeNodePointerFactory."

        The issue was not caused by app-schema. It was caused by the use of jxpath, with registers handlers globally across an application, rather than providing means for registering a context that can provide NodePointerFactory implementations. Reproducing this required manual classpath manipulation in Eclipse.

        I am not sure that this is the underlying cause in this case, although the failure looks similar.

        James, do you have the app-schema plugin installed? If not, then it cannot be the cause.

        Show
        Ben Caradoc-Davies added a comment - - edited Andrea, you are thinking of GEOS-3525 (fixed a while ago), which caused WMS to fail on some platforms if app-schema was installed: "The problem is caused by warring jxpath NodePointerFactory implementations that are registered in both xsd-core and app-schema. Factory priority depends on SPI load order (classpath), hence the apparent randomness in reproducing the problem across platforms and releases (default Eclipse classpath never shows this error). The workaround is to add extra type guards to app-schema AttributeNodePointerFactory." The issue was not caused by app-schema. It was caused by the use of jxpath, with registers handlers globally across an application, rather than providing means for registering a context that can provide NodePointerFactory implementations. Reproducing this required manual classpath manipulation in Eclipse. I am not sure that this is the underlying cause in this case, although the failure looks similar. James, do you have the app-schema plugin installed? If not, then it cannot be the cause.
        Hide
        Andrea Aime added a comment -

        James, anything to add? As said, I don't want to apply the patch you're suggesting because it would just end up hiding the real problems.
        Did you try a recent nightly build, it might have the issue fixed already:
        http://gridlock.openplans.org/geoserver/2.0.x/

        Show
        Andrea Aime added a comment - James, anything to add? As said, I don't want to apply the patch you're suggesting because it would just end up hiding the real problems. Did you try a recent nightly build, it might have the issue fixed already: http://gridlock.openplans.org/geoserver/2.0.x/

          People

          • Assignee:
            Andrea Aime
            Reporter:
            James Nicolson
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: