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.
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
>