[Geoserver-devel] Progress on spring upgrade

Hey folks, thought I would send a quick update on progress. To recap the branch currently being worked on is here:

https://github.com/geoserver/geoserver/tree/spring4-upgrade

The branch currently contains:

  • Core upgrades to spring 4.2.5 and spring security 4.0.4
  • Upgrade to servlet api 3.0.1
  • Andreas work to migrate from mockrunner to spring-test

I also pushed a branch for geowebcache:

https://github.com/GeoWebCache/geowebcache/tree/spring-servlet-upgrade

Although it looks like Kevin already did the work here?:

https://github.com/GeoWebCache/geowebcache/tree/spring4-upgrade

At any rate, one of those branches will be required to build the geoserver branch.

At the moment all the core modules compile and pass tests. With the exception of one wms test that from what I can tell was some wierd osx failure. It would be nice if someone else could verify that though.

I’ve also run the server and everythign starts up ok, but I haven’t poked it much harder than a quick smoke test.

There is one interesting thing that I found with spring security. The login and logout endpoints have changed. So “/j_spring_security_check" is now “/login” and “/j_spring_security_logout” is now “/logout”. I’m still unsure what the backwards compatability repercussions will be with this. It looks like those paths are configurable in some places (like if using annotation based config) but the way we are using some of the filters it didn’t look like they were. I was going to circle back to this.

So… next steps is to start updating extensions and community modules. The big one being cas. @Christian: I think you have all you need on that branch to start looking at the CAS migration. Let me know if you have any questions.

That’s about it for now.

-Justin

Hi Justin,
had a very quick look, GeoServer wise the only thing I noticed was the lack of header upgrades (which
can be done later), all the other changes look reasonable (but mind, I haven’t used Spring 4 anywhere else).

···

On Sat, Mar 5, 2016 at 6:23 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hey folks, thought I would send a quick update on progress. To recap the branch currently being worked on is here:

https://github.com/geoserver/geoserver/tree/spring4-upgrade

The branch currently contains:

  • Core upgrades to spring 4.2.5 and spring security 4.0.4
  • Upgrade to servlet api 3.0.1
  • Andreas work to migrate from mockrunner to spring-test

I also pushed a branch for geowebcache:

https://github.com/GeoWebCache/geowebcache/tree/spring-servlet-upgrade

Tried to build this one, I get a failure in gwc-wmts:

Tests run: 6, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 11.632 sec <<< FAILURE!
testGetTileWithStyle(org.geowebcache.service.wmts.WMTSServiceTest) Time elapsed: 0.416 sec <<< FAILURE!
java.lang.AssertionError:
Expected: map containing [“STYLES”->“Bar”]
but: map was
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8)
at org.geowebcache.service.wmts.WMTSServiceTest.testGetTileWithStyle(WMTSServiceTest.java:524)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at junit.framework.TestCase.runTest(TestCase.java:176)
at junit.framework.TestCase.runBare(TestCase.java:141)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)

It was a simple fix for a mock expectation, so I’ve fixed it. One liner change pushed to the branch.

Although it looks like Kevin already did the work here?:

https://github.com/GeoWebCache/geowebcache/tree/spring4-upgrade

Looks like this one misses the servlet api upgrade though.

At any rate, one of those branches will be required to build the geoserver branch.

At the moment all the core modules compile and pass tests. With the exception of one wms test that from what I can tell was some wierd osx failure. It would be nice if someone else could verify that though.

No failures in wms here (also made a fresh build of geotools to be on the safe side), do you have details?
I’ve made a full build and I have failures in the following extensions: CAS (expected), WPS, XSLT, monitoring hibernate… not all
that many in the end.
Assuming you’re not working on it right now, I’m going to have a quick look.

I’ve also run the server and everythign starts up ok, but I haven’t poked it much harder than a quick smoke test.

There is one interesting thing that I found with spring security. The login and logout endpoints have changed. So “/j_spring_security_check" is now “/login” and “/j_spring_security_logout” is now “/logout”. I’m still unsure what the backwards compatability repercussions will be with this. It looks like those paths are configurable in some places (like if using annotation based config) but the way we are using some of the filters it didn’t look like they were. I was going to circle back to this.

