[Geoserver-users] prefix "null" problem for app-schema WFS service

I have a WFS service I am running using the app-schema extension. (This is using the GeoSciML-Portrayal schema for the GeologicUnits polygons.) My workspace name is “gsmlp” and the source data is in PostGIS. (Attached is my mapping file.)

The error I get when running is WFS GetFeature request is:

The prefix “null” for element “null:GeologicUnitView” is not bound.

The request is

http://maps.dgs.udel.edu/geoserver/gsmlp/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=gsmlp:GeologicUnitView&maxFeatures=1

It also fails using WFS 1.0.0 (java.lang.ClassCastException: org.geotools.feature.type.ComplexFeatureTypeImpl cannot be cast to org.opengis.feature.simple.SimpleFeatureType) but actually returns a response with WFS 2.0.0.

A strange behavior is that if I make the gsmlp worksapce the default workspace, then this app-schema service works great. As well, if I enable “Strict CITE Compliance” for the WFS:gsmlp service, then the service works fine as well. However, in these cases when the gsmlp WFS services (app schema based) work (i.e., they return valid WFS GetFeature responses), then none of the other WFS services I have on the machine work properly. Here is an example of a WFS service on the server.

http://maps.dgs.udel.edu/geoserver/DGS_Surficial_and_Contact_Geology/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=DGS_Surficial_and_Contact_Geology:US-DE_DGS_100k_Surficial_Geology&maxFeatures=1

The fact that when the app-schema gsmlp WFS service works, none of the other WFS services work, and vice-versa, makes me think the mapping file is correct but geoserver is not utilizing xmlns:gsmlp=“http://xmlns.geosciml.org/geosciml-portrayal/2.0” in the feature response.

Any suggestions on what I can try? Thanks.

  • John

John Callahan
Research Scientist
Delaware Geological Survey
University of Delaware
http://www.dgs.udel.edu

john.callahan@anonymised.com

GeologicUnitView.xml (5.63 KB)

John,

the first link you provided works for me (possibly because you applied the workaround you described).

I think that there is likely a problem with your namespace configuration. Do you have namespace.xml and workspace.xml files for the gsmlp workspace? Is it in a directory called "gsmlp"? Do you have a featuretype.xml file for this type that specifies the namespace id given in namespace.xml?

Please compare with the app-schema tutorial.

The error is similar to that seen when a secondary namespace is required, but in this case gsmlp is not a secondary namespace.

Kind regards,
Ben.

On 28/08/13 14:33, John Callahan wrote:

I have a WFS service I am running using the app-schema extension. (This
is using the GeoSciML-Portrayal schema for the GeologicUnits polygons.)
  My workspace name is "gsmlp" and the source data is in PostGIS.
  (Attached is my mapping file.)

The error I get when running is WFS GetFeature request is:

     The prefix "null" for element "null:GeologicUnitView" is not bound.

The request is

http://maps.dgs.udel.edu/geoserver/gsmlp/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=gsmlp:GeologicUnitView&maxFeatures=1

It also fails using WFS 1.0.0 (java.lang.ClassCastException:
org.geotools.feature.type.ComplexFeatureTypeImpl cannot be cast to
org.opengis.feature.simple.SimpleFeatureType) but actually returns a
response with WFS 2.0.0.

A strange behavior is that if I make the gsmlp worksapce the default
workspace, then this app-schema service works great. As well, if I
enable "Strict CITE Compliance" for the WFS:gsmlp service, then the
service works fine as well. However, in these cases when the gsmlp WFS
services (app schema based) work (i.e., they return valid WFS GetFeature
responses), then none of the other WFS services I have on the machine
work properly. Here is an example of a WFS service on the server.

http://maps.dgs.udel.edu/geoserver/DGS_Surficial_and_Contact_Geology/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=DGS_Surficial_and_Contact_Geology:US-DE_DGS_100k_Surficial_Geology&maxFeatures=1

The fact that when the app-schema gsmlp WFS service works, none of the
other WFS services work, and vice-versa, makes me think the mapping file
is correct but geoserver is not utilizing
xmlns:gsmlp="http://xmlns.geosciml.org/geosciml-portrayal/2.0" in the
feature response.

