-------- Original Message --------
Subject: port unification structure
Date: Thu, 20 May 2010 10:39:56 -0400
From: Justin Lee <justin.d.lee_at_oracle.com>
Reply-To: dev_at_grizzly.dev.java.net
To: dev_at_grizzly.dev.java.net
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):
1. create-protocol X-protocol
2. create-protocol-filter x-filter
3. create-protocol http
4. create-protocol pu-protocol
5. create-protocol-finder http-finder
6. create-protocol-finder X-protocol-finder
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:
1. create-protocol X-protocol
2. create-protocol http
3. 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.
1. 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!
2. 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.
3. 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.
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.