JMX code - inplace or separate bundle?

[Justin Edelson <ju...@justinedelson.com>]

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. 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.
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?

WDYT?

Justin

Re: JMX code - inplace or separate bundle?

[Bertrand Delacretaz <bd...@apache.org>]

Hi Justin,

On Wed, Jun 15, 2011 at 12:13 AM, Justin Edelson
<ju...@justinedelson.com> 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