<snip> >> >> 1) enforce catalog listeners to be well behaved, and do not catch >> exceptions thrown by listeners > > This is the cleanest approach imho, you always get to know when things > go south. Downside, it might break operation, the current approach > allows some sort of graceful degradation (thought in some cases it's > not so graceful, restart GeoServer and your config is gone ;-) )
It goes both ways. Say you have a misbehaved listener that executes before the configuration persister. The same thing will happen (the persister will not execute so after restart you lose data). > >> 2) come up with a special exception class CatalogException that when >> thrown by a listener will not be caught by the catalog. > > This one is good if the programmer tries hard to foresee how things > can go wrong and what to do about it (stop the world or sweep under > the carpet?). > > I'm open to both solutions, with a preference on the first As am I. Hopefully others can weigh in. > > Cheers > Andrea > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
