On Wed, 27 Jul 2005, Jeff Genender wrote:
> For subclassing to make an SSL Gbean, I am against this...this nails up
> a particular connector GBean, where what I have allows the connector to
> be used for just that...a connector...any protocol, etc, makes no
> difference here. The Connector architecture I have implemented allows
> for a direct pass through to Tomcat's Connector object, and thus makes
> it as flexible as possible.
Here's the problem: if ConnectorGBean offers SSL settings, you're
offered the opportunity to provide/configure a bunch of stuff that is
totally irrelevant to a non-SSL connector (you know, user views an HTTP
connector, it asks them for a keystore -- what's up with that?). I don't
believe we should offer configuration and management setting that don't
apply.
So, I'd prefer to do this:
ConnectorGBean
- all connector code
- non-SSL config options
SSLConnectorGBean extends ConnectorGBean
- no additional connector code (config/mgmt only)
- always sets secure=true
- includes SSL config options (inherits non-SSL config options)
- ultimately can refer to an external keystore GBean
That wat if you go to manage a HTTP connector, it has only
settings pertinent to an HTTP connector, and if you go to manage an HTTPS
connector is has all the settings pertinent to an HTTPS connector.
Again, I'm not at all suggesting that we split up the code that
deals with the underlying Tomcat objects.
> If this is something you want to occur, then I would appreciate that
> this is opened up for discussion before anyone goes subclassing the
> ConnectorGBean.
Sorry -- I thought I wrote to the list about this aready, but it
was stuck in my postponed messages. Here was my original thought on the
topic.
Aaron
-------------------
So as part of this management API, I'd like to move a bunch of
properties out of the "initParams" and into separate properties for the
Tomcat connectors. Then those properties can be reflected in the
management interface.
One issue is that all connectors seem to support the same settings
-- in particular, the SSL settings, which I guess are just ignored unless
the secure flag is set. But it doesn't make sense to me to offer SSL
management properties for HTTP connectors.
That being the case, I'd like to break out an SSLConnectorGBean
from the ConnectorGBean. The SSL version would just extend the basic
one, add more manageable properties, and default the secure flag to true.
For now, you could still configure a SSL connector using the
standard ConectorGBean just to frustrate me, but eventually I'd like to
move all the connector properties into GBean properties and remove the
initParams all together.
> > On Wed, 27 Jul 2005, Matt Hogstrom wrote:
> >
> >>I was going to do that tonight or tomorrow and give Tomcat the same lovin.
> >>
> >>Matt
> >>
> >>
> >>----- Original Message -----
> >>From: "Aaron Mulder" <[EMAIL PROTECTED]>
> >>To: <dev@geronimo.apache.org>
> >>Sent: Wednesday, July 27, 2005 8:44 PM
> >>Subject: Jetty Max Threads Patch
> >>
> >>
> >>
> >>>Matt,
> >>>If you're up to it, can you submit an additional patch for the
> >>>Jetty connectors to fully implement
> >>>
> >>>
> >>
> >>modules/j2ee/src/java/org/apache/geronimo/j2ee/management/geronimo/WebConnec
> >>tor.java
> >>
> >>>I've verified that the underlying product supports all the methods
> >>>in there (I put the URLs in the JavaDoc). There's also a
> >>>SecureConnector.java interface in the same dir for the SSL connector.
> >>>
> >>>Thanks,
> >>>Aaron
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >>
> >>
>
