[Geoserver-users] geoserver-1.6.0-beta Exception

Chris_Hodgson · August 28, 2007, 9:32pm

I'm getting the following error when trying to do a basic GET request from my 1.6.0-beta server:

http://…/geoserver/wfs?request=GetFeature&service=WFS&version=1.1.0&typename=PlaceName&maxFeatures=1

<?xml version="1.0" encoding="UTF-8"?>
<ows:ExceptionReport version="1.0.0"
   xsi:schemaLocation="http://www.opengis.net/ows http://office.refractions.net:21880/geoserver/schemas/ows/1.0.0/owsExceptionReport.xsd"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ows="http://www.opengis.net/ows">
   <ows:Exception exceptionCode="NoApplicableCode">
     <ows:ExceptionText>java.lang.NullPointerException
java.lang.NullPointerException</ows:ExceptionText>
   </ows:Exception>
</ows:ExceptionReport>

The following output is logged during the request - the exception appears to occur in the org.geotools.gml2 package, which appears to be provided by gt2-xml-gml2-2.4-SNAPSHOT.jar, which apparently is an unsupported module of geotools... all in all it looks like an awful mess to debug, especially for me who doesn't already have a geoserver build environment set up. Can anyone guess what would cause an exception there, that only happens for *most* of my postgis tables when setup using the basic default configuration in the web config GUI? I can't see how the tables that do respond to a basic request are different from the ones that cause this exception.

2163579753 [btpool0-0] INFO org.geoserver.wfs -
Request: getFeature
         handle = null
         service = WFS
         version = 1.1.0
         query = [net.opengis.wfs.impl.QueryTypeImpl@anonymised.com (group: null, propertyName: null, function: null, filter: null, sortBy: null, featureVersion: null, handle: null, srsName: null, typeName: [{http://www.geobase.ca/interop-pilot-2007\}PlaceName])]
         maxFeatures = 1
         outputFormat = text/xml; subtype=gml/3.1.1
         resultType = results
         traverseXlinkDepth = null
         traverseXlinkExpiry = null

Result:
2163579790 [btpool0-0] WARN org.geoserver.ows -
java.lang.NullPointerException
         at org.geotools.gml2.FeaturePropertyExtractor.properties(FeaturePropertyExtractor.java:60)
         at org.geotools.xml.Encoder.encode(Encoder.java:527)
         at org.geoserver.wfs.xml.GML3OutputFormat.write(GML3OutputFormat.java:106)
         at org.geoserver.wfs.WFSGetFeatureOutputFormat.write(WFSGetFeatureOutputFormat.java:98)
         at org.geoserver.ows.Dispatcher.response(Dispatcher.java:611)
         at org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:210)
         at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:139)
         at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:44)
         at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:684)
         at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:625)
         at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:392)
         at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:347)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
         at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
         at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:459)
         at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1054)
         at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
         at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)
         at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)
         at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
         at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
         at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
         at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
         at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
         at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:178)
         at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
         at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)
         at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
         at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
         at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
         at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
         at org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
         at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
         at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:358)
         at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:231)
         at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:629)
         at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:453)
         at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:149)
         at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:123)
         at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:141)
         at org.mortbay.jetty.Server.handle(Server.java:303)
         at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:452)
         at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:721)
         at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:509)
         at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
         at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:349)
         at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:320)
         at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
2163579816 [Finalizer] ERROR org.geotools.data.jdbc - There's code leaving readers, writers or iterators unclosed (you got an unclosed QueryData object, which is usually held by a reader or a writer).
Call reader/writer.close() or FeatureCollection.close(iterator) after using them to ensure they do not hold state such as JDCB connections.
QueryData was open against feature type: PlaceName

Andrea_Aime3 · August 29, 2007, 8:05am

Chris Hodgson ha scritto:

I'm getting the following error when trying to do a basic GET request from my 1.6.0-beta server:

http://…/geoserver/wfs?request=GetFeature&service=WFS&version=1.1.0&typename=PlaceName&maxFeatures=1

<?xml version="1.0" encoding="UTF-8"?>
<ows:ExceptionReport version="1.0.0"
   xsi:schemaLocation="http://www.opengis.net/ows http://office.refractions.net:21880/geoserver/schemas/ows/1.0.0/owsExceptionReport.xsd"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ows="http://www.opengis.net/ows">
   <ows:Exception exceptionCode="NoApplicableCode">
     <ows:ExceptionText>java.lang.NullPointerException
