[Geoserver-devel] Property changes of Geoserver's nested XXInfo objects aren't notified to the globalChanges event listeners registered to the related initializers (CoverageAccessInitializer, JAIInitializer, ...)

Hi all,
yesterday I was debugging geoserver to figure out why any global change is triggering a JAI initialization and a coverageAccess initialization.
Long story short the handleGlobalChange and the handlePostGlobalChange of the custom ConfigurationListenerAdapter simply invoke the initialization method without doing any check of the changed properties/values.
Beside of that, I have noticed that the propertyNames, oldValues and newValues lists are empty (even when changing some params from the JAI page or the CoverageAccess page). The only changing thing seems the “updateSequence”.
After a brief meeting with Andrea, the outcome of the discussion is that the properties changes won’t be reported to the listener in case the properties belong to an object which is nested in the main object (as CoverageAccessInfo and JAIInfo are nested into GeoServerInfo).
Having these properties changes being notified would allow to check them and potentially avoid some initializations (JAI TileCache settings, TileScheduler settings, Tile Recycling , CoverageAccess threadPoolExecutor settings) when they aren’t needed.

How can we deal with that?

Best Regards,
Daniele

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313

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


Hi Daniele,

Yeah, the way we deal with nested objects like this is kind of weird. So I think there are a couple of things things going on here.

The first is that JAIInfo and CoverageAcecssInfo don’t extend from the Info interface, so modification proxy doesn’t treat them like any differently than a “regular” object ,in that they generally don’t get picked up as dirty unless they are set with a setter. So one way to fix this problem would be to have them extend from the Info interface.

WIth that I believe that modification proxy will actually treat them as “dirty” when you do something like this:

GeoServerInfo global = geoServer.getGlobal();
JAIInfo jai = global.getJAI();
jai.setSomething(…);
geoServer.save(global);

SO what you will get is a property changed event which reports that the “JAI” property has changed. The trouble is that as currently implemented the new value and the old value will be the same object. And of course it doesn’t give you any notion of what properties in the nested object has changed.

I am not so sure how to fix this. Obviously the change of hanging the interfaces extend Info is a trivial one but how to report the changes to the nested objects isn’t. One thing we could do is instead of just reporting that the “jai” object changes is use a nested notation to report what properties actually changed, and pass them into the listener method. SO instead of af an event that looks like this:

postModifed(GeoServerINfoImp@anonymised.com, [“jai”], [JAIInfoImpl@anonymised.com], [JAIInfoImpl@anonymised.com])

You would get one like:

postModifed(GeoServerINfoImp@anonymised.com, [“jai.something”], [“oldSomething”], [“newSomething”])

If that makes sense? This would require some changes to modification proxy.

An alternative would be to ensure we throw multiple events in this case. Not sure which one is better.

-Justin

On Thu, Jul 19, 2012 at 2:33 AM, Daniele Romagnoli <daniele.romagnoli@anonymised.com> wrote:

Hi all,
yesterday I was debugging geoserver to figure out why any global change is triggering a JAI initialization and a coverageAccess initialization.
Long story short the handleGlobalChange and the handlePostGlobalChange of the custom ConfigurationListenerAdapter simply invoke the initialization method without doing any check of the changed properties/values.
Beside of that, I have noticed that the propertyNames, oldValues and newValues lists are empty (even when changing some params from the JAI page or the CoverageAccess page). The only changing thing seems the “updateSequence”.
After a brief meeting with Andrea, the outcome of the discussion is that the properties changes won’t be reported to the listener in case the properties belong to an object which is nested in the main object (as CoverageAccessInfo and JAIInfo are nested into GeoServerInfo).
Having these properties changes being notified would allow to check them and potentially avoid some initializations (JAI TileCache settings, TileScheduler settings, Tile Recycling , CoverageAccess threadPoolExecutor settings) when they aren’t needed.

How can we deal with that?

Best Regards,
Daniele

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313

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



Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/


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


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Hi Daniele,

the reason is that the model used to edit JAIInfo is a
LoadableDetachableModel, so when the edit page does gobal.setJAI, it
is actually setting the same object reference, and hence the
modificationproxy does not count it as a change.

Check the attached patch for a possible solution, which is editing a
clone of the original JAIInfo.

