[Geoserver-devel] [jira] Created: (GEOS-4290) outputFormat text/xml; subtype=gml/3.2 don't eppear in section describefeaturetype in getcapabilities response in GeoServer 2.1-beta3
outputFormat text/xml; subtype=gml/3.2 don't eppear in section describefeaturetype in getcapabilities response in GeoServer 2.1-beta3 --- Key: GEOS-4290 URL: http://jira.codehaus.org/browse/GEOS-4290 Project: GeoServer Issue Type: Bug Components: WFS Affects Versions: 2.1-beta3 Reporter: Bart#322;omiej Burkot Assignee: Andrea Aime In getcapabilities's response ?SERVICE=WFSREQUEST=GetCapabilitiesVERSION=1.1.0 there is the outputFormat GML 3.2.1 in Getfeature section but for DescribeFeatureType it is only gml 3.1.1 support. OutputFormat GML32 isn't present for DescribeFeatureType? Under I add a piece of getcapabilities response When I issu describefeaturetype with parameter outputFormat GML 3.2.1: ?service=wfsversion=1.1.0request=DescribeFeatureTypeoutputFormat=text/xml; subtype=gml/3.2typename=tbd:onetypename i get on top of xml response xsd:import namespace=http://www.opengis.net/wfs/2.0: xsd:schema elementFormDefault=qualified targetNamespace=http://www.probka.gugik.gov.pl/TBD; xsd:import namespace=http://www.opengis.net/wfs/2.0; schemaLocation=http://192.168.1.102:8085/geoserver/schemas/gml/3.2.1/gml.xsd/ This seems to point to WFS 2.0 insteed of 1.1.0 as in request parameter ?service=wfsversion=1.1.0 Response with outputFormat=text/xml; subtype=gml/3.1.1 from: ?service=wfsversion=1.1.0request=DescribeFeatureTypeoutputFormat=text/xml; subtype=gml/3.1.1typename=tbd:onetypename is correct. A piece of getcapabilities document: ows:Operation name=DescribeFeatureType #8722; ows:DCP #8722; ows:HTTP ows:Get xlink:href=http://localhost:8080/geoserver/wfs/ ows:Post xlink:href=http://localhost:8080/geoserver/wfs/ /ows:HTTP /ows:DCP #8722; ows:Parameter name=outputFormat ows:Valuetext/xml; subtype=gml/3.1.1/ows:Value /ows:Parameter /ows:Operation #8722; ows:Operation name=GetFeature #8722; ows:DCP #8722; ows:HTTP ows:Get xlink:href=http://localhost:8080/geoserver/wfs/ ows:Post xlink:href=http://localhost:8080/geoserver/wfs/ /ows:HTTP /ows:DCP #8722; ows:Parameter name=resultType ows:Valueresults/ows:Value ows:Valuehits/ows:Value /ows:Parameter #8722; ows:Parameter name=outputFormat ows:Valuetext/xml; subtype=gml/3.1.1/ows:Value ows:ValueGML2/ows:Value ows:ValueGML2-GZIP/ows:Value ows:ValueSHAPE-ZIP/ows:Value ows:Valuecsv/ows:Value ows:Valuegml3/ows:Value ows:Valuegml32/ows:Value ows:Valuejson/ows:Value ows:Valuetext/xml; subtype=gml/2.1.2/ows:Value ows:Valuetext/xml; subtype=gml/3.2/ows:Value /ows:Parameter -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] timing for RC1
Ah, sorry, reading back over the other responses I realize I got confused. Since Simone and I were talking about it more than a week ahead of time I parsed 'one week delay' as something like one week from when you got back, and that friday was the day. My 'a couple days extra' meant in to next week, not the following week. Reading back it looks like my error. Next time though let's say explicit dates that we're talking about, since it can be hard to unpack when things are relative. ... And Gabriel's proposed patch is pretty damn sweet. So I guess I'll even back down from my desire to make a beta that's a feature freeze. People doing cool stuff every single week makes it hard to do releases :P Ok, sorry for all the noise, let's just go with the plan I didn't realize I agreed to of RC1 next week, by the 14th at the absolute latest. I will try to read email more closely in the future and not cause so much confusion. As for beta4, I guess there's no real compelling reason to do it, especially since it looks like GSIP-57 isn't in yet. I guess the one reason to do a beta is if we want more testing for gsip 57 and gwc/wms integration, but it seems like if we get things in now then the nightlies should get some testing. And +1 on branching for RC1 and continuing work on trunk, freezing all features at rc1. C On Fri, Jan 7, 2011 at 2:35 AM, Andrea Aime andrea.a...@geo-solutions.itwrote: On Fri, Jan 7, 2011 at 8:33 AM, Andrea Aime andrea.a...@geo-solutions.it wrote: 1. Call tomorrows release another beta, and actually give a bit of a cool down period before the official RC1 comes out that is restricted to bug fixes and more modest features and improvements. Btw, did not read the other responses. This one works for me as well, I'm just surprised by the change of mind after discussing the delay just a few days ago. Cheers Andrea - Ing. Andrea Aime Senior Software Engineer GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584962313 fax: +39 0584962313 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf - -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] GSIP 57 patch ready for review
On Fri, Jan 7, 2011 at 1:35 AM, Justin Deoliveira jdeol...@opengeo.org wrote: GIven the description of the changes here and a scan through the patch +1. But given my familiarity with the security subsystem I have to admit it is not really an in depth review :) Added tests for WMS cascading as well and committed. Let me know if it causes any trouble Cheers Andrea - Ing. Andrea Aime Senior Software Engineer GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584962313 fax: +39 0584962313 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf - -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] [jira] Created: (GEOS-4291) enable logging about gzip compression
enable logging about gzip compression - Key: GEOS-4291 URL: http://jira.codehaus.org/browse/GEOS-4291 Project: GeoServer Issue Type: Improvement Components: Global Affects Versions: 2.1-beta3, 2.0.2 Reporter: David Winslow Assignee: Andrea Aime Priority: Minor Attachments: enable-gzip-logging.diff The logging in the GZIP compression filter is disabled by commenting out in the code rather than using the logging level system. This patch would change that, logging whether GZIP compression is applied at the DEBUG level. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] timing for RC1
Ah ok, sorry I did not catch it. I had a lot of email to catch up on after 2 weeks of holidays and this one must have slipped through the cracks. On Fri, Jan 7, 2011 at 12:33 AM, Andrea Aime andrea.a...@geo-solutions.itwrote: On Fri, Jan 7, 2011 at 1:51 AM, Justin Deoliveira jdeol...@opengeo.org wrote: Hi all, As was discussed last week the plan is to start the RC1 release tomorrow. After thinking about the timing I have some reservations about calling tomorrows release an RC with regard to some fo the major changes that have taken place over the last few days and will happen tomorrow. Most notably the gwc/wms and the coming security changes. I am a little hesitant about starting a release directly after these changes land, and calling that release an RC. I had the same concern that's why I asked for a one week delay of the RC release. I guess that was lost in the discussion? However Chris said it was ok to delay a few days. Anyways perhaps I am putting too much though into what RC means but I just though I would voice the concern in case others feel the same, and present some possible alternatives that have crossed my mind. 1. Call tomorrows release another beta, and actually give a bit of a cool down period before the official RC1 comes out that is restricted to bug fixes and more modest features and improvements. 2. Wait a week before releasing RC1 to at least give some time for more testing from devs. +1 on this one, it's what me and Simone already proposed 3. Tell me to shut up for being a wimp and just release RC1 tomorrow. And if problems to pop up we just fix them and put out another RC quickly. Since hey it is not like we are going to run out of numbers. 4. Other thoughts and alternatives welcome. This does however beg the larger question about how we want to approach 2.1.0. Do we just continue full steam ahead and eventually choose a time to release 2.1.0? Or do we want some sort of ramp down period where we stick to more conservative development as we get closer to 2.1.0? I guess once RC1 is out only bug fixes are in. I'd suggest to branch off 2.1.x as we cut the RC and let trunk go full steam, we can backport whatever changes after 2.1.0 is out with review and whatnot. Cheers Andrea - Ing. Andrea Aime Senior Software Engineer GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584962313 fax: +39 0584962313 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf - -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] timing for RC1
Great, so RC1 next week it is with no release this week. This actually works a little nicer as it gives us a week to organize the corresponding geotools release as well. On Fri, Jan 7, 2011 at 1:26 AM, Gabriel Roldán grol...@opengeo.org wrote: On Fri, 2011-01-07 at 08:35 +0100, Andrea Aime wrote: On Fri, Jan 7, 2011 at 8:33 AM, Andrea Aime andrea.a...@geo-solutions.it wrote: 1. Call tomorrows release another beta, and actually give a bit of a cool down period before the official RC1 comes out that is restricted to bug fixes and more modest features and improvements. Btw, did not read the other responses. This one works for me as well, I'm just surprised by the change of mind after discussing the delay just a few days ago. Looks like I missed that discussion, as I usually do when overwhelmed, sorry. Any case, I've my own selfish reasons not to call tomorrow's release an RC. Actually I'm more towards option #2, waiting a week to release, as I want to include the following new feature (which complements gwc/wms integration, and for which I'm obviously working overtime, given the time I'm writing this at) and wouldn't feel comfortable doing so for an RC. See attached screenshot. With this and Justin's concerns in mind, which I share, I think if there's a release tomorrow it should be another beta. And it bothers me cause though I didn't sleep today at all, I won't make it for tomorrow cause I have 500km ride in less than two hours... If we waited till next week, we wouldn't be doubling efforts in release processes and I could get diskquota in. At the same time I don't want to stop others if tomorrow's release is needed, so I'll abstain from a vote with a preference to wait, or a plea to let me get this functionality after the fact and before we call 2.1.x for a feature freeze. Cheers, Gabriel Cheers Andrea - Ing. Andrea Aime Senior Software Engineer GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584962313 fax: +39 0584962313 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf - -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel -- Gabriel Roldan grol...@opengeo.org Expert service straight from the developers -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] the road to 2.1.0
Hi all, I just thought I would sum up the current plan moving toward 2.1.0 so that everyone is on the same page. So it was decided that there will be no release today, and instead we will release RC1 next week. Giving a week for trunk to cool down in light of some recent changes. After RC1 is released we move into stable mode in which we stick to only bug fixes and modest features/improvements. To compliment this change in in development, and to keep trunk open for new major developments, we will create the 2.1.x branch at the same time RC1 is cut. 2.1.x becomes the new stable branch and we continue moving toward 2.1.0 on it releasing a few more release candidates. How many I guess will depend on what bugs pop up. How does that sound. Did I miss anything? -Justin -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] the road to 2.1.0
On Fri, Jan 7, 2011 at 6:03 PM, Justin Deoliveira jdeol...@opengeo.org wrote: Hi all, I just thought I would sum up the current plan moving toward 2.1.0 so that everyone is on the same page. So it was decided that there will be no release today, and instead we will release RC1 next week. Giving a week for trunk to cool down in light of some recent changes. After RC1 is released we move into stable mode in which we stick to only bug fixes and modest features/improvements. To compliment this change in in development, and to keep trunk open for new major developments, we will create the 2.1.x branch at the same time RC1 is cut. 2.1.x becomes the new stable branch and we continue moving toward 2.1.0 on it releasing a few more release candidates. How many I guess will depend on what bugs pop up. How does that sound. Sounds good to me. Did I miss anything? The parallel GT2 release you were talking about in the other mail I guess :-p Cheers Andrea -- Ing. Andrea Aime Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584962313 fax: +39 0584962313 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf - -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] [jira] Created: (GEOS-4292) Add ability to upload files into store of different type
Add ability to upload files into store of different type Key: GEOS-4292 URL: http://jira.codehaus.org/browse/GEOS-4292 Project: GeoServer Issue Type: Improvement Components: REST Reporter: Justin Deoliveira Assignee: Justin Deoliveira Attachments: GEOS-4292.patch Simple example, upload shapefile into an existing postgis datastore. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] Some restconfig proposals
Hi all, With the pushing back of RC1 by a week I could not help myself to whip up two pending proposals having to do with restconfig. http://geoserver.org/display/GEOS/GSIP+59+-+Promote+RESTConfig+to+Core+Module http://geoserver.org/display/GEOS/GSIP+58+-+RESTConfig+API+Improvements The first I don't imagine will require too much discussion and actually has already been more or less agreed upon by devs. It is the promoting of RESTConfig to core module. It is pretty low risk so I don't forsee much resistance to getting it into RC1. GSIP 58 though probably requires more discussion. Although it was discussed in this previous email thread: http://old.nabble.com/some-restconfig-improvements-td30202559.html The outcome of that proposal was two fold: 1. It would be good to somehow share code or merge this with the wps import functionality. 2. Some concerns about this functionality continuing down the rest good practice violation path Both good concerns. For (1) I would like to push off as a future improvement. I have some ideas about how to factor out such code but it would be a significant under taking. For (2) I think it was agreed that fixing these mal practices will have to be something done in a version 2 of the api in which we can break some of the api. As for getting GSIP 58 into RC1 or even 2.1.0 I am not going to push on that, i want to hear peoples opinions on that. On the one hand I want to push for more modest development which means holding back on features like this. On the other hand since its a public api addition it would be good to get it into 2.1.0. Feedback welcome. -Justin -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] [jira] Created: (GEOS-4293) ForceCoordinateSystemFeatureResults will npe if the inner collection returns null bounds
ForceCoordinateSystemFeatureResults will npe if the inner collection returns null bounds Key: GEOS-4293 URL: http://jira.codehaus.org/browse/GEOS-4293 Project: GeoServer Issue Type: Bug Affects Versions: 2.1-beta3 Reporter: Andrea Aime Assignee: Andrea Aime Fix For: 2.1-RC1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
[Geoserver-devel] Problem with ArcSDEGridCoverage2DReaderJAI
Hi,
I'm trying to set a ArcSDE Raster (9.2) store in Geoserver 2.0.2 and I'm
getting the following error from the Add Store page:
Could not list layers for this store, an error occurred retrieving them: Unable
to acquire test coverage for format:ArcSDE Raster
I've checked out the code and looked at it.
In the CatalogBuilder class there is some code that generates a fake small
GridCoverage to retrieve meta information which is added to the parameters Map
send to the reader.
(~Line 651-653)
//build the corresponding envelope
final MathTransform gridToWorldCorner =
reader.getOriginalGridToWorld(PixelInCell.CELL_CORNER);
GeneralEnvelope testEnvelope =CRS.transform(gridToWorldCorner,new
GeneralEnvelope(testRange.getBounds()));
Then on ~Line 660 the reader.read method is called:
//try to read this coverage
gc = (GridCoverage2D)
reader.read(CoverageUtils.getParameters(readParams, parameters,
true));
gc will be null which explain the error: ' Unable to acquire test coverage for
format:ArcSDE Raster'
The reader called is : ArcSDEGridCoverage2DReaderJAI
From what I can tell, findMatchingRasters (Line 205) is empty because
RasterUtils.findMatchingRasters is returning an empty list.
The following condition is always false therefore nothing will be added to the
list matchingRasters:
(RasterUtils, line 520)
if (requestedEnvelope.intersects(gridEnvelope, edgesInclusive)) {
Basically, there is no data available for the requestedEnvelope in ArcSDE.
My understanding is that the original envelope is calculated using the
rasterInfo. This envelope is something like the smallest rectangle that can
contain all the raster data. There is good chance that there some area without
data which is the case for the test envelope.
The test envelope is using the top left corner to generate the bounding box.
The problem is that it can't be guarantee that there is data for this envelope
for every single store.
If I hardcode the test envelope to a value where I know there is data, it's
working just fine.
- Is there any possible workaround ?
- Is it something wrong in ArcSDE (which I'm not an expert) ?
- Is Geoserver expecting to get data for every area of the envelope ?
Thanks
Mathieu Lavoie
--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web. Learn how to
best implement a security strategy that keeps consumers' information secure
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl ___
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Re: [Geoserver-devel] Some restconfig proposals
On Fri, Jan 7, 2011 at 7:01 PM, Justin Deoliveira jdeol...@opengeo.org wrote: Hi all, With the pushing back of RC1 by a week I could not help myself to whip up two pending proposals having to do with restconfig. http://geoserver.org/display/GEOS/GSIP+59+-+Promote+RESTConfig+to+Core+Module http://geoserver.org/display/GEOS/GSIP+58+-+RESTConfig+API+Improvements The first I don't imagine will require too much discussion and actually has already been more or less agreed upon by devs. It is the promoting of RESTConfig to core module. It is pretty low risk so I don't forsee much resistance to getting it into RC1. Little resistance? Ha, power up your lightsaber and face me then! (kidding, of course +1 to get restconfig into core) GSIP 58 though probably requires more discussion. Although it was discussed in this previous email thread: http://old.nabble.com/some-restconfig-improvements-td30202559.html The outcome of that proposal was two fold: 1. It would be good to somehow share code or merge this with the wps import functionality. 2. Some concerns about this functionality continuing down the rest good practice violation path Both good concerns. For (1) I would like to push off as a future improvement. I have some ideas about how to factor out such code but it would be a significant under taking. For (2) I think it was agreed that fixing these mal practices will have to be something done in a version 2 of the api in which we can break some of the api. As for getting GSIP 58 into RC1 or even 2.1.0 I am not going to push on that, i want to hear peoples opinions on that. On the one hand I want to push for more modest development which means holding back on features like this. On the other hand since its a public api addition it would be good to get it into 2.1.0. Works for me, +1 on this one as well Cheers Andrea -- Ing. Andrea Aime Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584962313 fax: +39 0584962313 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf - -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
