Agreed, we should remove the flag (see my other message): --
Djavax.management.builder.initial
=com.sun.enterprise.admin.server.core.jmx.AppServerMBeanServerBuilder
We should try very hard to not have any need for it as it can only
incur incompatibility issues. The reasons we had in V2 for it were
minimal and Kedar is going to design a much better syste for V3
(pushing config to remote systems).
Lloyd
On Feb 8, 2008, at 10:38 AM, Kedar Mhaswade wrote:
>
>
> Nandini Ektare wrote:
>>>> Interestingly, using java -jar to start the server I do not see
>>>> the class not found exceptions for
>>>> com.sun.enterprise.admin.server.core.jmx.AppServerMBeanServerBuilde
>>>> r that I see when I run using mvn gf:run.
>>> looks like the domain.xml that is being used when doing gf:run
>>> still has the jvmOption to set the MBeanServer like in V2. I have
>>> removed that jvm option from the nucleus-base.zip's domain.xml
>>> since we will be using the JDK MBeanServer in v3, so I am not
>>> sure why you still have the old one.
>> In v2 MBeanServer startup was controlled using this property to
>> get a way to intercept MBeanServer startup in a way to allow us to
>> wrap the PlatformMBeanServer (JDK's MBeanServer) with our
>> interceptor (which also had the ability to register some basic
>> config mbeans during startup). The JDK MBeanServer is used even in
>> v2.
>> I agree that if v3 does not plan to use the custom interceptor,
>> the system property is redundant but otherwise we need it.
>
> Correct.
> At some point, we might need an interceptor. That adds some
> flexibility
> and the only way to do is through this -D. Since config is done
> differently
> for V3, this may not be needed immediately, but we might
> reintroduce this
> later.
>
> - Kedar
>
>> Nandini
>>>> Further, if I run with mvn gf:run then I see the exceptions I
>>>> wrote about last night but I *do *get a new domain.xml in the
>>>> domain's config directory!
>>>>
>>>> Odd. Any ideas?
>>>>
>>>> - Tim
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
---
Lloyd L Chambers
lloyd.chambers_at_sun.com
Sun Microsystems, Inc