[Geoserver-devel] Re: [jira] Created: (GEOS-152) Start error after altering the configuration applied by web interface (and more)

Description:
Hello!
1.) (Important)
I placed the geoserver.war into the \webapp directory of Tomcat. The

installation first works fine and I can alter the configuration with
the webinterface.

I can't exactly reproduce the error:

# I can restart TOMCAT several time and the web interface works. But it
seems to stop working if I altered the configuration of the WFS
#(adding new namespace, change log-level, ...) and start TOMCAT again.
Then the web interface won't start the following error on the #console:

#> ERROR compiling http://127.0.0.1:9080/geoserver/welcome.do

ERROR compiling http://127.0.0.1:9080/geoserver/admin/index.do
ERROR compiling http://127.0.0.1:9080/geoserver/config/index.do
ERROR compiling http://127.0.0.1:9080/geoserver/contactInformation.do
ERROR compiling http://127.0.0.1:9080/geoserver/config/wfs/index.do
ERROR compiling

http://127.0.0.1:9080/geoserver/config/wfs/description.do

ERROR compiling http://127.0.0.1:9080/geoserver/config/wfs/content.do
ERROR compiling http://127.0.0.1:9080/geoserver/config/wms/index.do
ERROR compiling

http://127.0.0.1:9080/geoserver/config/wms/description.do

ERROR compiling http://127.0.0.1:9080/geoserver/config/wms/content.do
ERROR compiling http://127.0.0.1:9080/geoserver/config/data/index.do
ERROR compiling http://127.0.0.1:9080/geoserver/config/data/store.do
ERROR compiling

http://127.0.0.1:9080/geoserver/config/data/namespace.do

ERROR compiling http://127.0.0.1:9080/geoserver/config/data/style.do
ERROR compiling

http://127.0.0.1:9080/geoserver/config/validation/index.do
#> ERROR compiling
http://127.0.0.1:9080/geoserver/config/validation/test.do
#>
#> Removing the created files in the \work directory of TOMCAT doesn't
work. I have to completely remove the created \geoserver
#> directory and let TOMCAT reinstall the application.
Hrm, I tried for awhile to reproduce this to no avail. I think the easy
work around for you is to only access the web interface through
http://127.0.0.1:9080/geoserver/welcome.do . I suspect that may fix
your problems, as it looks like this is because of our JSPCompiler,
which just does not have much tomcat love (the other thing you can do
is switch servlet containers, to Resin or Jetty, they both work fine).
Hopefully we'll figure out a better solution for the JSPCompilation,
maybe tomcat should just not try it - it's just our attempt to do the
loading up front instead of having a really slow web app when you first
start it up.

2.) (Not important)
The URLs provided at the web interface for testing the GetCapabilities

doesn't work, the returned document contains the following error
description:

<?xml version="1.0" ?>
<ServiceExceptionReport
   version="1.2.0"
   xmlns="http://www.opengis.net/ogc&quot;
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;
   xsi:schemaLocation="http://www.opengis.net/ogc

wfs/1.0.0/OGC-exception.xsd">

   <ServiceException>
      No wfs kvp request recognized. The REQUEST parameter must be

one of GetFeature, GetFeatureWIthLock, DescribeFeatureType,
LockFeature, or Transaction. </ServiceException>

</ServiceExceptionReport>

Hrm. What is the url that it's sending you to? I feel like I would
have tested for 1.2-beta, but I don't have that war file on my computer
right now, and it works on my versions...

3.) (Important)
I tried to add new feature types. I imported some data (Osnabrueck

shapefiles from [deegree] project) into PostGIS (that worked with the
[deegree] WFS).

The SRS of the data is: EPSG:31467
The LatLonBoundingBox of the data is:
minx="7.93" miny="52.22" maxx="8.19" maxy="52.34"

I tried to enter the Box values via the web interface but when I saved

the configuration the values completely messed up. Actually I can't

recognize a schema what's going on :wink: Some values seems not to be

accepted?! Maybe it is my error, if the coordinates are out of range
for >the specified SRS but yet I had no problem using it with the
[deegree] WFS.
No, it should work, we've already got a bug report for it, so it should
be fixed for the next release, hopefully. Yeah, I should make a schema
for our config files...

4.) (Not important)
Is it necessary that one is "forced" to specify a namespace for a

database? Or is it possible to turn the use of namespaces off - so the

feature type names will be listed in the capabilities document without

namespace?

I've run into problems when I configured the [deegree] WMS to access

the [geoserver] WFS...because my data before had no

namespaces. I added it to the WMS configuration but currently it does

not work :frowning:
You mean without the namespace prefix? You'd like something like:
<FeatureType>
<Name>hong_kong</Name>
<Title>test postgis</Title>
   ....
</FeatureType>
instead of

<FeatureType>
<Name>topp:hong_kong</Name>
<Title>test postgis</Title>
    ...
</FeatureType> ?

I could probably get something in their for you, I think it'd be great
if the deegree WMS could access the geoserver WFS. The downside to the
shiny new web config tool is that it makes adding new user options
quite a bitch, you have to modify like at least 10 files for one little
option to be added. Right before 1.2.0-rc1 I don't think I can get it
in for you, but what about an extra parameter in the GetCapabilities
request? I haven't looked into it, it might be more of a bitch than
I'm imagining right now. But you could do
http.../geoserver/wfs?request=GetCapabilities?PREFIXING=FALSE
and in the post request
<GetCapabilities prefixing="false" version="1.0.0" service="WFS">

And then all featureTypes in the default namespace (if you only set one
namespace it becomes the default, or else you specify it with the
default="true" attribute) would not have prefixes in the caps document.

It's already in the code for the next release that you can call
GetFeatures without using the prefix if it is in the default namespace:
http:…/geoserver/wfs?request=GETFEATURE&typename=hong_kong (was
supposed to be in the beta but there was a bug).

So if that's sufficient let me know and I can try to squeeze it in to
the next release.

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