Cheers,
Gabriel

On Thu, Jul 19, 2012 at 5:33 AM, Daniele Romagnoli
<daniele.romagnoli@anonymised.com> wrote:

Hi all,
yesterday I was debugging geoserver to figure out why any global change is
triggering a JAI initialization and a coverageAccess initialization.
Long story short the handleGlobalChange and the handlePostGlobalChange of
the custom ConfigurationListenerAdapter simply invoke the initialization
method without doing any check of the changed properties/values.
Beside of that, I have noticed that the propertyNames, oldValues and
newValues lists are empty (even when changing some params from the JAI page
or the CoverageAccess page). The only changing thing seems the
"updateSequence".
After a brief meeting with Andrea, the outcome of the discussion is that the
properties changes won't be reported to the listener in case the properties
belong to an object which is nested in the main object (as
CoverageAccessInfo and JAIInfo are nested into GeoServerInfo).
Having these properties changes being notified would allow to check them and
potentially avoid some initializations (JAI TileCache settings,
TileScheduler settings, Tile Recycling , CoverageAccess threadPoolExecutor
settings) when they aren't needed.

How can we deal with that?

Best Regards,
Daniele
--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313

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

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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

(attachments)

jaichange.patch (4.75 KB)

Since JAIInfo is a plain data type (i.e. GeoServerInfo _owns_ it), I
think it's just easier to use a clone for the JAIInfo wicket model and
then set it on save. See attached patch on my previous reply?

On Thu, Jul 19, 2012 at 1:53 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi Daniele,

Yeah, the way we deal with nested objects like this is kind of weird. So I
think there are a couple of things things going on here.

The first is that JAIInfo and CoverageAcecssInfo don't extend from the Info
interface, so modification proxy doesn't treat them like any differently
than a "regular" object ,in that they generally don't get picked up as dirty
unless they are set with a setter. So one way to fix this problem would be
to have them extend from the Info interface.

WIth that I believe that modification proxy will actually treat them as
"dirty" when you do something like this:

GeoServerInfo global = geoServer.getGlobal();
JAIInfo jai = global.getJAI();
jai.setSomething(...);
geoServer.save(global);

SO what you will get is a property changed event which reports that the
"JAI" property has changed. The trouble is that as currently implemented the
new value and the old value will be the same object. And of course it
doesn't give you any notion of what properties in the nested object has
changed.

I am not so sure how to fix this. Obviously the change of hanging the
interfaces extend Info is a trivial one but how to report the changes to the
nested objects isn't. One thing we could do is instead of just reporting
that the "jai" object changes is use a nested notation to report what
properties actually changed, and pass them into the listener method. SO
instead of af an event that looks like this:

  postModifed(GeoServerINfoImp@anonymised.com, ["jai"], [JAIInfoImpl@anonymised.com],
[JAIInfoImpl@anonymised.com])

You would get one like:

  postModifed(GeoServerINfoImp@anonymised.com, ["jai.something"], ["oldSomething"],
["newSomething"])

If that makes sense? This would require some changes to modification proxy.

An alternative would be to ensure we throw multiple events in this case. Not
sure which one is better.

-Justin

On Thu, Jul 19, 2012 at 2:33 AM, Daniele Romagnoli
<daniele.romagnoli@anonymised.com> wrote:

Hi all,
yesterday I was debugging geoserver to figure out why any global change is
triggering a JAI initialization and a coverageAccess initialization.
Long story short the handleGlobalChange and the handlePostGlobalChange of
the custom ConfigurationListenerAdapter simply invoke the initialization
method without doing any check of the changed properties/values.
Beside of that, I have noticed that the propertyNames, oldValues and
newValues lists are empty (even when changing some params from the JAI page
or the CoverageAccess page). The only changing thing seems the
"updateSequence".
After a brief meeting with Andrea, the outcome of the discussion is that
the properties changes won't be reported to the listener in case the
properties belong to an object which is nested in the main object (as
CoverageAccessInfo and JAIInfo are nested into GeoServerInfo).
Having these properties changes being notified would allow to check them
and potentially avoid some initializations (JAI TileCache settings,
TileScheduler settings, Tile Recycling , CoverageAccess threadPoolExecutor
settings) when they aren't needed.