Any suggestions on what I can try? Thanks.

- John

John Callahan
Research Scientist
Delaware Geological Survey
University of Delaware
http://www.dgs.udel.edu
john.callahan@anonymised.com <mailto:john.callahan@anonymised.com>

------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk

_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

Also:

On 28/08/13 14:33, John Callahan wrote:

It also fails using WFS 1.0.0 (java.lang.ClassCastException:
org.geotools.feature.type.ComplexFeatureTypeImpl cannot be cast to
org.opengis.feature.simple.SimpleFeatureType)

app-schema does not support WFS 1.0.0 (which uses GML 2). Your GML 3.1.1 application schema should work fine with WFS 1.1.0, which defaults to GML 3.1.1 output. See:
http://docs.geoserver.org/latest/en/user/data/app-schema/supported-gml-versions.html

but actually returns a response with WFS 2.0.0

If you look closely you will likely discover missing elements and other problems as there are type mismatches between the GML 3.2.1 encoder configuration that is the default for WFS 2.0.0 responses and the GML 3.1.1 information model in your application schema. GeoServer tries its best, but will make a hash of things.

Kind regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

Thank you Ben for your explanations. You are right, that service was working fine. However, it is not anymore. :wink: It stopped working when I changed the default workspace. I reviewed the app-schema tutorial and matched everything the best I can. It does work great when “gsmlp” is the default workspace (and occassionally other times but I cannot figure out a pattern.)

http://maps.dgs.udel.edu/geoserver/gsmlp/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=gsmlp:GeologicUnitView&maxFeatures=1

Perhaps the error is not app-schema related. Other services, not app-schema related, are also throwing the same “null” errors on WFS requests, shown below. I thought app-schema was involved because the problems started when the app-schema extension was installed and services created. My default workspace is now “dgs” (in second service below).

http://maps.dgs.udel.edu/geoserver/DGS_Surficial_and_Contact_Geology/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=DGS_Surficial_and_Contact_Geology:US-DE_DGS_100k_Surficial_Geology&maxFeatures=1 (does not work)

http://maps.dgs.udel.edu/geoserver/dgs/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=dgs:geomap18&maxFeatures=1 (works)

Thanks for any thoughts you might have. I am running GeoServer 2.3.4 on Windows.

···
  • John

John Callahan
Research Scientist
Delaware Geological Survey
University of Delaware
http://www.dgs.udel.edu

john.callahan@anonymised.com

On Wed, Aug 28, 2013 at 4:26 AM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com> wrote:

Also:

On 28/08/13 14:33, John Callahan wrote:

It also fails using WFS 1.0.0 (java.lang.ClassCastException:
org.geotools.feature.type.ComplexFeatureTypeImpl cannot be cast to
org.opengis.feature.simple.SimpleFeatureType)

app-schema does not support WFS 1.0.0 (which uses GML 2). Your GML 3.1.1 application schema should work fine with WFS 1.1.0, which defaults to GML 3.1.1 output. See:
http://docs.geoserver.org/latest/en/user/data/app-schema/supported-gml-versions.html

but actually returns a response with WFS 2.0.0

If you look closely you will likely discover missing elements and other problems as there are type mismatches between the GML 3.2.1 encoder configuration that is the default for WFS 2.0.0 responses and the GML 3.1.1 information model in your application schema. GeoServer tries its best, but will make a hash of things.

Kind regards,


Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

John,

this is perplexing. I have had a look at the capabilities responses and the responses for the top-level and workspace service URLs and I cannot see a pattern or anything obviously wrong.

- Do you get any errors in the logs when you start GeoServer?

- What happens if you remove the app-schema plugin and restart GeoServer? Do you still have problems with your simple feature response encoding?

- Please check that your app-schema plugin is from the same build as GeoServer core.

As a last resort, you could send me your workspaces folder.

Kind regards,
Ben.

On 29/08/13 02:27, John Callahan wrote:

Thank you Ben for your explanations. You are right, that service was
working fine. However, it is not anymore. :wink: It stopped working when
I changed the default workspace. I reviewed the app-schema tutorial and
matched everything the best I can. It does work great when "gsmlp" is
the default workspace (and occassionally other times but I cannot figure
out a pattern.)