java.lang.NullPointerException</ows:ExceptionText>
   </ows:Exception>
</ows:ExceptionReport>

...

Result:
2163579790 [btpool0-0] WARN org.geoserver.ows -
java.lang.NullPointerException
at

Ok, can I ask you to do two things? The first one would be to try out a nightly, it may be that Justin already fixed this one:
http://geo.openplans.org/nightly/trunk/

Also, what happens if you qualify your typename with the prefix? (topp:PlaceName or whatever is the namespace you used).

Cheers
Andrea

Justin_Deoliveira · August 29, 2007, 4:15pm

I can replicate the problem... and it seems to occur when reprojection
is occurring. I am currently looking into wfs reprojection,

Chris: it appears my patch from the other day was not complete. I am
working on a revised one. I will keep you posted.

-Justin

Andrea Aime wrote:

Chris Hodgson ha scritto:

I'm getting the following error when trying to do a basic GET request
from my 1.6.0-beta server:

http://…/geoserver/wfs?request=GetFeature&service=WFS&version=1.1.0&typename=PlaceName&maxFeatures=1

<?xml version="1.0" encoding="UTF-8"?>
<ows:ExceptionReport version="1.0.0"
   xsi:schemaLocation="http://www.opengis.net/ows
http://office.refractions.net:21880/geoserver/schemas/ows/1.0.0/owsExceptionReport.xsd"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ows="http://www.opengis.net/ows">
   <ows:Exception exceptionCode="NoApplicableCode">
     <ows:ExceptionText>java.lang.NullPointerException
java.lang.NullPointerException</ows:ExceptionText>
   </ows:Exception>
</ows:ExceptionReport>

...

Result:
2163579790 [btpool0-0] WARN org.geoserver.ows -
java.lang.NullPointerException
         at

Ok, can I ask you to do two things? The first one would be to try out a
nightly, it may be that Justin already fixed this one:
http://geo.openplans.org/nightly/trunk/

Also, what happens if you qualify your typename with the prefix?
(topp:PlaceName or whatever is the namespace you used).

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

!DSPAM:4007,46d528e1170551804284693!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Chris_Hodgson · August 29, 2007, 4:36pm

Interesting Justin, though my request isn't specifying any projection.

To Andrea, I have tried with and without the namespace prefix specified, it doesn't change the resulting error.

I haven't tried the latest nightly yet, I was in the process of downloading it but if Justin thinks there is more to fix I may just wait for a bit until he's made those changes before re-installing.

Thanks very much for the help!

Chris

Justin Deoliveira wrote:

I can replicate the problem... and it seems to occur when reprojection
is occurring. I am currently looking into wfs reprojection,

Chris: it appears my patch from the other day was not complete. I am
working on a revised one. I will keep you posted.

-Justin

Andrea Aime wrote:

Chris Hodgson ha scritto:

I'm getting the following error when trying to do a basic GET request from my 1.6.0-beta server:

http://…/geoserver/wfs?request=GetFeature&service=WFS&version=1.1.0&typename=PlaceName&maxFeatures=1

<?xml version="1.0" encoding="UTF-8"?>
<ows:ExceptionReport version="1.0.0"
   xsi:schemaLocation="http://www.opengis.net/ows http://office.refractions.net:21880/geoserver/schemas/ows/1.0.0/owsExceptionReport.xsd"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ows="http://www.opengis.net/ows">
   <ows:Exception exceptionCode="NoApplicableCode">
     <ows:ExceptionText>java.lang.NullPointerException
java.lang.NullPointerException</ows:ExceptionText>
   </ows:Exception>
</ows:ExceptionReport>

...

Result:
2163579790 [btpool0-0] WARN org.geoserver.ows -
java.lang.NullPointerException
         at

Ok, can I ask you to do two things? The first one would be to try out a nightly, it may be that Justin already fixed this one:
http://geo.openplans.org/nightly/trunk/

Also, what happens if you qualify your typename with the prefix? (topp:PlaceName or whatever is the namespace you used).

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

!DSPAM:4007,46d528e1170551804284693!

Justin_Deoliveira · August 29, 2007, 9:18pm

Hi Chris,

I just generated a new nightly build which has all the projection fixes
applied.

http://geo.openplans.org/nightly/trunk/geoserver-trunk-latest-bin.zip

Aleda: I believe this will also be relevant to you.

