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>
> 
> 
> ******
> 
> 


-- 
Gabriel Roldan
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

Reply via email to