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
> create-protocol-finder X-protocol-finder
The same here:
create-protocol-finder X-protocol-finder X-protocol
> That's a little involved and creates quite a bit of, well, noise in
> the xml file. I'd like to simplify that a bit as I think some
> things are a little redundant. Consider this alternative shown in
> grizzly-config-new-pu.xml. This process would be created with:
> create-protocol X-protocol
> create-protocol http
> create-protocol pu-protocol
> This approach uses half the classes (because we merge the idea of
> the Finders and Filters) and half the steps. And is, to my mind,
> much easier to comprehend. While I'm not advocating this approach
> *specifically* it embodies a number ideas I'd like to throw out.
> And those points are as follows.
> Several arcane elements become implicit structures. If you don't
> know what ProtocolChainInstanceHandler is (and I don't ;) ) then you
> need never know or care that it's there. Same with ProtocolChain
> and PortUnification. These elements really just serve to contain
> other elements and allow to specify a classname for a custom
> implementation. Still want to do that? Great! just specify them
> as attribute on the "pu-protocol" element. Easy!
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