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.