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
>