How can we deal with that?

Best Regards,
Daniele
--

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313

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

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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Hi guys,
sorry for the late reply.
Thanks for your feedbacks… I have already taken a quick look to them and I’ll check them again as soon as possible.

Cheers,
Daniele

On Thu, Jul 19, 2012 at 7:00 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

Since JAIInfo is a plain data type (i.e. GeoServerInfo owns it), I
think it’s just easier to use a clone for the JAIInfo wicket model and
then set it on save. See attached patch on my previous reply?

On Thu, Jul 19, 2012 at 1:53 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi Daniele,

Yeah, the way we deal with nested objects like this is kind of weird. So I
think there are a couple of things things going on here.

The first is that JAIInfo and CoverageAcecssInfo don’t extend from the Info
interface, so modification proxy doesn’t treat them like any differently
than a “regular” object ,in that they generally don’t get picked up as dirty
unless they are set with a setter. So one way to fix this problem would be
to have them extend from the Info interface.

WIth that I believe that modification proxy will actually treat them as
“dirty” when you do something like this:

GeoServerInfo global = geoServer.getGlobal();
JAIInfo jai = global.getJAI();
jai.setSomething(…);
geoServer.save(global);

SO what you will get is a property changed event which reports that the
“JAI” property has changed. The trouble is that as currently implemented the
new value and the old value will be the same object. And of course it
doesn’t give you any notion of what properties in the nested object has
changed.

I am not so sure how to fix this. Obviously the change of hanging the
interfaces extend Info is a trivial one but how to report the changes to the
nested objects isn’t. One thing we could do is instead of just reporting
that the “jai” object changes is use a nested notation to report what
properties actually changed, and pass them into the listener method. SO
instead of af an event that looks like this:

postModifed(GeoServerINfoImp@anonymised.com, [“jai”], [JAIInfoImpl@anonymised.com],
[JAIInfoImpl@anonymised.com])

You would get one like:

postModifed(GeoServerINfoImp@anonymised.com, [“jai.something”], [“oldSomething”],
[“newSomething”])

If that makes sense? This would require some changes to modification proxy.

An alternative would be to ensure we throw multiple events in this case. Not
sure which one is better.

-Justin

On Thu, Jul 19, 2012 at 2:33 AM, Daniele Romagnoli
<daniele.romagnoli@…1268…> wrote:

Hi all,
yesterday I was debugging geoserver to figure out why any global change is
triggering a JAI initialization and a coverageAccess initialization.
Long story short the handleGlobalChange and the handlePostGlobalChange of
the custom ConfigurationListenerAdapter simply invoke the initialization
method without doing any check of the changed properties/values.
Beside of that, I have noticed that the propertyNames, oldValues and
newValues lists are empty (even when changing some params from the JAI page
or the CoverageAccess page). The only changing thing seems the
“updateSequence”.
After a brief meeting with Andrea, the outcome of the discussion is that
the properties changes won’t be reported to the listener in case the
properties belong to an object which is nested in the main object (as
CoverageAccessInfo and JAIInfo are nested into GeoServerInfo).
Having these properties changes being notified would allow to check them
and potentially avoid some initializations (JAI TileCache settings,
TileScheduler settings, Tile Recycling , CoverageAccess threadPoolExecutor
settings) when they aren’t needed.

How can we deal with that?

Best Regards,
Daniele

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313

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



Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/


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


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.


Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/


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

Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313

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


Hi again,
I have tested the patch provided by Gabriel which seems properly working.
I have added a few comments to some code and I have also added the part for the coverageAccess page management.
http://jira.codehaus.org/secure/attachment/60845/GEOS-5226.diff

Do you have any chance to take a quick look to that?
(Although it’s nothing so different with respect to the code already provided by Gabriel).

Cheers,
Daniele

On Mon, Jul 30, 2012 at 10:43 AM, Daniele Romagnoli <daniele.romagnoli@anonymised.com> wrote:

Hi guys,
sorry for the late reply.
Thanks for your feedbacks… I have already taken a quick look to them and I’ll check them again as soon as possible.

Cheers,
Daniele

On Thu, Jul 19, 2012 at 7:00 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

