This may be kind of a backwards way to do it, like there should be a
real way to solve the problem, but what about using the file at the url
instead of in the file tree. Ie the schemas stuff is always going to
be public, and instead of calling getDataDir you can call
Requests.getBaseUrl() (would probably have to change the method
signature of validateSLD to use the servlet request instead of the
context), and then add on schemas/sld. I think you'll have to change
the xerces validation method - to get it to recognize the 'remote'
file, instead of one on the path. Looking at the code it actually
looks like the xerces stuff uses a Url anyways to set the schema
location, and digging into it, it looks like we go from Url -> String,
and tack that on, which is probably why it fails. So the http://
location that results from Requests.getBaseUrl() should likely do a lot
better. The other option would be to fix up the proper escaping when
we go File -> String.
Regardless, it shouldn't be _that_ difficult to solve this, like it's
not a unique problem that no one has ever solved. Either switch things
to use the external url of http://…geoserver/schemas/sld/…, or else
get the interal file one escaping properly - the way it currently
passes a string straight in seems a bit flawed.
Chris
Quoting Brent Owens <brentowens@anonymised.com>:
It doesn't fail if the relative path doesn't have a space in it. So
if
the path is "C:/temp/geoserver" the relative path of "schemas/sld"
works
fine.
It does seem that this should have been encountered before. Maybe no
one
installs into "Program files" =)
I know there was this problem with shapefile paths, but we just put
in
the GUI a note saying the path can't have spaces.
Brent Owens
(The Open Planning Project)
Justin Deoliveira wrote:
> Hmm, someone must have run up against this one before. Does it also
> fail if a relative path is used?
>
> Brent Owens wrote:
>
>> Hey guys,
>> Took a while to figure out the real problem.
>> This bug turns out to be a problem with spaces in the URL of the
>> files needed to validate the XML. (ie. "Program files")
>> Any helpful ideas on how to go about fixing it? The issue is in
>> SLDValidator.java
>> Note that putting an absolute, hacked in, path resolves the
problem;
>> but then several other problems appear:
>> ...
>> src-resolve: Cannot resolve the name 'xlink:simpleLink' to a(n)
>> 'attribute group' component.
>> s4s-elt-invalid-content.1: The content of
'#AnonType_OnlineResource'
>> is invalid. Element 'attributeGroup' is invalid, misplaced, or
>> occurs too often.
>> src-resolve: Cannot resolve the name 'ogc:Filter' to a(n) 'element
>> declaration' component.
>>
>
>
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/