I notice that the cite configurations have been merged into a single one. The obvious benefit of this is that we can run all the cite suites without having to restart GeoServer. However I have found some downsides.
1. Its harder to debug a particular problem with a particular feature type when there are more around.
2. I fear wfs 1.0 cite configuration and wfs 1.1 configuration will step on each others toes, however I don't have anything concrete on this yet, i need to try running both the 1.0 suite and the 1.1 suite with a single configuration.
So I thought I would start up an informal vote on this. Please respond with a -1 if you are against the single directory, +1 if you are for it, or 0 if you dont really care.
Yeh it might be that it clears things up. With the new testing suite you can only run one at a time anyways (or so I have found so far) so there is no huge benefit to lumping all the configs into one.
whichever really, 0
Brent Owens
(The Open Planning Project)
Justin Deoliveira wrote:
Hi all,
I notice that the cite configurations have been merged into a single one. The obvious benefit of this is that we can run all the cite suites without having to restart GeoServer. However I have found some downsides.
1. Its harder to debug a particular problem with a particular feature type when there are more around.
2. I fear wfs 1.0 cite configuration and wfs 1.1 configuration will step on each others toes, however I don't have anything concrete on this yet, i need to try running both the 1.0 suite and the 1.1 suite with a single configuration.
So I thought I would start up an informal vote on this. Please respond with a -1 if you are against the single directory, +1 if you are for it, or 0 if you dont really care.
Hard call - it would be nice to fire up configuration of GeoServer for all cite tests (it will make the release process easier). So if we *can* pull this off then we should - really the only person using cite is developers making GeoServer releases correct? If we are forced to go into multiple configurations then we should do so by specification / version.
So based on lack of anything concrete -0 (ie do you best to maintain a single cite configuration).
Jody
1. Its harder to debug a particular problem with a particular feature type when there are more around.
2. I fear wfs 1.0 cite configuration and wfs 1.1 configuration will step on each others toes, however I don't have anything concrete on this yet, i need to try running both the 1.0 suite and the 1.1 suite with a single configuration.
So I thought I would start up an informal vote on this. Please respond with a -1 if you are against the single directory, +1 if you are for it, or 0 if you dont really care.
Cool, way to step up and make a decision Brent!! I also think seperate configs make sense from a modularity point of view. I would like us at some point be able to modularize GeoServer to the point where one can sa y "I want to run WFS, but not WMS, etc...". A single config for all the services would kind of go against that.
-Justin
Brent Owens wrote:
ok, since I make the majority of the releases, I'm going to make an executive decision and say 'separate configurations'. For the main reason being, when debugging through cite tests, you do it my module, wfs, wms... It will will be just too overloaded with the shear number of tests if all are run at once. Also, smaller configs means less chance of them conflicting.
And with the new cite tests I don't think you can run all at once, so there is no real point to have a config with everything. Especially since rebuilding is easy enough.
When it comes to testing I always check the configuration first to see how it runs just through the UI and sample requests (map preview etc), before running the tests. When all the config data sets are there (wms, wfs, wcs) it gets hard to track down each layer you are interested in, because there are like 50 of them. And often it takes a couple of runs before you get the tests set up right.
Brent Owens
(The Open Planning Project)
Jody Garnett wrote:
Hard call - it would be nice to fire up configuration of GeoServer for all cite tests (it will make the release process easier). So if we *can* pull this off then we should - really the only person using cite is developers making GeoServer releases correct? If we are forced to go into multiple configurations then we should do so by specification / version.
So based on lack of anything concrete -0 (ie do you best to maintain a single cite configuration).
Jody
1. Its harder to debug a particular problem with a particular feature type when there are more around.
2. I fear wfs 1.0 cite configuration and wfs 1.1 configuration will step on each others toes, however I don't have anything concrete on this yet, i need to try running both the 1.0 suite and the 1.1 suite with a single configuration.
So I thought I would start up an informal vote on this. Please respond with a -1 if you are against the single directory, +1 if you are for it, or 0 if you dont really care.
I will start if off with a -1 :).
-Justin
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
I will make the changes to the configs after the release gets announced monday. I will create:
citewms
citewcs
citewfs
Cool.
Justin, do the cite tests for wfs 1.1 contain different data? If so we can have citewfs1.0 and citewfs1.1
Yup they do. The naming works for me.
-Justin
Brent Owens
(The Open Planning Project)
Justin Deoliveira wrote:
Cool, way to step up and make a decision Brent!! I also think seperate configs make sense from a modularity point of view. I would like us at some point be able to modularize GeoServer to the point where one can sa y "I want to run WFS, but not WMS, etc...". A single config for all the services would kind of go against that.
-Justin
Brent Owens wrote:
ok, since I make the majority of the releases, I'm going to make an executive decision and say 'separate configurations'. For the main reason being, when debugging through cite tests, you do it my module, wfs, wms... It will will be just too overloaded with the shear number of tests if all are run at once. Also, smaller configs means less chance of them conflicting.
And with the new cite tests I don't think you can run all at once, so there is no real point to have a config with everything. Especially since rebuilding is easy enough.
When it comes to testing I always check the configuration first to see how it runs just through the UI and sample requests (map preview etc), before running the tests. When all the config data sets are there (wms, wfs, wcs) it gets hard to track down each layer you are interested in, because there are like 50 of them. And often it takes a couple of runs before you get the tests set up right.
Brent Owens
(The Open Planning Project)
Jody Garnett wrote:
Hard call - it would be nice to fire up configuration of GeoServer for all cite tests (it will make the release process easier). So if we *can* pull this off then we should - really the only person using cite is developers making GeoServer releases correct? If we are forced to go into multiple configurations then we should do so by specification / version.
So based on lack of anything concrete -0 (ie do you best to maintain a single cite configuration).
Jody
1. Its harder to debug a particular problem with a particular feature type when there are more around.
2. I fear wfs 1.0 cite configuration and wfs 1.1 configuration will step on each others toes, however I don't have anything concrete on this yet, i need to try running both the 1.0 suite and the 1.1 suite with a single configuration.
So I thought I would start up an informal vote on this. Please respond with a -1 if you are against the single directory, +1 if you are for it, or 0 if you dont really care.
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642