dev@grizzly.java.net

Re: Moving JMX monitoring logic to separate modules

From: Ryan Lubke <ryan.lubke_at_oracle.com>
Date: Wed, 08 May 2013 10:20:30 -0700

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"