Hi,
> What i'm tempted to do is to abstract this method in GrizzlyService
> to simply create a StatsThreadPool in Grizzly and then override in
> glassfish to create the Probe stuff. It looks like all this
> ProbeParam stuff is for glassfish monitoring (and only in a very
> niche case at that). Then I can move several classes back to
> glassfish.
I agree here. Probes were introduced my Jan just for monitoring
reasons as wrappers above Grizzly thread pool (worker threads), so
IMHO, there is no reason to move it under Grizzly.
WBR,
Alexey.
>
> Justin Lee wrote:
>> Hrm. It does not appear that ThreadPoolProbeProvider is used
>> outside of GrizzlyService... What exactly does @ProbeParam
>> provide? It's part of the glassfish flashlight module... I'll see
>> if there's any javadoc worth reading.
>>
>> Justin Lee wrote:
>>>
>>>
>>> Jeanfrancois Arcand wrote:
>>>> Salut,
>>>>
>>>> Justin Lee wrote:
>>>>> The grizzly related code in glassfish has a pretty convoluted.
>>>>> I'm doing my best to sever that as much as possible but I'm
>>>>> seeing some places where that might not be (cleanly) possible.
>>>>> I'm hoping to be able to move stuff over and subclass in the
>>>>> glassfish tree in some places to provide the additional hooks
>>>>> that glassfish uses. I'm not sure that's going to be possible
>>>>> everywhere, though. How bad would "small" deps be on certain
>>>>> glassfish artifacts be inside the grizzly-config module?
>>>>
>>>> That's fine but I hope you don't have to bring the entire GF
>>>> dependencies tree. Since Grizzly is pretty small, having too many
>>>> dependencies might prevent adoption of that module.
>>> Same here. I'm hoping to get rid of all of them. I'm not sure I
>>> can fix the Result dep but I'll explore glassfish subclassing as
>>> outlined below.
>>>>
>>>>
>>>> e.g., Result is used in a number of places and
>>>>> those might be hard to extract. I have the dep defined right
>>>>> now for convenience and I'm going to try to work that dep back
>>>>> out but it might be hard sailing.
>>>>>
>>>>> So with all that in mind, would it be the end of the world? I
>>>>> don't like and I'm trying to avoid that but I'm afraid of ending
>>>>> up with horribly convoluted code otherwise.
>>>>
>>>> Can you elaborate about the convoluted part?
>>>>
>>> e.g., there's GrizzlyService. For the most part, this is all
>>> grizzly stuff and can be moved over. However, there are some
>>> glassfish related lifecycle methods. Now, in this case, i think i
>>> can move over the bulk of GrizzlyService and then subclass in
>>> Glassfish to proved those extra hooks that glassfish needs but
>>> grizzly doesn't. In this case, I think we can cut a clear line.
>>> I'm less hopeful in other areas, but I'm doing some clean up of
>>> static util classes like GrizzlyListenerConfigurator that seems to
>>> be helping.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>