Hi Alexey,
Thanks for the quick response. Too quick in fact, as I was switching my
java.net subscriptions from @sun.com to @oracle.com and missed your
response! :-/
Responses below...
On -10/01/37 20:59, Oleksiy Stashok wrote:
> Hi Matthew,
>
>> I've noticed that a dependency was recently introduced between the
>> Grizzly 2dot0 branch and Glassfish code. For example:
>>
>> [...]
>>
>> Is this just a temporary state of the code? If not, how are
>> non-Glassfish applications supposed to compile/use Grizzly without
>> pulling in a bunch of unwanted code?
> It's actually not GF code, it's Grizzly :)
> We're planning to use gmbal project [1] for JMX support in Grizzly
> 2.0. Yes, gmbal is also used by GF, but we use it directly without any
> GF dependency. The complete gmbal impl. is 200K jar big, but the API
> bundle (which we're finally have embedded) is just 20K. It shouldn't
> be a big dependency, isn't it?
Ahhh - I hadn't heard of gmbal. It looks pretty neat and we could use it
ourselves in OpenDS: we already have JMX monitoring support but this
framework looks like it might make it easier to develop in future.
My main concern is for client application developers who will want small
lightweight libraries. I don't think that they will want/need the JMX
monitoring support so they will just take the 20KB hit of the API only
bundle, which is almost nothing. If it is embedded into Grizzly then
even better still. :-)
>
>> Also, it looks like a load of funky changes have been made in the
>> 2dot0 core Grizzly APIs (e.g. probes) recently. Are there any which
>> we should be particularly aware of and use?
> If you won't be interested in monitoring Grizzly - then not :) If yes
> - we're planning to document those probes :)
>
Cool - I think that the monitoring will be useful for us, especially
when we use Grizzly in our core server.
Matt