Hum… thinking, don’t we have some javascript apps around using these endpoints to test authentication
when using a custom login form?

Cheers
Andrea

==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313

fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.


On Sun, Mar 6, 2016 at 11:00 AM, Andrea Aime <andrea.aime@anonymised.com>
wrote:

No failures in wms here (also made a fresh build of geotools to be on the
safe side), do you have details?
I've made a full build and I have failures in the following extensions:
CAS (expected), WPS, XSLT, monitoring hibernate... not all
that many in the end.
Assuming you're not working on it right now, I'm going to have a quick
look.

Made WPS, XSLT and monitor hibernate build, the first two needed the same
timer changes as wcs, the latter had
issues with deprecated API and generics, hopefully fixed too (well, the
test pass, don't know if it actually works at runtime).

Of course I'll leave the CAS upgrade fun to Christian.

Had a cursory look though community modules in the community-release
profile too:
* JDBCConfig fails to compile, as well as gs-jms-geoserver
* gs-rest-ext, js-rest-upload, gs-wms-eo, gs-dds, gs-web-solr,
gs-geofence-server, gs-geopgk, gs-script-js, gs-script-groovy all
   have test failures

Three of them were already known from the mockrunner removal (if memory
serves me right).
Haven't investigated them.

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

Thanks Andrea. Comments inline.

Hi Justin,
had a very quick look, GeoServer wise the only thing I noticed was the lack of header upgrades (which
can be done later), all the other changes look reasonable (but mind, I haven’t used Spring 4 anywhere else).

Nice, thanks!

I’ve attached the failure trace I get from testCoverageViewMap(org.geoserver.wms.wms_1_1_1.GetMapIntegrationTest). I am pretty sure I have seen this failure before in my environment.

Yeah, I know of one app (geoexplorer) that uses one of the endpoints to create a session. One thought I had (if we can’t configure the endpoint paths) was to create a redirect from old to the new.

(attachments)

failure.txt (9.02 KB)

···

On Sat, Mar 5, 2016 at 6:23 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hey folks, thought I would send a quick update on progress. To recap the branch currently being worked on is here:

https://github.com/geoserver/geoserver/tree/spring4-upgrade

The branch currently contains:

  • Core upgrades to spring 4.2.5 and spring security 4.0.4
  • Upgrade to servlet api 3.0.1
  • Andreas work to migrate from mockrunner to spring-test

I also pushed a branch for geowebcache:

https://github.com/GeoWebCache/geowebcache/tree/spring-servlet-upgrade

Tried to build this one, I get a failure in gwc-wmts:

Tests run: 6, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 11.632 sec <<< FAILURE!
testGetTileWithStyle(org.geowebcache.service.wmts.WMTSServiceTest) Time elapsed: 0.416 sec <<< FAILURE!
java.lang.AssertionError:
Expected: map containing [“STYLES”->“Bar”]
but: map was
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8)
at org.geowebcache.service.wmts.WMTSServiceTest.testGetTileWithStyle(WMTSServiceTest.java:524)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at junit.framework.TestCase.runTest(TestCase.java:176)
at junit.framework.TestCase.runBare(TestCase.java:141)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)

It was a simple fix for a mock expectation, so I’ve fixed it. One liner change pushed to the branch.

Although it looks like Kevin already did the work here?:

https://github.com/GeoWebCache/geowebcache/tree/spring4-upgrade

Looks like this one misses the servlet api upgrade though.

At any rate, one of those branches will be required to build the geoserver branch.

At the moment all the core modules compile and pass tests. With the exception of one wms test that from what I can tell was some wierd osx failure. It would be nice if someone else could verify that though.

No failures in wms here (also made a fresh build of geotools to be on the safe side), do you have details?
I’ve made a full build and I have failures in the following extensions: CAS (expected), WPS, XSLT, monitoring hibernate… not all
that many in the end.
Assuming you’re not working on it right now, I’m going to have a quick look.

