Lloyd L Chambers wrote:
> Bill,
>
> Correct. There are no "hooks" for virtualization/on demand loading
> other than "wrapping" an MBeanServer--a regrettable design flaw IMO.
> The only option is an inner/outer pattern in which the outer ("wrapper")
> MBeanServer watches for activity of interest, passing along requests to
> the inner (standard) MBeanServer, which accommodates this process by
> being aware of a possible wrapper.
>
> Wrapping the Platform MBeanServer was done in V2 and a variety of bugs
> remain as a result. For example, profilers and other such things that
> run before main() fail, because the wrapper class itself as well as any
> classes it might use are not available before main() is called; this
> precludes creating an MBeanServer until later in the boot process, which
> causes the profiler (or whatever) code to fail.
>
> So to avoid the incompatibility problems, a new MBeanServer is created
> at a time of our choice (early in the startup process). It is wrapped
> so that we can intercept all MBeanServer calls.
Has Eamonn suggested any better approach?
Have we considered asking the owners of the platform MBeanServer to add
the capabilities we need, in a non-standard way if necessary?
Is it worth having two code paths, one that allows us to use (or replace)
the platform MBeanServer when possible, and the other as you've currently
done?
Your current approach may be the best we can do easily, but for people who
want the benefits of integrating with the platform MBeanServer, and are
willing to do extra work, can we offer that choice as well?