Hi Justin, On Wed, Jun 15, 2011 at 12:13 AM, Justin Edelson <[email protected]> wrote: > I'd like to go ahead and commit the code attached to SLING-1476 with > some additions to start pushing forward on adding JMX instrumentation > to Sling...
Sounds good - I just added some minor comments to that issue. > ...I'm trying to decide whether or not this should be placed > into the engine bundle or as a separate bundle. This particular bit of > JMX support can go in either place, but I'd like to use it to > establish some best practices around JMX instrumentation within Sling.... I'd put the JMX support (as provided by SLING-1476 for now) in its own bundle, assuming that this will need to be extended later with utility classes to help create MBeans, webconsole plugins etc. > ...While a simple Filter can be used to track request counts (and > min/max/average times), that may not always be the case, e.g. > instrumenting the servlet resolver or the JCR resource resolver. > > So the question is... do we add a separate instrumentation bundle just > for things which can be instrumented externally to the bundle or start > establishing the idea that each bundle is responsible for providing > its own instrumentation?... If providing MBeans does not require adding dependencies (outside of basic JMX deps) to a bundle, I'd add the MBeans and instrumentation code in the bundle. Maybe use bundlename.impl.mbeans (or impl.jmx) as the package name by convention so have some consistency. OTOH, if MBeans and instrumentation require additional dependencies that the bundle would not need without them, I'd create a separate bundle. -Bertrand