http://maps.dgs.udel.edu/geoserver/gsmlp/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=gsmlp:GeologicUnitView&maxFeatures=1

Perhaps the error is not app-schema related. Other services, not
app-schema related, are also throwing the same "null" errors on WFS
requests, shown below. I thought app-schema was involved because the
problems started when the app-schema extension was installed and
services created. My default workspace is now "dgs" (in second service
below).

http://maps.dgs.udel.edu/geoserver/DGS_Surficial_and_Contact_Geology/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=DGS_Surficial_and_Contact_Geology:US-DE_DGS_100k_Surficial_Geology&maxFeatures=1
(does not work)

http://maps.dgs.udel.edu/geoserver/dgs/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=dgs:geomap18&maxFeatures=1 (works)

Thanks for any thoughts you might have. I am running GeoServer 2.3.4 on
Windows.

- John

John Callahan
Research Scientist
Delaware Geological Survey
University of Delaware
http://www.dgs.udel.edu
john.callahan@anonymised.com <mailto:john.callahan@anonymised.com>

On Wed, Aug 28, 2013 at 4:26 AM, Ben Caradoc-Davies
<Ben.Caradoc-Davies@anonymised.com <mailto:Ben.Caradoc-Davies@anonymised.com>> wrote:

    Also:

    On 28/08/13 14:33, John Callahan wrote:

        It also fails using WFS 1.0.0 (java.lang.ClassCastException:
        org.geotools.feature.type.__ComplexFeatureTypeImpl cannot be cast to
        org.opengis.feature.simple.__SimpleFeatureType)

    app-schema does not support WFS 1.0.0 (which uses GML 2). Your GML
    3.1.1 application schema should work fine with WFS 1.1.0, which
    defaults to GML 3.1.1 output. See:
    http://docs.geoserver.org/__latest/en/user/data/app-__schema/supported-gml-versions.__html
    <http://docs.geoserver.org/latest/en/user/data/app-schema/supported-gml-versions.html&gt;

        but actually returns a response with WFS 2.0.0

    If you look closely you will likely discover missing elements and
    other problems as there are type mismatches between the GML 3.2.1
    encoder configuration that is the default for WFS 2.0.0 responses
    and the GML 3.1.1 information model in your application schema.
    GeoServer tries its best, but will make a hash of things.

    Kind regards,

    --
    Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
    Software Engineer
    CSIRO Earth Science and Resource Engineering
    Australian Resources Research Centre

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

Thanks Ben. Yes, it is perplexing. The gsmlp (app-schema) service now has been working well but the simple feature WFS services, for all workspaces other then gsmlp, continue to return errors.

I have noticed that for the responses that return errors, the gsmlp namespace is included rather than the namespace being being called. This in turn (I think) leads to the null prefix for the featureMembers. For example, the call

http://maps.dgs.udel.edu/geoserver/DGS_Surficial_and_Contact_Geology/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=DGS_Surficial_and_Contact_Geology:US-DE_DGS_100k_Surficial_Geology&maxFeatures=1

includes in the response the following xmlns:

xmlns:gsmlp=“http://xmlns.geosciml.org/geosciml-portrayal/2.0

but should instead include:

xmlns:DGS_Surficial_and_Contact_Geology=“http://www.dgs.udel.edu/surficial_geology

I will look into your other questions. Good points.

···
  • John

On Thu, Aug 29, 2013 at 12:18 AM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com> wrote:

John,

this is perplexing. I have had a look at the capabilities responses and the responses for the top-level and workspace service URLs and I cannot see a pattern or anything obviously wrong.

  • Do you get any errors in the logs when you start GeoServer?

  • What happens if you remove the app-schema plugin and restart GeoServer? Do you still have problems with your simple feature response encoding?

  • Please check that your app-schema plugin is from the same build as GeoServer core.

As a last resort, you could send me your workspaces folder.

Kind regards,
Ben.

On 29/08/13 02:27, John Callahan wrote:

Thank you Ben for your explanations. You are right, that service was
working fine. However, it is not anymore. :wink: It stopped working when
I changed the default workspace. I reviewed the app-schema tutorial and
matched everything the best I can. It does work great when “gsmlp” is
the default workspace (and occassionally other times but I cannot figure
out a pattern.)

