From: Bongjae Chang <bongjae.chang_at_gmail.com>
Date: Mon, 13 May 2013 11:06:09 +0900

+1
I am also much in favor of removing Gmbal dependency.

Regards,
Bongjae Chang


From: Ryan Lubke <ryan.lubke_at_oracle.com>
Reply-To: <dev_at_grizzly.java.net>
Date: Thursday, May 9, 2013 2:20 AM
To: <dev_at_grizzly.java.net>
Subject: Re: Moving JMX monitoring logic to separate modules

At the moment, I don't see a better alternative, so +1 for the separation.

>
>
>
> Oleksiy Stashok <mailto:oleksiy.stashok_at_oracle.com>
>
> May 7, 2013 5:44 PM
>
> Hi guys,
>
> wanted to hear your feedback on the subj.
> It is related to the issue [1], looks like the majority of incompatible
> classes come from Gmbal (+ JMX) dependency.
> IMO the way we can solve this issue is separate Gmbal (JMX) logic to separate
> modules, so we'll create separate monitoring module for each existing module
> that has Gmbal dependency.
>
> For example we'll create additional grizzly-framework-monitoring,
> grizzly-http-monitoring, grizzly-http-server-monitoring etcetc... modules.
> This way existing grizzly-framework, grizzly-http, grizzly-http-server (etc)
> will not have any dependency on Gmbal (JMX) and if we need monitoring we'll
> have to include correspondent monitoring module.
>
> I see following pros and cons:
> Pros: decrease basic module size, remove Gmbal (JMX) dependency in order to
> make Grizzly compatible with compact2 java 8 profile
> Cons: we create lots of extra modules (additional monitoring module per each
> basic module).
>
> What do you think?
>
> Thanks.
>
> WBR,
> Alexey.
>
> [1]
> https://java.net/jira/browse/GRIZZLY-1477
> " Make Grizzly runnable on compact2 java 8 profile"
>