Hi,
as you might know GeoServer right now won't work properly under JDK 7 due to
XStream not being able to deal with JDK 7 reflection changes: trying
to serialize
and deserialize certain objects will result in exceptions about
XStream not finding
the no-arg constructor, breaking both rest-config and ogr2ogr
The following pull requests addresses that, and copes with a couple of
differences in
the XStream 1.4 behavior compared to the 1.3 series:
https://github.com/geoserver/geoserver/pull/50
Two notable differences:
- when using the XStream JSON writer one has to explicitly call
flush() once done to
actually make it emit the JSON
- in 1.3 calling omitField(class, field) resulted in the field not
being wrote out, but in
1.4 it's symmetric and the field won't be parsed either, which
breaks our ability to
create new feature types in a store (e.g. new tables in a
database)via REST config
because the attributes field is being omitted.
The last one is also a bit odd, FeatureTypeResource configured xstream to omit
the attributes field, but then generates it manually.
I guess that this was a tentative to force the attribute list to be last?
My patch removes the omission and just moves the attributes field last in the
FeatureTypeInfoImpl to preserve the current order.
Looked a bit at the REST xml/json representations I did not notice
any other significant
difference.
With modern distributions making it harder to install Oracle JDK and
people looking
at actively using OpenJDK 7 despite our recommendations
( http://research.geodan.nl/2012/10/openjdk7-vs-oracle-jdk7-with-geoserver/ )
I believe it's going to get increasingly important to keep an eye on
how we run on that JDK,
even if we're not officially supporting it
Cheers
Andrea
--
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
Hey Andrea,
On Thu, Nov 1, 2012 at 9:40 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
Hi,
as you might know GeoServer right now won’t work properly under JDK 7 due to
XStream not being able to deal with JDK 7 reflection changes: trying
to serialize
and deserialize certain objects will result in exceptions about
XStream not finding
the no-arg constructor, breaking both rest-config and ogr2ogr
The following pull requests addresses that, and copes with a couple of
differences in
the XStream 1.4 behavior compared to the 1.3 series:
https://github.com/geoserver/geoserver/pull/50
Two notable differences:
- when using the XStream JSON writer one has to explicitly call
flush() once done to
actually make it emit the JSON
- in 1.3 calling omitField(class, field) resulted in the field not
being wrote out, but in
1.4 it’s symmetric and the field won’t be parsed either, which
breaks our ability to
create new feature types in a store (e.g. new tables in a
database)via REST config
because the attributes field is being omitted.
The last one is also a bit odd, FeatureTypeResource configured xstream to omit
the attributes field, but then generates it manually.
I guess that this was a tentative to force the attribute list to be last?
My patch removes the omission and just moves the attributes field last in the
FeatureTypeInfoImpl to preserve the current order.
Actually, the point is to ensure that its FeatureTypeInfo.attributes() that generates the list (which delegates to the resource pool, applies any schema overrides, etc…), and not just the raw attribute field list, which for the most part is always empty. SO maybe a better way to do this would be to move that logic into the XsTreamPersister converter itself (perhaps configurable) , so that during parse the normal behaviour is applied, but during encode the derived property is used.
Looked a bit at the REST xml/json representations I did not notice
any other significant
difference.
With modern distributions making it harder to install Oracle JDK and
people looking
at actively using OpenJDK 7 despite our recommendations
( http://research.geodan.nl/2012/10/openjdk7-vs-oracle-jdk7-with-geoserver/ )
I believe it’s going to get increasingly important to keep an eye on
how we run on that JDK,
even if we’re not officially supporting it
Agree fully, it is key to stay in good standing and hopefully eventually officially support openjdk. Your great efforts are certainly moving us closer to that goal. Much appreciated.
Cheers
Andrea
–
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.