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:
- It would be good to somehow share code or merge this with the wps import functionality.
- 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.
On Fri, Jan 7, 2011 at 7:01 PM, Justin Deoliveira <jdeolive@anonymised.com> 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
-----------------------------------------------------
Upload to existing datastores sounds pretty useful to me… I notice the example only mentions the …/file.shp endpoint; will url.shp and external.shp also be supported?
I have also been working on some improvements to RESTConfig - with respect to error handling. The motivation is that in GeoNode we don’t do a lot of validation on shapefiles before passing them along to GeoServer, figuring that our validation won’t necessarily match GeoServer’s anyway. If the import fails somehow (most often due to a missing/unrecognized PRJ file) then the layer is enabled anyway, and GeoServer’s WMS capabilities document fails after that. (We currently have some fairly kludgy code that runs after such uploads to try and clean up.)
I think it would be better if the RESTConfig importer would disable a layer if it doesn’t have all the required fields for continuing WMS (and WFS/WCS/etc) service. I’ve done some work on it for WMS already (though I am sure some refactoring is in order.) Diff is at https://github.com/dwins/geoserver/compare/master…dont_break_wms_via_rest (and if you want an actual diff file, just add .diff to the end of the URL).
–
David Winslow
OpenGeo - http://opengeo.org/
On Sat, Jan 8, 2011 at 2:49 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
On Fri, Jan 7, 2011 at 7:01 PM, Justin Deoliveira <jdeolive@anonymised.com> 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:
- It would be good to somehow share code or merge this with the wps import
functionality.
- 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@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Ciao a tutti,
I am +1 on the first item.
I am +0 on the second one; actually I think cascade deletes are much
neede but I am bit hesitant about making this change now.
Long story short, ithnk we can move on with both items.
Simone.
On 1/8/11, Andrea Aime <andrea.aime@anonymised.com> wrote:
On Fri, Jan 7, 2011 at 7:01 PM, Justin Deoliveira <jdeolive@anonymised.com>
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
--
-------------------------------------------------------
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo
-------------------------------------------------------
I’m +1 on both. Restconfig API scared me a bit looking at the title, but these look to be completely additive, so if we get bad feedback during RC’s then we can just cut them.
I’m also +1 on David’s proposed commit, seems like a good idea to have REST uploads not automatically break the whole capabilities document - seems like a bug to have that happen.
David - you should probably at least file a jira, if there’s not one already. Perhaps a GSIP if there needs to be discussion around it… I guess an alternate path would be to have GeoServer just reject uploads that will break capabilities, but just leaving them disabled seems a friendlier solution.
C
On Sat, Jan 8, 2011 at 10:47 AM, Simone Giannecchini <simone.giannecchini@anonymised.com> wrote:
Ciao a tutti,
I am +1 on the first item.
I am +0 on the second one; actually I think cascade deletes are much
neede but I am bit hesitant about making this change now.
Long story short, ithnk we can move on with both items.
Simone.
On 1/8/11, Andrea Aime <andrea.aime@anonymised.com> wrote:
On Fri, Jan 7, 2011 at 7:01 PM, Justin Deoliveira <jdeolive@anonymised.com>
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:
- It would be good to somehow share code or merge this with the wps
import
functionality.
- 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
–
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder - Software Engineer
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo
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@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
On Sat, Jan 8, 2011 at 7:20 AM, David Winslow <dwinslow@anonymised.com> wrote:
Upload to existing datastores sounds pretty useful to me… I notice the example only mentions the …/file.shp endpoint; will url.shp and external.shp also be supported?
Yup, url and external are supported as well.
I have also been working on some improvements to RESTConfig - with respect to error handling. The motivation is that in GeoNode we don’t do a lot of validation on shapefiles before passing them along to GeoServer, figuring that our validation won’t necessarily match GeoServer’s anyway. If the import fails somehow (most often due to a missing/unrecognized PRJ file) then the layer is enabled anyway, and GeoServer’s WMS capabilities document fails after that. (We currently have some fairly kludgy code that runs after such uploads to try and clean up.)
I think it would be better if the RESTConfig importer would disable a layer if it doesn’t have all the required fields for continuing WMS (and WFS/WCS/etc) service. I’ve done some work on it for WMS already (though I am sure some refactoring is in order.) Diff is at https://github.com/dwins/geoserver/compare/master…dont_break_wms_via_rest (and if you want an actual diff file, just add .diff to the end of the URL).
I agree that indeed disabling the layer if it is invalid makes sense. As for the patch I think it needs some work. For one all the existing validation lives in the catalog itself, so it would be nice to keep it there rather than in the catalog info classes which by design we try to keep as “dumb” as possible.
Currently CatalogImpl has a set of “validate” methods it uses for internal validation. There was talk before about making them actually part of the Catalog interface and make them actual api. This strengthens that case.
Anyways, while I am all for the changes I think some more work still needs to be done before this gets in. And as it will probably require core changes I am tempted to push it off until after RC1. Although if David has time to put into this I will do my best to help it along.
–
David Winslow
OpenGeo - http://opengeo.org/
On Sat, Jan 8, 2011 at 2:49 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
On Fri, Jan 7, 2011 at 7:01 PM, Justin Deoliveira <jdeolive@anonymised.com.1501…> 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:
- It would be good to somehow share code or merge this with the wps import
functionality.
- 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
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Apologies for both the low code quality and the late timing, this code was kind of a back-burner experiment. I would like to get it into RC1 however and can put some more serious effort into it this week.
I gather the design should be something along the lines of:
- CatalogImpl::validate becomes public API (moving to Catalog::validate)
- The validation code I added in ResourceInfoImpl moves to CatalogImpl::validate(ResourceInfo, boolean)
One question comes to mind: would it be worthwhile to make this an extension point (for example, the style requirement would only be enforced if you have WMS disabled)? I guess the WMS/WFS/WCS related fields are pretty well baked-in to the catalog so perhaps it wouldn’t be useful.
–
David Winslow
OpenGeo - http://opengeo.org/
On Mon, Jan 10, 2011 at 11:48 AM, Justin Deoliveira <jdeolive@anonymised.com…> wrote:
On Sat, Jan 8, 2011 at 7:20 AM, David Winslow <dwinslow@anonymised.com> wrote:
Upload to existing datastores sounds pretty useful to me… I notice the example only mentions the …/file.shp endpoint; will url.shp and external.shp also be supported?
Yup, url and external are supported as well.
I have also been working on some improvements to RESTConfig - with respect to error handling. The motivation is that in GeoNode we don’t do a lot of validation on shapefiles before passing them along to GeoServer, figuring that our validation won’t necessarily match GeoServer’s anyway. If the import fails somehow (most often due to a missing/unrecognized PRJ file) then the layer is enabled anyway, and GeoServer’s WMS capabilities document fails after that. (We currently have some fairly kludgy code that runs after such uploads to try and clean up.)
I think it would be better if the RESTConfig importer would disable a layer if it doesn’t have all the required fields for continuing WMS (and WFS/WCS/etc) service. I’ve done some work on it for WMS already (though I am sure some refactoring is in order.) Diff is at https://github.com/dwins/geoserver/compare/master…dont_break_wms_via_rest (and if you want an actual diff file, just add .diff to the end of the URL).
I agree that indeed disabling the layer if it is invalid makes sense. As for the patch I think it needs some work. For one all the existing validation lives in the catalog itself, so it would be nice to keep it there rather than in the catalog info classes which by design we try to keep as “dumb” as possible.
Currently CatalogImpl has a set of “validate” methods it uses for internal validation. There was talk before about making them actually part of the Catalog interface and make them actual api. This strengthens that case.
Anyways, while I am all for the changes I think some more work still needs to be done before this gets in. And as it will probably require core changes I am tempted to push it off until after RC1. Although if David has time to put into this I will do my best to help it along.
–
David Winslow
OpenGeo - http://opengeo.org/
On Sat, Jan 8, 2011 at 2:49 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
On Fri, Jan 7, 2011 at 7:01 PM, Justin Deoliveira <jdeolive@anonymised.com> 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:
- It would be good to somehow share code or merge this with the wps import
functionality.
- 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
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
On Mon, Jan 10, 2011 at 10:22 AM, David Winslow <dwinslow@anonymised.com> wrote:
Apologies for both the low code quality and the late timing, this code was kind of a back-burner experiment. I would like to get it into RC1 however and can put some more serious effort into it this week.
Great. But just be warned that this will be changes to core code. And last week we pushed back RC1 to accomodate some core security changes. The concerns raised there will probably be apply here in that it seems risky to make a bunch of core changes and then stamp it RC1 directly after. However I imagine the scale of these changes to be smaller so I guess we can discuss that when we have a patch in hand.
I gather the design should be something along the lines of:
- CatalogImpl::validate becomes public API (moving to Catalog::validate)
- The validation code I added in ResourceInfoImpl moves to CatalogImpl::validate(ResourceInfo, boolean)
One question comes to mind: would it be worthwhile to make this an extension point (for example, the style requirement would only be enforced if you have WMS disabled)? I guess the WMS/WFS/WCS related fields are pretty well baked-in to the catalog so perhaps it wouldn’t be useful.
Big +1. I think an extension point makes a lot of sense and indeed something that came up in the past. It also gives smaller extensions that store metadata on catalog entries a chance for validation.
–
David Winslow
OpenGeo - http://opengeo.org/
On Mon, Jan 10, 2011 at 11:48 AM, Justin Deoliveira <jdeolive@anonymised.com1501…> wrote:
On Sat, Jan 8, 2011 at 7:20 AM, David Winslow <dwinslow@anonymised.com> wrote:
Upload to existing datastores sounds pretty useful to me… I notice the example only mentions the …/file.shp endpoint; will url.shp and external.shp also be supported?
Yup, url and external are supported as well.
I have also been working on some improvements to RESTConfig - with respect to error handling. The motivation is that in GeoNode we don’t do a lot of validation on shapefiles before passing them along to GeoServer, figuring that our validation won’t necessarily match GeoServer’s anyway. If the import fails somehow (most often due to a missing/unrecognized PRJ file) then the layer is enabled anyway, and GeoServer’s WMS capabilities document fails after that. (We currently have some fairly kludgy code that runs after such uploads to try and clean up.)
I think it would be better if the RESTConfig importer would disable a layer if it doesn’t have all the required fields for continuing WMS (and WFS/WCS/etc) service. I’ve done some work on it for WMS already (though I am sure some refactoring is in order.) Diff is at https://github.com/dwins/geoserver/compare/master…dont_break_wms_via_rest (and if you want an actual diff file, just add .diff to the end of the URL).
I agree that indeed disabling the layer if it is invalid makes sense. As for the patch I think it needs some work. For one all the existing validation lives in the catalog itself, so it would be nice to keep it there rather than in the catalog info classes which by design we try to keep as “dumb” as possible.
Currently CatalogImpl has a set of “validate” methods it uses for internal validation. There was talk before about making them actually part of the Catalog interface and make them actual api. This strengthens that case.
Anyways, while I am all for the changes I think some more work still needs to be done before this gets in. And as it will probably require core changes I am tempted to push it off until after RC1. Although if David has time to put into this I will do my best to help it along.
–
David Winslow
OpenGeo - http://opengeo.org/
On Sat, Jan 8, 2011 at 2:49 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
On Fri, Jan 7, 2011 at 7:01 PM, Justin Deoliveira <jdeolive@anonymised.com> 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:
- It would be good to somehow share code or merge this with the wps import
functionality.
- 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
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
http://jira.codehaus.org/browse/GEOS-4297 is the JIRA issue. I have attached a patch that, I believe, contains all the changes discussed in this thread.
–
David Winslow
OpenGeo - http://opengeo.org/
On Mon, Jan 10, 2011 at 12:31 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
On Mon, Jan 10, 2011 at 10:22 AM, David Winslow <dwinslow@anonymised.com501…> wrote:
Apologies for both the low code quality and the late timing, this code was kind of a back-burner experiment. I would like to get it into RC1 however and can put some more serious effort into it this week.
Great. But just be warned that this will be changes to core code. And last week we pushed back RC1 to accomodate some core security changes. The concerns raised there will probably be apply here in that it seems risky to make a bunch of core changes and then stamp it RC1 directly after. However I imagine the scale of these changes to be smaller so I guess we can discuss that when we have a patch in hand.
I gather the design should be something along the lines of:
- CatalogImpl::validate becomes public API (moving to Catalog::validate)
- The validation code I added in ResourceInfoImpl moves to CatalogImpl::validate(ResourceInfo, boolean)
One question comes to mind: would it be worthwhile to make this an extension point (for example, the style requirement would only be enforced if you have WMS disabled)? I guess the WMS/WFS/WCS related fields are pretty well baked-in to the catalog so perhaps it wouldn’t be useful.
Big +1. I think an extension point makes a lot of sense and indeed something that came up in the past. It also gives smaller extensions that store metadata on catalog entries a chance for validation.
–
David Winslow
OpenGeo - http://opengeo.org/
On Mon, Jan 10, 2011 at 11:48 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
On Sat, Jan 8, 2011 at 7:20 AM, David Winslow <dwinslow@anonymised.com> wrote:
Upload to existing datastores sounds pretty useful to me… I notice the example only mentions the …/file.shp endpoint; will url.shp and external.shp also be supported?
Yup, url and external are supported as well.
I have also been working on some improvements to RESTConfig - with respect to error handling. The motivation is that in GeoNode we don’t do a lot of validation on shapefiles before passing them along to GeoServer, figuring that our validation won’t necessarily match GeoServer’s anyway. If the import fails somehow (most often due to a missing/unrecognized PRJ file) then the layer is enabled anyway, and GeoServer’s WMS capabilities document fails after that. (We currently have some fairly kludgy code that runs after such uploads to try and clean up.)
I think it would be better if the RESTConfig importer would disable a layer if it doesn’t have all the required fields for continuing WMS (and WFS/WCS/etc) service. I’ve done some work on it for WMS already (though I am sure some refactoring is in order.) Diff is at https://github.com/dwins/geoserver/compare/master…dont_break_wms_via_rest (and if you want an actual diff file, just add .diff to the end of the URL).
I agree that indeed disabling the layer if it is invalid makes sense. As for the patch I think it needs some work. For one all the existing validation lives in the catalog itself, so it would be nice to keep it there rather than in the catalog info classes which by design we try to keep as “dumb” as possible.
Currently CatalogImpl has a set of “validate” methods it uses for internal validation. There was talk before about making them actually part of the Catalog interface and make them actual api. This strengthens that case.
Anyways, while I am all for the changes I think some more work still needs to be done before this gets in. And as it will probably require core changes I am tempted to push it off until after RC1. Although if David has time to put into this I will do my best to help it along.
–
David Winslow
OpenGeo - http://opengeo.org/
On Sat, Jan 8, 2011 at 2:49 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
On Fri, Jan 7, 2011 at 7:01 PM, Justin Deoliveira <jdeolive@anonymised.com> 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:
- It would be good to somehow share code or merge this with the wps import
functionality.
- 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
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
And I’ve just updated with a newer patch to resolve some conflicts introduced by Justin’s committing of GSIP 58.
–
David Winslow
OpenGeo - http://opengeo.org/
On Mon, Jan 10, 2011 at 6:42 PM, David Winslow <dwinslow@anonymised.com.1501…> wrote:
http://jira.codehaus.org/browse/GEOS-4297 is the JIRA issue. I have attached a patch that, I believe, contains all the changes discussed in this thread.
–
David Winslow
OpenGeo - http://opengeo.org/
On Mon, Jan 10, 2011 at 12:31 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
On Mon, Jan 10, 2011 at 10:22 AM, David Winslow <dwinslow@anonymised.com> wrote:
Apologies for both the low code quality and the late timing, this code was kind of a back-burner experiment. I would like to get it into RC1 however and can put some more serious effort into it this week.
Great. But just be warned that this will be changes to core code. And last week we pushed back RC1 to accomodate some core security changes. The concerns raised there will probably be apply here in that it seems risky to make a bunch of core changes and then stamp it RC1 directly after. However I imagine the scale of these changes to be smaller so I guess we can discuss that when we have a patch in hand.
I gather the design should be something along the lines of:
- CatalogImpl::validate becomes public API (moving to Catalog::validate)
- The validation code I added in ResourceInfoImpl moves to CatalogImpl::validate(ResourceInfo, boolean)
One question comes to mind: would it be worthwhile to make this an extension point (for example, the style requirement would only be enforced if you have WMS disabled)? I guess the WMS/WFS/WCS related fields are pretty well baked-in to the catalog so perhaps it wouldn’t be useful.
Big +1. I think an extension point makes a lot of sense and indeed something that came up in the past. It also gives smaller extensions that store metadata on catalog entries a chance for validation.
–
David Winslow
OpenGeo - http://opengeo.org/
On Mon, Jan 10, 2011 at 11:48 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
On Sat, Jan 8, 2011 at 7:20 AM, David Winslow <dwinslow@anonymised.com> wrote:
Upload to existing datastores sounds pretty useful to me… I notice the example only mentions the …/file.shp endpoint; will url.shp and external.shp also be supported?
Yup, url and external are supported as well.
I have also been working on some improvements to RESTConfig - with respect to error handling. The motivation is that in GeoNode we don’t do a lot of validation on shapefiles before passing them along to GeoServer, figuring that our validation won’t necessarily match GeoServer’s anyway. If the import fails somehow (most often due to a missing/unrecognized PRJ file) then the layer is enabled anyway, and GeoServer’s WMS capabilities document fails after that. (We currently have some fairly kludgy code that runs after such uploads to try and clean up.)
I think it would be better if the RESTConfig importer would disable a layer if it doesn’t have all the required fields for continuing WMS (and WFS/WCS/etc) service. I’ve done some work on it for WMS already (though I am sure some refactoring is in order.) Diff is at https://github.com/dwins/geoserver/compare/master…dont_break_wms_via_rest (and if you want an actual diff file, just add .diff to the end of the URL).
I agree that indeed disabling the layer if it is invalid makes sense. As for the patch I think it needs some work. For one all the existing validation lives in the catalog itself, so it would be nice to keep it there rather than in the catalog info classes which by design we try to keep as “dumb” as possible.
Currently CatalogImpl has a set of “validate” methods it uses for internal validation. There was talk before about making them actually part of the Catalog interface and make them actual api. This strengthens that case.
Anyways, while I am all for the changes I think some more work still needs to be done before this gets in. And as it will probably require core changes I am tempted to push it off until after RC1. Although if David has time to put into this I will do my best to help it along.
–
David Winslow
OpenGeo - http://opengeo.org/
On Sat, Jan 8, 2011 at 2:49 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
On Fri, Jan 7, 2011 at 7:01 PM, Justin Deoliveira <jdeolive@anonymised.com> 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:
- It would be good to somehow share code or merge this with the wps import
functionality.
- 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
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
The patch has Justin with a +1, but he wanted feedback from another developer since it’s a fairly core thing.
I’m obviously no longer qualified, but could anyone look at it before Justin starts the release process? Totally fine if the answer is ‘no, too core’, but it’d be good to not miss the fix just because people forgot about it. And I think it’d be a nice rest api improvement, so people break their geoservers less easily.
Andrea? Alessio? Simone?
Issue and patch at http://jira.codehaus.org/browse/GEOS-4297
thanks,
C
On Wed, Jan 12, 2011 at 7:23 PM, David Winslow <dwinslow@anonymised.com> wrote:
And I’ve just updated with a newer patch to resolve some conflicts introduced by Justin’s committing of GSIP 58.
–
David Winslow
OpenGeo - http://opengeo.org/
On Mon, Jan 10, 2011 at 6:42 PM, David Winslow <dwinslow@anonymised.com> wrote:
http://jira.codehaus.org/browse/GEOS-4297 is the JIRA issue. I have attached a patch that, I believe, contains all the changes discussed in this thread.
–
David Winslow
OpenGeo - http://opengeo.org/
On Mon, Jan 10, 2011 at 12:31 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
On Mon, Jan 10, 2011 at 10:22 AM, David Winslow <dwinslow@anonymised.com> wrote:
Apologies for both the low code quality and the late timing, this code was kind of a back-burner experiment. I would like to get it into RC1 however and can put some more serious effort into it this week.
Great. But just be warned that this will be changes to core code. And last week we pushed back RC1 to accomodate some core security changes. The concerns raised there will probably be apply here in that it seems risky to make a bunch of core changes and then stamp it RC1 directly after. However I imagine the scale of these changes to be smaller so I guess we can discuss that when we have a patch in hand.
I gather the design should be something along the lines of:
- CatalogImpl::validate becomes public API (moving to Catalog::validate)
- The validation code I added in ResourceInfoImpl moves to CatalogImpl::validate(ResourceInfo, boolean)
One question comes to mind: would it be worthwhile to make this an extension point (for example, the style requirement would only be enforced if you have WMS disabled)? I guess the WMS/WFS/WCS related fields are pretty well baked-in to the catalog so perhaps it wouldn’t be useful.
Big +1. I think an extension point makes a lot of sense and indeed something that came up in the past. It also gives smaller extensions that store metadata on catalog entries a chance for validation.
–
David Winslow
OpenGeo - http://opengeo.org/
On Mon, Jan 10, 2011 at 11:48 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
On Sat, Jan 8, 2011 at 7:20 AM, David Winslow <dwinslow@anonymised.com> wrote:
Upload to existing datastores sounds pretty useful to me… I notice the example only mentions the …/file.shp endpoint; will url.shp and external.shp also be supported?
Yup, url and external are supported as well.
I have also been working on some improvements to RESTConfig - with respect to error handling. The motivation is that in GeoNode we don’t do a lot of validation on shapefiles before passing them along to GeoServer, figuring that our validation won’t necessarily match GeoServer’s anyway. If the import fails somehow (most often due to a missing/unrecognized PRJ file) then the layer is enabled anyway, and GeoServer’s WMS capabilities document fails after that. (We currently have some fairly kludgy code that runs after such uploads to try and clean up.)
I think it would be better if the RESTConfig importer would disable a layer if it doesn’t have all the required fields for continuing WMS (and WFS/WCS/etc) service. I’ve done some work on it for WMS already (though I am sure some refactoring is in order.) Diff is at https://github.com/dwins/geoserver/compare/master…dont_break_wms_via_rest (and if you want an actual diff file, just add .diff to the end of the URL).
I agree that indeed disabling the layer if it is invalid makes sense. As for the patch I think it needs some work. For one all the existing validation lives in the catalog itself, so it would be nice to keep it there rather than in the catalog info classes which by design we try to keep as “dumb” as possible.
Currently CatalogImpl has a set of “validate” methods it uses for internal validation. There was talk before about making them actually part of the Catalog interface and make them actual api. This strengthens that case.
Anyways, while I am all for the changes I think some more work still needs to be done before this gets in. And as it will probably require core changes I am tempted to push it off until after RC1. Although if David has time to put into this I will do my best to help it along.
–
David Winslow
OpenGeo - http://opengeo.org/
On Sat, Jan 8, 2011 at 2:49 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
On Fri, Jan 7, 2011 at 7:01 PM, Justin Deoliveira <jdeolive@anonymised.com.> 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:
- It would be good to somehow share code or merge this with the wps import
functionality.
- 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
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
On Fri, Jan 14, 2011 at 2:56 PM, Chris Holmes <cholmes@anonymised.com> wrote:
The patch has Justin with a +1, but he wanted feedback from another
developer since it's a fairly core thing.
I'm obviously no longer qualified, but could anyone look at it before Justin
starts the release process? Totally fine if the answer is 'no, too core',
but it'd be good to not miss the fix just because people forgot about it.
And I think it'd be a nice rest api improvement, so people break their
geoservers less easily.
Andrea? Alessio? Simone?
Issue and patch at http://jira.codehaus.org/browse/GEOS-4297
Had a look, the patch seems reasonable to me. +1 on committing
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
-----------------------------------------------------
Cool, thanks Andrea. I am going to apply the patch and commit and then start the release train.
On Fri, Jan 14, 2011 at 9:36 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:
On Fri, Jan 14, 2011 at 2:56 PM, Chris Holmes <cholmes@anonymised.com501…> wrote:
The patch has Justin with a +1, but he wanted feedback from another
developer since it’s a fairly core thing.
I’m obviously no longer qualified, but could anyone look at it before Justin
starts the release process? Totally fine if the answer is ‘no, too core’,
but it’d be good to not miss the fix just because people forgot about it.
And I think it’d be a nice rest api improvement, so people break their
geoservers less easily.
Andrea? Alessio? Simone?
Issue and patch at http://jira.codehaus.org/browse/GEOS-4297
Had a look, the patch seems reasonable to me. +1 on committing
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
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.