Chris: I don't think this will fix your second problem with the gml3
encoding but it will be good to be running the same code. I am still
working on reproducing that problem over here.

Can I get access to the configuration on the server? Perhaps you can
send me the info in a private email?

-Justin

Chris Hodgson wrote:

Interesting Justin, though my request isn't specifying any projection.

To Andrea, I have tried with and without the namespace prefix specified,
it doesn't change the resulting error.

I haven't tried the latest nightly yet, I was in the process of
downloading it but if Justin thinks there is more to fix I may just wait
for a bit until he's made those changes before re-installing.

Thanks very much for the help!

Chris

Justin Deoliveira wrote:

I can replicate the problem... and it seems to occur when reprojection
is occurring. I am currently looking into wfs reprojection,

Chris: it appears my patch from the other day was not complete. I am
working on a revised one. I will keep you posted.

-Justin

Andrea Aime wrote:

Chris Hodgson ha scritto:

I'm getting the following error when trying to do a basic GET request
from my 1.6.0-beta server:

http://…/geoserver/wfs?request=GetFeature&service=WFS&version=1.1.0&typename=PlaceName&maxFeatures=1

<?xml version="1.0" encoding="UTF-8"?>
<ows:ExceptionReport version="1.0.0"
   xsi:schemaLocation="http://www.opengis.net/ows
http://office.refractions.net:21880/geoserver/schemas/ows/1.0.0/owsExceptionReport.xsd"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ows="http://www.opengis.net/ows">
   <ows:Exception exceptionCode="NoApplicableCode">
     <ows:ExceptionText>java.lang.NullPointerException
java.lang.NullPointerException</ows:ExceptionText>
   </ows:Exception>
</ows:ExceptionReport>

...

Result:
2163579790 [btpool0-0] WARN org.geoserver.ows -
java.lang.NullPointerException
         at

Ok, can I ask you to do two things? The first one would be to try out a
nightly, it may be that Justin already fixed this one:
http://geo.openplans.org/nightly/trunk/

Also, what happens if you qualify your typename with the prefix?
(topp:PlaceName or whatever is the namespace you used).

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

!DSPAM:4007,46d5ab0c301111804284693!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Chris_Hodgson · August 29, 2007, 11:23pm

Justin: The nightly build you made seems to have fixed everything. Who knows what was causing the exception I reported (gml related) but it seems to be fixed. Yay!

Thanks a bunch!

Chris

Justin Deoliveira wrote:

Hi Chris,

I just generated a new nightly build which has all the projection fixes
applied.

http://geo.openplans.org/nightly/trunk/geoserver-trunk-latest-bin.zip

Aleda: I believe this will also be relevant to you.

Chris: I don't think this will fix your second problem with the gml3
encoding but it will be good to be running the same code. I am still
working on reproducing that problem over here.

Can I get access to the configuration on the server? Perhaps you can
send me the info in a private email?

-Justin

Chris Hodgson wrote:

Interesting Justin, though my request isn't specifying any projection.

To Andrea, I have tried with and without the namespace prefix specified, it doesn't change the resulting error.

I haven't tried the latest nightly yet, I was in the process of downloading it but if Justin thinks there is more to fix I may just wait for a bit until he's made those changes before re-installing.

Thanks very much for the help!

Chris

Justin Deoliveira wrote:

I can replicate the problem... and it seems to occur when reprojection
is occurring. I am currently looking into wfs reprojection,

Chris: it appears my patch from the other day was not complete. I am
working on a revised one. I will keep you posted.

-Justin

Andrea Aime wrote:

Chris Hodgson ha scritto:

I'm getting the following error when trying to do a basic GET request from my 1.6.0-beta server:

http://…/geoserver/wfs?request=GetFeature&service=WFS&version=1.1.0&typename=PlaceName&maxFeatures=1

<?xml version="1.0" encoding="UTF-8"?>
<ows:ExceptionReport version="1.0.0"
   xsi:schemaLocation="http://www.opengis.net/ows http://office.refractions.net:21880/geoserver/schemas/ows/1.0.0/owsExceptionReport.xsd"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ows="http://www.opengis.net/ows">
   <ows:Exception exceptionCode="NoApplicableCode">
     <ows:ExceptionText>java.lang.NullPointerException
java.lang.NullPointerException</ows:ExceptionText>
   </ows:Exception>
</ows:ExceptionReport>

...

Result:
2163579790 [btpool0-0] WARN org.geoserver.ows -
java.lang.NullPointerException
         at

