Hi Matthew,
> I've noticed that a dependency was recently introduced between the
> Grizzly 2dot0 branch and Glassfish code. For example:
>
> com.sun.grizzly.memory.jmx.ByteBufferManager:
> import org.glassfish.gmbal.Description;
> import org.glassfish.gmbal.ManagedAttribute;
> import org.glassfish.gmbal.ManagedObject;
>
> /**
> * {_at_link com.sun.grizzly.memory.ByteBufferManager} JMX object.
> *
> * @author Alexey Stashok
> */
> @ManagedObject
> @Description("Grizzly Memory Manager")
> public class ByteBufferManager extends MemoryManager {
> ...
> }
>
> 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?
> 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 :)
Thanks.
WBR,
Alexey.
[1]
http://gmbal.kenai.com/
> Many thanks,
>
> Matt
>