Hi all,
I mentioned this briefly a week or so back but I would like to propose some refactoring of the monitoring module. To sum up basically moving out the monitoring dao into a separate module resulting in two modules.
- The monitor core module - as it exists today, minus the hibernate dao
- 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.
-
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.
-
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.
I’ve thrown together an initial cut of the work, located here:
https://github.com/jdeolive/geoserver/commit/6c46371e6b7816cd08219ecce175e582f5be119e
Thoughts? Opinions?
-Justin
–
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
On Fri, Dec 7, 2012 at 5:38 AM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
Hi all,
I mentioned this briefly a week or so back but I would like to propose some refactoring of the monitoring module. To sum up basically moving out the monitoring dao into a separate module resulting in two modules.
- The monitor core module - as it exists today, minus the hibernate dao
- 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.
-
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.
-
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.
Seems reasonable, makes me just wonder if audit logging should not be seen as a separate storage mechanism with its own DAO… although there is a catch, it would not be able to operate in live mode, but only in history mode.
I’ve thrown together an initial cut of the work, located here:
https://github.com/jdeolive/geoserver/commit/6c46371e6b7816cd08219ecce175e582f5be119e
Thoughts? Opinions?
Monitoring is growing quite a bit for a community module. Any plans to graduate it to extension status?
Cheers
Andrea
–
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
On Fri, Dec 7, 2012 at 2:18 AM, Andrea Aime <andrea.aime@anonymised.com>wrote:
On Fri, Dec 7, 2012 at 5:38 AM, Justin Deoliveira <jdeolive@anonymised.com>wrote:
Hi all,
I mentioned this briefly a week or so back but I would like to propose
some refactoring of the monitoring module. 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.
Seems reasonable, makes me just wonder if audit logging should not be seen
as a separate storage mechanism with its own DAO... although there is a
catch, it would not be able to operate in live mode, but only in history
mode.
Yeah, makes sense. I can take a crack at it if you would like since i am
already playing around there. Regarding support for modes we actually have
the same issue with the memory dao, in that it doesn't really do history
mode. I imagine just having the daos log a warning when a mode is set that
they don;t support would probably suffice though.
I've thrown together an initial cut of the work, located here:
https://github.com/jdeolive/geoserver/commit/6c46371e6b7816cd08219ecce175e582f5be119e
Thoughts? Opinions?
Monitoring is growing quite a bit for a community module. Any plans to
graduate it to extension status?
Agreed. This change was really the last major change i had on my todo list.
I think it would great to push monitoring to extension. Happy to start
pushing on this.
Cheers
Andrea
--
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
-------------------------------------------------------
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Seems reasonable, makes me just wonder if audit logging should not be seen as a separate storage mechanism with its own DAO… although there is a catch, it would not be able to operate in live mode, but only in history mode.
Cool, proceed as you see fit (the above was not a requirement by any means, was mostly sharing an idea).
Nice 
Cheers
Andrea
···
Yeah, makes sense. I can take a crack at it if you would like since i am already playing around there. Regarding support for modes we actually have the same issue with the memory dao, in that it doesn’t really do history mode. I imagine just having the daos log a warning when a mode is set that they don;t support would probably suffice though.
I’ve thrown together an initial cut of the work, located here:
https://github.com/jdeolive/geoserver/commit/6c46371e6b7816cd08219ecce175e582f5be119e
Thoughts? Opinions?
Monitoring is growing quite a bit for a community module. Any plans to graduate it to extension status?
Agreed. This change was really the last major change i had on my todo list. I think it would great to push monitoring to extension. Happy to start pushing on this.