My first thought for saving type information was to add a
breif=true|false flag to XStreamPersister itself, and when set to false
simply disable BriefMapConverter, although this would work too.
And now that we support a brief syntax, simply disabling it might lead
to backwards compatability issue.
That said, i agree with Gabriel that restoring the type information and
creating the right type of object seems like a good idea which fixes
this problem.
Gabriel Roldan wrote:
> Btw, I may of share Justin's concern of bloating the file. Adding the
> "type" attribute to every entry on a java.util.Map marshaling may
> unwanted. Still, check the line:
> xs.registerLocalConverter(StoreInfoImpl.class, "connectionParameters",
> new BreifMapConverter() );
> We are using a special converter for datastore connection parameters, so
> the change can be limited to that, and using a BriefMapConverter that
> does value = Converters.convert like in the sample patch?
>
> Cheers,
> Gabriel
>
> Gabriel Roldan wrote:
>> The BreifMapConverter is a good thing (note the typo, Breif... instead
>> of Brief...), loosing type may not be.
>>
>> From my perspective, since config file schema is out of question, it
>> still would be good if BreifMapConverter can hold some type
>> information where available, and you both guys seem to have valid
>> arguments one way and the other, I think something like the following
>> may be of help:
>>
>> <patch>
>> ### Eclipse Workspace Patch 1.0
>> #P main
>> Index: src/main/java/org/geoserver/config/util/XStreamPersister.java
>> ===================================================================
>> --- src/main/java/org/geoserver/config/util/XStreamPersister.java
>> (revision 12631)
>> +++ src/main/java/org/geoserver/config/util/XStreamPersister.java
>> (working copy)
>> @@ -69,6 +69,7 @@
>> import org.geotools.referencing.crs.DefaultProjectedCRS;
>> import org.geotools.referencing.operation.DefaultMathTransformFactory;
>> import org.geotools.referencing.operation.matrix.GeneralMatrix;
>> +import org.geotools.util.Converters;
>> import org.geotools.util.NumberRange;
>> import org.geotools.util.logging.Logging;
>> import org.opengis.coverage.grid.GridGeometry;
>> @@ -481,6 +482,7 @@
>> writer.startNode("entry");
>> writer.addAttribute( "key", entry.getKey().toString());
>> if ( entry.getValue() != null ) {
>> + writer.addAttribute("type",
>> entry.getValue().getClass().getName());
>> writer.setValue(entry.getValue().toString());
>> }
>>
>> @@ -510,6 +512,14 @@
>> //this is case 3
>> key = reader.getAttribute( "key" );
>> value = reader.getValue();
>> + String type = reader.getAttribute("type");
>> + if(type != null){
>> + try{
>> + value = Converters.convert(value,
>> Class.forName(type));
>> + }catch(Exception e){
>> + //can't convert, leave it as is
>> + }
>> + }
>> }
>> else if ( reader.hasMoreChildren() ){
>> //this is case 4
>> </patch>
>>
>> That is, augment the <entry> node with a "type" attribute, then try to
>> use Converters to restore it to it's original type.
>>
>> The good news is that org.geotools.util.URConverterFactory will
>> already handle the whitespace trimming with no modification. Try this:
>>
>> URL url = new URL(" \n\t http://localhost:8080/geoserver \n\t ");
>> System.out.println( "'" + url.toExternalForm() + "'" );
>>
>> the output is: 'http://localhost:8080/geoserver'
>>
>>
>> This should be supported by the fact that DataAccess.Param has a
>> binding class, hence the UI _should_ (can't confirm it does right now)
>> set the datastore connection parameters to the proper Param.binding type.
>> I don't think there's any magic in doing this, but just being
>> consistent at both ends.
>>
>> My 2c.-
>>
>> Gabriel
>>
>> Ben Caradoc-Davies wrote:
>>> Justin Deoliveira wrote:
>>>> Ben Caradoc-Davies wrote:
>>>>> Would this be an opportunity to trim whitespace from strings in
>>>>> datastore.xml connectionParameters/entry elements?
>>>> Hmmm... I am still not sure I think this is such a great idea. I
>>>> still stand by" whatever you put into the config you should get out
>>>> exactly that". If for some reason a datastore relied on whitespace
>>>> they would be screwed.
>>>> That said I don't have an example of where this would be
>>>> problematic, so I don't have a strong case, just a gut feeling. Can
>>>> you job my memory as to why the entity creating the entries can't do
>>>> the trim? It is because it comes from formatted XML which looks like
>>>> this:
>>>> <a>
>>>> the value
>>>> </a>
>>> Yes, hand editing of datastore.xml in an XML-aware editor, while
>>> configuring an app-schema data store. I can fix it for app-schema,
>>> but any other datastore with a long path may be vulnerable.
>>>
>>> From the last time we discussed this:
>>>
>>> ******
>>>
>>> The end user is editing the XML and formats the file before saving,
>>> introducing whitespace.
>>>
>>> (Note: this will be a bit mangled by email:)
>>>
>>> This works:
>>>
>>> <dataStore>
>>> <id>gsml_MappedFeature_datastore</id>
>>> <name>gsml_MappedFeature</name>
>>> <enabled>true</enabled>
>>> <workspace>
>>> <id>gsml_workspace</id>
>>> </workspace>
>>> <connectionParameters>
>>> <entry key="namespace">urn:cgi:xmlns:CGI:GeoSciML:2.0
>>> </entry>
>>> <entry
>>> key="url">file:workspaces/gsml/gsml_MappedFeature/gsml_MappedFeature.xml</entry>
>>>
>>>
>>> <entry key="dbtype">app-schema</entry>
>>> </connectionParameters>
>>> </dataStore>
>>>
>>> This does not:
>>>
>>> <dataStore>
>>> <id>gsml_MappedFeature_datastore</id>
>>> <name>gsml_MappedFeature</name>
>>> <enabled>true</enabled>
>>> <workspace>
>>> <id>gsml_workspace</id>
>>> </workspace>
>>> <connectionParameters>
>>> <entry key="namespace">urn:cgi:xmlns:CGI:GeoSciML:2.0
>>> </entry>
>>> <entry key="url">
>>>
>>> file:workspaces/gsml/gsml_MappedFeature/gsml_MappedFeature.xml
>>> </entry>
>>> <entry key="dbtype">app-schema</entry>
>>> </connectionParameters>
>>> </dataStore>
>>>
>>>
>>> ******
>>>
>>>
>>
>>
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
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
