[Geoserver-devel] Re: GOES-509

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.

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

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.

What I mean is not using ServletConext.getRealPath("/") + "schemas/sld"... and just the "schemas/sld...". Will the xml parser still be able to resolve the path? Not sure, just a guess.

-Justin

Brent Owens wrote:

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 SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

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/

Hey Brent, I'm doing some doc stuff now, and I was wondering about the
resolution of: http://jira.codehaus.org/browse/GEOS-464 ? I'm finding
a few links to GEOTOOLS/GEOT, did you check for geotools links as well?

I ask not because it's all that important (though should be all double
checked for final release), but more because for
http://jira.codehaus.org/browse/GEOS-512 my plan is to just move all
the big non-picture attachements over to GEOS:
http://docs.codehaus.org/display/GEOS/Attachments So that from the docs
they are just links to download. But I'm wondering if I should turn
the links to the full url's, instead of the GEOS links?

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

ServletContext#getResource() seems to do the trick. Brent I committed the fix, can you run a few quick tests to cover windows. Thanks.

Brent Owens wrote:

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.

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Ah cool, I just did the same.
I first tried request.getRequestURL but it just hung the process (I think I know why), but the context.getResource() did it. There are a couple places in that class that use File still, so I will merge my change in with yours, that should cover it all. I tested it on windows and it is all better.

Brent Owens
(The Open Planning Project)

Justin Deoliveira wrote:

ServletContext#getResource() seems to do the trick. Brent I committed the fix, can you run a few quick tests to cover windows. Thanks.

Brent Owens wrote:

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.

Sweet, I think that is the last scheduled bug. Minus a few documentation tasks we are pretty much ready to release!!

Brent Owens wrote:

Ah cool, I just did the same.
I first tried request.getRequestURL but it just hung the process (I think I know why), but the context.getResource() did it. There are a couple places in that class that use File still, so I will merge my change in with yours, that should cover it all. I tested it on windows and it is all better.

Brent Owens
(The Open Planning Project)

Justin Deoliveira wrote:

ServletContext#getResource() seems to do the trick. Brent I committed the fix, can you run a few quick tests to cover windows. Thanks.

Brent Owens wrote:

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 SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org