Ok, can I ask you to do two things? The first one would be to try out a nightly, it may be that Justin already fixed this one:
http://geo.openplans.org/nightly/trunk/

Also, what happens if you qualify your typename with the prefix? (topp:PlaceName or whatever is the namespace you used).

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

!DSPAM:4007,46d5ab0c301111804284693!

Chris_Hodgson · August 30, 2007, 11:33pm

Chris Hodgson wrote:

Justin: The nightly build you made seems to have fixed everything. Who knows what was causing the exception I reported (gml related) but it seems to be fixed. Yay!

I spoke too soon it seems. I am experiencing a few new issues with a very recent nightly build of 1.6:

- for some FeatureTypes (seems to be the point layers that are more troublesome) the geometry property is not being returned at all in either getFeature or describeFeatureType - unless version 1.0 is specified in the request, in which case it correctly returns the geometry property

- I am unable to get it to return MultiSurfaces instead of MultiPolygons. MultiPolygons have been deprecated in GML3 and replaced by MultiSurfaces, and the schema I am trying to match is specifying a MultiSurface.

- one of the properties of one of my featureTypes is "name" and Geoserver is returning it as <gml:name>foobar</gml:name> instead of <gb:name>foobar</gb:name>, which is what I would expect since my default namespace is configured to be gb.

Justin figured that these are likely bugs related to the GML3 generation code. I'd love to here of any workarounds or solutions.

Thanks,
Chris

Andrea_Aime3 · August 31, 2007, 3:59pm

Chris Hodgson ha scritto:

Chris Hodgson wrote:

Justin: The nightly build you made seems to have fixed everything. Who knows what was causing the exception I reported (gml related) but it seems to be fixed. Yay!

I spoke too soon it seems. I am experiencing a few new issues with a very recent nightly build of 1.6:

- for some FeatureTypes (seems to be the point layers that are more troublesome) the geometry property is not being returned at all in either getFeature or describeFeatureType - unless version 1.0 is specified in the request, in which case it correctly returns the geometry property

This is strange... can you set up a request showing the problem against
the sample data sets (there are three point layers) or provide us
with the request and with the

- I am unable to get it to return MultiSurfaces instead of MultiPolygons. MultiPolygons have been deprecated in GML3 and replaced by MultiSurfaces, and the schema I am trying to match is specifying a MultiSurface.

There was some discussion on this and I believe we had some troubles
with insert request using MultiPolygons but... I most probably
need Justin to see over this.

- one of the properties of one of my featureTypes is "name" and Geoserver is returning it as <gml:name>foobar</gml:name> instead of <gb:name>foobar</gb:name>, which is what I would expect since my default namespace is configured to be gb.

Hum, I guess the problem here is that <gml:Feature> has the name attribute inside and I don't know if we can replaced with the
namespace of an extending type. Justin will know more, but he's
not around today.

Cheers
Andrea

Justin_Deoliveira · September 4, 2007, 5:41am

Hi Chris,

Apologies for the delayed response. But looking into your problems I
would bet that you are running a java 1.6 jdk?

If I am correct you are running into a couple of bugs that only rear
their head in java 6. You may or may not be aware but in java 6 they
have reversed the iteration order for hash maps. Which as you can see is
leading to some strange bugs.

So... an easy fix is to revert to java 4 or 5. I am fairly certain this
will fix your problem of returning MultiPolygon instead of MultiSurface.
And I have a hunch that it will fix the geometry not being encoded
problem as well... but i am not sure.. .i cant replicate that one.

I you are not running java 6 well.... i eat my words :). In that case
getting access to the data would be helpful. Is there anyway we can get
a partial dump the data?

As for the gb:name vs gml:name issue... as Andrea states in gml3 the
base type which all features inheirit from, "AbstractFeatureType",
defines a "name" member. So GeoServer maps this to the gml:name.

That being said having a second name which is part of the "application
schema" is perfectly valid. The problem lies in the underlying geotools
feature model. An AttributeType has only a single name, and not a
namespace qualified name... so there is no real way to tell GeoServer
which namespace an attribute is actually in. The new feature model
remedies this but that work is still in the experimental stages
currently on geotools trunk.

-Justin

Chris Hodgson wrote:

Chris Hodgson wrote:

Justin: The nightly build you made seems to have fixed everything. Who
knows what was causing the exception I reported (gml related) but it
seems to be fixed. Yay!

