[Geoserver-devel] jai-ext initialisation

GeoServer GeoServer Developer
1

Hello,

I discovered an issue with JAI-ext that concerns both geotools and geoserver.

Currently I noticed that the JAIExt.initJAIEXT method (the initialisation of jai-ext) is called from a static block in geotools:

https://github.com/geotools/geotools/blob/master/modules/library/coverage/src/main/java/org/geotools/image/ImageWorker.java#L182

However, in Geoserver, the following line potentially wipes clean all jai-ext operations by assuming a regular JAI registry is needed :

https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/GeoserverInitStartupListener.java#L123

In GeoServer, the GeoserverInitStartupListener is apparently called by the web context before the static clause. So there is no problem.

However, I believe this is just a fluke, there is absolutely no guarantee that it happens in that order. We currently are working on a project that is built on top of geoserver where the two things happen in the opposite order. In this project, the JAI-EXT configuration is wiped clean. And we needed a hack to explicitly reinitialise JAI-ext a second time.

I do think that this is a bit of dodgy situation in general.

Regards,
Niels

2

On Fri, Dec 9, 2016 at 5:40 PM, Niels Charlier <niels@anonymised.com> wrote:

I do think that this is a bit of dodgy situation in general.

Thank you for the non constructive criticism. Maybe try again with some
suggestion on how to improve the situation instead?

Regards
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.

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

3

On 10/12/16 09:07, Andrea Aime wrote:

On Fri, Dec 9, 2016 at 5:40 PM, Niels Charlier <niels@anonymised.com> wrote:

I do think that this is a bit of dodgy situation in general.

I think this was a fair comment.

I have dealt with at least three other examples where the decoupled nature of GeoTools classes (a good practice) makes it difficult to orchestrate collections of these classes when they are composed in a larger application:

- app-schema data access coordination through a static data access registry to permit the implementation of feature chaining

- Schema caching, originally from app-schema, in which one class has magic behaviour, searching nearby directories to see if code is running in GeoServer (I feel so dirty)

- A new feature I am prototyping, NcML templates, in which NetCDF data stores will share an optional template resource

In my view, each of these is caused by the strong decoupling of features in GeoTools and the lack of an API for injecting shared managers/registries into GeoTools. Many implementations resort to static initialisers to make sure they work both in GeoTools and when composed in a larger application. These solutions seem to be less testable and harder to compose.

Andrea, I would appreciate your view on whether GeoTools could benefit from some sort of configuration API. I know little about JAI and JAIExt, but could a configuration API be used to inject some sort of manager into GeoTools? Or do dependencies and cycles mean we will end up reinventing Spring?

Kind regards,

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/&gt;
New Zealand

4

On Fri, Dec 9, 2016 at 10:19 PM, Ben Caradoc-Davies <ben@anonymised.com>
wrote:

I think this was a fair comment.

Our community provided a guideline as to what constructive criticism is,
that is not, it's simply criticism (without the constructive part).

The voting guidelines for anything are clear, one can vote -1 but only
providing alternative paths, while this is of course just a random
discussion
the expected approach would be the same, simply venting out criticism does
not help anybody, besides maybe make the
one writing the mail feel better.

I can understand the frustration of someone that did not put the
GeoServerInitStartupListener
as the very first thing running at JVM startup, forgetting or being unable
to do so is going to cause a lot of frustrating debugging (not just for JAI
but for other aspects as well), however simple complaints are of no help to
anyone.

Andrea, I would appreciate your view on whether GeoTools could benefit
from some sort of configuration API. I know little about JAI and JAIExt,
but could a configuration API be used to inject some sort of manager into
GeoTools? Or do dependencies and cycles mean we will end up reinventing
Spring?

I don't have a view on this problem, haven't been bit by it significantly
and/or when it happened, I could only blame myself
and did not have resource to propose an actual improvement along with the
resources to implement it
(typical case, forgetting to set the axis order hints right on startup).

