[Geoserver-devel] GSIP-136 Resource Notification Dispatcher

Jody,

your ROOT ResourceListener Alternative would work but could unnecessary notifications. I think your original proposal is superior.

I also have a new question about your original proposal:

Would Resource.getListeners and Resource.removeAllListeners help discover and manage listeners from code that does not retain a reference to listeners? Or would this break responsibility boundaries in which the subscriber retains a reference to the listener and only it should unsubscribe?

Kind regards,
Ben.

On 16/01/16 10:26, Jody Garnett wrote:

I have updated the proposal:
https://github.com/geoserver/geoserver/wiki/GSIP-136

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

Does it make sense that the proposal gets rejected with only +1 and 0 votes? If people are saying 0 it means that they don’t particularly care one way or the other. Normally in elections, parliaments and referenda you only need half of the non-neutral votes, with a minimum participation threshold for the vote to be valid.

Regards
Niels

···

On 01/15/2016 10:26 PM, Jody Garnett wrote:

This is a bit awkward as process is rejecting the proposal due to lack of participation, leaving a rejected proposal and no clear way forward. We could take that the proposal was not sufficiently clear (ie quick to read) and revise and submit again … but I am really not interested in running around in circles, or revising our process beyond making it consistent, at this time.

The GeoTools process has a 15 day time limit to prevent deadlock due to “lack of interest/time” from the community - thus far we have not needed this kind of thing for GeoServer.

… thinking …

I have updated the proposal: https://github.com/geoserver/geoserver/wiki/GSIP-136 including the following single sentence overview:

Create an ResourceNotificationDispatcher API, to inject into the ResourceStore implementation allowing dispatch of event notification to be handled differently for a clustered environment.

I also note that Simone has not responded yet, if he votes +1 Ben will get his 50% :slight_smile: I have also documented the alternative proposed in email, it can work as a fallback plan for Niels that does not require an API change.


Jody Garnett

On 15 January 2016 at 11:51, Ben Caradoc-Davies <ben@anonymised.com> wrote:

Jody,

I also like +0/-0, but I think that these votes should be counted as the same.

As the PSC has grown (in terms of active members), was it our intent that we need more +1 votes to accept a GSIP to reach a majority? One consequence is that this GSIP was in effect rejected by the 0 votes of voting members who did not oppose the proposal, diluting the majority that the GSIP had achieved before Jody encouraged PSC members to vote (which was a good thing in itself). If these 0-voting PSC members had ignored the vote, the GSIP would have been accepted. This GSIP was rejected by diligent conformance to process.

We might consider changing the process success to define success by (for example) three +1 votes and no -1 votes, like the rules for GeoTools commit access (but with only PSC members voting).

Should change require support from a minimum number of PSC members, or should change as is now the case require active support from a (simple) majority of the PSC?

Kind regards,
Ben.

On 16/01/16 06:02, Jody Garnett wrote:

I do not want to get too hung up on words, the quick take is the PSC does
not have enough capacity to review the proposal at the moment so we should
wait. The GeoServer process does not have a time limit like the GeoTools
one.

