Bill,
It won't hurt to ask Eamonn (I will); this has been an issue for years
though; the API doesn't allow insertion of a hook; it requires
wrapping which means that the MBeanServer must be wrapped when first
built, as opposed to having something inserted into it later when
needed/available.
The basic driver of issues is that the code is in the JDK and the JDK
supports certain features (eg profiling) that allowing creating the
MBeanServer prior to main(), which causes problems for any product
doesn't just put all its jar files in the classpath before launch.
In V2 the problem was even worse; making the wrapper class available
caused recursive needs for all sorts of classes. I tried one day and
had to add jar after jar.
In V3, the module-based system might make the problem easier or
harder, I'm not sure.
Lloyd
On Mar 19, 2008, at 1:54 PM, Bill Shannon wrote:
> 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?
>
>
>
> ---------------------------------------------------------------------
> 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