Gabriel Roldan ha scritto:
> Andrea Aime wrote:
>> Justin Deoliveira ha scritto:
>>> Hi all,
>>>
>>> A few issues have popped up recently related to how maps (in
>>> particular the metadata map for catalog objects) is
>>> persisted/depersisted. The latest issue revolves around someone
>>> trying ot configure a feature type via rest.
>>>
>>> The issue is that in an attempt to make xstream less verbose, i made
>>> it so that someone trying to upload map data with rest can do this:
>>>
>>> <map>
>>> <key1>value1</key1>
>>> <key2>value2</key2>
>>> ...
>>> </map>
>>>
>>> As opposed to the xstream default:
>>>
>>> <map>
>>> <entry>
>>> <string>key1</string>
>>> <string>value1</string>
>>> </entry>
>>> <entry>
>>> <string>key2</string>
>>> <string>value2</string>
>>> </entry>
>>> </map>
>>>
>>> However this has caused some issues. The main issue is that type
>>> information is lost. This pops up in a couple of places:
>>>
>>> * when a feature is persisted in geoserver, and then read back in
>>> again it is always read back in as a string.
>>>
>>> * when a feature type is uploaded via rest, the values in the
>>> metadata map are of type string.
>>>
>>> The end result is the same, ClassClassException for code that assumes
>>> type information about the metadata map.
>>>
>>> The quick solution for now has been to replace this:
>>>
>>> (Integer) featureType.getMetadata().get( "foo" );
>>>
>>> with:
>>>
>>> Converters.convert( featureType.getMetadata().get( "foo" ),
>>> Integer.class );
>>>
>>> The longer term solution is to amend the xstream persistence a bit so
>>> that type information is not lost. This is however a bit tricky
>>> though. And probably won't fix every REST case.
>>>
>>> So I am wondering. What do people think about making it practice that
>>> whenever accessing data from a metadata map, that a converter be used.
>>
>> I would be ok using the converters everywhere. But we should make it
>> pretty explicit that the user map is made of strings,
>> Map<String,String>. This way the need of using some kind of conversion
>> is obvious (teaching people that they can use Converters instead of
>> Integer.parseInt(xxx) is another story).
>
> It looks to me like MetadataMap claims to be an class itself rather than
> a java.uti.Map
> MetadataMap{
> private Map internalMap;
> ...
> boolean contains(Serializable key);
> <T extends Serializable> get(Serialiable key, Class<T>);
> ///same for put
> }
>
> then isolate the use of converters inside it.
Hum.... uh?
I looked in CatalogInfo and found:
Map<String,Serializable> getMetadata();
in ServiceInfo:
Map<String,Serializable> getMetadata();
Or else... you mean we should create the MetadataMap
class and replace those Map<String,Serializable>
references? Sounds like a good idea to me.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
