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.
Lloyd
On Mar 18, 2008, at 10:59 PM, Bill Shannon wrote:
> Lloyd L Chambers wrote:
>> With mixed feelings I've committed a code change we've discussed on
>> and off for some time:
>> The AMX MBeans now load ON DEMAND in an MBeanServer of their own,
>> NOT the Platform MBeanServer (call this the "Official" MBS). When
>> a request comes in for an AMX MBean (query or otherwise), all the
>> AMX MBeans are loaded at that time.
>
> Is this because you couldn't make them load on demand if the platform
> MBeanServer is used?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>
---
Lloyd L Chambers
lloyd.chambers_at_sun.com
Sun Microsystems, Inc