[EMAIL PROTECTED] wrote:
>
> Hi Christopher,
>
> I just checked, and for 3.3 you don't need any change in the core or any
> other place in tomcat.
Cool, I didn't think so. I figure that if I needed a core change for a
command-line challenge at startup, I most probably did something wrong.
=)
> All you need to do is write a simple interceptor and implement
> addInterceptor() callback.
> In the implementation all you have to do is ask for a password ( one
> sugestion: you can add an option and before asking for pass you can do a
> url connection to a "key server" ? ).
> You will also need to call getModules(), look for Http10Interceptor and
> call setKeypass().
Yep, I can certainly implement it that way if you like. How does that
jive with the current server.xml setup, though? Isn't there still a
separate <Connector> tag in 3.3 for SSL? Does that then go away in favor
of the Interceptor, or does the Interceptor become the "secured" cert
option and the current connector become the "unsecured" option (with
appropriate commenting, of course)?
Also, I'm a little confused about why an Interceptor makes sense here.
All I need to do is prompt for a password on container startup, then use
that value to open the keystore rather than grabbing it from the
"keystorePass" parameter on the <Connector> tag. Isn't the purpose of
Interceptors to process client requests (can you tell I've never used
them :-)? Maybe I just need a little clarification.
I assume you didn't like my "grab the keystorePass attribute if it's
there, prompt if it's not idea"?
> I'm -1 on checking this into tomcat CVS, +1 on checking it into a
> "modules" repository or placing it anywhere outside tomcat. The reasons:
> first we're in beta, that means only bug fixes. But the important one -
> this is not an "essential" feature, I think it's very important to keep
> the basic distribution focused on what's essential and without featurism.
> ( I agree there are many modules in the current 3.3 distribution that are
> also not essential and shouldn't be there, but it's hard to remove
> existing code, even if that would be benefical ).
>
> Please don't let this affect your work - I'm -1 on adding any feature that
> is not required by the spec as long as it can be implemented as a module,
> including my own "itches".
Cool. Honestly, I'm not too hung up on where the code lives, or to a
certain extent how it's even hooked in. So if you prefer an Interceptor
then Interceptor it is.
> If you find you need any additional callback or API in the core or
> existing modules - please let us know ASAP, that would be a flaw that must
> be fixed before we release.
Will do.
- Christopher
