Those of you watch the commit logs will notice I committed my changes for GSIP 34 :). What this means is:
1) the new data directory is in effect. So the first time you start up geoserver with your current data directory it will be "morphed" as outlined by the proposal.
2) When you make changes via the UI (wicket ui) they are committed as soon as you click submit, no more apply save cycle.
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Justin Deoliveira wrote:
Those of you watch the commit logs will notice I committed my changes for GSIP 34 :). What this means is:
1) the new data directory is in effect. So the first time you start up geoserver with your current data directory it will be "morphed" as outlined by the proposal.
What is the minimal configuration required to serve a single WFS feature type from a single data store? app-schema is configured by manually editing these test files.
I wonder how your "morphing" handles relative paths? Examples:
(1) the app-schema DataAccess url, which is the relative path from the catalog.xml to the app-schema configuration/mapping file
<datastore namespace="gsml" enabled="true" id="MappedFeature">
<connectionParams>
<parameter value="app-schema" name="dbtype"/>
<parameter value="file:featureTypes/MappedFeatureUseCase2A/MappedFeatureUseCase2A.xml" name="url"/>
</connectionParams>
</datastore>
(2) the relative paths in said configuration file to the OASIS catalog and profile schemas.
<catalog>../../schemas/catalog.xml</catalog>
and
<targetTypes>
<FeatureType>
<schemaUri>../../profiles/MappedFeatureUseCase2A.xsd</schemaUri>
</FeatureType>
</targetTypes>
I expect these will break. :~-(
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
Justin Deoliveira wrote:
Those of you watch the commit logs will notice I committed my changes for GSIP 34 :). What this means is:
1) the new data directory is in effect. So the first time you start up geoserver with your current data directory it will be "morphed" as outlined by the proposal.
Does this happen when GeoServerAbstractTestSupport is invoked by JUnit? That is, has MockData been ported? I guess I can answer my own question by looking at HEAD:
In GeoServerAbstractTestSupport:
//HACK: once we port tests to the new data directory, remove this
GeoServerLoader.setLegacy( true );
I assume this suppresses the morphing, and that MockData has not yet been ported.
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
Ben Caradoc-Davies wrote:
Justin Deoliveira wrote:
Those of you watch the commit logs will notice I committed my changes for GSIP 34 :). What this means is:
1) the new data directory is in effect. So the first time you start up geoserver with your current data directory it will be "morphed" as outlined by the proposal.What is the minimal configuration required to serve a single WFS feature type from a single data store? app-schema is configured by manually editing these test files.
I wonder how your "morphing" handles relative paths? Examples:
(1) the app-schema DataAccess url, which is the relative path from the catalog.xml to the app-schema configuration/mapping file
<datastore namespace="gsml" enabled="true" id="MappedFeature">
<connectionParams>
<parameter value="app-schema" name="dbtype"/>
<parameter value="file:featureTypes/MappedFeatureUseCase2A/MappedFeatureUseCase2A.xml" name="url"/>
</connectionParams>
</datastore>
Any relative path that is a data store parameter should remain in tact. And the original files will left in place so if your code is reading these files in place directly then it will probably still work. That said I don't think we should rely on the old structure, it should be a clean switch.
(2) the relative paths in said configuration file to the OASIS catalog and profile schemas.
<catalog>../../schemas/catalog.xml</catalog>
and
<targetTypes>
<FeatureType>
<schemaUri>../../profiles/MappedFeatureUseCase2A.xsd</schemaUri>
</FeatureType>
</targetTypes>I expect these will break. :~-(
I can't really comment since I really have no idea how the files are setup. Do you have some docs somewhere?
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Yup, I have yet to port the mock tests to the new configuration. Although 99% of the tests work transparently with the new data directory. The only tests that have issues are ones that change the data directory in place and reload the catalog in the test case. This requires a bit of hacking on the base classes. There is a jira already open for this one:
http://jira.codehaus.org/browse/GEOS-2729
-Justin
Ben Caradoc-Davies wrote:
Justin Deoliveira wrote:
Those of you watch the commit logs will notice I committed my changes for GSIP 34 :). What this means is:
1) the new data directory is in effect. So the first time you start up geoserver with your current data directory it will be "morphed" as outlined by the proposal.Does this happen when GeoServerAbstractTestSupport is invoked by JUnit? That is, has MockData been ported? I guess I can answer my own question by looking at HEAD:
In GeoServerAbstractTestSupport:
//HACK: once we port tests to the new data directory, remove this
GeoServerLoader.setLegacy( true );I assume this suppresses the morphing, and that MockData has not yet been ported.
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.