I welcome correction, but my understanding is that since a container runs inside a JVM, and system properties are set at the level of a JVM, you can't do that.
Perhaps there's a different parameterization (using something other than a system property) that could provide the behavior you seek?
---
A. Soroka
Digital Research and Scholarship R & D
the University of Virginia Library
On Sep 22, 2010, at 7:30 PM, <Terry.Rankine@anonymised.com> wrote:
Hi All
This is a tomcat6 question - but someone else may know...
I am currently experiencing the different XY behaviour (WFS 1.1, 1.0 behave differently by default) in a vanilla geoserver 2.0.2.
inside my webapp (not at container level - at the context level?)
I am using tomcat6.
Regards
Terry Rankine
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
inside my webapp (not at container level - at the context level?)
In GeoServer we set that option in the GeoServerInitStartupListener.
Maybe you can roll your own servlet context variable that is
read by the above listener and makes it set the system variable
accordingly.
The timing when that variable is set is crucial: it has to be before
anything starts hitting the CRS subsystem, once that happens changing
the variable will have no effect.
Also, have no idea what will happen to other applications starting
in parallel, if they also use geotools you might get odd results.
Also mind, a WFS 1.1.0 that returns data in lon/lat order for GML3 is
not compliant.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.