I’ve also run the server and everythign starts up ok, but I haven’t poked it much harder than a quick smoke test.

There is one interesting thing that I found with spring security. The login and logout endpoints have changed. So “/j_spring_security_check" is now “/login” and “/j_spring_security_logout” is now “/logout”. I’m still unsure what the backwards compatability repercussions will be with this. It looks like those paths are configurable in some places (like if using annotation based config) but the way we are using some of the filters it didn’t look like they were. I was going to circle back to this.

Hum… thinking, don’t we have some javascript apps around using these endpoints to test authentication
when using a custom login form?

Cheers
Andrea

==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313

fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.


Thanks to both of you for the hard work, Kevin if you are working on that branch please remember to coordinate with the email list.

I will catch up mid week.

···

On Sat, Mar 5, 2016 at 6:23 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hey folks, thought I would send a quick update on progress. To recap the branch currently being worked on is here:

https://github.com/geoserver/geoserver/tree/spring4-upgrade

The branch currently contains:

  • Core upgrades to spring 4.2.5 and spring security 4.0.4
  • Upgrade to servlet api 3.0.1
  • Andreas work to migrate from mockrunner to spring-test

I also pushed a branch for geowebcache:

https://github.com/GeoWebCache/geowebcache/tree/spring-servlet-upgrade

Tried to build this one, I get a failure in gwc-wmts:

Tests run: 6, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 11.632 sec <<< FAILURE!
testGetTileWithStyle(org.geowebcache.service.wmts.WMTSServiceTest) Time elapsed: 0.416 sec <<< FAILURE!
java.lang.AssertionError:
Expected: map containing [“STYLES”->“Bar”]
but: map was
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8)
at org.geowebcache.service.wmts.WMTSServiceTest.testGetTileWithStyle(WMTSServiceTest.java:524)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at junit.framework.TestCase.runTest(TestCase.java:176)
at junit.framework.TestCase.runBare(TestCase.java:141)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:84)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)

It was a simple fix for a mock expectation, so I’ve fixed it. One liner change pushed to the branch.

Although it looks like Kevin already did the work here?:

https://github.com/GeoWebCache/geowebcache/tree/spring4-upgrade

Looks like this one misses the servlet api upgrade though.

At any rate, one of those branches will be required to build the geoserver branch.

At the moment all the core modules compile and pass tests. With the exception of one wms test that from what I can tell was some wierd osx failure. It would be nice if someone else could verify that though.

No failures in wms here (also made a fresh build of geotools to be on the safe side), do you have details?
I’ve made a full build and I have failures in the following extensions: CAS (expected), WPS, XSLT, monitoring hibernate… not all
that many in the end.
Assuming you’re not working on it right now, I’m going to have a quick look.

I’ve also run the server and everythign starts up ok, but I haven’t poked it much harder than a quick smoke test.

There is one interesting thing that I found with spring security. The login and logout endpoints have changed. So “/j_spring_security_check" is now “/login” and “/j_spring_security_logout” is now “/logout”. I’m still unsure what the backwards compatability repercussions will be with this. It looks like those paths are configurable in some places (like if using annotation based config) but the way we are using some of the filters it didn’t look like they were. I was going to circle back to this.

Hum… thinking, don’t we have some javascript apps around using these endpoints to test authentication
when using a custom login form?

Cheers
Andrea

==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313

fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.


On Sun, Mar 6, 2016 at 6:34 PM, Justin Deoliveira <jdeolive@anonymised.com>
wrote:

No failures in wms here (also made a fresh build of geotools to be on the

safe side), do you have details?
I've made a full build and I have failures in the following extensions:
CAS (expected), WPS, XSLT, monitoring hibernate... not all
that many in the end.
Assuming you're not working on it right now, I'm going to have a quick
look.

I’ve attached the failure trace I get
from testCoverageViewMap(org.geoserver.wms.wms_1_1_1.GetMapIntegrationTest).
I am pretty sure I have seen this failure before in my environment.

Aah... yeah, I know that beast. One quick solution is to remove the native
JAI for OSX, it's the only one using that
operation that is not implemented in JAITools ROIGeometry, and not used by
the native jai for windows and linux (or the pure java jai).

