Interesting, this is my guide to what changed when:
* http://docs.geotools.org/stable/userguide/welcome/upgrade.html
So it shows me you are up against two changes:
a) java 5
b) a new feature model!
So you are in for a bit of an upgrade.
As for defaultValue - that is supposed to try and make a default
placeholder value in an empty feature. Since Geometry is abstract it cannot
manage it. Try allowing your column to be nullable, then GeoTools will not
try and create a default value.
Still I would actually recommend updating to a newer implementation of
GeoTools then 2.7 - since a lot of work/investment/time was put into
rewriting the JDBC support. No sense working through issues in code that
has since been replaced.
--
Jody
Jody Garnett
On Tue, Jun 3, 2014 at 6:58 AM, Jeremy Lindsey <lind...@mosaicatm.com>
wrote:
> All,
>
> We are having some unexpected behavior with our WMS services since a
> recent switch from 2.3.3 to 2.5. For what its worth, we had previously
> done limited testing 2.4.2 as well without issue.
>
> We have thee PostGIS tables that get rendered as WMS layers. All three
> previously worked fine. Since the update though, one of the three started
> failing, giving this error:
>
>
> *Caused by: java.lang.IllegalArgumentException: class
> com.vividsolutions.jts.geom.Geometry is not supported by this method at
> org.geotools.data.DataUtilities.defaultValue(DataUtilities.java:1006)*
>
> We noticed that this one table has some MULTIPOLYGONs mixed in with
> POLYGONs whereas the working tables were a POLYGONs. These multipolygons
> are a product of an ST_UNION call in our data import process that groups
> neighboring polygons (that apparently can have little gaps between them).
> I was able to prove that these were indeed problematic by pointing my
> geoserver layer over to a view that filtered out the multipolygons. I was
> then tried pointing to another view which calls ST_ConvexHull on each of
> the geometries to make sure they all come out as a single polygon. This
> also worked, so my initial theory was that WMS wasn't jiving with
> MULTIPOLYGONs in 2.5. That might still be true, but we ran into one more
> issue.
>
> We changed our import process to make the ST_ConvexHull call at import
> time, so that we would not need the view. This indeed resulted in a table
> that no longer had any multipolygons, however the WMS layer still failed!
> We made a new view that does nothing more than query the exact same
> geometry from the table and this one works fine for the geoserver layer.
> So aside from the multipolygon issues, it looks like there is just
> something different about how geoserver handles the table vs the view, even
> when the data is the same. I haven't been able to track down what this
> might be.
>
> Anybody have any ideas? I imagine I'm missing something simple, but
> perhaps there is a bug there as well.
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> GeoTools-GT2-Users mailing list
> GeoTools-GT2-Users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
>
>
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
GeoTools-GT2-Users mailing list
GeoTools-GT2-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