http://maps.dgs.udel.edu/geoserver/gsmlp/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=gsmlp:GeologicUnitView&maxFeatures=1

Perhaps the error is not app-schema related. Other services, not
app-schema related, are also throwing the same “null” errors on WFS
requests, shown below. I thought app-schema was involved because the
problems started when the app-schema extension was installed and
services created. My default workspace is now “dgs” (in second service
below).

http://maps.dgs.udel.edu/geoserver/DGS_Surficial_and_Contact_Geology/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=DGS_Surficial_and_Contact_Geology:US-DE_DGS_100k_Surficial_Geology&maxFeatures=1
(does not work)

http://maps.dgs.udel.edu/geoserver/dgs/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=dgs:geomap18&maxFeatures=1 (works)

Thanks for any thoughts you might have. I am running GeoServer 2.3.4 on
Windows.

  • John

John Callahan
Research Scientist
Delaware Geological Survey
University of Delaware
http://www.dgs.udel.edu

john.callahan@anonymised.com mailto:[john.callahan@anonymised.com](mailto:john.callahan@anonymised.com847...)

On Wed, Aug 28, 2013 at 4:26 AM, Ben Caradoc-Davies

<Ben.Caradoc-Davies@anonymised.com mailto:[Ben.Caradoc-Davies@csiro.au](mailto:Ben.Caradoc-Davies@anonymised.com)> wrote:

Also:

On 28/08/13 14:33, John Callahan wrote:

It also fails using WFS 1.0.0 (java.lang.ClassCastException:

org.geotools.feature.type.__ComplexFeatureTypeImpl cannot be cast to
org.opengis.feature.simple.__SimpleFeatureType)

app-schema does not support WFS 1.0.0 (which uses GML 2). Your GML
3.1.1 application schema should work fine with WFS 1.1.0, which
defaults to GML 3.1.1 output. See:

http://docs.geoserver.org/__latest/en/user/data/app-__schema/supported-gml-versions.__html

<http://docs.geoserver.org/latest/en/user/data/app-schema/supported-gml-versions.html>

but actually returns a response with WFS 2.0.0

If you look closely you will likely discover missing elements and
other problems as there are type mismatches between the GML 3.2.1
encoder configuration that is the default for WFS 2.0.0 responses
and the GML 3.1.1 information model in your application schema.
GeoServer tries its best, but will make a hash of things.

Kind regards,


Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre


Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

Thanks again Ben. As answers to your questions…

I started from scratch with GeoServer 2.3.5 on Windows. My simple feature WFS services work great, even with the app-schema extension loaded. However, the errors start when I create a layer with app-schema (by creating the layer first with the original data store, then editing the datastore.aml file and creating a new mapping file, then restarting Tomcat.) The new schema xsd is downloaded and stored in appo-schema-cache, as would be expected. The error is thrown with a WFS GetFeature request and is always something like:

The prefix “null” for element “null:GeologicUnitView” is not bound.

with of course GeologicUnitView is sometimes the simple feature WFS layer name. I still cannot determine a pattern on when the app-schema service throws the error or when the simple feature WFS service throws the error, but it is always one or the other. I cannot get both of them to work simultaneously. (I can always force one of them to work by setting that workspace as the default workspace.)

I have full verbose logging turned on. Not many errors when starting GeoServer, except for the standard JP2/ECW/MrSID errors. I do see plenty of

2013-09-01 12:11:45,210 DEBUG [referencing.factory] - Failure in the primary factory: No code “EPSG:26957” from authority “European Petroleum Survey Group” found for object of type “IdentifiedObject”. Now trying the fallback factory…

for each of my layers. Doubt this has anything to do with the problems since all my WMS services continue to work great.

Strange. Does anyone have a configuration of WFS simple feature and app-schema services both working fine? Would you be willing to share the config xml docs?

···
  • John

John Callahan
Research Scientist
Delaware Geological Survey
University of Delaware
http://www.dgs.udel.edu

john.callahan@anonymised.com

On Thu, Aug 29, 2013 at 1:14 AM, John Callahan <john.callahan@anonymised.com> wrote:

Thanks Ben. Yes, it is perplexing. The gsmlp (app-schema) service now has been working well but the simple feature WFS services, for all workspaces other then gsmlp, continue to return errors.

I have noticed that for the responses that return errors, the gsmlp namespace is included rather than the namespace being being called. This in turn (I think) leads to the null prefix for the featureMembers. For example, the call

http://maps.dgs.udel.edu/geoserver/DGS_Surficial_and_Contact_Geology/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=DGS_Surficial_and_Contact_Geology:US-DE_DGS_100k_Surficial_Geology&maxFeatures=1

includes in the response the following xmlns:

xmlns:gsmlp=“http://xmlns.geosciml.org/geosciml-portrayal/2.0

but should instead include:

xmlns:DGS_Surficial_and_Contact_Geology=“http://www.dgs.udel.edu/surficial_geology

I will look into your other questions. Good points.

  • John

On Thu, Aug 29, 2013 at 12:18 AM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com> wrote:

John,

this is perplexing. I have had a look at the capabilities responses and the responses for the top-level and workspace service URLs and I cannot see a pattern or anything obviously wrong.

  • Do you get any errors in the logs when you start GeoServer?

  • What happens if you remove the app-schema plugin and restart GeoServer? Do you still have problems with your simple feature response encoding?

  • Please check that your app-schema plugin is from the same build as GeoServer core.

As a last resort, you could send me your workspaces folder.

Kind regards,
Ben.

On 29/08/13 02:27, John Callahan wrote:

Thank you Ben for your explanations. You are right, that service was
working fine. However, it is not anymore. :wink: It stopped working when
I changed the default workspace. I reviewed the app-schema tutorial and
matched everything the best I can. It does work great when “gsmlp” is
the default workspace (and occassionally other times but I cannot figure
out a pattern.)

http://maps.dgs.udel.edu/geoserver/gsmlp/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=gsmlp:GeologicUnitView&maxFeatures=1

Perhaps the error is not app-schema related. Other services, not
app-schema related, are also throwing the same “null” errors on WFS
requests, shown below. I thought app-schema was involved because the
problems started when the app-schema extension was installed and
services created. My default workspace is now “dgs” (in second service
below).

http://maps.dgs.udel.edu/geoserver/DGS_Surficial_and_Contact_Geology/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=DGS_Surficial_and_Contact_Geology:US-DE_DGS_100k_Surficial_Geology&maxFeatures=1
(does not work)

http://maps.dgs.udel.edu/geoserver/dgs/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=dgs:geomap18&maxFeatures=1 (works)

Thanks for any thoughts you might have. I am running GeoServer 2.3.4 on
Windows.

  • John

John Callahan
Research Scientist
Delaware Geological Survey
University of Delaware
http://www.dgs.udel.edu

john.callahan@anonymised.com mailto:[john.callahan@anonymised.com](mailto:john.callahan@anonymised.com847...)

On Wed, Aug 28, 2013 at 4:26 AM, Ben Caradoc-Davies

<Ben.Caradoc-Davies@anonymised.com mailto:[Ben.Caradoc-Davies@csiro.au](mailto:Ben.Caradoc-Davies@anonymised.com)> wrote:

Also:

On 28/08/13 14:33, John Callahan wrote:

It also fails using WFS 1.0.0 (java.lang.ClassCastException:

org.geotools.feature.type.__ComplexFeatureTypeImpl cannot be cast to
org.opengis.feature.simple.__SimpleFeatureType)

app-schema does not support WFS 1.0.0 (which uses GML 2). Your GML
3.1.1 application schema should work fine with WFS 1.1.0, which
defaults to GML 3.1.1 output. See:

http://docs.geoserver.org/__latest/en/user/data/app-__schema/supported-gml-versions.__html

<http://docs.geoserver.org/latest/en/user/data/app-schema/supported-gml-versions.html>

but actually returns a response with WFS 2.0.0

If you look closely you will likely discover missing elements and
other problems as there are type mismatches between the GML 3.2.1
encoder configuration that is the default for WFS 2.0.0 responses
and the GML 3.1.1 information model in your application schema.
GeoServer tries its best, but will make a hash of things.

Kind regards,


Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre


Ben Caradoc-Davies Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

On 02/09/13 00:38, John Callahan wrote:

The prefix "null" for element "null:GeologicUnitView" is not bound.

Please zip your workspaces folder and email it to me. Feel free to remove anything confidential; I mainly want to see the default.xml, workspace.xml, namespace.xml, and featuretype.xml.

Does anyone have a configuration of WFS simple feature and
app-schema services both working fine?

Yes, with gsml:Borehole and gsmlp:BoreholeView, in addition to two simple feature namespaces. Not public at this time, but apparently working.

Kind regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

Confirmed.

Thanks for your zipped workspace. I started with the release example workspace (the one shipped with GeoServer) and used the app-schema tutorial GeologicUnit property file in a new gsmlp workspace and then edited the datastore as you described. I used your mapping file, changed the data store to use the property file, and edited the mappings to match the property file. The output is either fine or has null namespaces, seen both gsmlp:GeologicUnitView and topp:tasmania_roads, the latter being an unrelated simple feature. I have attached the workspace zip file.

The problem is intermittent. Changing settings seems to trigger it, but not reliably. If I can figure out how to repeat the behaviour, I might be able to determine if app-schema is the root cause.

Kind regards,
Ben.

On 02/09/13 14:02, John Callahan wrote:

Thanks Ben. Attached is the zipped workspaces folder tree.

Also thanks for your response to Christy. I am working with her on that
problem as well. We need to have the WMS SLDs working for the
app-schema services.

- John

John Callahan
Research Scientist
Delaware Geological Survey
University of Delaware
http://www.dgs.udel.edu
john.callahan@anonymised.com <mailto:john.callahan@anonymised.com>

On Mon, Sep 2, 2013 at 1:10 AM, Ben Caradoc-Davies
<Ben.Caradoc-Davies@anonymised.com <mailto:Ben.Caradoc-Davies@anonymised.com>> wrote:

    On 02/09/13 00:38, John Callahan wrote:

        The prefix "null" for element "null:GeologicUnitView" is not bound.

    Please zip your workspaces folder and email it to me. Feel free to
    remove anything confidential; I mainly want to see the default.xml,
    workspace.xml, namespace.xml, and featuretype.xml.

        Does anyone have a configuration of WFS simple feature and
        app-schema services both working fine?

    Yes, with gsml:Borehole and gsmlp:BoreholeView, in addition to two
    simple feature namespaces. Not public at this time, but apparently
    working.

    Kind regards,

    --
    Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
    Software Engineer
    CSIRO Earth Science and Resource Engineering
    Australian Resources Research Centre

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

gsmlp.zip (3.92 KB)

John,

thanks very much for your detailed bug report. I can now reliably reproduce this behaviour. I have created a Jira issue:
https://jira.codehaus.org/browse/GEOS-6014

Per-workspace URLs are a relatively new feature. These are the URLs containing geoserver/gsmlp/ows or similar instead of the top-level geoserver/ows or similar. It looks like there is a bug in app-schema, and that app-schema per-workspace URLs cause corruption of other namespaces, if and only if they are the first layer accessed after a GeoServer restart.

The workaround is to not use per-workspace URLs like this:

http://maps.dgs.udel.edu/geoserver/gsmlp/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=gsmlp:GeologicUnitView&maxFeatures=1

Instead only use top-level URLs like this:

http://maps.dgs.udel.edu/geoserver/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=gsmlp:GeologicUnitView&maxFeatures=1

Thanks again.

Kind regards,
Ben.

On 02/09/13 15:48, Ben Caradoc-Davies wrote:

Confirmed.

Thanks for your zipped workspace. I started with the release example
workspace (the one shipped with GeoServer) and used the app-schema
tutorial GeologicUnit property file in a new gsmlp workspace and then
edited the datastore as you described. I used your mapping file, changed
the data store to use the property file, and edited the mappings to
match the property file. The output is either fine or has null
namespaces, seen both gsmlp:GeologicUnitView and topp:tasmania_roads,
the latter being an unrelated simple feature. I have attached the
workspace zip file.

The problem is intermittent. Changing settings seems to trigger it, but
not reliably. If I can figure out how to repeat the behaviour, I might
be able to determine if app-schema is the root cause.

Kind regards,
Ben.

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

