Hi Gabriel, Justin,
First of all my thanks for confirming this bug, and finding the root cause
of the issue. Unfortunately the workaround is not an option for us, we have
disabled global services altogether in GeoServer, and only use virtual
services. I'll guess we'll have to wait for a bugfix. Is it possible to give
an estimation of when this will be? Is it weeks/months/2011/2012?
Cheers,
Jasper
On Tue, Sep 27, 2011 at 7:43 PM, Gabriel Roldan <[email protected]> wrote:
> Hey thanks Justin for following up on this
>
> On Mon, Sep 26, 2011 at 12:12 PM, Justin Deoliveira
> <[email protected]> wrote:
> > Confirmed a bug. Here is the long version.
> > Through the layer preview geoserver is not accessed through the global
> > service endpoint, but through a local virtual endpoint. The first time a
> > request causes something to do GML 3 encoding an internal schema is built
> > and cache. Now if this is through the global endpoint the schema contains
> > the info for all feature types in the catalog. But if this happens
> through a
> > virtual one it will contain only that info for that specific
> > workspace/namespace. So when the second request comes in for a different
> > namespace, kaboom.
> > Yet another issue that boils down to poor management of xsdschema
> objects.
> > The workaround for this one is not to make a GML 3.1 request through a
> > virtual service endpoint on the first request, or on any request
> following a
> > configuration change. Obviously not ideal but for a static server in
> terms
> > of configuration could work ok. Filed a bug report:
> > http://jira.codehaus.org/browse/GEOS-4773
> > -Justin
> >
> > On Fri, Sep 23, 2011 at 2:39 PM, Gabriel Roldan <[email protected]>
> wrote:
> >>
> >> Hi Jasper,
> >>
> >> I was able to reproduce, but couldn't easily find the root of the
> >> problem. Odd indeed.
> >> Perhaps Justin (cc'd) can spot it out more easily as he knows the WFS
> >> module better than anyone.
> >>
> >> Cheers,
> >> Gabriel
> >>
> >> On Tue, Sep 20, 2011 at 4:13 AM, Jasper de Barbanson
> >> <[email protected]> wrote:
> >> > Recently we discovered a problem regarding namespaces in WFS
> responses.
> >> > First we assumed it was an configuration problem on our end, however
> >> > further
> >> > analysis has resulted in reproducing this problem in a default
> Geoserver
> >> > installation. I have reproduced this issue in Geoserver 2.1.1 using
> the
> >> > Web
> >> > Archive version, installed on linux, and in the Windows Installer
> >> > version,
> >> > installed on Windows XP SP3. The problem also exists is the latest
> >> > nightly
> >> > build.
> >> > What is the problem you ask? A WFS-request of datastore X with
> >> > outputFormat
> >> > GML 3.1 works fine, however every next WFS-request of another
> datastore
> >> > Y
> >> > will fail. It will fail for all other datastores, accept the first
> >> > accessed
> >> > datastore. The response which is generated contains null-namespaces.
> The
> >> > namespace of datastore Y is not added to the response, but instead the
> >> > namespace of datastore X is added. Because of de null-namespaces the
> >> > response is invalid for most applications and browsers.
> >> > How-to reproduce?
> >> > - Take a clean install of Geoserver 2.1.1
> >> > - Open the console
> >> > - Go to Layer Preview
> >> > - Open de preview for 'tiger:giant_polygon' in format 'WFS - GML3.1'
> >> > (this
> >> > should give a correct response)
> >> > - Open de preview for 'topp:states' in format 'WFS - GML3.1'
> >> > If you do this in Chrome you get the following error: Namespace prefix
> >> > null
> >> > on states is not defined. If you look into the response, you can see
> >> > there
> >> > is no namespace defined for 'topp', however there is a namespace for
> >> > 'tiger'.
> >> > I have the following questions:
> >> > - is this a bug in Geoserver?
> >> > - is so, is there a workaround?
> >> > - if not, what should I change in the configuration to make
> WFS-requests
> >> > work for all datastores?
> >> > Kind regards,
> >> > Jasper
> >> >
> >> >
> >> >
> >> >
> ------------------------------------------------------------------------------
> >> > All the data continuously generated in your IT infrastructure contains
> a
> >> > definitive record of customers, application performance, security
> >> > threats, fraudulent activity and more. Splunk takes this data and
> makes
> >> > sense of it. Business sense. IT sense. Common sense.
> >> > http://p.sf.net/sfu/splunk-d2dcopy1
> >> > _______________________________________________
> >> > Geoserver-users mailing list
> >> > [email protected]
> >> > https://lists.sourceforge.net/lists/listinfo/geoserver-users
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Gabriel Roldan
> >> OpenGeo - http://opengeo.org
> >> Expert service straight from the developers.
> >
> >
> >
> > --
> > Justin Deoliveira
> > OpenGeo - http://opengeo.org
> > Enterprise support for open source geospatial.
> >
>
>
>
> --
> Gabriel Roldan
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Geoserver-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