I spoke too soon it seems. I am experiencing a few new issues with a
very recent nightly build of 1.6:

- for some FeatureTypes (seems to be the point layers that are more
troublesome) the geometry property is not being returned at all in
either getFeature or describeFeatureType - unless version 1.0 is
specified in the request, in which case it correctly returns the
geometry property

- I am unable to get it to return MultiSurfaces instead of
MultiPolygons. MultiPolygons have been deprecated in GML3 and replaced
by MultiSurfaces, and the schema I am trying to match is specifying a
MultiSurface.

- one of the properties of one of my featureTypes is "name" and
Geoserver is returning it as <gml:name>foobar</gml:name> instead of
<gb:name>foobar</gb:name>, which is what I would expect since my default
namespace is configured to be gb.

Justin figured that these are likely bugs related to the GML3 generation
code. I'd love to here of any workarounds or solutions.

Thanks,
Chris

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

!DSPAM:4007,46d75eb238567180515871!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Andrea_Aime3 · September 4, 2007, 6:19am

Justin Deoliveira ha scritto:

Hi Chris,

...

As for the gb:name vs gml:name issue... as Andrea states in gml3 the
base type which all features inheirit from, "AbstractFeatureType",
defines a "name" member. So GeoServer maps this to the gml:name.

That being said having a second name which is part of the "application
schema" is perfectly valid. The problem lies in the underlying geotools
feature model. An AttributeType has only a single name, and not a
namespace qualified name... so there is no real way to tell GeoServer
which namespace an attribute is actually in. The new feature model
remedies this but that work is still in the experimental stages
currently on geotools trunk.

Wondering... would it be safe/possible to assume if "name" is an explicit attribute then it should be treated as part of the application
schema? I believe this may cause troubles with cite tests, in this case,
would definiting a custom schema in the feature type directory cure
the problem?

Cheers
Andrea

Justin_Deoliveira · September 4, 2007, 7:34am

Wondering... would it be safe/possible to assume if "name" is an
explicit attribute then it should be treated as part of the application
schema? I believe this may cause troubles with cite tests, in this case,
would definiting a custom schema in the feature type directory cure
the problem?

Yeah... it would definitely through off cite tests. Tough call... as
points can be made for both ways....

Chris: Is there a particular issue with using gml:name? Or is it just
something that you noted as different from 1.0 output?

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

!DSPAM:4007,46dcf8f784994901796417!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Ugo_Taddei · September 4, 2007, 7:35am

Hi,

I thought I'd drop a note on this.

I had an issue with geoserver (1.5.1 or 1.5.2) and a postgis datastore. Geoserver refused to serve feature types backed by a table which had a 'name' column. Renaming the column to 'the_name' fixed the issue.

Anyway, I wonder whether it's too much to have a gml name, and a second application-specific name. (Does anyone out there really need such a thing?)

Cheers,

Ugo

Andrea Aime wrote:

Justin Deoliveira ha scritto:

Hi Chris,

...

As for the gb:name vs gml:name issue... as Andrea states in gml3 the
base type which all features inheirit from, "AbstractFeatureType",
defines a "name" member. So GeoServer maps this to the gml:name.

That being said having a second name which is part of the "application
schema" is perfectly valid. The problem lies in the underlying geotools
feature model. An AttributeType has only a single name, and not a
namespace qualified name... so there is no real way to tell GeoServer
which namespace an attribute is actually in. The new feature model
remedies this but that work is still in the experimental stages
currently on geotools trunk.

Wondering... would it be safe/possible to assume if "name" is an explicit attribute then it should be treated as part of the application
schema? I believe this may cause troubles with cite tests, in this case,
would definiting a custom schema in the feature type directory cure
the problem?

Cheers
Andrea

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Ugo Taddei

Fraunhofer Institut Intelligente Analyse- und Informationssysteme (FhG IAIS)
http://www.iais.fraunhofer.de
Department Knowledge Discovery - IAIS.KD -
Working Group Spatial Decision Support
http://www.iais.fraunhofer.de/kd.html
phone (+49)2241-14-2184 fax (+49)2241-14-2072
Schloss Birlinghoven, D-53754 Sankt Augustin, Germany
------------------------------------------------------
Visit our thematic mapping tool CommonGIS: http://www.commongis.de

Chris_Hodgson · September 6, 2007, 4:55pm

