The merged class would look something like the attached, perhaps.
On 5/21/10 5:00 AM, Oleksiy Stashok wrote:
> Hi Justin,
>
> thank you very much! I think it's great that we finally will have
> Glassfish CLI commands in order to support Grizzly port unification,
> bringing it to say legal level :)
> Please see comments inlined...
>
>> This will be slightly glassfish oriented so my apologies up front,
>> but it's simpler to describe that way and is actually where my
>> concerns popped up. Under the current scheme, PU is set up in
>> domain.xml as shown in the attached grizzly-config-pu.xml. To create
>> this structure, you issue these commands (slightly pseudocoded for
>> simplicity):
>> create-protocol X-protocol
>> create-protocol-filter x-filter
>> create-protocol http
>> create-protocol pu-protocol
>> create-protocol-finder http-finder
> create-protocol-finder will have 2 params, right? Like:
>
> create-protocol-finder http-finder http-protocol
Yes, I just left them out so as to not flood everyone with details.
> Agree. In 99.99% cases users will use default
> ProtocolChain/ProtocolChainInstanceHandler implementations.
>
>> Having separate Finder and Filter classes seems a little redundant
>> and unnecessary. In this scenario, they're combined into one class.
>> You'd still have roughly the same code (slightly less due to not
>> needing all the class def stuff for both) and certainly the same
>> logic would live in the combined class. But this means it'd be
>> simpler to define/implement a custom protocol or a custom handler for
>> an existing one (check for specific header fields, e.g.) Having them
>> separate means you could have one finder but then provide different
>> implementations of the filter. You could still do this with on
>> uber-class by simply subclassing and overriding the method that
>> processes the byte stream.
> I see your point here, but not sure I see the way how we can have it.
> Currently we're having ProtocolFilter and ProtocolFinder APIs
> separated. Do you propose to extend ProtocolFilter API, or create new
> abstraction?
>
>> Ultimately, though, the big perk of something like this approach is
>> that is infinitely simpler and can be easily understood at a glance.
>> There are no arcane structures to have to look past. The creation
>> order is much easier to see and understand. The more complex cases
>> are still supported but are otherwise invisible unless you really
>> need to use them. An approach like this flattens the config and
>> removes what would otherwise be clutter to all but a handful of users.
> Right, port unification and its customization requires some knowledge,
> it's not so easy to make it simple. IMO with the command set you
> described and good documentation - it looks pretty straightforward how
> to create port unification protocol and use it in GF.
> But for sure if community will have ideas how we can make better - it
> would be great.
>
> Thanks.
>
> WBR,
> Alexey.
>> So, there's my suggestion. I actually like the proposed XML better
>> than I thought I would when I started this email (I shifted my
>> suggestion midstream once I'd started thinking it through). It may
>> not feasible to go with this exact approach, but like I said, it
>> embodies the ideas I'd like to see at least. So what do you think?
>> Is this a change worth making or is the current approach acceptable?
>> Any change we decide to make will likely need to confirmed/approved
>> by the glassfish asarch/CCC boards, but now is probably the time to
>> make any changes before we're committed to them in glassfish.
>> <grizzly-config-pu.xml><grizzly-config-new-pu.xml>---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
>