The other option would be to put some more effort behind this pull request,
in which I did implement the said method (although,
not sure if correctly or fast enough, I don't have a good way to test
it...):

https://github.com/mbedward/jaitools/pull/233

The main thing keeping that pull request at bay is that I've implemented it
fully in my spare time, and it would require
manual testing... I was thinking to merge it right away after the new
stable gets cut, which was supposed to be
soon enough, in order to gather feedback in the next dev cycle without
causing troubles to this release.
Now, with this delay it would be tempting to merge it and release another
version of jaitools,
but of course it also has the risk of adding more "late" changes, and thus
potentially more instability.

I’ve also run the server and everythign starts up ok, but I haven’t
poked it much harder than a quick smoke test.

There is one interesting thing that I found with spring security. The
login and logout endpoints have changed. So “/j_spring_security_check" is
now “/login” and “/j_spring_security_logout” is now “/logout”. I’m still
unsure what the backwards compatability repercussions will be with this. It
looks like those paths are configurable in some places (like if using
annotation based config) but the way we are using some of the filters it
didn’t look like they were. I was going to circle back to this.

Hum... thinking, don't we have some javascript apps around using these
endpoints to test authentication
when using a custom login form?

Yeah, I know of one app (geoexplorer) that uses one of the endpoints to
create a session. One thought I had (if we can’t configure the endpoint
paths) was to create a redirect from old to the new.

Ah, yep... not everything handles redirects seamlessly (maven anyone? :wink:
), but browsers should.

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

Can we do some OS specific priority thing to avoid use of the native operations on OSX? They really are not around much anymore; very hard to find on the apple website etc…

We could document the result and add it to GeoTools init()

···

On 6 March 2016 at 12:10, Andrea Aime <andrea.aime@anonymised.com> wrote:



Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Jody Garnett

On Sun, Mar 6, 2016 at 6:34 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

I’ve attached the failure trace I get from testCoverageViewMap(org.geoserver.wms.wms_1_1_1.GetMapIntegrationTest). I am pretty sure I have seen this failure before in my environment.

Aah… yeah, I know that beast. One quick solution is to remove the native JAI for OSX, it’s the only one using that
operation that is not implemented in JAITools ROIGeometry, and not used by the native jai for windows and linux (or the pure java jai).

The other option would be to put some more effort behind this pull request, in which I did implement the said method (although,
not sure if correctly or fast enough, I don’t have a good way to test it…):

https://github.com/mbedward/jaitools/pull/233

The main thing keeping that pull request at bay is that I’ve implemented it fully in my spare time, and it would require
manual testing… I was thinking to merge it right away after the new stable gets cut, which was supposed to be
soon enough, in order to gather feedback in the next dev cycle without causing troubles to this release.
Now, with this delay it would be tempting to merge it and release another version of jaitools,
but of course it also has the risk of adding more “late” changes, and thus potentially more instability.

Yeah, I know of one app (geoexplorer) that uses one of the endpoints to create a session. One thought I had (if we can’t configure the endpoint paths) was to create a redirect from old to the new.

Ah, yep… not everything handles redirects seamlessly (maven anyone? :wink: ), but browsers should.

Cheers

Andrea

==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313

fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.


No failures in wms here (also made a fresh build of geotools to be on the safe side), do you have details?

I’ve made a full build and I have failures in the following extensions: CAS (expected), WPS, XSLT, monitoring hibernate… not all
that many in the end.
Assuming you’re not working on it right now, I’m going to have a quick look.

I’ve also run the server and everythign starts up ok, but I haven’t poked it much harder than a quick smoke test.

There is one interesting thing that I found with spring security. The login and logout endpoints have changed. So “/j_spring_security_check" is now “/login” and “/j_spring_security_logout” is now “/logout”. I’m still unsure what the backwards compatability repercussions will be with this. It looks like those paths are configurable in some places (like if using annotation based config) but the way we are using some of the filters it didn’t look like they were. I was going to circle back to this.

Hum… thinking, don’t we have some javascript apps around using these endpoints to test authentication
when using a custom login form?

