Hi List
(I sent this email before from a non-subscribed address...)
sorry to bother you guys with something I guess belongs in the JIRA, but
after convincing the powers that be to switch from proprietary software
to OpenLayers/Geoserver, I really have to get this thing to work fast 
Anywho, I just hooked up my geoserver 2.0 to a postgis database and used
an openlayers based client to display a wms overlayed with features from
a wfs. To test the whole thing I simply adjusted the OpenLayers 2.8
example at
http://dev.openlayers.org/releases/OpenLayers-2.8/examples/wfs-protocol-transactions.html
I then realized that the Delete operation was not working. A quick
analysis showed that unlike the Insert operation (which worked fine),
the DeleteElementType drops the "xmlns:feature="http://www.myuri.net"
attribute from the wfs:Delete node. Yet during Transaction.execute() the
available FeatureStores are mapped against the full typeName (e.g.
{www.myuri.net}myfeature). By doing this, the store is no longer found
inside DeleteElementHandler.execute(), where the map is searched using
only the "base" typeName as stored in the DeleteElementType object (in
this case simply "myfeature").
From what I can see geoserver acts according to OGC specs, but I am
guessing many people use a combination of OL/Geoserver, hence this
deviation from the specs by OL may have to be handled by Geoserver, what
do you think?
I have made a quick fix for my installation here, I just have to get it
over to the production environment. Possibly this is however a setup
issue? or already fixed in the repo (using release version here for the
customer).
cheers,
lorenz
Hi Lorenz,
The list to use for this question would be geoserver-users@anonymised.com
That said, it seems like it could be an OL issue but some more information would help:
* GeoServer version, Java version
* the GEoServer logs (turn up the logging level to VERBOSE) and then try the request
* the request OL is sending to GeoServer, easily available via Firebug
* any information about the postgis table, in particular does it have a primary key
With that hopefully we can isolate the problem.
-Justin
Lorenz Breu wrote:
Hi List
(I sent this email before from a non-subscribed address...)
sorry to bother you guys with something I guess belongs in the JIRA, but
after convincing the powers that be to switch from proprietary software
to OpenLayers/Geoserver, I really have to get this thing to work fast
Anywho, I just hooked up my geoserver 2.0 to a postgis database and used
an openlayers based client to display a wms overlayed with features from
a wfs. To test the whole thing I simply adjusted the OpenLayers 2.8
example at
http://dev.openlayers.org/releases/OpenLayers-2.8/examples/wfs-protocol-transactions.html
I then realized that the Delete operation was not working. A quick
analysis showed that unlike the Insert operation (which worked fine),
the DeleteElementType drops the "xmlns:feature="http://www.myuri.net"
attribute from the wfs:Delete node. Yet during Transaction.execute() the
available FeatureStores are mapped against the full typeName (e.g.
{www.myuri.net}myfeature). By doing this, the store is no longer found
inside DeleteElementHandler.execute(), where the map is searched using
only the "base" typeName as stored in the DeleteElementType object (in
this case simply "myfeature").
From what I can see geoserver acts according to OGC specs, but I am
guessing many people use a combination of OL/Geoserver, hence this
deviation from the specs by OL may have to be handled by Geoserver, what
do you think?
I have made a quick fix for my installation here, I just have to get it
over to the production environment. Possibly this is however a setup
issue? or already fixed in the repo (using release version here for the
customer).
cheers,
lorenz
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev _______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.