Since JAIInfo is a plain data type (i.e. GeoServerInfo owns it), I
think it’s just easier to use a clone for the JAIInfo wicket model and
then set it on save. See attached patch on my previous reply?

On Thu, Jul 19, 2012 at 1:53 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi Daniele,

Yeah, the way we deal with nested objects like this is kind of weird. So I
think there are a couple of things things going on here.

The first is that JAIInfo and CoverageAcecssInfo don’t extend from the Info
interface, so modification proxy doesn’t treat them like any differently
than a “regular” object ,in that they generally don’t get picked up as dirty
unless they are set with a setter. So one way to fix this problem would be
to have them extend from the Info interface.

WIth that I believe that modification proxy will actually treat them as
“dirty” when you do something like this:

GeoServerInfo global = geoServer.getGlobal();
JAIInfo jai = global.getJAI();
jai.setSomething(…);
geoServer.save(global);

SO what you will get is a property changed event which reports that the
“JAI” property has changed. The trouble is that as currently implemented the
new value and the old value will be the same object. And of course it
doesn’t give you any notion of what properties in the nested object has
changed.

I am not so sure how to fix this. Obviously the change of hanging the
interfaces extend Info is a trivial one but how to report the changes to the
nested objects isn’t. One thing we could do is instead of just reporting
that the “jai” object changes is use a nested notation to report what
properties actually changed, and pass them into the listener method. SO
instead of af an event that looks like this:

postModifed(GeoServerINfoImp@anonymised.com, [“jai”], [JAIInfoImpl@anonymised.com],
[JAIInfoImpl@anonymised.com])

You would get one like:

postModifed(GeoServerINfoImp@anonymised.com, [“jai.something”], [“oldSomething”],
[“newSomething”])

If that makes sense? This would require some changes to modification proxy.

An alternative would be to ensure we throw multiple events in this case. Not
sure which one is better.

-Justin

On Thu, Jul 19, 2012 at 2:33 AM, Daniele Romagnoli
<daniele.romagnoli@anonymised.com> wrote:

Hi all,
yesterday I was debugging geoserver to figure out why any global change is
triggering a JAI initialization and a coverageAccess initialization.
Long story short the handleGlobalChange and the handlePostGlobalChange of
the custom ConfigurationListenerAdapter simply invoke the initialization
method without doing any check of the changed properties/values.
Beside of that, I have noticed that the propertyNames, oldValues and
newValues lists are empty (even when changing some params from the JAI page
or the CoverageAccess page). The only changing thing seems the
“updateSequence”.
After a brief meeting with Andrea, the outcome of the discussion is that
the properties changes won’t be reported to the listener in case the
properties belong to an object which is nested in the main object (as
CoverageAccessInfo and JAIInfo are nested into GeoServerInfo).
Having these properties changes being notified would allow to check them
and potentially avoid some initializations (JAI TileCache settings,
TileScheduler settings, Tile Recycling , CoverageAccess threadPoolExecutor
settings) when they aren’t needed.

How can we deal with that?

Best Regards,
Daniele

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313

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



Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/


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


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.


Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/


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

Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313

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


Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313

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


Hi Danielle,

Made some comments on the issue.

-Justin

On Tue, Aug 7, 2012 at 7:14 AM, Daniele Romagnoli <daniele.romagnoli@anonymised.com.> wrote:

Hi again,
I have tested the patch provided by Gabriel which seems properly working.
I have added a few comments to some code and I have also added the part for the coverageAccess page management.
http://jira.codehaus.org/secure/attachment/60845/GEOS-5226.diff

Do you have any chance to take a quick look to that?
(Although it’s nothing so different with respect to the code already provided by Gabriel).

Cheers,
Daniele

On Mon, Jul 30, 2012 at 10:43 AM, Daniele Romagnoli <daniele.romagnoli@anonymised.com> wrote:

Hi guys,
sorry for the late reply.
Thanks for your feedbacks… I have already taken a quick look to them and I’ll check them again as soon as possible.

Cheers,
Daniele

On Thu, Jul 19, 2012 at 7:00 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

Since JAIInfo is a plain data type (i.e. GeoServerInfo owns it), I
think it’s just easier to use a clone for the JAIInfo wicket model and
then set it on save. See attached patch on my previous reply?

