Hmmm... nasty :)
How about we go with (c) and not remove the listeners, but also add a
handleDispose() method to the CatalogListener interface?
On Sun, Nov 4, 2012 at 4:12 AM, Andrea Aime <[email protected]>wrote:
> Hi,
> I was trying to debug a seemingly JDK 7 specific issue in the
> GWCIntegrationTest and
> found a more serious one.
> Basically under JDK7 the executiohn order of the test methods inside a
> test class
> changes dependending on whether I run them from Eclipse, in Maven in a full
> build, in maven in a single test build (lots of fun).
>
> Now, there are some parts of the GWCIntegrationTest that do eliminate a
> layer,
> and I already added a revert so that the layer comes back for the
> other tests, but
> when the first method run happens to be testMissingGeoServerLayerAtStartUp
> well, that does not help and most of the other test methods fail.
>
> I've tracked it down to the method calling getGeoServer.reload(), and
> by looking into
> it something scary came up: when we call that method we loose all
> CatalogListener
> objects previously attached, as a result of Catalog.disponse() being
> called.
>
> When that happens we loose significant pieces of functionality:
> * the gwc catalog listeners, that synchs up the cache with the
> add/remove/modify events
> related to styles and layers
> * the namespace/workspace synch listener, making sure the two never
> get out of synch
> * the update sequence listener
>
> What we don't lose, is the resource pool own cache clearing listener,
> probably because
> a new resource pool is created in the process.
>
> Looking at the CatalogListener API does not say that the code should
> try to reattach
> new listeners after GeoServer reload.
>
> Some (possibly ugly) way forwards:
> a) change the docs and tell implementors to listen for reload events,
> and reattach listeners
> b) grab the existing listeners from the catalog, reload, and reattach
> them to the
> catalog afterwads (but we'd have to pay attention to skip attaching
> the old
> resource pool listener)
> c) don't get rid of the listeners list in the Catalog.dispose() call
> (same issue as b
> with the resource pool one though)
>
> Hum... thoughts on what's the best way to proceed?
>
> Cheers
> Andrea
>
> PS: the only sane way to do a) would be to implement
> ConfigurationListener.reloaded()
> but that method is now deprecated on trunk? I don't remember a
> discussion about
> deprecating it?
>
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it 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
>
> -------------------------------------------------------
>
>
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> Geoserver-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
