Hi all,
Andrea and myself recently had a discussion in jira that we think should probably take place on the wider list.
It has to do with CatalogListeners, and exceptions. The current behavior of the catalog is to protect itself against listeners that throw exceptions, and simply log the warning.
Sometimes this behavior is intended, for those listeners that are "non-crucial". An example here would be the GWCListener. However for some listeners this behavior is uwanted and the exception should be thrown so that it can be reported to the user. Example here would be the GeoServerPersister.
So we have a couple of options. It would be nice to hear what people prefer:
1) enforce catalog listeners to be well behaved, and do not catch exceptions thrown by listeners
2) come up with a special exception class CatalogException that when thrown by a listener will not be caught by the catalog.
Thoughts?
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Justin Deoliveira ha scritto:
Hi all,
Andrea and myself recently had a discussion in jira that we think should probably take place on the wider list.
It has to do with CatalogListeners, and exceptions. The current behavior of the catalog is to protect itself against listeners that throw exceptions, and simply log the warning.
Sometimes this behavior is intended, for those listeners that are "non-crucial". An example here would be the GWCListener. However for some listeners this behavior is uwanted and the exception should be thrown so that it can be reported to the user. Example here would be the GeoServerPersister.
So we have a couple of options. It would be nice to hear what people prefer:
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 
)
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
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
<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.
Justin Deoliveira ha scritto:
<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).
Good point!
Hmmm... I guess I'm starting to like option 2 better
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.