I had done the Servlet 3.0.1 update on Friday, but hadn’t committed it yet. I’ve merged spring-servlet-upgrade into spring4-upgrade to make sure we don’t loose anything. The conflicts were fairly simple to resolve and all unit tests are passing.

I’ll do some stand alone GWC testing to check if anything non-obvious has broken.

Kevin Michael Smith

smithkm@anonymised.com

On Sun, Mar 6, 2016, at 12:14 PM, Jody Garnett wrote:

Can we do some OS specific priority thing to avoid use of the native operations on OSX? They really are not around much anymore; very hard to find on the apple website etc…

We could document the result and add it to GeoTools init()

Jody Garnett

On 6 March 2016 at 12:10, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Sun, Mar 6, 2016 at 6:34 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

No failures in wms here (also made a fresh build of geotools to be on the safe side), do you have details?

I’ve made a full build and I have failures in the following extensions: CAS (expected), WPS, XSLT, monitoring hibernate… not all

that many in the end.

Assuming you’re not working on it right now, I’m going to have a quick look.

I’ve attached the failure trace I get from testCoverageViewMap(org.geoserver.wms.wms_1_1_1.GetMapIntegrationTest). I am pretty sure I have seen this failure before in my environment.

Aah… yeah, I know that beast. One quick solution is to remove the native JAI for OSX, it’s the only one using that

operation that is not implemented in JAITools ROIGeometry, and not used by the native jai for windows and linux (or the pure java jai).

The other option would be to put some more effort behind this pull request, in which I did implement the said method (although,

not sure if correctly or fast enough, I don’t have a good way to test it…):

https://github.com/mbedward/jaitools/pull/233

The main thing keeping that pull request at bay is that I’ve implemented it fully in my spare time, and it would require

manual testing… I was thinking to merge it right away after the new stable gets cut, which was supposed to be

soon enough, in order to gather feedback in the next dev cycle without causing troubles to this release.

Now, with this delay it would be tempting to merge it and release another version of jaitools,

but of course it also has the risk of adding more “late” changes, and thus potentially more instability.

I’ve also run the server and everythign starts up ok, but I haven’t poked it much harder than a quick smoke test.

There is one interesting thing that I found with spring security. The login and logout endpoints have changed. So “/j_spring_security_check" is now “/login” and “/j_spring_security_logout” is now “/logout”. I’m still unsure what the backwards compatability repercussions will be with this. It looks like those paths are configurable in some places (like if using annotation based config) but the way we are using some of the filters it didn’t look like they were. I was going to circle back to this.

Hum… thinking, don’t we have some javascript apps around using these endpoints to test authentication

when using a custom login form?

Yeah, I know of one app (geoexplorer) that uses one of the endpoints to create a session. One thought I had (if we can’t configure the endpoint paths) was to create a redirect from old to the new.

Ah, yep… not everything handles redirects seamlessly (maven anyone? :wink: ), but browsers should.

Cheers

Andrea

==

GeoServer Professional Services from the experts! Visit

http://goo.gl/it488V for more information.

==

Ing. Andrea Aime

@geowolf

Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313

fax: +39 0584 1660272

mob: +39 339 8844549

http://www.geo-solutions.it

http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.




Geoserver-devel mailing list

Geoserver-devel@anonymised.comsts.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/geoserver-devel



Geoserver-devel mailing list

Geoserver-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/geoserver-devel

I’ll also be on the GeoServer and GeoWebCache gitter channels while working on this in case we need realtime coordination.

Kevin Michael Smith

smithkm@anonymised.com

On Mon, Mar 7, 2016, at 01:36 PM, Kevin Smith wrote:

I had done the Servlet 3.0.1 update on Friday, but hadn’t committed it yet. I’ve merged spring-servlet-upgrade into spring4-upgrade to make sure we don’t loose anything. The conflicts were fairly simple to resolve and all unit tests are passing.

I’ll do some stand alone GWC testing to check if anything non-obvious has broken.

Kevin Michael Smith

smithkm@anonymised.com