Justin Deoliveira wrote:
> Apologies for the delayed response. But looking into your problems I
> would bet that you are running a java 1.6 jdk?

Yes, I am running java 1.6, I thought newest would surely be best. <buzzer> Wrong again! Tell him what he didn't won, Bob!
I'll setup java 1.5 and give it a try.

Justin Deoliveira wrote:

As for the gb:name vs gml:name issue... as Andrea states in gml3 the
base type which all features inheirit from, "AbstractFeatureType",
defines a "name" member. So GeoServer maps this to the gml:name.

That being said having a second name which is part of the "application
schema" is perfectly valid. The problem lies in the underlying geotools
feature model. An AttributeType has only a single name, and not a
namespace qualified name... so there is no real way to tell GeoServer
which namespace an attribute is actually in. The new feature model
remedies this but that work is still in the experimental stages
currently on geotools trunk.

Yah, I think when this schema was created they weren't necessarily paying much attention to AbstractFeatureType and possible overlap in property names (neither trying to re-use nor trying to avoid re-using them). But ideally I want to be able to match it. Perhaps using gml:name is good enough, but perhaps it would make more sense to default to the application schema rather than to inherited properties... hard to say.

Chris

Justin_Deoliveira · September 6, 2007, 5:08pm

Chris Hodgson wrote:

Justin Deoliveira wrote:
> Apologies for the delayed response. But looking into your problems I
> would bet that you are running a java 1.6 jdk?

Yes, I am running java 1.6, I thought newest would surely be best.
<buzzer> Wrong again! Tell him what he didn't won, Bob!
I'll setup java 1.5 and give it a try.

Well in terms of performance java 6 is far and away better. Just that
with the reversed iteration order we still have some bugs to sort out.

Justin Deoliveira wrote:

As for the gb:name vs gml:name issue... as Andrea states in gml3 the
base type which all features inheirit from, "AbstractFeatureType",
defines a "name" member. So GeoServer maps this to the gml:name.

That being said having a second name which is part of the "application
schema" is perfectly valid. The problem lies in the underlying geotools
feature model. An AttributeType has only a single name, and not a
namespace qualified name... so there is no real way to tell GeoServer
which namespace an attribute is actually in. The new feature model
remedies this but that work is still in the experimental stages
currently on geotools trunk.

Yah, I think when this schema was created they weren't necessarily
paying much attention to AbstractFeatureType and possible overlap in
property names (neither trying to re-use nor trying to avoid re-using
them). But ideally I want to be able to match it. Perhaps using gml:name
is good enough, but perhaps it would make more sense to default to the
application schema rather than to inherited properties... hard to say.

I hear you there... its a tough call. Maybe try continuing on as is and
this represents a real roadblock for you just let us know.

Chris

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

!DSPAM:4007,46e0330e275158362916074!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Chris_Hodgson · September 6, 2007, 5:21pm

Justin Deoliveira wrote:

So... an easy fix is to revert to java 4 or 5. I am fairly certain this
will fix your problem of returning MultiPolygon instead of MultiSurface.
And I have a hunch that it will fix the geometry not being encoded
problem as well... but i am not sure.. .i cant replicate that one.

I've got in running on Java 1.5 now, this does fix the MultiSurface vs. MultiPolygon issue. Relying on the order of an iterator over a Map doesn't sound like a good idea

However, this doesn't do anything for my "no geometry property returned for WFS 1.1/GML3 while it is returned fine in WFS 1.0/GML2" issue. Hopefully Andrea's further investigation can find something there. Andrea please let me know if there is anything else I can do to help you look into this.

Thanks,
Chris

Justin_Deoliveira · September 7, 2007, 6:55pm

Hi Chris,

SO looking into it... it appears that the problem actually is that the
column is named "location". AbstractFeatureType actually declares a a
member called "location", however looking at the schema it appears to be
deprecated...

The reason you did not see it fixed when you changed the column name is
that geoserver was caching the old name in memory. So you actually have
to remove the feature type from the configuration and add it again.

Regardless, this is a bug and I am opening an issue for it.

http://jira.codehaus.org/browse/GEOS-1320

-Justin

However, this doesn't do anything for my "no geometry property returned
for WFS 1.1/GML3 while it is returned fine in WFS 1.0/GML2" issue.
Hopefully Andrea's further investigation can find something there.
Andrea please let me know if there is anything else I can do to help you
look into this.

Thanks,
Chris

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

!DSPAM:4007,46e03a23285501849620573!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org