Re: [Geoserver-devel] Proposal: svn externals in new svn 1.5 format in the GeoServer repo?
Justin Deoliveira wrote: > Ben Caradoc-Davies wrote: >> I want to add a relative svn external in the new format introduced in >> svn 1.5, which permits relative paths. This is a great improvement for >> maintenance because it removes host names and makes internal externals >> (I am turning into Rumsfeld) robust against branching. >> This *will* cause those using an old (pre 1.5) svn client to be forced >> to upgrade. In another project, these externals did cause minor user >> confusion. >> So, please vote (or just tell me if it is allowed): >> svn externals in svn 1.5 format in the GeoServer repo? Yes or no? > Does our current version of subversion at codehaus support this? As far as I know, all interpretation of svn:externals occurs on the client side. You can even turn them off with --ignore-externals if you like. What svn version is used by Hudson? -- Ben Caradoc-Davies Software Engineer, CSIRO Exploration and Mining Australian Resources Research Centre 26 Dick Perry Ave, Kensington WA 6151, Australia -- 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
Re: [Geoserver-devel] whitespace in datastore.xml
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: > >the value > 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: gsml_MappedFeature_datastore gsml_MappedFeature true gsml_workspace urn:cgi:xmlns:CGI:GeoSciML:2.0 file:workspaces/gsml/gsml_MappedFeature/gsml_MappedFeature.xml app-schema This does not: gsml_MappedFeature_datastore gsml_MappedFeature true gsml_workspace urn:cgi:xmlns:CGI:GeoSciML:2.0 file:workspaces/gsml/gsml_MappedFeature/gsml_MappedFeature.xml app-schema ** -- Ben Caradoc-Davies Software Engineer, CSIRO Exploration and Mining Australian Resources Research Centre 26 Dick Perry Ave, Kensington WA 6151, Australia -- 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
Re: [Geoserver-devel] whitespace in datastore.xml
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:
### 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
That is, augment the 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:
>>
>>the value
>>
>
> 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:
>
>
> gsml_MappedFeature_datastore
> gsml_MappedFeature
> true
>
> gsml_workspace
>
>
> urn:cgi:xmlns:CGI:GeoSciML:2.0
>
>key="url">file:workspaces/gsml/gsml_MappedFeature/gsml_MappedFeature.xml
> app-schema
>
>
>
> This does not:
>
>
> gsml_MappedFeature_datastore
> gsml_MappedFeature
> true
>
> gsml_workspace
>
>
> urn:cgi:xmlns:CGI:GeoSciML:2.0
>
>
>
> file:workspaces/gsml/gsml_MappedFeature/gsml_MappedFeature.xml
>
> app-schema
>
>
>
>
> **
>
>
--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Re: [Geoserver-devel] whitespace in datastore.xml
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:
>
>
> ### 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
>
>
> That is, augment the 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:
>>>
>>>the value
>>>
>> 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:
>>
>>
>> gsml_MappedFeature_datastore
>> gsml_MappedFeature
>> true
>>
>> gsml_workspace
>>
>>
>> urn:cgi:xmlns:CGI
Re: [Geoserver-devel] Proposal: svn externals in new svn 1.5 format in the GeoServer repo?
Ben Caradoc-Davies ha scritto: > Justin Deoliveira wrote: >> Ben Caradoc-Davies wrote: >>> I want to add a relative svn external in the new format introduced in >>> svn 1.5, which permits relative paths. This is a great improvement for >>> maintenance because it removes host names and makes internal externals >>> (I am turning into Rumsfeld) robust against branching. >>> This *will* cause those using an old (pre 1.5) svn client to be forced >>> to upgrade. In another project, these externals did cause minor user >>> confusion. >>> So, please vote (or just tell me if it is allowed): >>> svn externals in svn 1.5 format in the GeoServer repo? Yes or no? >> Does our current version of subversion at codehaus support this? > > As far as I know, all interpretation of svn:externals occurs on the > client side. You can even turn them off with --ignore-externals if you like. > > What svn version is used by Hudson? It would seem 1.5.1, if Hudson is using the same svn as the rest of the system: [aa...@gridlock ~]$ svn --version svn, version 1.5.1 (r32289) compiled Jul 31 2008, 00:26:12 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