I like +0 and -0 as that provides a way for people who have not had time to
provide their “rough feeling” about the topic.

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

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
[http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140](http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140)
_______________________________________________
Geoserver-devel mailing list
[Geoserver-devel@lists.sourceforge.net](mailto:Geoserver-devel@lists.sourceforge.net)
[https://lists.sourceforge.net/lists/listinfo/geoserver-devel](https://lists.sourceforge.net/lists/listinfo/geoserver-devel)

Niels,

our voting procedure makes no sense to me. The perverse outcome in this vote has made that clear to me. I would like to change our voting procedure to require three +1 votes and no -1 votes for a GSIP to succeed. That should have a similar effect to requiring a quorum and a simple majority but without the unintended impact of 0 votes.

Kind regards,
Ben.

On 17/01/16 12:31, Niels Charlier wrote:

Does it make sense that the proposal gets rejected with only +1 and 0
votes? If people are saying 0 it means that they don't particularly care
one way or the other. Normally in elections, parliaments and referenda
you only need half of the non-neutral votes, with a minimum
participation threshold for the vote to be valid.

Regards
Niels

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

I agree with Ben, when I voted 0 it was simply to indicate I was aware of the GISP but was busy all week with work and so couldn’t review it and didn’t want to hold things up. I confess I hadn’t read the GeoServer voting rules and assumed they were the same as the GeoTools rules. Had I realised that it would be more supportive to not vote than to vote 0 I would have ignored the call to vote :slight_smile:

Ian

···

On 17 January 2016 at 01:14, Ben Caradoc-Davies <ben@anonymised.com> wrote:

Niels,

our voting procedure makes no sense to me. The perverse outcome in this
vote has made that clear to me. I would like to change our voting
procedure to require three +1 votes and no -1 votes for a GSIP to
succeed. That should have a similar effect to requiring a quorum and a
simple majority but without the unintended impact of 0 votes.

Kind regards,
Ben.

On 17/01/16 12:31, Niels Charlier wrote:

Does it make sense that the proposal gets rejected with only +1 and 0
votes? If people are saying 0 it means that they don’t particularly care
one way or the other. Normally in elections, parliaments and referenda
you only need half of the non-neutral votes, with a minimum
participation threshold for the vote to be valid.

Regards
Niels


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


Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140


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

Ian Turton

Hi Ian,
my take on the 0 vote was the same, I just had no time to look into it and did not want to block it.
However, there is something to be said about a proposal that is not getting anybody’s attention… I see it as a red flag,
maybe it’s about something that did not deserve a proposal, or maybe something too niche?
In this case I believe it was just too close to a codesprint and people were busy closing up work stuff before leaving
(at least that was my case).

The main issue with proposals with too much “0, did not look at it” is that it could get in something really bad
just because nobody checked it seriously… that would be bad.

That said, I’m looking at the proposal right now, so hopefully this will put this long thread to rest :-p

Cheers
Andrea

···

On Sun, Jan 17, 2016 at 3:10 AM, Ian Turton <ijturton@anonymised.com> wrote:

I agree with Ben, when I voted 0 it was simply to indicate I was aware of the GISP but was busy all week with work and so couldn’t review it and didn’t want to hold things up. I confess I hadn’t read the GeoServer voting rules and assumed they were the same as the GeoTools rules. Had I realised that it would be more supportive to not vote than to vote 0 I would have ignored the call to vote :slight_smile:

Ian


Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140


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

On 17 January 2016 at 01:14, Ben Caradoc-Davies <ben@anonymised.com> wrote:

Niels,

our voting procedure makes no sense to me. The perverse outcome in this
vote has made that clear to me. I would like to change our voting
procedure to require three +1 votes and no -1 votes for a GSIP to
succeed. That should have a similar effect to requiring a quorum and a
simple majority but without the unintended impact of 0 votes.

Kind regards,
Ben.

On 17/01/16 12:31, Niels Charlier wrote:

Does it make sense that the proposal gets rejected with only +1 and 0
votes? If people are saying 0 it means that they don’t particularly care
one way or the other. Normally in elections, parliaments and referenda
you only need half of the non-neutral votes, with a minimum
participation threshold for the vote to be valid.

Regards
Niels


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


Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140


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

Ian Turton

==
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 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

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.


Hi Jody,
I’ve just had a quick conversation with you about the proposal and we discussed it,
now I’m sharing my feedback with the rest of the community.

Personally, I find it redundant that there is and add/remove listener method in both
the resource and the store, given that the Resource can be created out of a non
yet existing file/directory, I would be happy about just having the methods in the resource
itself, maybe with some javadoc explaining that it’s ok to to listen to a non yet existing
resource yet (one will get events if the resource pop up in existence).

I’m also looking at the API and wondering where’s the recursive behavior. You told
me it’s part of the pre-existing behavior, and I’ve checked ResourceListener/ResourceNotification,
but the best I could find is in ResourceNotification stating:

“Listeners on a directory will be notified on any resource change in the directory. The delta will include any modified directories”

Still does not tell me if the notification is about directly children of the directory, or if includes
also all sub-directories at all levels. I was looking at Java 7 file watching API and the tutorial states that
if you want to watch and entire file tree, you have to register a watcher for each and every directory in
it.
I was actually looking at how FileSystemWatcher is implemented, I’m not seeing any recursive
behavior (and it’s not using java 7 file watching api either, it’s polling), so I mean, not sure
this is actually going to work correctly in recursive mode… if anything, it seems to be working
at single level… which would mean there is no way to “watch everything”. Fair enough,
but then the API should be clear and the proposal too about it :slight_smile:

Final feedback, if you want to be up front that there is a central notification hub,
imho, better to remove the add/remove listener methods from the store, and
add a getResourceNotificationDispatcher/setResourceNotificationDispatcher
at the ResourceStore level instead: this would make it evident that there is a centralized
one, and offer an opportunity to programmatically plug in a custom one (for clusters).
Though… hum… thinking out loud, for standard vs non standard implementations
of a interface, we normally go for a “lookup in spring, if none is found, instantiate a
default one programmatically approach”. Which would be fine for this case too, just
document it (and describe it in the proposal)

Sorry it’s not a +1 yet, at the moment the proposal is leaving me with questions :slight_smile:

Cheers
Andrea

···

On Wed, Jan 6, 2016 at 6:46 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

This is a follow up to pull request #1361 introducing some new public API:

https://github.com/geoserver/geoserver/wiki/GSIP-136

Niels I have changed your proposed interface a bit, to use paths rather than a resource when adding/removing listeners.


Jody Garnett



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

==
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 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

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 18/01/16 10:54, Andrea Aime wrote:

Sorry it's not a +1 yet, at the moment the proposal is leaving me with
questions :slight_smile:

Thanks very much, Andrea. Your questions are much more useful than any vote!

Kind regards,

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

Agreed, proposal is a tool for discussion and resolution.

Java7FileWatcher - yeah we upgraded to Java 7 right as the ResourceStore API was being written so I made the internal FileWatcher class compatible - so if it listens to things a directory at a time that is probably what I did as well:

Resource.addListener( listener ) has:

Listeners can be configured to check for changes to individual files or directory contents.

  • styles: listener receives events for any change to the contents of the styles directory
  • user_projections/epsg.properties: listener notified for any change to the epsg.properties resource

Notification is course grained, often just based on change of last modified time stamp, as such they are issued after the change has been performed.

I also like your suggestion for a get/set ResourceNotificationDispatcher which better communicates intent.

···

On 17 January 2016 at 13:54, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi Jody,
I’ve just had a quick conversation with you about the proposal and we discussed it,
now I’m sharing my feedback with the rest of the community.

Personally, I find it redundant that there is and add/remove listener method in both
the resource and the store, given that the Resource can be created out of a non
yet existing file/directory, I would be happy about just having the methods in the resource
itself, maybe with some javadoc explaining that it’s ok to to listen to a non yet existing
resource yet (one will get events if the resource pop up in existence).

I’m also looking at the API and wondering where’s the recursive behavior. You told
me it’s part of the pre-existing behavior, and I’ve checked ResourceListener/ResourceNotification,
but the best I could find is in ResourceNotification stating:

“Listeners on a directory will be notified on any resource change in the directory. The delta will include any modified directories”

Still does not tell me if the notification is about directly children of the directory, or if includes
also all sub-directories at all levels. I was looking at Java 7 file watching API and the tutorial states that
if you want to watch and entire file tree, you have to register a watcher for each and every directory in
it.
I was actually looking at how FileSystemWatcher is implemented, I’m not seeing any recursive
behavior (and it’s not using java 7 file watching api either, it’s polling), so I mean, not sure
this is actually going to work correctly in recursive mode… if anything, it seems to be working
at single level… which would mean there is no way to “watch everything”. Fair enough,
but then the API should be clear and the proposal too about it :slight_smile:

Final feedback, if you want to be up front that there is a central notification hub,
imho, better to remove the add/remove listener methods from the store, and
add a getResourceNotificationDispatcher/setResourceNotificationDispatcher
at the ResourceStore level instead: this would make it evident that there is a centralized
one, and offer an opportunity to programmatically plug in a custom one (for clusters).
Though… hum… thinking out loud, for standard vs non standard implementations
of a interface, we normally go for a “lookup in spring, if none is found, instantiate a
default one programmatically approach”. Which would be fine for this case too, just
document it (and describe it in the proposal)

Sorry it’s not a +1 yet, at the moment the proposal is leaving me with questions :slight_smile:

Cheers

Andrea


Jody Garnett

On Wed, Jan 6, 2016 at 6:46 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:

This is a follow up to pull request #1361 introducing some new public API:

https://github.com/geoserver/geoserver/wiki/GSIP-136

Niels I have changed your proposed interface a bit, to use paths rather than a resource when adding/removing listeners.


Jody Garnett



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

==
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 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

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.


Ben I noticed ResourceNotificationDispatcher is now available on master - was that accidentally merged?

···

On 17 January 2016 at 14:01, Ben Caradoc-Davies <ben@anonymised.com> wrote:

On 18/01/16 10:54, Andrea Aime wrote:

Sorry it’s not a +1 yet, at the moment the proposal is leaving me with
questions :slight_smile:

Thanks very much, Andrea. Your questions are much more useful than any vote!

Kind regards,


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


Jody Garnett

Sorry, yes it was, be me. I mistakenly assumed that all the GSIP-136 changes were isolated to the last two commits of PR #1361, but the addition of this interface and the implementation SimpleResourceNotificationDispatcher were included in an earlier commit. We will need to refactor it to match the final decision on GSIP-136.

Kind regards,
Ben.

On 18/01/16 12:55, Jody Garnett wrote:

Ben I noticed ResourceNotificationDispatcher
<https://github.com/geoserver/geoserver/blob/master/src/platform/src/main/java/org/geoserver/platform/resource/ResourceNotificationDispatcher.java&gt;
is
now available on master - was that accidentally merged?

--
Jody Garnett

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

Niels - do you mind if I gather up the result of this email thread and update the proposal - or would you like to?

On Sun, Jan 17, 2016 at 4:05 PM Ben Caradoc-Davies <ben@anonymised.com> wrote:

Sorry, yes it was, be me. I mistakenly assumed that all the GSIP-136
changes were isolated to the last two commits of PR #1361, but the
addition of this interface and the implementation
SimpleResourceNotificationDispatcher were included in an earlier commit.
We will need to refactor it to match the final decision on GSIP-136.

Kind regards,
Ben.

On 18/01/16 12:55, Jody Garnett wrote:

Ben I noticed ResourceNotificationDispatcher
<https://github.com/geoserver/geoserver/blob/master/src/platform/src/main/java/org/geoserver/platform/resource/ResourceNotificationDispatcher.java>
is
now available on master - was that accidentally merged?


Jody Garnett


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


Jody Garnett

And it might be best to clean up after me by cherry-picking the two commits that were left on PR #1361 (with GSIP-136 in their title) onto master.
https://github.com/NielsCharlier/geoserver/commit/c28e8ddbbbaaa19ec697210ae6da696877e9af1d
https://github.com/NielsCharlier/geoserver/commit/0219db6e784f06b533e1c9b7840751129cf72347

The current state is Niels' original draft API before Jody's review, and the two commits are the diff from Niels' original to GSIP-136. Again, sorry about that. At least we are done with that monstrous pull request.

Kind regards,
Ben.

On 18/01/16 14:39, Jody Garnett wrote:

Niels - do you mind if I gather up the result of this email thread and
update the proposal - or would you like to?
On Sun, Jan 17, 2016 at 4:05 PM Ben Caradoc-Davies <ben@anonymised.com> wrote:

Sorry, yes it was, be me. I mistakenly assumed that all the GSIP-136
changes were isolated to the last two commits of PR #1361, but the
addition of this interface and the implementation
SimpleResourceNotificationDispatcher were included in an earlier commit.
We will need to refactor it to match the final decision on GSIP-136.

Kind regards,
Ben.

On 18/01/16 12:55, Jody Garnett wrote:

Ben I noticed ResourceNotificationDispatcher
<

https://github.com/geoserver/geoserver/blob/master/src/platform/src/main/java/org/geoserver/platform/resource/ResourceNotificationDispatcher.java

is
now available on master - was that accidentally merged?

--
Jody Garnett

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

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

Thanks Ben, I'll make a new PR as soon as we figured out the proposal

Cheers
Niels

On 01/17/2016 06:18 PM, Ben Caradoc-Davies wrote:

And it might be best to clean up after me by cherry-picking the two
commits that were left on PR #1361 (with GSIP-136 in their title) onto
master.
https://github.com/NielsCharlier/geoserver/commit/c28e8ddbbbaaa19ec697210ae6da696877e9af1d
https://github.com/NielsCharlier/geoserver/commit/0219db6e784f06b533e1c9b7840751129cf72347

The current state is Niels' original draft API before Jody's review, and
the two commits are the diff from Niels' original to GSIP-136. Again,
sorry about that. At least we are done with that monstrous pull request.

Kind regards,
Ben.

On 18/01/16 14:39, Jody Garnett wrote:

Niels - do you mind if I gather up the result of this email thread and
update the proposal - or would you like to?
On Sun, Jan 17, 2016 at 4:05 PM Ben Caradoc-Davies <ben@anonymised.com> wrote:

Sorry, yes it was, be me. I mistakenly assumed that all the GSIP-136
changes were isolated to the last two commits of PR #1361, but the
addition of this interface and the implementation
SimpleResourceNotificationDispatcher were included in an earlier commit.
We will need to refactor it to match the final decision on GSIP-136.

Kind regards,
Ben.

On 18/01/16 12:55, Jody Garnett wrote:

Ben I noticed ResourceNotificationDispatcher
<

https://github.com/geoserver/geoserver/blob/master/src/platform/src/main/java/org/geoserver/platform/resource/ResourceNotificationDispatcher.java

is
now available on master - was that accidentally merged?

--
Jody Garnett

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

This change is fine by me, my original idea was to keep the API as unaffected as possible and keep the dispatcher something running in the background, optionally.

But - that means that the FileSystemRS also will need a ResourceNotificationDispatcher.
The FileSystemWatcher almost implements it, but it takes an extra File argument
addListener(File file, String path, ResourceListener listener)

Either that could be changed or a FileSystemDispatcher needs to be wrapped around the FileSystemWatcher.

Regards
Niels

···

On 01/17/2016 05:39 PM, Jody Garnett wrote:

Niels - do you mind if I gather up the result of this email thread and update the proposal - or would you like to?

On Sun, Jan 17, 2016 at 4:05 PM Ben Caradoc-Davies <ben@anonymised.com> wrote:

Sorry, yes it was, be me. I mistakenly assumed that all the GSIP-136
changes were isolated to the last two commits of PR #1361, but the
addition of this interface and the implementation
SimpleResourceNotificationDispatcher were included in an earlier commit.
We will need to refactor it to match the final decision on GSIP-136.

Kind regards,
Ben.

On 18/01/16 12:55, Jody Garnett wrote:

Ben I noticed ResourceNotificationDispatcher
<https://github.com/geoserver/geoserver/blob/master/src/platform/src/main/java/org/geoserver/platform/resource/ResourceNotificationDispatcher.java>
is
now available on master - was that accidentally merged?


Jody Garnett


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


Jody Garnett

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
[http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140](http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140)
_______________________________________________
Geoserver-devel mailing list
[Geoserver-devel@lists.sourceforge.net](mailto:Geoserver-devel@lists.sourceforge.net)
[https://lists.sourceforge.net/lists/listinfo/geoserver-devel](https://lists.sourceforge.net/lists/listinfo/geoserver-devel)

Catching email list up on sprint discussion :slight_smile: This conversation has settled down and I will update the proposal and ask for a second review.

The take home message is:

  • Watching resources change (on the file system or in jdbc resource store) is different from broadcasting the change to listeners
  • Our FileSystemWatcher should be updated/replaced with the Java 7 FileSystemWatcher

On Mon, 18 Jan 2016 at 09:39 Niels Charlier <niels@anonymised.com> wrote:

This change is fine by me, my original idea was to keep the API as unaffected as possible and keep the dispatcher something running in the background, optionally.

But - that means that the FileSystemRS also will need a ResourceNotificationDispatcher.
The FileSystemWatcher almost implements it, but it takes an extra File argument
addListener(File file, String path, ResourceListener listener)

Either that could be changed or a FileSystemDispatcher needs to be wrapped around the FileSystemWatcher.

Regards

Niels

On 01/17/2016 05:39 PM, Jody Garnett wrote:

Niels - do you mind if I gather up the result of this email thread and update the proposal - or would you like to?

On Sun, Jan 17, 2016 at 4:05 PM Ben Caradoc-Davies <ben@anonymised.com> wrote:

Sorry, yes it was, be me. I mistakenly assumed that all the GSIP-136
changes were isolated to the last two commits of PR #1361, but the
addition of this interface and the implementation
SimpleResourceNotificationDispatcher were included in an earlier commit.
We will need to refactor it to match the final decision on GSIP-136.

Kind regards,
Ben.

On 18/01/16 12:55, Jody Garnett wrote:

Ben I noticed ResourceNotificationDispatcher
<https://github.com/geoserver/geoserver/blob/master/src/platform/src/main/java/org/geoserver/platform/resource/ResourceNotificationDispatcher.java>
is
now available on master - was that accidentally merged?


Jody Garnett


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


Jody Garnett

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
[http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140](http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140)
_______________________________________________
Geoserver-devel mailing list
[Geoserver-devel@lists.sourceforge.net](mailto:Geoserver-devel@lists.sourceforge.net)
[https://lists.sourceforge.net/lists/listinfo/geoserver-devel](https://lists.sourceforge.net/lists/listinfo/geoserver-devel)


Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel


Jody Garnett

Changes look fine. Still +1.

Kevin Michael Smith

smithkm@anonymised.com

On Tue, Jan 19, 2016, at 05:05 PM, Jody Garnett wrote:

Catching email list up on sprint discussion :slight_smile: This conversation has settled down and I will update the proposal and ask for a second review.

The take home message is:

  • Watching resources change (on the file system or in jdbc resource store) is different from broadcasting the change to listeners

  • Our FileSystemWatcher should be updated/replaced with the Java 7 FileSystemWatcher

On Mon, 18 Jan 2016 at 09:39 Niels Charlier <niels@anonymised.com> wrote:

This change is fine by me, my original idea was to keep the API as unaffected as possible and keep the dispatcher something running in the background, optionally.

But - that means that the FileSystemRS also will need a ResourceNotificationDispatcher.

The FileSystemWatcher almost implements it, but it takes an extra File argument

addListener(File file, String path, ResourceListener listener)

Either that could be changed or a FileSystemDispatcher needs to be wrapped around the FileSystemWatcher.

Regards

Niels

On 01/17/2016 05:39 PM, Jody Garnett wrote:

Niels - do you mind if I gather up the result of this email thread and update the proposal - or would you like to?

On Sun, Jan 17, 2016 at 4:05 PM Ben Caradoc-Davies <ben@anonymised.com> wrote:

Sorry, yes it was, be me. I mistakenly assumed that all the GSIP-136

changes were isolated to the last two commits of PR #1361, but the

addition of this interface and the implementation

SimpleResourceNotificationDispatcher were included in an earlier commit.

We will need to refactor it to match the final decision on GSIP-136.

Kind regards,

Ben.

On 18/01/16 12:55, Jody Garnett wrote:

Ben I noticed ResourceNotificationDispatcher

<https://github.com/geoserver/geoserver/blob/master/src/platform/src/main/java/org/geoserver/platform/resource/ResourceNotificationDispatcher.java>

is

now available on master - was that accidentally merged?

Jody Garnett

Ben Caradoc-Davies <ben@anonymised.com>

Director

Transient Software Limited <http://transient.nz/>

New Zealand

Jody Garnett

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
[http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140](http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140)

_______________________________________________
Geoserver-devel mailing list
[Geoserver-devel@lists.sourceforge.net](mailto:Geoserver-devel@lists.sourceforge.net) [https://lists.sourceforge.net/lists/listinfo/geoserver-devel](https://lists.sourceforge.net/lists/listinfo/geoserver-devel)


Site24x7 APM Insight: Get Deep Visibility into Application Performance

APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month

Monitor end-to-end web transactions and take corrective actions now

Troubleshoot faster and improve end-user experience. Signup Now!

http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140_______________________________________________

Geoserver-devel mailing list

Geoserver-devel@lists.sourceforge.net

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

Jody Garnett


Site24x7 APM Insight: Get Deep Visibility into Application Performance

APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month

Monitor end-to-end web transactions and take corrective actions now

Troubleshoot faster and improve end-user experience. Signup Now!

http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140


Geoserver-devel mailing list

Geoserver-devel@lists.sourceforge.net

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

On Wed, Jan 20, 2016 at 2:05 AM, Jody Garnett <jody.garnett@anonymised.com>
wrote:

Catching email list up on sprint discussion :slight_smile: This conversation has
settled down and I will update the proposal and ask for a second review.

The take home message is:

- Watching resources change (on the file system or in jdbc resource store)
is different from broadcasting the change to listeners
- Our FileSystemWatcher should be updated/replaced with the Java 7
FileSystemWatcher

Hi Jody,
the proposal looks much better, but I'm still confused by the ROOT
notification part. If it cannot work,
why is it part of the document? The text seems to imply there is a better
way, but I don't see it?

"Update: Inspecting the code shows that listening to a directory is not
recursive - so the proposed alternative above (listening to the ROOT
directory would not work)."

Also, during our discussion in Victoria I believe you said that listening
to the ROOT was required for clustering
to work.
Have I misunderstood, is that no more the case, or should we just ignore
clustering needs for the moment?

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

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

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

Right, I can delete the “listen to root” idea. I had the idea that we could listen to the root folder (as an alternative to this proposal) and be advised of all resource changes.

Turns out listening to a directory - only gives you updates to the files listed in the directory - but does not do recursion.

So listening to ROOT would tell you about changes to resources in the GEOSERVER_DATA_DIRECTORY … but not tell you about a change to GEOSERVER_DATA_DIRECTORY/styles.

I will make a note of this in the “feedback” and remove the alternative from the proposal.

···

On 30 January 2016 at 11:49, Andrea Aime <andrea.aime@anonymised.com> wrote:


Jody Garnett

On Wed, Jan 20, 2016 at 2:05 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Catching email list up on sprint discussion :slight_smile: This conversation has settled down and I will update the proposal and ask for a second review.

The take home message is:

  • Watching resources change (on the file system or in jdbc resource store) is different from broadcasting the change to listeners
  • Our FileSystemWatcher should be updated/replaced with the Java 7 FileSystemWatcher

Hi Jody,
the proposal looks much better, but I’m still confused by the ROOT notification part. If it cannot work,
why is it part of the document? The text seems to imply there is a better way, but I don’t see it?

“Update: Inspecting the code shows that listening to a directory is not recursive - so the proposed alternative above (listening to the ROOT directory would not work).”

Also, during our discussion in Victoria I believe you said that listening to the ROOT was required for clustering
to work.
Have I misunderstood, is that no more the case, or should we just ignore clustering needs for the moment?

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

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.


So, if that has been fixed does that mean we can get an additional +1?

  :)

On 31-01-16 19:18, Jody Garnett wrote:

Right, I can delete the "listen to root" idea. I had the idea that we could listen to the root folder (as an alternative to this proposal) and be advised of all resource changes.

Turns out listening to a directory - only gives you updates to the files listed in the directory - but does not do recursion.

So listening to ROOT would tell you about changes to resources in the GEOSERVER_DATA_DIRECTORY .. but not tell you about a change to GEOSERVER_DATA_DIRECTORY/styles.

I will make a note of this in the "feedback" and remove the alternative from the proposal.

--
Jody Garnett

On 30 January 2016 at 11:49, Andrea Aime <andrea.aime@anonymised.com <mailto:andrea.aime@anonymised.com>> wrote:

    On Wed, Jan 20, 2016 at 2:05 AM, Jody Garnett
    <jody.garnett@anonymised.com <mailto:jody.garnett@anonymised.com>> wrote:

        Catching email list up on sprint discussion :slight_smile: This
        conversation has settled down and I will update the proposal
        and ask for a second review.

        The take home message is:

        - Watching resources change (on the file system or in jdbc
        resource store) is different from broadcasting the change to
        listeners
        - Our FileSystemWatcher should be updated/replaced with the
        Java 7 FileSystemWatcher

    Hi Jody,
    the proposal looks much better, but I'm still confused by the ROOT
    notification part. If it cannot work,
    why is it part of the document? The text seems to imply there is a
    better way, but I don't see it?

    "Update: Inspecting the code shows that listening to a directory
    is not recursive - so the proposed alternative above (listening to
    the ROOT directory would not work)."

    Also, during our discussion in Victoria I believe you said that
    listening to the ROOT was required for clustering
    to work.
    Have I misunderstood, is that no more the case, or should we just
    ignore clustering needs for the moment?

    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 Poggio alle Viti 1187
    55054 Massarosa (LU)
    Italy
    phone: +39 0584 962313 <tel:%2B39%200584%20962313>
    fax: +39 0584 1660272 <tel:%2B39%200584%201660272>
    mob: +39 339 8844549 <tel:%2B39%20%C2%A0339%208844549>

    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.

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

Ops, yes, of course! +1

Cheers
Andrea

···

On Tue, Feb 2, 2016 at 10:43 AM, Niels Charlier <niels@anonymised.com> wrote:

So, if that has been fixed does that mean we can get an additional +1?

:slight_smile:

On 31-01-16 19:18, Jody Garnett wrote:

Right, I can delete the “listen to root” idea. I had the idea that we could listen to the root folder (as an alternative to this proposal) and be advised of all resource changes.

Turns out listening to a directory - only gives you updates to the files listed in the directory - but does not do recursion.

So listening to ROOT would tell you about changes to resources in the GEOSERVER_DATA_DIRECTORY … but not tell you about a change to GEOSERVER_DATA_DIRECTORY/styles.

I will make a note of this in the “feedback” and remove the alternative from the proposal.


Jody Garnett

On 30 January 2016 at 11:49, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Wed, Jan 20, 2016 at 2:05 AM, Jody Garnett <jody.garnett@anonymised.com> wrote:

Catching email list up on sprint discussion :slight_smile: This conversation has settled down and I will update the proposal and ask for a second review.

The take home message is:

  • Watching resources change (on the file system or in jdbc resource store) is different from broadcasting the change to listeners
  • Our FileSystemWatcher should be updated/replaced with the Java 7 FileSystemWatcher

Hi Jody,
the proposal looks much better, but I’m still confused by the ROOT notification part. If it cannot work,
why is it part of the document? The text seems to imply there is a better way, but I don’t see it?

“Update: Inspecting the code shows that listening to a directory is not recursive - so the proposed alternative above (listening to the ROOT directory would not work).”

Also, during our discussion in Victoria I believe you said that listening to the ROOT was required for clustering
to work.
Have I misunderstood, is that no more the case, or should we just ignore clustering needs for the moment?

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

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 Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

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

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.