Promoting the monitoring module from community to extension with some restructuring along the way.

Justin Deoliveira

master, 2.2.x

Under Discussion, In Progress, Completed, Rejected, Deferred

[Current implementation|https://github.com/jdeolive/geoserver/compare/mon_refactor]

The monitoring module is one of the more widely used community modules and has been a good candidate for promotion for quite some time.

Coupled with the promotion is a bit of reorganization to restructure the plugin into two parts.

1. core extension
2. hibernate persistence

The main motivation for doing so is to relieve users who don’t require persistence from paying the pice that comes with hibernate, which is a very sizeable (and complex) dependency.

To sum up basically moving out the monitoring dao into a separate module resulting in two modules.

\1. The monitor core module - as it exists today, minus the hibernate dao 2. The hibernate module - with everything hibernate

Implicit in this change is making the backend dao fully pluggable, which isn’t the case today. This should make it easier to implement new back end daos.

The biggest impact is that projects that are using on the hibernate backend will have to update their dependencies. Aside from that not much should really change. The plan is do the refactoring in a way that behaves exactly like it does today when the hibernate module is present.

However there are some subtle things that will change in the core module related to configuration. Currently the monitor config has the “mode” property which is currently a mix of two things. The first is that it controls which dao is chosen, the memory dao or the hibernate dao. But it also controls how the hibernate dao operates with respect to when during the life cycle of a request it persists to the database.

In light of this i am also proposing the following configuration changes.

\1. A new config parameter named “storage”, which would control specially what dao is used. Its values would be “memory”, “hibernate”, and the future names of daos yet to be implemented. I was also thinking “none” would make sense as well which would basically make persistent a no-op. For instance this would be handy for folks who only use the audit logging functionality and don’t want to pay the overhead of the memory dao, even though the overhead is fairly minimal.

\2. A change to the “mode” parameter to be one of “live” or “history”, which is a subset of what he values are today. Basically removing the “hybrid” mode. The value “live” specifies that the dao should persist continuously over the life cycle of the request. The value “history” specifies that the dao should only persist after the request is fully completed. To retain backward compatibility the value “hybrid” will still be recognized by the hibernate extension but will essentially be an alias for “live”. Which is more or less the same behaviour as today.

First thing is to ensure all the requirements for promotion have been met.

(/) The module has at least a “handful” of users Not necessarily the average users but the extension has seen more use among developers or solution providers.

(/) The module has a designated and active maintainer. Yours truly. The module has also seen development from other developers.

(/) The module is considered “stable” by the majority of the PSC Unless anyone has any recent objections.

(/) The module maintains 40% test coverage The following are the cobertura coverage reports.

Line coverage average is about 55%.

(/) The module has no IP violations

(/) The module has a page in the user manual Current documentation sits here . Updated docs will reflect changes, as as well status as extension.

(/) The maintainer has signed the GeoServer Contributor Agreement

None.

Andrea Aime: +1 Alessio Fabiani: +1 Ben Caradoc Davies: Gabriel Roldan: +1 Justin Deoliveira: +1 Jody Garnett: Simone Giannecchini: +1 Jukka Rahkonen: +1

JIRA Task Email Discussion Wiki Page