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? 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.
Jan Luehe wrote:
> On 02/06/09 09:53, Jeanfrancois Arcand wrote:
>> Salut,
>>
>> cc-ing the creator of that class :-)
>>
>> A+
>>
>> -- Jeanfrancois
>>
>> Justin Lee wrote:
>>> I'm trying to move the classes related to wiring up grizzly in
>>> glassfish to grizzly-config to centralize that code and I'm slogging
>>> through some of the glassfish intertwinings. One class that's in
>>> glassfish but appears to only be used in grizzly related code is
>>> ThreadPoolProbeProvider. Anyone know much about that? Is it safe
>>> to migrate that one?
>
> Yes, you can safely migrate it.
>
> Jan
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>