Hm, I didn't realize we already had a LegendInfo. Is it used elsewhere?
We might be writing ourselves into a corner if we start reusing the same
class for unrelated tasks.
The serialization is accomplished using XStream:
http://xstream.codehaus.org/ They have a two-minute tutorial that covers
the basics, I'd recommend going through it.
The error message you're getting says:
> Caused by: java.lang.InstantiationError: org.geoserver.catalog.LegendInfo
> at
> sun.reflect.GeneratedSerializationConstructorAccessor4.newInstance(Unknown
> Source)
>
That is, org.geoserver.catalog.LegendInfo doesn't have a default
constructor (in fact it has no constructors at all - it's an interface and
so inherently abstract.) So the problem seems to be that XStream is
configured to serialize legends without any information about which
implementation class to use when deserializing. I believe
org.geoserver.config.util.XStreamPersister will need to be modified to
account for this, but even if it's not that's probably a good place to
start digging around.
--
David Winslow
OpenGeo - http://opengeo.org/
On Tue, Oct 2, 2012 at 7:24 PM, Yancy Matherne
<[email protected]>wrote:
> David,
>
> Thank you for your quick reply. I agree with your comments, but have run
> into a snag.
>
> There already exists LegendInfo and LegendInfoImpl classes, so I figured
> I would just use those. I added the LegendInfo as a property to the
> StyleInfo and modified my test style.xml file.
>
> <style>
> <id>StyleInfoImpl--570ae188:124761b8d78:-7fe2</id>
> <name>raster</name>
> <filename>raster.sld</filename>
> <legend>
> <id>LegendInfoImpl--570ae188:124761b8d78:-7fe1</id>
> <width>50</width>
> <height>75</height>
> <format>image/png</format>
> <onlineResource>http://www.google.com/images/srpr/logo3w.png
> </onlineResource>
> </legend>
> </style>
>
> Unfortunately, it is unable to construct the LegendInfo object when it
> is loading the catalog.
>
> Excerpt from log [see attached tomcat.log]:
> ...
> Caused by: java.lang.InstantiationError: org.geoserver.catalog.LegendInfo
> at
> sun.reflect.GeneratedSerializationConstructorAccessor4.newInstance(Unknown
> Source)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
> at
> com.thoughtworks.xstream.converters.reflection.Sun14ReflectionProvider.newInstance(Sun14ReflectionProvider.java:74)
> ...
>
> At this point, I'm not really sure how the XML parsing works, so I'm not
> sure what the error means. I tried adding constructors with different
> arguments to the LegendInfoImpl, but I get the same error. Do you have any
> ideas?
>
> I was able to add the LegendInfo properties directly to the StyleInfo
> and just create the LegendInfo object on the fly when StyleInfo.getLegend()
> is called. Of course this isn't the way to do it, but I was at least able
> to prove that the GetCapabilities will work as expected.
>
>
> Thanks,
> Yancy Matherne
> Software Developer
>
> Geocent, LLC
> 111 Veterans Blvd., Suite 1600
> Metairie, LA 70005
> O: (504) 831-1900
> E: [email protected]
> http://www.geocent.com
> ------------------------------
> *From:* David Winslow [[email protected]]
> *Sent:* Tuesday, October 02, 2012 8:40 AM
> *To:* Yancy Matherne
> *Cc:* Geoserver-devel
> *Subject:* Re: [Geoserver-devel] GetLegendGraphic Enhancements
>
> LegendInfo could be embedded in the StyleInfo, and in fact this would
> happen automatically if you simply make a LegendInfo class and add one as a
> property of StyleInfo objects. Justin might disagree but I don't see any
> potential drawbacks with this approach (unless it's useful to share legends
> between styles - but it shouldn't be, right?)
>
> As for having ShapePainter paint external legends, I think that I would
> use a separate method rather than trying to wrap Legends as Styles somehow.
>
> --
> David Winslow
> OpenGeo - http://opengeo.org/
>
> On Mon, Oct 1, 2012 at 7:10 PM, Yancy Matherne <[email protected]
> > wrote:
>
>> Hi all,
>>
>> We have a few weather observation layers that include many attributes,
>> and we use several TextSymbolizers with custom fonts, rotations, anchor
>> points, etc. to generate a complex icon that graphically represents several
>> attributes' values at the same time [see attached GetMap]. Unfortunately,
>> the GetLegendGraphic service does not generate a useful legend out of the
>> box for these styles [see attached GetLegendGraphic]. The icons for these
>> layers are so complex that a legend like [
>> http://visual.merriam-webster.com/images/earth/meteorology/station-model.jpg]
>> would be more useful than a vertical listing of the rules.
>>
>> We are looking to patch GeoServer to do two things:
>> 1) Point the LegendURL in the GetCapabilities to an ExternalGraphic.
>> 2) Implement the LegendGraphic for Rules in SLD.
>>
>> I have already started looking into each patch, and I think I have a
>> general approach to each.
>>
>> 1) Capabilities_1_3_0_Transformer.handleLegendURL() already takes a
>> LegendInfo parameter, but Capabilities_1_3_0_Transformer.handleStyles()
>> always passes in null. I was thinking we could add a LegendInfo to
>> StyleInfo to persist the ExternalGraphic information. But I'm not sure on
>> the details of this. Would I be able to put the LegendInfo directly into
>> the StyleInfo XML file or would there need to a separate file with
>> references between them?
>>
>> 2) The LegendGraphic element in Rules is part of the SLD spec, but it
>> does not appear (to me) to be implemented in GeoServer. While using the
>> debugger, in BufferedImageLegendGraphicBuilder.buildLegendGraphic(), a
>> LegendGraphic that is included in your SLD is accessible by calling
>> applicableRules[i].getLegend(). But that never happens in the actual code
>> so it never gets used. I was looking to just paint the GraphicLegend there,
>> but the shapePainter.paint() method that is used there takes a Style2D
>> object and I haven't been able to figure out how to convert a GraphicLegend
>> to a Style2D object or perhaps use a different paint method?
>>
>> I think these would be useful additions for the whole community and I
>> appreciate any feedback or recommendations on this. Part of the tasking is
>> to commit this back to GeoServer source.
>>
>>
>> Thanks,
>> Yancy Matherne
>> Software Developer
>>
>> Geocent, LLC
>> 111 Veterans Blvd., Suite 1600
>> Metairie, LA 70005
>> O: (504) 831-1900
>> E: [email protected]
>> http://www.geocent.com
>>
>>
>> ------------------------------------------------------------------------------
>> Got visibility?
>> Most devs has no idea what their production app looks like.
>> Find out how fast your code is with AppDynamics Lite.
>> http://ad.doubleclick.net/clk;262219671;13503038;y?
>> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
>> _______________________________________________
>> Geoserver-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>
>>
>
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
