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