I was originally leaning towards 2a, but Costin has convinced me of the
merits of 2b+1. It is simplest and more generalizable to Ajp14/JNI in
j-t-c. It also allows you to skip implementing the pooling/recycling stuff
(since it should be possible to reuse one instance per connector).
If you decide on 2a, like Costin, I'd prefer it as a property of the
SocketFactory (the base class can return null, since Ajp1x would use it's
own mechanism) rather than an interface. However, it's your call.
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, November 13, 2001 8:52 AM
Subject: Re: Portable SSL Support
>
> > 3. Originally I'd intended to have ServerSockets return a class
> > that subclassed SSLSupport. E.g.
> >
> > class PureTLSSSLSocket extends SSLSocket implements SSLSupport {
> > ...
> > }
> >
> > Unfortunately, as I should have seen immediately this isn't very
> > convenient. There's no way to make JSSE return a programmer-specified
> > subclass of SSLSocket instead of SSLSocket. I can of course make
> > PureTLS do so but that ties it inappropriately to Tomcat.
>
>
> > This leaves us with two alternatives:
> > (1) Create a wrapper class for SSLSocket:
> >
> > class SSLSocketWrapper extends Socket implements SSLSupport {
> > Socket internal;
> >
> > SSLSocketWrapper(Socket sock) {
> > internal=sock;
> > }
> >
> > // Forwarding for all the relevant socket methods
> > }
> >
> > In general I hate class forwarding so I'm strongly tempted not to
> > do this.
>
> A don't like this either ( and I didn't like too much the idea
> of returning a socket that implements SSLSupport either ).
>
> What I would do is:
>
> SSLSupport {
> String getFoo( Object socket, ... );
>
> }
>
> In other words, you pass the socket from which the SSLSupport object will
> extract the information. ( it doens't have to be a socket - it can also be
> an Ajp14Connection ). I think this is quite flexible and doesn't have too
> much overhead
>
> ( but it's your choice, of course - you are writing the code :-)
>
>
> > (2) Extend/generalize the socketFactory to include an SSLSupport
> > factory. This is actually pretty convenient since the relevant
> > section of code, Http10Interceptor already has access to
> > the socketFactory information via inheritance from
> > PoolTcpConnector. This could be done in several ways
> >
> > (a) Require that all SocketFactorys that produce SSL sockets implement
> >
> > interface SSLSupportFactory {
> > public SSLSupport createSSLSupport(Socket socket);
> > }
>
> That's fine too. For Ajp connectors we could have a different mechansim to
> create the SSLSupport.
>
>
> > (b) Have a second factory object in PoolTcpConnector and use reflection
> > to look it up. I don't much like this idea because it implies that
> > you can mix and match SocketFactories with SSLSupport classes
> > which of course you cannot.
>
> Well, I like this idea - combined with the first one ( reversed ) :-)
>
> I.e:
> - SSLSupport act as a factory for SSLSocketFactories
> - user will set only the SSLSupport class, which will create the socket
> factory
> - PoolTcpConnector will just have a method 'setSSLSupport'
> - SSLSupport will be an abstract class, and will contain code to do
> reflection and create the exact implementation
> - Code using SSL will call SSLSupport.getSSLSupport() ( and maybe
> setProperty, etc ), then set it on PoolTcpConnector ( if sockets are
> used), etc.
> - SSLSupport should be independent of tomcat ( you may noticed that
> tomcat.util is compiled without any other tomcat class in classpath,
> i.e. it can't have any dependencies on any internal tomcat class ! )
>
>
> BTW, my personal preference is to avoid too many interfaces - in general I
> prefer abstract classes if it is possible. At least until it becomes clear
> we need a certain abstraction, otherwise we end up with something too
> complex. For most people ( other than the author ) it is hard to
> 'navigate' around dozens of interfaces and base classes and hierarchies (
> at least it is for me )
>
> Costin
>
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
>
*----*
This message is intended only for the use of the person(s) listed above
as the intended recipient(s), and may contain information that is
PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient,
you may not read, copy, or distribute this message or any attachment.
If you received this communication in error, please notify us immediately
by e-mail and then delete all copies of this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent
through the Internet is not secure. Do not send confidential or sensitive
information, such as social security numbers, account numbers, personal
identification numbers and passwords, to us via ordinary (unencrypted)
e-mail.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