On Thu, Jul 19, 2012 at 1:53 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi Daniele,

Yeah, the way we deal with nested objects like this is kind of weird. So I
think there are a couple of things things going on here.

The first is that JAIInfo and CoverageAcecssInfo don’t extend from the Info
interface, so modification proxy doesn’t treat them like any differently
than a “regular” object ,in that they generally don’t get picked up as dirty
unless they are set with a setter. So one way to fix this problem would be
to have them extend from the Info interface.

WIth that I believe that modification proxy will actually treat them as
“dirty” when you do something like this:

GeoServerInfo global = geoServer.getGlobal();
JAIInfo jai = global.getJAI();
jai.setSomething(…);
geoServer.save(global);

SO what you will get is a property changed event which reports that the
“JAI” property has changed. The trouble is that as currently implemented the
new value and the old value will be the same object. And of course it
doesn’t give you any notion of what properties in the nested object has
changed.

I am not so sure how to fix this. Obviously the change of hanging the
interfaces extend Info is a trivial one but how to report the changes to the
nested objects isn’t. One thing we could do is instead of just reporting
that the “jai” object changes is use a nested notation to report what
properties actually changed, and pass them into the listener method. SO
instead of af an event that looks like this:

postModifed(GeoServerINfoImp@anonymised.com, [“jai”], [JAIInfoImpl@anonymised.com],
[JAIInfoImpl@anonymised.com])

You would get one like:

postModifed(GeoServerINfoImp@anonymised.com, [“jai.something”], [“oldSomething”],
[“newSomething”])

If that makes sense? This would require some changes to modification proxy.

An alternative would be to ensure we throw multiple events in this case. Not
sure which one is better.

-Justin

On Thu, Jul 19, 2012 at 2:33 AM, Daniele Romagnoli
<daniele.romagnoli@anonymised.com> wrote:

Hi all,
yesterday I was debugging geoserver to figure out why any global change is
triggering a JAI initialization and a coverageAccess initialization.
Long story short the handleGlobalChange and the handlePostGlobalChange of
the custom ConfigurationListenerAdapter simply invoke the initialization
method without doing any check of the changed properties/values.
Beside of that, I have noticed that the propertyNames, oldValues and
newValues lists are empty (even when changing some params from the JAI page
or the CoverageAccess page). The only changing thing seems the
“updateSequence”.
After a brief meeting with Andrea, the outcome of the discussion is that
the properties changes won’t be reported to the listener in case the
properties belong to an object which is nested in the main object (as
CoverageAccessInfo and JAIInfo are nested into GeoServerInfo).
Having these properties changes being notified would allow to check them
and potentially avoid some initializations (JAI TileCache settings,
TileScheduler settings, Tile Recycling , CoverageAccess threadPoolExecutor
settings) when they aren’t needed.

How can we deal with that?

Best Regards,
Daniele

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313

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



Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/


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


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.


Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/


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

Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313

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


Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313

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



Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Hi Justin,
thanks… added some more info (comments) on top of the explanations provided by Gabriel the past days.

Daniele

On Tue, Aug 7, 2012 at 4:46 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi Danielle,

Made some comments on the issue.

-Justin

On Tue, Aug 7, 2012 at 7:14 AM, Daniele Romagnoli <daniele.romagnoli@anonymised.com> wrote:

Hi again,
I have tested the patch provided by Gabriel which seems properly working.
I have added a few comments to some code and I have also added the part for the coverageAccess page management.
http://jira.codehaus.org/secure/attachment/60845/GEOS-5226.diff

Do you have any chance to take a quick look to that?
(Although it’s nothing so different with respect to the code already provided by Gabriel).

Cheers,
Daniele

On Mon, Jul 30, 2012 at 10:43 AM, Daniele Romagnoli <daniele.romagnoli@anonymised.com> wrote:

Hi guys,
sorry for the late reply.
Thanks for your feedbacks… I have already taken a quick look to them and I’ll check them again as soon as possible.

Cheers,
Daniele

On Thu, Jul 19, 2012 at 7:00 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