On Sun, Mar 6, 2016, at 12:14 PM, Jody Garnett wrote:

Can we do some OS specific priority thing to avoid use of the native operations on OSX? They really are not around much anymore; very hard to find on the apple website etc…

We could document the result and add it to GeoTools init()

Jody Garnett

On 6 March 2016 at 12:10, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Sun, Mar 6, 2016 at 6:34 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

No failures in wms here (also made a fresh build of geotools to be on the safe side), do you have details?

I’ve made a full build and I have failures in the following extensions: CAS (expected), WPS, XSLT, monitoring hibernate… not all

that many in the end.

Assuming you’re not working on it right now, I’m going to have a quick look.

I’ve attached the failure trace I get from testCoverageViewMap(org.geoserver.wms.wms_1_1_1.GetMapIntegrationTest). I am pretty sure I have seen this failure before in my environment.

Aah… yeah, I know that beast. One quick solution is to remove the native JAI for OSX, it’s the only one using that

operation that is not implemented in JAITools ROIGeometry, and not used by the native jai for windows and linux (or the pure java jai).

The other option would be to put some more effort behind this pull request, in which I did implement the said method (although,

not sure if correctly or fast enough, I don’t have a good way to test it…):

https://github.com/mbedward/jaitools/pull/233

The main thing keeping that pull request at bay is that I’ve implemented it fully in my spare time, and it would require

manual testing… I was thinking to merge it right away after the new stable gets cut, which was supposed to be

soon enough, in order to gather feedback in the next dev cycle without causing troubles to this release.

Now, with this delay it would be tempting to merge it and release another version of jaitools,

but of course it also has the risk of adding more “late” changes, and thus potentially more instability.

I’ve also run the server and everythign starts up ok, but I haven’t poked it much harder than a quick smoke test.

There is one interesting thing that I found with spring security. The login and logout endpoints have changed. So “/j_spring_security_check" is now “/login” and “/j_spring_security_logout” is now “/logout”. I’m still unsure what the backwards compatability repercussions will be with this. It looks like those paths are configurable in some places (like if using annotation based config) but the way we are using some of the filters it didn’t look like they were. I was going to circle back to this.

Hum… thinking, don’t we have some javascript apps around using these endpoints to test authentication

when using a custom login form?

Yeah, I know of one app (geoexplorer) that uses one of the endpoints to create a session. One thought I had (if we can’t configure the endpoint paths) was to create a redirect from old to the new.

Ah, yep… not everything handles redirects seamlessly (maven anyone? :wink: ), but browsers should.

Cheers

Andrea

==

GeoServer Professional Services from the experts! Visit

http://goo.gl/it488V for more information.

==

Ing. Andrea Aime

@geowolf

Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313

fax: +39 0584 1660272

mob: +39 339 8844549

http://www.geo-solutions.it

http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.




Geoserver-devel mailing list

Geoserver-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/geoserver-devel



Geoserver-devel mailing list

Geoserver-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Transform Data into Opportunity.

Accelerate data analysis in your applications with

Intel Data Analytics Acceleration Library.

Click to learn more.

http://makebettercode.com/inteldaal-eval


Geoserver-devel mailing list

Geoserver-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/geoserver-devel

I compared a diff of the changes made to GWC to the unit test coverage and found two changes that hadn’t been covered. I’m rather pleasantly surprised given how spotty test coverage in GWC can be. One change was in the Metastore Remover which is used in upgrades from 1.3.x or earlier and the other was in the getModifiableParameters method of the TileLayer class.

I did an ad hoc test of upgrading from 1.3 to 1.9 and it worked fine, and I added a unit test to cover getModifiableParameters which is passing.

On the GWC front, that still leaves upgrading Acegi Security 1.0.7 to Spring Security 4.0.4. They do use different namespaces so I suppose we don’t need to keep in sync with GeoServer here and Acegi seems to be working with Spring 4.2.5, but if there’s one thing we really shouldn’t be using such an ancient library for, it’s security.

Kevin Michael Smith

smithkm@anonymised.com

On Mon, Mar 7, 2016, at 05:18 PM, Kevin Smith wrote:

I’ll also be on the GeoServer and GeoWebCache gitter channels while working on this in case we need realtime coordination.

Kevin Michael Smith

smithkm@anonymised.com

On Mon, Mar 7, 2016, at 01:36 PM, Kevin Smith wrote:

I had done the Servlet 3.0.1 update on Friday, but hadn’t committed it yet. I’ve merged spring-servlet-upgrade into spring4-upgrade to make sure we don’t loose anything. The conflicts were fairly simple to resolve and all unit tests are passing.

I’ll do some stand alone GWC testing to check if anything non-obvious has broken.

Kevin Michael Smith

smithkm@anonymised.com

On Sun, Mar 6, 2016, at 12:14 PM, Jody Garnett wrote:

Can we do some OS specific priority thing to avoid use of the native operations on OSX? They really are not around much anymore; very hard to find on the apple website etc…

We could document the result and add it to GeoTools init()

Jody Garnett

On 6 March 2016 at 12:10, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Sun, Mar 6, 2016 at 6:34 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

No failures in wms here (also made a fresh build of geotools to be on the safe side), do you have details?

I’ve made a full build and I have failures in the following extensions: CAS (expected), WPS, XSLT, monitoring hibernate… not all

that many in the end.

Assuming you’re not working on it right now, I’m going to have a quick look.

I’ve attached the failure trace I get from testCoverageViewMap(org.geoserver.wms.wms_1_1_1.GetMapIntegrationTest). I am pretty sure I have seen this failure before in my environment.

Aah… yeah, I know that beast. One quick solution is to remove the native JAI for OSX, it’s the only one using that

operation that is not implemented in JAITools ROIGeometry, and not used by the native jai for windows and linux (or the pure java jai).

The other option would be to put some more effort behind this pull request, in which I did implement the said method (although,

not sure if correctly or fast enough, I don’t have a good way to test it…):

https://github.com/mbedward/jaitools/pull/233

The main thing keeping that pull request at bay is that I’ve implemented it fully in my spare time, and it would require

manual testing… I was thinking to merge it right away after the new stable gets cut, which was supposed to be

soon enough, in order to gather feedback in the next dev cycle without causing troubles to this release.

Now, with this delay it would be tempting to merge it and release another version of jaitools,

but of course it also has the risk of adding more “late” changes, and thus potentially more instability.

I’ve also run the server and everythign starts up ok, but I haven’t poked it much harder than a quick smoke test.

There is one interesting thing that I found with spring security. The login and logout endpoints have changed. So “/j_spring_security_check" is now “/login” and “/j_spring_security_logout” is now “/logout”. I’m still unsure what the backwards compatability repercussions will be with this. It looks like those paths are configurable in some places (like if using annotation based config) but the way we are using some of the filters it didn’t look like they were. I was going to circle back to this.

Hum… thinking, don’t we have some javascript apps around using these endpoints to test authentication

when using a custom login form?

Yeah, I know of one app (geoexplorer) that uses one of the endpoints to create a session. One thought I had (if we can’t configure the endpoint paths) was to create a redirect from old to the new.

Ah, yep… not everything handles redirects seamlessly (maven anyone? :wink: ), but browsers should.

Cheers

Andrea

==

GeoServer Professional Services from the experts! Visit

http://goo.gl/it488V for more information.

==

Ing. Andrea Aime

@geowolf

Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313

fax: +39 0584 1660272

mob: +39 339 8844549

http://www.geo-solutions.it

http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.




Geoserver-devel mailing list

Geoserver-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/geoserver-devel



Geoserver-devel mailing list

Geoserver-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Transform Data into Opportunity.

Accelerate data analysis in your applications with

Intel Data Analytics Acceleration Library.

Click to learn more.

http://makebettercode.com/inteldaal-eval


Geoserver-devel mailing list

Geoserver-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Transform Data into Opportunity.

Accelerate data analysis in your applications with

Intel Data Analytics Acceleration Library.

Click to learn more.

http://makebettercode.com/inteldaal-eval


Geoserver-devel mailing list

Geoserver-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/geoserver-devel