Hi Devs,
I am looking at GEOS-6006 and want to use Springs MVC's interceptors to implement a quick fix (the longer term fix will require some discussion on the this list).
In order the register the interceptor in the WMS module's applicationContext.xml I need to update from the 2.x based DTD to a 3.x XSD version in order to properly register the interceptor. My first cut looks good, I was wondering… Is there any standard guidance related to this conversion in the geoserver codebase? Known issues?
Thanks,
Tom
Hey Tom,
Afaik in the past the pattern has been when a new module is added (mostly extensions and community modules) if the author decides to use the new xsd style they can. And I don’t know of any ill side affects of doing so. But as for porting existing modules to the xsd style not sure that has ever been done.
To clarify though, as I thought the new xsd style was mostly just syntactic sugar around the old stuff, you are saying that the spring feature you are trying to use won’t work at all with the old dtd style? Or is just much easier to work with the new xsd style?
ANyways, regarding any change of this nature (along the same lines as spring upgrades, etc…) we generally try them out on master first in order to give them some more exposure past the continuous testing that is done. And if no issues pop up within a few weeks to a month we allow the change to be backported to the stable branch, given that the change is “stable”, ie has no backward compatibility, stability, or api change concerns.
-Justin
$0.02
···
On Thu, Sep 12, 2013 at 3:59 PM, Tom Kunicki <tkunicki@anonymised.com01…> wrote:
Hi Devs,
I am looking at GEOS-6006 and want to use Springs MVC’s interceptors to implement a quick fix (the longer term fix will require some discussion on the this list).
In order the register the interceptor in the WMS module’s applicationContext.xml I need to update from the 2.x based DTD to a 3.x XSD version in order to properly register the interceptor. My first cut looks good, I was wondering… Is there any standard guidance related to this conversion in the geoserver codebase? Known issues?
Thanks,
Tom
How ServiceNow helps IT people transform IT departments:
- Consolidate legacy IT systems to a single system of record for IT
- Standardize and globalize service processes across IT
- Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Hi Justin,
Thanks, for the response. I wanted to use the “interceptor” element which exists in an alternate namespace. The interceptor registration method available with the DTD style requires nesting under each Mapping instance, with some mapping instances being outside the WMS module (“/**”). With the interceptor element element I can register an interceptor with it’s own mappings.
I’ve issued a pull request against master with the quick fix for GEOS 6006 (https://github.com/geoserver/geoserver/pull/330). The change to the appellationContext.xml file that requires the xdd conversion is here: https://github.com/geoserver/geoserver/pull/330/files#L0R609
Tom
···
On Thu, Sep 12, 2013 at 3:59 PM, Tom Kunicki <tkunicki@anonymised.com01…> wrote:
Hi Devs,
I am looking at GEOS-6006 and want to use Springs MVC’s interceptors to implement a quick fix (the longer term fix will require some discussion on the this list).
In order the register the interceptor in the WMS module’s applicationContext.xml I need to update from the 2.x based DTD to a 3.x XSD version in order to properly register the interceptor. My first cut looks good, I was wondering… Is there any standard guidance related to this conversion in the geoserver codebase? Known issues?
Thanks,
Tom
How ServiceNow helps IT people transform IT departments:
- Consolidate legacy IT systems to a single system of record for IT
- Standardize and globalize service processes across IT
- Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
On Fri, Sep 13, 2013 at 12:58 PM, Justin Deoliveira <jdeolive@anonymised.com>wrote:
Hey Tom,
Afaik in the past the pattern has been when a new module is added (mostly
extensions and community modules) if the author decides to use the new xsd
style they can. And I don't know of any ill side affects of doing so. But
as for porting existing modules to the xsd style not sure that has ever
been done.
To clarify though, as I thought the new xsd style was mostly just
syntactic sugar around the old stuff, you are saying that the spring
feature you are trying to use won't work at all with the old dtd style? Or
is just much easier to work with the new xsd style?
ANyways, regarding any change of this nature (along the same lines as
spring upgrades, etc...) we generally try them out on master first in order
to give them some more exposure past the continuous testing that is done.
And if no issues pop up within a few weeks to a month we allow the change
to be backported to the stable branch, given that the change is "stable",
ie has no backward compatibility, stability, or api change concerns.
Hum... I'm just wondering, won't a dispatcher callback work at all?
We can also register dynamic servlet filters that extend GeoServerFilter
Cheers
Andrea
--
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
Hi Andrea,
I’ll look at the DispatcherCallback and GeoServerFilter. For reference the code is up on as a pull request for inspection…
https://github.com/geoserver/geoserver/pull/330
Tom
···
Hey Tom,
Afaik in the past the pattern has been when a new module is added (mostly extensions and community modules) if the author decides to use the new xsd style they can. And I don’t know of any ill side affects of doing so. But as for porting existing modules to the xsd style not sure that has ever been done.
To clarify though, as I thought the new xsd style was mostly just syntactic sugar around the old stuff, you are saying that the spring feature you are trying to use won’t work at all with the old dtd style? Or is just much easier to work with the new xsd style?
ANyways, regarding any change of this nature (along the same lines as spring upgrades, etc…) we generally try them out on master first in order to give them some more exposure past the continuous testing that is done. And if no issues pop up within a few weeks to a month we allow the change to be backported to the stable branch, given that the change is “stable”, ie has no backward compatibility, stability, or api change concerns.
Hum… I’m just wondering, won’t a dispatcher callback work at all?
We can also register dynamic servlet filters that extend GeoServerFilter
Cheers
Andrea
–
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it