openlayers 2 - String update - only first character gets stored

Client: OpenLayers / Server: Geoserver

When I update a WFS Element,

JAVASCRIPT:

element.feature.attributes.ENAME = "Mystring";
saveStrategy.save();

HTTP-POST:

 
  ENAME
  MyString

some features of Type String do not get fully updated, only the first letter ends up in the WFS layer.

    ...

   
       M
   

//only M ends up on the server, not Mystring as expected

the respective line in the logfile (catalina.out) says:

        name = ENAME
        value = Mystringproperty[0]:

strangely, the attached property[0] is on all attributes, not only on the one which is reduced to its first letter, but also on some strings that do not get shortened as well as some integers.

I would expect the type of the respective feature to be something like String[1], but as far as I can see the Type System, there are no length attributes to Strings.

Who knows what I can do?

---

UPDATE

---

When I change the value of any feature's attribute (ENAME) with OpenJump and upload the changed data, my application shows the feature correctly, which means, the geoserver itself CAN store a string longer than 1 in the respective attribute.

However, everytime I make an update via OpenLayers, regardless on which feature, any other feature's ENAME attribute gets shortened (like from 'MyString' to 'M'), even if it was a totally different feature that was updated on OpenLayers.

The log (catalina.out) says NOTHING about this perfidious update operation.

---

UPDATE

---

Content of the Firebug Post TAB, Content of the respective Log Section:

the_geom 363261.475316,5770742.697063 363260.253031,5770742.452777 363260.011425,5770743.66165201 363261.233711,5770743.90593801 363261.475316,5770742.697063 LAYER Grab GRABNAME Huber NUTZENDE 2023-07-14

2015-01-20 17:01:00,671 INFO [geoserver.wfs] - Request: transaction service = WFS version = 1.1.0 baseUrl = http://myserver.de:80/geoserver/ group[0] = wfs:update=net.opengis.wfs.impl.UpdateElementTypeImpl@53a7e8d6 (filter: [ Graeber.203 ], handle: null, inputFormat: , srsName: null, typeName: {myserver.de/ah_neu}Graeber) update[0]: property[0]: name = the_geom value = MULTIPOLYGON (((363248.39039900305 5770772.417071999, 363249.21531199943 5770770.058744, 363248.0047730003 5770769.655668, 363248.0010000006 5770769.667, 363247.17900000024 5770772.016999999, 363248.39039900305 5770772.417071999)))property[0]: name = LAYER value = Grabproperty[0]: name = GRABNAME value = Huberproperty[0]: name = NUTZENDE value = 2023-07-14 filter = [ Graeber.203 ] inputFormat = x-application/gml:3 typeName = {myserver.de/ah_neu}Graeber releaseAction = ALL

---

STILL not solved

WFS Layer:

---

Javascript definition:

layer_selectable = new OpenLayers.Layer.Vector("WFS", { strategies : [new OpenLayers.Strategy.BBOX(), saveStrategy], styleMap: new OpenLayers.StyleMap({ 'default': style, 'select': style_selected }), protocol : new OpenLayers.Protocol.WFS({ url : geoserver + config.wfs_layer, version : "1.1.0", featureType : "Graeber", featureNS : config.featureNS, srsName : epsg, }), renderers : renderer //tileOptions: {crossOriginKeyword: 'anonymous'} });

Answer

You could edit your WFS-T Service directly with QGIS for example to see if it's an error of your javascript-application or of geoserver itself.

http://docs.qgis.org/2.2/en/docs/user_manual/working_with_ogc/ogc_client_support.html section "WFS and WFS-T Client" ( or in german: "QGIS als OGC Datenclient")

In QGIS you could also check which limit is set for the character-length of the column that gets cut off (in Layer-Properties):

Have you considered importing the shapefile to postgis and then publish the layer directly from an postgis-store?

If you like to you can post the javascript-code on http://jsfiddle.net/ or http://www.codeshare.io/

The Content of the Firebug Post TAB and Content of the respective Log Section you posted shows different versions(1.0.0 vs. 1.1.1):

and logfile:
2015-01-20 17:01:00,671 INFO [geoserver.wfs] - 
Request: transaction
    service = WFS
    version = 1.1.0

but I guess these were two different tries, weren't it?