Just an observation, initialization of JAI is an issue of itself, something
like setting up the registry needs to be done
at startup, very first thing, so some control over init order is necessary
there, what provides this control depends on the technology
used to write the application and its context (command line, OSGI, servlet,
aws lambda), but I'm skeptical that is actually a GeoTools
problem to solve (we'd have to marry some specific class wiring solution).

The highly dynamic nature of JAI (dynamic registry, priorities, anything
swappable at any time, but not without side effects) makes it
hard to deal with, especially today that we have replaced most parts of it.
If we ever get to rewrite it, the new version could
use some lessons learned to avoid some of these issues (e.g., it could
disallow changing the registry past a certain init point).

Regards
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.

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

5

Hello,

I think this is a misunderstanding. I did not intend my email as a complaint or criticism (and especially not to make myself “feel better”, I don’t see it that way at all). It was merely intended as an entirely neutral issue report, like “hey, I found this thing that seemed to have slipped in to our project that is something for all of us to look at and think about”.

Perhaps “dodgy” was a poor word choice, but all I meant with that particular sentence was “despite the fact that this isn’t causing any major issues for anyone, it is still a potential loophole and a situation we should maybe consider improving /either way/”. By no means I was pointing the finger at a particular person(s), I think these things just happen in a project like ours and I wanted to report it. That is my honest opinion about it, and that is honestly all that what was on my mind when I wrote that email.

And yes, I am absolutely more than willing to think along for solutions. But I didn’t have any solutions yet and I felt I needed more information first, or to study it better, and I thought I’d report it in the meantime as a open question, invite some brainstorming (as Ben did). Sometimes other people know things of the top of their heads that they can respond immediately that saves me a lot of time finding out, so that is why I send an email before I have a solution. I guess that I should have written more specific questions in my email rather than ending with the “dodgy” comment. I do apologise for my poor communication in that regard, which can be explained by the fact that I wrote it at the end of my workday (next time, I’ll keep it for the beginning of the next and take the time to ask specific questions). I hope that clears it up.

I do like Ben’s suggestions, but of course he is looking at the broader picture, and particularly from the geotools side. I think any way we can get rid of static code in geotools would be an improvement.

I have another question though - why is geoserver doing this thing in GeoServerInitStartupListener? I’m not just asking about the place it is doing, why is it doing this at all? What was the original idea behind it and does it still count? I think ImageWorker is on the classpath of geoserver in any case, so whether it does its own JAI initialisation before or after ImageWorker, it seems pointless. Or am I wrong?

Kind Regards

Niels

···

On 12/10/2016 10:48 AM, Andrea Aime wrote:

On Fri, Dec 9, 2016 at 10:19 PM, Ben Caradoc-Davies <ben@anonymised.com> wrote:

I think this was a fair comment.

Our community provided a guideline as to what constructive criticism is, that is not, it’s simply criticism (without the constructive part).

The voting guidelines for anything are clear, one can vote -1 but only providing alternative paths, while this is of course just a random discussion
the expected approach would be the same, simply venting out criticism does not help anybody, besides maybe make the
one writing the mail feel better.

I can understand the frustration of someone that did not put the GeoServerInitStartupListener
as the very first thing running at JVM startup, forgetting or being unable to do so is going to cause a lot of frustrating debugging (not just for JAI
but for other aspects as well), however simple complaints are of no help to anyone.

Andrea, I would appreciate your view on whether GeoTools could benefit from some sort of configuration API. I know little about JAI and JAIExt, but could a configuration API be used to inject some sort of manager into GeoTools? Or do dependencies and cycles mean we will end up reinventing Spring?

I don’t have a view on this problem, haven’t been bit by it significantly and/or when it happened, I could only blame myself
and did not have resource to propose an actual improvement along with the resources to implement it
(typical case, forgetting to set the axis order hints right on startup).

Just an observation, initialization of JAI is an issue of itself, something like setting up the registry needs to be done
at startup, very first thing, so some control over init order is necessary there, what provides this control depends on the technology
used to write the application and its context (command line, OSGI, servlet, aws lambda), but I’m skeptical that is actually a GeoTools
problem to solve (we’d have to marry some specific class wiring solution).

The highly dynamic nature of JAI (dynamic registry, priorities, anything swappable at any time, but not without side effects) makes it
hard to deal with, especially today that we have replaced most parts of it. If we ever get to rewrite it, the new version could
use some lessons learned to avoid some of these issues (e.g., it could disallow changing the registry past a certain init point).

Regards
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.

6

2 cents:

···

Andrea, I would appreciate your view on whether GeoTools could benefit
from some sort of configuration API. I know little about JAI and JAIExt,
but could a configuration API be used to inject some sort of manager
into GeoTools? Or do dependencies and cycles mean we will end up
reinventing Spring?

We do have a very limited configuration API - the GeoTools class allows some configuration. We also have a problem to solve - rewriting ServiceRegistery for Java 9 that may dig into this question.

7

On Mon, Dec 12, 2016 at 1:58 PM, Niels Charlier <niels@anonymised.com> wrote:

I have another question though - why is geoserver doing this thing in
GeoServerInitStartupListener? I'm not just asking about the place it is
doing, why is it doing this at all? What was the original idea behind it
and does it still count? I think ImageWorker is on the classpath of
geoserver in any case, so whether it does its own JAI initialisation before
or after ImageWorker, it seems pointless. Or am I wrong?

For most things I believe there is no obvious/simple alternative to
performing certain inits as the very first action while the app starts up.

Let's have a look line by line:

   - GeoTools initialization, that needs to be done very first thing to
   avoid losing logging and JAI logs, https://github.com/
   geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/
   GeoserverInitStartupListener.java#L85
   <https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/GeoserverInitStartupListener.java#L85&gt;
   - Avoid logs on standard error in JAI, also needs to be done first, or
   we might get some spurious logs during system init, https://github.com/
   geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/
   GeoserverInitStartupListener.java#L88
   <https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/GeoserverInitStartupListener.java#L88&gt;
   - Setting up JAI alternative registry and tile cache, yep, also needs to
   be done very first thing, if not you already know what the consequences
   are: https://github.com/geoserver/geoserver/blob/
   master/src/main/src/main/java/org/geoserver/GeoserverInitStartupListener.
   java#L121
   <https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/GeoserverInitStartupListener.java#L121&gt;
   Not setting up these two at all will have dire scalability and runtime
   consequences, either under high load or in certain conditions (e.g., highly
   oversampled requests)
   - Forcing axis order, also needs to be done before anything starts using
   the CRS factories or the order won't be the expected one,
   https://github.com/geoserver/geoserver/blob/
   master/src/main/src/main/java/org/geoserver/GeoserverInitStartupListener.
   java#L141
   <https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/GeoserverInitStartupListener.java#L141&gt;
   This could actually be avoided by applying everywhere the same changes
   you just proposed in the geopackage module, and that would be applied in
   several other places as well, plus changing the axis order logic in WMS
   1.3, in WFS, in the GML encoder, and so on... doable, not sure anyone is
   willing to spend days to chase all the points where this happens, and then
   discoverer 6 months later that a few have been missed (not to mention, the
   effect on plugins that are not in the GeoTools/GeoServer source trees,
   those would have to be updated too).
   Anyways, worth pursuing imho, just hard to fund.
   - The rest of the inits in that method are also needed to be done very
   first thing, but are a bit less obvious to explain. Suffice it to say that
   not doing those will have other adverse effects, either functional,
   performance or availability related

The JAI initializations should not be moved to the ImageWorker for the
simple reason that not everything uses the ImageWorker, and its
initializations are specific to a few operations... if anything, I'd move
the ImageWorker inits somewhere else instead. However there is no obvious
place at the moment, GeoTools.init would not have the necessary classes in
the classpath.
_Maybe_ a plugin system could be developed to allow per module inits that
would be called as GeoTools.init is called.... still, people would have to
remember to call it.

Not all use cases will need all the inits that GeoServer is performing, a
desktop application will likely not need several of them (several of the
JAI related ones) and under different conditions, different registries and
tile caches (we have done several times in GeoSolutions to adapt to the
specific environment requirements).

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 <+39%200584%20962313>
fax: +39 0584 1660272 <+39%200584%20166%200272>
mob: +39 339 8844549 <+39%20339%20884%204549>

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.

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

8

Hello Andrea,

I definitely wouldn't want to move all initialisation code to static, if anything I'd prefer moving things the other way as Ben suggested.

My question was rather about those specific lines of code (initialising the OperationRegistry). My assumption was ImageWorker was going to be on the class path anyway, but you have answered my question by saying that this is not actually the case.

However, it appears that jai-ext is on the classpath of gs-main in any case. At least the following small patch could be an improvement that would prevent the issue we came across without the need for double initialisation of jai-ext:

https://github.com/geoserver/geoserver/pull/2032/

Does that make sense?

For the rest, I think it is an interesting discussion for the long run to think of a more structured way to initialise geotools.

Kind Regards
Niels

On 14-12-16 15:55, Andrea Aime wrote:

On Mon, Dec 12, 2016 at 1:58 PM, Niels Charlier <niels@anonymised.com <mailto:niels@anonymised.com>> wrote:

    I have another question though - why is geoserver doing this thing
    in GeoServerInitStartupListener? I'm not just asking about the
    place it is doing, why is it doing this at all? What was the
    original idea behind it and does it still count? I think
    ImageWorker is on the classpath of geoserver in any case, so
    whether it does its own JAI initialisation before or after
    ImageWorker, it seems pointless. Or am I wrong?

For most things I believe there is no obvious/simple alternative to performing certain inits as the very first action while the app starts up.

Let's have a look line by line:

  * GeoTools initialization, that needs to be done very first thing to
    avoid losing logging and JAI logs,
    https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/GeoserverInitStartupListener.java#L85
    <https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/GeoserverInitStartupListener.java#L85&gt;
  * Avoid logs on standard error in JAI, also needs to be done first,
    or we might get some spurious logs during system init,
    https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/GeoserverInitStartupListener.java#L88
    <https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/GeoserverInitStartupListener.java#L88&gt;
  * Setting up JAI alternative registry and tile cache, yep, also
    needs to be done very first thing, if not you already know what
    the consequences are:
    https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/GeoserverInitStartupListener.java#L121
    <https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/GeoserverInitStartupListener.java#L121&gt;
    Not setting up these two at all will have dire scalability and
    runtime consequences, either under high load or in certain
    conditions (e.g., highly oversampled requests)
  * Forcing axis order, also needs to be done before anything starts
    using the CRS factories or the order won't be the expected one,
    https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/GeoserverInitStartupListener.java#L141
    <https://github.com/geoserver/geoserver/blob/master/src/main/src/main/java/org/geoserver/GeoserverInitStartupListener.java#L141&gt;
    This could actually be avoided by applying everywhere the same
    changes you just proposed in the geopackage module, and that would
    be applied in several other places as well, plus changing the axis
    order logic in WMS 1.3, in WFS, in the GML encoder, and so on...
    doable, not sure anyone is willing to spend days to chase all the
    points where this happens, and then discoverer 6 months later that
    a few have been missed (not to mention, the effect on plugins that
    are not in the GeoTools/GeoServer source trees, those would have
    to be updated too).
    Anyways, worth pursuing imho, just hard to fund.
  * The rest of the inits in that method are also needed to be done
    very first thing, but are a bit less obvious to explain. Suffice
    it to say that not doing those will have other adverse effects,
    either functional, performance or availability related

The JAI initializations should not be moved to the ImageWorker for the simple reason that not everything uses the ImageWorker, and its initializations are specific to a few operations... if anything, I'd move the ImageWorker inits somewhere else instead. However there is no obvious place at the moment, GeoTools.init would not have the necessary classes in the classpath.
_Maybe_ a plugin system could be developed to allow per module inits that would be called as GeoTools.init is called.... still, people would have to remember to call it.

Not all use cases will need all the inits that GeoServer is performing, a desktop application will likely not need several of them (several of the JAI related ones) and under different conditions, different registries and tile caches (we have done several times in GeoSolutions to adapt to the specific environment requirements).

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 <tel:+39%200584%20962313>
fax: +39 0584 1660272 <tel:+39%200584%20166%200272>
mob: +39 339 8844549 <tel:+39%20339%20884%204549>

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.

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