Hmm, but is it safe to use per workspace GetCapabilities? I think that is necessary, if one workspace is for WMS, and the other for WFS. We have a confiruration here, where common WMS and WFS are turned off and those services are configured by workspace.

Oiva Hakala, Agrifood Research Finland

________________________________________
Lähettäjä: Ben Caradoc-Davies [Ben.Caradoc-Davies@anonymised.com]
Lähetetty: 2. syyskuuta 2013 11:59
Vastaanottaja: John Callahan
Kopio: Rini Angreani; geoserver-users@lists.sourceforge.net
Aihe: Re: [Geoserver-users] [ExternalEmail] Re: prefix "null" problem for app-schema WFS service

John,

thanks very much for your detailed bug report. I can now reliably
reproduce this behaviour. I have created a Jira issue:
https://jira.codehaus.org/browse/GEOS-6014

Per-workspace URLs are a relatively new feature. These are the URLs
containing geoserver/gsmlp/ows or similar instead of the top-level
geoserver/ows or similar. It looks like there is a bug in app-schema,
and that app-schema per-workspace URLs cause corruption of other
namespaces, if and only if they are the first layer accessed after a
GeoServer restart.

The workaround is to not use per-workspace URLs like this:

http://maps.dgs.udel.edu/geoserver/gsmlp/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=gsmlp:GeologicUnitView&maxFeatures=1

Instead only use top-level URLs like this:

http://maps.dgs.udel.edu/geoserver/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=gsmlp:GeologicUnitView&maxFeatures=1

Thanks again.

Kind regards,
Ben.

Oiva,

this is unsafe with app-schema layers as accessing these via a workspace-specific URL appears to cause the problem. I strongly recommend using only the top-level service URLs for app-schema layers until this bug is fixed. Exposing workspace GetCapabilities will cause workspace service URLs to be discovered.

Kind regards,
Ben.

On 02/09/13 18:21, Hakala Oiva (MTT) wrote:

Hmm, but is it safe to use per workspace GetCapabilities? I think that is necessary, if one workspace is for WMS, and the other for WFS. We have a confiruration here, where common WMS and WFS are turned off and those services are configured by workspace.

Oiva Hakala, Agrifood Research Finland

________________________________________
Lähettäjä: Ben Caradoc-Davies [Ben.Caradoc-Davies@anonymised.com]
Lähetetty: 2. syyskuuta 2013 11:59
Vastaanottaja: John Callahan
Kopio: Rini Angreani; geoserver-users@lists.sourceforge.net
Aihe: Re: [Geoserver-users] [ExternalEmail] Re: prefix "null" problem for app-schema WFS service

John,

thanks very much for your detailed bug report. I can now reliably
reproduce this behaviour. I have created a Jira issue:
https://jira.codehaus.org/browse/GEOS-6014

Per-workspace URLs are a relatively new feature. These are the URLs
containing geoserver/gsmlp/ows or similar instead of the top-level
geoserver/ows or similar. It looks like there is a bug in app-schema,
and that app-schema per-workspace URLs cause corruption of other
namespaces, if and only if they are the first layer accessed after a
GeoServer restart.

The workaround is to not use per-workspace URLs like this:

http://maps.dgs.udel.edu/geoserver/gsmlp/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=gsmlp:GeologicUnitView&maxFeatures=1

Instead only use top-level URLs like this:

http://maps.dgs.udel.edu/geoserver/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=gsmlp:GeologicUnitView&maxFeatures=1

Thanks again.

Kind regards,
Ben.

------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

Thanks Ben.

However I do not know anything about app-schema layers. I have published layers in a very basic way from shapes and mostly from Postgis database. So maybe I am not concerned, when talking about this specific bug. Maybe I get to know later what an app-schema layer is :wink:

Best regards,

Oiva

Oiva,

this is unsafe with app-schema layers as accessing these via a
workspace-specific URL appears to cause the problem. I strongly
recommend using only the top-level service URLs for app-schema layers
until this bug is fixed. Exposing workspace GetCapabilities will cause
workspace service URLs to be discovered.

Kind regards,
Ben.

On 02/09/13 18:21, Hakala Oiva (MTT) wrote:

Hmm, but is it safe to use per workspace GetCapabilities? I think that is necessary, if one workspace is for WMS, and the other for WFS. We have a confiruration here, where common WMS and WFS are turned off and those services are configured by workspace.

Oiva Hakala, Agrifood Research Finland

________________________________________
Lähettäjä: Ben Caradoc-Davies [Ben.Caradoc-Davies@anonymised.com]
Lähetetty: 2. syyskuuta 2013 11:59
Vastaanottaja: John Callahan
Kopio: Rini Angreani; geoserver-users@lists.sourceforge.net
Aihe: Re: [Geoserver-users] [ExternalEmail] Re: prefix "null" problem for app-schema WFS service

John,

thanks very much for your detailed bug report. I can now reliably
reproduce this behaviour. I have created a Jira issue:
https://jira.codehaus.org/browse/GEOS-6014

Per-workspace URLs are a relatively new feature. These are the URLs
containing geoserver/gsmlp/ows or similar instead of the top-level
geoserver/ows or similar. It looks like there is a bug in app-schema,
and that app-schema per-workspace URLs cause corruption of other
namespaces, if and only if they are the first layer accessed after a
GeoServer restart.

The workaround is to not use per-workspace URLs like this:

http://maps.dgs.udel.edu/geoserver/gsmlp/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=gsmlp:GeologicUnitView&maxFeatures=1

Instead only use top-level URLs like this:

http://maps.dgs.udel.edu/geoserver/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=gsmlp:GeologicUnitView&maxFeatures=1

Thanks again.

Kind regards,
Ben.

------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

Oiva,

if you have not installed the app-schema plugin, you will not be affected by this bug, and it is safe for you to continue using per-workspace service URLs.

The app-schema plugin maps simple features (the "normal" features you get from shapefiles/postgis/...) into complex information models defined by application schemas:
http://docs.geoserver.org/latest/en/user/data/app-schema/index.html

Kind regards,
Ben.

On 03/09/13 12:59, Hakala Oiva (MTT) wrote:

Thanks Ben.

However I do not know anything about app-schema layers. I have published layers in a very basic way from shapes and mostly from Postgis database. So maybe I am not concerned, when talking about this specific bug. Maybe I get to know later what an app-schema layer is :wink:

Best regards,

Oiva

Oiva,

this is unsafe with app-schema layers as accessing these via a
workspace-specific URL appears to cause the problem. I strongly
recommend using only the top-level service URLs for app-schema layers
until this bug is fixed. Exposing workspace GetCapabilities will cause
workspace service URLs to be discovered.

Kind regards,
Ben.

On 02/09/13 18:21, Hakala Oiva (MTT) wrote:

Hmm, but is it safe to use per workspace GetCapabilities? I think that is necessary, if one workspace is for WMS, and the other for WFS. We have a confiruration here, where common WMS and WFS are turned off and those services are configured by workspace.

Oiva Hakala, Agrifood Research Finland

________________________________________
Lähettäjä: Ben Caradoc-Davies [Ben.Caradoc-Davies@anonymised.com]
Lähetetty: 2. syyskuuta 2013 11:59
Vastaanottaja: John Callahan
Kopio: Rini Angreani; geoserver-users@lists.sourceforge.net
Aihe: Re: [Geoserver-users] [ExternalEmail] Re: prefix "null" problem for app-schema WFS service

John,

thanks very much for your detailed bug report. I can now reliably
reproduce this behaviour. I have created a Jira issue:
https://jira.codehaus.org/browse/GEOS-6014

Per-workspace URLs are a relatively new feature. These are the URLs
containing geoserver/gsmlp/ows or similar instead of the top-level
geoserver/ows or similar. It looks like there is a bug in app-schema,
and that app-schema per-workspace URLs cause corruption of other
namespaces, if and only if they are the first layer accessed after a
GeoServer restart.

The workaround is to not use per-workspace URLs like this:

http://maps.dgs.udel.edu/geoserver/gsmlp/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=gsmlp:GeologicUnitView&maxFeatures=1

Instead only use top-level URLs like this:

http://maps.dgs.udel.edu/geoserver/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=gsmlp:GeologicUnitView&maxFeatures=1

Thanks again.

Kind regards,
Ben.

------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre