tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: svn commit: r465303 - in /tomcat/tc6.0.x/trunk: java/org/apache/coyote/http11/ java/org/apache/tomcat/util/net/ webapps/docs/ webapps/docs/config/
Date Wed, 18 Oct 2006 21:22:10 GMT
Remy Maucherat wrote:
> Filip Hanik - Dev Lists wrote:
>> Mladen Turk wrote:
>>> Filip Hanik - Dev Lists wrote:
>>>> to eager to press send, that way the connector would have only 
>>>> on/off values, while the actual SSLEngine value neuron would be in 
>>>> the APRLifeCycleListener,
>>>> much cleaner, and all our connectors become consistent on that value
>>> Look, 
>> no need to get edgy :), your point is well taken.
>>> SSLEngine concept was derived from mod_ssl where SSLEngine
>>> toggles the usage of SSL/TLS (usually per VHost).
>>> We extended that (because we can not have per-vhost connectors)
>>> on the connector basis and added optional initialization for
>>> hardware SSL engines, and thus conceptually has nothing to
>>> do with the thing you are trying to use it for.
>> I understand the concept, but because the JNI API has a limitation of 
>> "one per VM" according to the code, then the connector is the wrong 
>> place to put it in.
>>> It would mean that the same directive (SSLEngine) would
>>> have two different meanings/purposes depending on the
>>> connector itself.
>>  > I would suggest that you came up with a different name
>>> (as well as documentation) that would properly describe
>>> what you are trying to do.
>> Lets expand on that suggestion then, lets come up with an attribute 
>> that goes across all three connectors, currently APR is using 
>> SSLEngine for dual purposes, including the "on" value which does the 
>> same as the Java connectors. So instead of having attributes with 
>> dual features, that always at some point become problems cause folks 
>> will want one feature but not the other, lets agree on something.
> Let's keep SSLEngine: it's explicit, and it works.
not really, this wouldn't work
<Connector port="8444" scheme="https" secure="true" 
<Connector port="8555" scheme="https" secure="true" 

Fully valid configuration, and the docs don't mention that a uniqueness 
have to be enforced, configuration should be as easy as possible,
and I believe we have a spot here to make it easier, if it is a one per 
server value, then lets put it where it would only be initialized once.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message