Since JAIInfo is a plain data type (i.e. GeoServerInfo owns it), I
think it’s just easier to use a clone for the JAIInfo wicket model and
then set it on save. See attached patch on my previous reply?

On Thu, Jul 19, 2012 at 1:53 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi Daniele,

Yeah, the way we deal with nested objects like this is kind of weird. So I
think there are a couple of things things going on here.

The first is that JAIInfo and CoverageAcecssInfo don’t extend from the Info
interface, so modification proxy doesn’t treat them like any differently
than a “regular” object ,in that they generally don’t get picked up as dirty
unless they are set with a setter. So one way to fix this problem would be
to have them extend from the Info interface.

WIth that I believe that modification proxy will actually treat them as
“dirty” when you do something like this:

GeoServerInfo global = geoServer.getGlobal();
JAIInfo jai = global.getJAI();
jai.setSomething(…);
geoServer.save(global);

SO what you will get is a property changed event which reports that the
“JAI” property has changed. The trouble is that as currently implemented the
new value and the old value will be the same object. And of course it
doesn’t give you any notion of what properties in the nested object has
changed.

I am not so sure how to fix this. Obviously the change of hanging the
interfaces extend Info is a trivial one but how to report the changes to the
nested objects isn’t. One thing we could do is instead of just reporting
that the “jai” object changes is use a nested notation to report what
properties actually changed, and pass them into the listener method. SO
instead of af an event that looks like this:

postModifed(GeoServerINfoImp@anonymised.com, [“jai”], [JAIInfoImpl@anonymised.com],
[JAIInfoImpl@anonymised.com])

You would get one like:

postModifed(GeoServerINfoImp@anonymised.com, [“jai.something”], [“oldSomething”],
[“newSomething”])

If that makes sense? This would require some changes to modification proxy.

An alternative would be to ensure we throw multiple events in this case. Not
sure which one is better.

-Justin

On Thu, Jul 19, 2012 at 2:33 AM, Daniele Romagnoli
<daniele.romagnoli@anonymised.com> wrote:

Hi all,
yesterday I was debugging geoserver to figure out why any global change is
triggering a JAI initialization and a coverageAccess initialization.
Long story short the handleGlobalChange and the handlePostGlobalChange of
the custom ConfigurationListenerAdapter simply invoke the initialization
method without doing any check of the changed properties/values.
Beside of that, I have noticed that the propertyNames, oldValues and
newValues lists are empty (even when changing some params from the JAI page
or the CoverageAccess page). The only changing thing seems the
“updateSequence”.
After a brief meeting with Andrea, the outcome of the discussion is that
the properties changes won’t be reported to the listener in case the
properties belong to an object which is nested in the main object (as
CoverageAccessInfo and JAIInfo are nested into GeoServerInfo).
Having these properties changes being notified would allow to check them
and potentially avoid some initializations (JAI TileCache settings,
TileScheduler settings, Tile Recycling , CoverageAccess threadPoolExecutor
settings) when they aren’t needed.

How can we deal with that?

Best Regards,
Daniele

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313

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



Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/


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


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.


Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/


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

Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313

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


Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313

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



Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313

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


Hi guys,
based on the latest comments I have provided on the JIRA, do you think can I proceed with the fix (committing the patch)?

Please, let us know.
Daniele

On Tue, Aug 7, 2012 at 4:59 PM, Daniele Romagnoli <daniele.romagnoli@anonymised.com> wrote:

Hi Justin,
thanks… added some more info (comments) on top of the explanations provided by Gabriel the past days.

Daniele

On Tue, Aug 7, 2012 at 4:46 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi Danielle,

Made some comments on the issue.

-Justin

On Tue, Aug 7, 2012 at 7:14 AM, Daniele Romagnoli <daniele.romagnoli@anonymised.com> wrote:

Hi again,
I have tested the patch provided by Gabriel which seems properly working.
I have added a few comments to some code and I have also added the part for the coverageAccess page management.
http://jira.codehaus.org/secure/attachment/60845/GEOS-5226.diff

Do you have any chance to take a quick look to that?
(Although it’s nothing so different with respect to the code already provided by Gabriel).

Cheers,
Daniele

On Mon, Jul 30, 2012 at 10:43 AM, Daniele Romagnoli <daniele.romagnoli@anonymised.com> wrote:

Hi guys,
sorry for the late reply.
Thanks for your feedbacks… I have already taken a quick look to them and I’ll check them again as soon as possible.

Cheers,
Daniele

On Thu, Jul 19, 2012 at 7:00 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

Since JAIInfo is a plain data type (i.e. GeoServerInfo owns it), I
think it’s just easier to use a clone for the JAIInfo wicket model and
then set it on save. See attached patch on my previous reply?

On Thu, Jul 19, 2012 at 1:53 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi Daniele,

Yeah, the way we deal with nested objects like this is kind of weird. So I
think there are a couple of things things going on here.

The first is that JAIInfo and CoverageAcecssInfo don’t extend from the Info
interface, so modification proxy doesn’t treat them like any differently
than a “regular” object ,in that they generally don’t get picked up as dirty
unless they are set with a setter. So one way to fix this problem would be
to have them extend from the Info interface.

WIth that I believe that modification proxy will actually treat them as
“dirty” when you do something like this:

GeoServerInfo global = geoServer.getGlobal();
JAIInfo jai = global.getJAI();
jai.setSomething(…);
geoServer.save(global);

SO what you will get is a property changed event which reports that the
“JAI” property has changed. The trouble is that as currently implemented the
new value and the old value will be the same object. And of course it
doesn’t give you any notion of what properties in the nested object has
changed.

I am not so sure how to fix this. Obviously the change of hanging the
interfaces extend Info is a trivial one but how to report the changes to the
nested objects isn’t. One thing we could do is instead of just reporting
that the “jai” object changes is use a nested notation to report what
properties actually changed, and pass them into the listener method. SO
instead of af an event that looks like this:

postModifed(GeoServerINfoImp@anonymised.com, [“jai”], [JAIInfoImpl@anonymised.com],
[JAIInfoImpl@anonymised.com])

You would get one like:

postModifed(GeoServerINfoImp@anonymised.com, [“jai.something”], [“oldSomething”],
[“newSomething”])

If that makes sense? This would require some changes to modification proxy.

An alternative would be to ensure we throw multiple events in this case. Not
sure which one is better.

-Justin

On Thu, Jul 19, 2012 at 2:33 AM, Daniele Romagnoli
<daniele.romagnoli@anonymised.com> wrote:

Hi all,
yesterday I was debugging geoserver to figure out why any global change is
triggering a JAI initialization and a coverageAccess initialization.
Long story short the handleGlobalChange and the handlePostGlobalChange of
the custom ConfigurationListenerAdapter simply invoke the initialization
method without doing any check of the changed properties/values.
Beside of that, I have noticed that the propertyNames, oldValues and
newValues lists are empty (even when changing some params from the JAI page
or the CoverageAccess page). The only changing thing seems the
“updateSequence”.
After a brief meeting with Andrea, the outcome of the discussion is that
the properties changes won’t be reported to the listener in case the
properties belong to an object which is nested in the main object (as
CoverageAccessInfo and JAIInfo are nested into GeoServerInfo).
Having these properties changes being notified would allow to check them
and potentially avoid some initializations (JAI TileCache settings,
TileScheduler settings, Tile Recycling , CoverageAccess threadPoolExecutor
settings) when they aren’t needed.

How can we deal with that?

Best Regards,
Daniele

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313

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



Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/


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


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.


Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/


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

Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313

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


Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313

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



Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313

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


Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313

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


Cool. thanks Daniele. +1

On Wed, Aug 8, 2012 at 6:14 AM, Daniele Romagnoli <daniele.romagnoli@anonymised.com…> wrote:

Hi guys,
based on the latest comments I have provided on the JIRA, do you think can I proceed with the fix (committing the patch)?

Please, let us know.
Daniele

On Tue, Aug 7, 2012 at 4:59 PM, Daniele Romagnoli <daniele.romagnoli@anonymised.com> wrote:

Hi Justin,
thanks… added some more info (comments) on top of the explanations provided by Gabriel the past days.

Daniele

On Tue, Aug 7, 2012 at 4:46 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi Danielle,

Made some comments on the issue.

-Justin

On Tue, Aug 7, 2012 at 7:14 AM, Daniele Romagnoli <daniele.romagnoli@anonymised.com> wrote:

Hi again,
I have tested the patch provided by Gabriel which seems properly working.
I have added a few comments to some code and I have also added the part for the coverageAccess page management.
http://jira.codehaus.org/secure/attachment/60845/GEOS-5226.diff

Do you have any chance to take a quick look to that?
(Although it’s nothing so different with respect to the code already provided by Gabriel).

Cheers,
Daniele

On Mon, Jul 30, 2012 at 10:43 AM, Daniele Romagnoli <daniele.romagnoli@anonymised.com> wrote:

Hi guys,
sorry for the late reply.
Thanks for your feedbacks… I have already taken a quick look to them and I’ll check them again as soon as possible.

Cheers,
Daniele

On Thu, Jul 19, 2012 at 7:00 PM, Gabriel Roldan <groldan@anonymised.com> wrote:

Since JAIInfo is a plain data type (i.e. GeoServerInfo owns it), I
think it’s just easier to use a clone for the JAIInfo wicket model and
then set it on save. See attached patch on my previous reply?

On Thu, Jul 19, 2012 at 1:53 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi Daniele,

Yeah, the way we deal with nested objects like this is kind of weird. So I
think there are a couple of things things going on here.

The first is that JAIInfo and CoverageAcecssInfo don’t extend from the Info
interface, so modification proxy doesn’t treat them like any differently
than a “regular” object ,in that they generally don’t get picked up as dirty
unless they are set with a setter. So one way to fix this problem would be
to have them extend from the Info interface.

WIth that I believe that modification proxy will actually treat them as
“dirty” when you do something like this:

GeoServerInfo global = geoServer.getGlobal();
JAIInfo jai = global.getJAI();
jai.setSomething(…);
geoServer.save(global);

SO what you will get is a property changed event which reports that the
“JAI” property has changed. The trouble is that as currently implemented the
new value and the old value will be the same object. And of course it
doesn’t give you any notion of what properties in the nested object has
changed.

I am not so sure how to fix this. Obviously the change of hanging the
interfaces extend Info is a trivial one but how to report the changes to the
nested objects isn’t. One thing we could do is instead of just reporting
that the “jai” object changes is use a nested notation to report what
properties actually changed, and pass them into the listener method. SO
instead of af an event that looks like this:

postModifed(GeoServerINfoImp@anonymised.com, [“jai”], [JAIInfoImpl@anonymised.com],
[JAIInfoImpl@anonymised.com])

You would get one like:

postModifed(GeoServerINfoImp@anonymised.com, [“jai.something”], [“oldSomething”],
[“newSomething”])

If that makes sense? This would require some changes to modification proxy.

An alternative would be to ensure we throw multiple events in this case. Not
sure which one is better.

-Justin

On Thu, Jul 19, 2012 at 2:33 AM, Daniele Romagnoli
<daniele.romagnoli@anonymised.com> wrote:

Hi all,
yesterday I was debugging geoserver to figure out why any global change is
triggering a JAI initialization and a coverageAccess initialization.
Long story short the handleGlobalChange and the handlePostGlobalChange of
the custom ConfigurationListenerAdapter simply invoke the initialization
method without doing any check of the changed properties/values.
Beside of that, I have noticed that the propertyNames, oldValues and
newValues lists are empty (even when changing some params from the JAI page
or the CoverageAccess page). The only changing thing seems the
“updateSequence”.
After a brief meeting with Andrea, the outcome of the discussion is that
the properties changes won’t be reported to the listener in case the
properties belong to an object which is nested in the main object (as
CoverageAccessInfo and JAIInfo are nested into GeoServerInfo).
Having these properties changes being notified would allow to check them
and potentially avoid some initializations (JAI TileCache settings,
TileScheduler settings, Tile Recycling , CoverageAccess threadPoolExecutor
settings) when they aren’t needed.

How can we deal with that?

Best Regards,
Daniele

==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313

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



Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/


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


Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.


Live Security Virtual Conference
Exclusive live event will cover all the ways today’s security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/


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

Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313

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


Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313

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



Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313

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


Our support, Your Success! Visit http://opensdi.geo-solutions.it for more information.

Ing. Daniele Romagnoli
Senior Software Engineer

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313

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



Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.