Re: Coyote's ServerSocketFactory problem
Ok, I decided to modify the Http11Processor, since the SSL trick is kindof too hacky for my taste. It sets the attribute, and it's fine now. Another issue came up though with flushing the OutputStream - and this is something unrelated to the previous conversation. So in org.apache.coyote.http11.InternalOutputBuffer when endRequest() is called - on line 442 socketBuffer.flushBuffer() will in turn call realWriteBytes which does a write on the actual outputStream, but nothing will ever call flush() on the outputStream. This is not noticeable in case of the normal java.net.SocketOutputStream (it's unbuffered from what i can tell), but since I have overriden the outputstream and my class needs to be either flush()'ed or close()'ed, as a result my stuff is never sent back to the client, hanging the requests. I would think it's reasonable to expect a flush at some point on the OutputStream when ending the request, no? This lack of flushing in not present in the HttpConnector, in tomcat 4. thank you -anton On Fri, 2004-04-02 at 17:14, Bill Barker wrote: - Original Message - From: Anton Ushakov [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, April 02, 2004 10:46 AM Subject: Re: Coyote's ServerSocketFactory problem First I must say you've been extremely helpful, thank you for your prompt responses! I hate to bug you but I had another implementation question. I looked at JSSESocketFactory and how SSL is done in the connector, but it doesnt address one particular issue I'm having. Basically I have JAAS (GSSAPI) authentication done inside the Socket that my SocketFactory makes. Let's call it GssSocket, and it uses GssInputStream GssOutputStream for the authenticated encrypted communication. Inside the GssSocket I establish the identity (principal) of the incoming request, but have no way to set it into the CoyoteRequest so it can get passed to the target Servlets through the HttpServletRequest. Since all the servlet sees is the CoyoteRequestFacade, I cannot get access to either the GssSocket, or the GssStreams - the only places where the principal of the user is known. It looks like I can't avoid extending one of the Coyote classes after all. What would you suggest to override to be able to extract a string from the Socket and set it as an attribute for the servlets to get at? I'm sorry if this is getting too hairy, but any advice would be great. It's probably possible to do what you want without much, if any, modifying of Tomcat code. If you were to setup a full SSLImplementation to implement your socket factory, then you could have your code return the identity information in response to 'request.getAttribute(org.apache.coyote.request.X509Certificate)'. This should work because nothing in Tomcat outside of the SSLImplementation understands anything about SSL, so it won't really care that you aren't implementing real SSL. This method is a little hackish, but it has the advantage that you don't have to modify any of Tomcat's code to get it to work. The downside is that you have to implement a minimum of three classes, even if you can make most of the methods to be dummies. You'd also need to worry about the scheme getting set to https, but I could be talked into modifying that. Otherwise, you'd probably have to modify Http11Processor (about the only class that has access to both the Request and the Socket :) to set the attributes you want on the Request. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Coyote's ServerSocketFactory problem
- Original Message - From: Anton Ushakov [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, April 02, 2004 10:46 AM Subject: Re: Coyote's ServerSocketFactory problem First I must say you've been extremely helpful, thank you for your prompt responses! I hate to bug you but I had another implementation question. I looked at JSSESocketFactory and how SSL is done in the connector, but it doesnt address one particular issue I'm having. Basically I have JAAS (GSSAPI) authentication done inside the Socket that my SocketFactory makes. Let's call it GssSocket, and it uses GssInputStream GssOutputStream for the authenticated encrypted communication. Inside the GssSocket I establish the identity (principal) of the incoming request, but have no way to set it into the CoyoteRequest so it can get passed to the target Servlets through the HttpServletRequest. Since all the servlet sees is the CoyoteRequestFacade, I cannot get access to either the GssSocket, or the GssStreams - the only places where the principal of the user is known. It looks like I can't avoid extending one of the Coyote classes after all. What would you suggest to override to be able to extract a string from the Socket and set it as an attribute for the servlets to get at? I'm sorry if this is getting too hairy, but any advice would be great. It's probably possible to do what you want without much, if any, modifying of Tomcat code. If you were to setup a full SSLImplementation to implement your socket factory, then you could have your code return the identity information in response to 'request.getAttribute(org.apache.coyote.request.X509Certificate)'. This should work because nothing in Tomcat outside of the SSLImplementation understands anything about SSL, so it won't really care that you aren't implementing real SSL. This method is a little hackish, but it has the advantage that you don't have to modify any of Tomcat's code to get it to work. The downside is that you have to implement a minimum of three classes, even if you can make most of the methods to be dummies. You'd also need to worry about the scheme getting set to https, but I could be talked into modifying that. Otherwise, you'd probably have to modify Http11Processor (about the only class that has access to both the Request and the Socket :) to set the attributes you want on the Request. thanks -anton On Thu, 2004-04-01 at 13:32, Bill Barker wrote: - Original Message - From: Anton Ushakov [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, March 31, 2004 10:59 PM Subject: Re: Coyote's ServerSocketFactory problem Alright, thanks Bill. I have nothing against Tomcat5 and indeed the socketFactory=my.factory attribute works. But is there any way to pass custom parameters to the factory from the conf file? With a Factory element it was possible but with a single attribute am I out of luck? All this IntrospectionUtils business is confusing... The way this works is that all of the Connector attributes are passed on to the Protocol. In the case of the Http11Protocol, the attributes are then passed on to the SocketFactory (via calling the setAttribute method of o.a.t.u.net.ServerSocketFactory). So all you have to do is to set your parameters on the Connector, and they will end up passed to your SocketFactory. You can look at JSSESocketFactory to see how Tomcat handles this for the default SSL connector. On Fri, 2004-03-26 at 18:03, Bill Barker wrote: - Original Message - From: Anton Ushakov [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, March 26, 2004 4:24 PM Subject: Re: Coyote's ServerSocketFactory problem Should I make a bug entry for this? I wanted to get someone from the tomcat dev team to see if I was missing something before flagging this as a bug. The Catalina SocketFactory is deprecated for use with Coyote in 5.x, and it would probably should be for 4.x as well except for the fact that it is still required to set SSL attributes. This means that anything involving this SocketFactory will just get marked as WONTFIX. Passing the socketFactory attribute on to the Protocol might be something (except for the fact that it is working in 5.x means it may not get a lot of attention :). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [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
Re: Coyote's ServerSocketFactory problem
First I must say you've been extremely helpful, thank you for your prompt responses! I hate to bug you but I had another implementation question. I looked at JSSESocketFactory and how SSL is done in the connector, but it doesnt address one particular issue I'm having. Basically I have JAAS (GSSAPI) authentication done inside the Socket that my SocketFactory makes. Let's call it GssSocket, and it uses GssInputStream GssOutputStream for the authenticated encrypted communication. Inside the GssSocket I establish the identity (principal) of the incoming request, but have no way to set it into the CoyoteRequest so it can get passed to the target Servlets through the HttpServletRequest. Since all the servlet sees is the CoyoteRequestFacade, I cannot get access to either the GssSocket, or the GssStreams - the only places where the principal of the user is known. It looks like I can't avoid extending one of the Coyote classes after all. What would you suggest to override to be able to extract a string from the Socket and set it as an attribute for the servlets to get at? I'm sorry if this is getting too hairy, but any advice would be great. thanks -anton On Thu, 2004-04-01 at 13:32, Bill Barker wrote: - Original Message - From: Anton Ushakov [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, March 31, 2004 10:59 PM Subject: Re: Coyote's ServerSocketFactory problem Alright, thanks Bill. I have nothing against Tomcat5 and indeed the socketFactory=my.factory attribute works. But is there any way to pass custom parameters to the factory from the conf file? With a Factory element it was possible but with a single attribute am I out of luck? All this IntrospectionUtils business is confusing... The way this works is that all of the Connector attributes are passed on to the Protocol. In the case of the Http11Protocol, the attributes are then passed on to the SocketFactory (via calling the setAttribute method of o.a.t.u.net.ServerSocketFactory). So all you have to do is to set your parameters on the Connector, and they will end up passed to your SocketFactory. You can look at JSSESocketFactory to see how Tomcat handles this for the default SSL connector. On Fri, 2004-03-26 at 18:03, Bill Barker wrote: - Original Message - From: Anton Ushakov [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, March 26, 2004 4:24 PM Subject: Re: Coyote's ServerSocketFactory problem Should I make a bug entry for this? I wanted to get someone from the tomcat dev team to see if I was missing something before flagging this as a bug. The Catalina SocketFactory is deprecated for use with Coyote in 5.x, and it would probably should be for 4.x as well except for the fact that it is still required to set SSL attributes. This means that anything involving this SocketFactory will just get marked as WONTFIX. Passing the socketFactory attribute on to the Protocol might be something (except for the fact that it is working in 5.x means it may not get a lot of attention :). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Coyote's ServerSocketFactory problem
- Original Message - From: Anton Ushakov [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Wednesday, March 31, 2004 10:59 PM Subject: Re: Coyote's ServerSocketFactory problem Alright, thanks Bill. I have nothing against Tomcat5 and indeed the socketFactory=my.factory attribute works. But is there any way to pass custom parameters to the factory from the conf file? With a Factory element it was possible but with a single attribute am I out of luck? All this IntrospectionUtils business is confusing... The way this works is that all of the Connector attributes are passed on to the Protocol. In the case of the Http11Protocol, the attributes are then passed on to the SocketFactory (via calling the setAttribute method of o.a.t.u.net.ServerSocketFactory). So all you have to do is to set your parameters on the Connector, and they will end up passed to your SocketFactory. You can look at JSSESocketFactory to see how Tomcat handles this for the default SSL connector. On Fri, 2004-03-26 at 18:03, Bill Barker wrote: - Original Message - From: Anton Ushakov [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, March 26, 2004 4:24 PM Subject: Re: Coyote's ServerSocketFactory problem Should I make a bug entry for this? I wanted to get someone from the tomcat dev team to see if I was missing something before flagging this as a bug. The Catalina SocketFactory is deprecated for use with Coyote in 5.x, and it would probably should be for 4.x as well except for the fact that it is still required to set SSL attributes. This means that anything involving this SocketFactory will just get marked as WONTFIX. Passing the socketFactory attribute on to the Protocol might be something (except for the fact that it is working in 5.x means it may not get a lot of attention :). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Coyote's ServerSocketFactory problem
Alright, thanks Bill. I have nothing against Tomcat5 and indeed the socketFactory=my.factory attribute works. But is there any way to pass custom parameters to the factory from the conf file? With a Factory element it was possible but with a single attribute am I out of luck? All this IntrospectionUtils business is confusing... On Fri, 2004-03-26 at 18:03, Bill Barker wrote: - Original Message - From: Anton Ushakov [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, March 26, 2004 4:24 PM Subject: Re: Coyote's ServerSocketFactory problem Should I make a bug entry for this? I wanted to get someone from the tomcat dev team to see if I was missing something before flagging this as a bug. The Catalina SocketFactory is deprecated for use with Coyote in 5.x, and it would probably should be for 4.x as well except for the fact that it is still required to set SSL attributes. This means that anything involving this SocketFactory will just get marked as WONTFIX. Passing the socketFactory attribute on to the Protocol might be something (except for the fact that it is working in 5.x means it may not get a lot of attention :). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Coyote's ServerSocketFactory problem
Should I make a bug entry for this? I wanted to get someone from the tomcat dev team to see if I was missing something before flagging this as a bug. thank you -anton On Wed, 2004-03-24 at 17:16, Anton Ushakov wrote: In CoyoteConnector.initialize() there's an assumption that if the factory is an instance of CoyoteServerSocketFactory, it's gonna be SSL, and it sets secure=true. Then in Http11ConnectionHandler.checkSocketFactory() in the Http11Protocol.java, it interprets that secure flag as SSL and uses SSLImplementation to get the socket factory. In our case, the scheme is not ssl, so unfortunately this doesn't work. Http11Protocol just wasn't written to accept a socket factory object, and the one it makes from the passed classname is of a different type than CoyoteConnector's socket factory. It's not enough to make the types the same, it really should take a whole factory object, since the factory's attributes need to be set from the conf. On Wed, 2004-03-24 at 16:03, Jim Hopp wrote: We have a similar need (though for a different reason) and extend CoyoteServerSocketFactory. We're running TC 4.1.29. Here's our Connector element: Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=7002 scheme=https secure=true address=127.0.0.1 enableLookups=false Factory className=nyw.catalina.NYWCoyoteServerSocketFactory clientAuth=true/ /Connector Works great. -Jim Anton Ushakov wrote: Hello Tomcat Developers! I'm working with Tomcat 4.1.29 and I'd like to use my own ServerSocketFactory, as I'm working on a custom implementation of httpg (HTTP over GSSAPI authenticated sockets). This seems impossible by design, which I think may be a bug. Instead of using the deprecated HttpConnector I'm trying to use the CoyoteConnector. The trouble is, with CoyoteConnector there is no way to override the ServerSocketFactory to be used. My CustomServerSocketFactory implements org.apache.catalina.net.ServerSocketFactory, and I tried using the following in server.xml: Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=6688 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=100 debug=50 connectionTimeout=2 scheme=httpg useURIValidationHack=false disableUploadTimeout=true Factory className=my.own.CustomServerSocketFactory principal=service/[EMAIL PROTECTED] keytab=/etc/keytab / /Connector This will successfully set the factory in CoyoteConnector, but it does NOT propagate to org.apache.coyote.http11.Http11Protocol, and the actual factory getting used at runtime is the default one in Http11Protocol. The CoyoteConnector's factory datamember is totally ignored. I would think that in org/apache/coyote/tomcat4/CoyoteConnector.java around lines -1135 there should be something to propagate the socket factory to the protocolHandler. However even then, Http11Protocol insists on using org.apache.tomcat.util.net.ServerSocketFactory, not the org.apache.catalina.net.ServerSocketFactory required by the CoyoteConnector. (?) Bottom line - how is one supposed to specify a custom ServerSocketFactory with the CoyoteConnector? Bill Barker has emailed me a suggestion of using the socketFactory=fully.qualified.name.of.MyOwnServerSocketFactory attribute on the Connector element. While I appreciate the response, that doesn't set the factory datamember in the Connector, and neither does it change the socketFactory in the protocolHandler. I appreciate your help on this -anton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Coyote's ServerSocketFactory problem
- Original Message - From: Anton Ushakov [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Friday, March 26, 2004 4:24 PM Subject: Re: Coyote's ServerSocketFactory problem Should I make a bug entry for this? I wanted to get someone from the tomcat dev team to see if I was missing something before flagging this as a bug. The Catalina SocketFactory is deprecated for use with Coyote in 5.x, and it would probably should be for 4.x as well except for the fact that it is still required to set SSL attributes. This means that anything involving this SocketFactory will just get marked as WONTFIX. Passing the socketFactory attribute on to the Protocol might be something (except for the fact that it is working in 5.x means it may not get a lot of attention :). thank you -anton On Wed, 2004-03-24 at 17:16, Anton Ushakov wrote: In CoyoteConnector.initialize() there's an assumption that if the factory is an instance of CoyoteServerSocketFactory, it's gonna be SSL, and it sets secure=true. Then in Http11ConnectionHandler.checkSocketFactory() in the Http11Protocol.java, it interprets that secure flag as SSL and uses SSLImplementation to get the socket factory. In our case, the scheme is not ssl, so unfortunately this doesn't work. Http11Protocol just wasn't written to accept a socket factory object, and the one it makes from the passed classname is of a different type than CoyoteConnector's socket factory. It's not enough to make the types the same, it really should take a whole factory object, since the factory's attributes need to be set from the conf. On Wed, 2004-03-24 at 16:03, Jim Hopp wrote: We have a similar need (though for a different reason) and extend CoyoteServerSocketFactory. We're running TC 4.1.29. Here's our Connector element: Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=7002 scheme=https secure=true address=127.0.0.1 enableLookups=false Factory className=nyw.catalina.NYWCoyoteServerSocketFactory clientAuth=true/ /Connector Works great. -Jim Anton Ushakov wrote: Hello Tomcat Developers! I'm working with Tomcat 4.1.29 and I'd like to use my own ServerSocketFactory, as I'm working on a custom implementation of httpg (HTTP over GSSAPI authenticated sockets). This seems impossible by design, which I think may be a bug. Instead of using the deprecated HttpConnector I'm trying to use the CoyoteConnector. The trouble is, with CoyoteConnector there is no way to override the ServerSocketFactory to be used. My CustomServerSocketFactory implements org.apache.catalina.net.ServerSocketFactory, and I tried using the following in server.xml: Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=6688 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=100 debug=50 connectionTimeout=2 scheme=httpg useURIValidationHack=false disableUploadTimeout=true Factory className=my.own.CustomServerSocketFactory principal=service/[EMAIL PROTECTED] keytab=/etc/keytab / /Connector This will successfully set the factory in CoyoteConnector, but it does NOT propagate to org.apache.coyote.http11.Http11Protocol, and the actual factory getting used at runtime is the default one in Http11Protocol. The CoyoteConnector's factory datamember is totally ignored. I would think that in org/apache/coyote/tomcat4/CoyoteConnector.java around lines -1135 there should be something to propagate the socket factory to the protocolHandler. However even then, Http11Protocol insists on using org.apache.tomcat.util.net.ServerSocketFactory, not the org.apache.catalina.net.ServerSocketFactory required by the CoyoteConnector. (?) Bottom line - how is one supposed to specify a custom ServerSocketFactory with the CoyoteConnector? Bill Barker has emailed me a suggestion of using the socketFactory=fully.qualified.name.of.MyOwnServerSocketFactory attribute on the Connector element. While I appreciate the response, that doesn't set the factory datamember in the Connector, and neither does it change the socketFactory in the protocolHandler. I appreciate your help on this -anton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED
Coyote's ServerSocketFactory problem
Hello Tomcat Developers! I'm working with Tomcat 4.1.29 and I'd like to use my own ServerSocketFactory, as I'm working on a custom implementation of httpg (HTTP over GSSAPI authenticated sockets). This seems impossible by design, which I think may be a bug. Instead of using the deprecated HttpConnector I'm trying to use the CoyoteConnector. The trouble is, with CoyoteConnector there is no way to override the ServerSocketFactory to be used. My CustomServerSocketFactory implements org.apache.catalina.net.ServerSocketFactory, and I tried using the following in server.xml: Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=6688 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=100 debug=50 connectionTimeout=2 scheme=httpg useURIValidationHack=false disableUploadTimeout=true Factory className=my.own.CustomServerSocketFactory principal=service/[EMAIL PROTECTED] keytab=/etc/keytab / /Connector This will successfully set the factory in CoyoteConnector, but it does NOT propagate to org.apache.coyote.http11.Http11Protocol, and the actual factory getting used at runtime is the default one in Http11Protocol. The CoyoteConnector's factory datamember is totally ignored. I would think that in org/apache/coyote/tomcat4/CoyoteConnector.java around lines -1135 there should be something to propagate the socket factory to the protocolHandler. However even then, Http11Protocol insists on using org.apache.tomcat.util.net.ServerSocketFactory, not the org.apache.catalina.net.ServerSocketFactory required by the CoyoteConnector. (?) Bottom line - how is one supposed to specify a custom ServerSocketFactory with the CoyoteConnector? Bill Barker has emailed me a suggestion of using the socketFactory=fully.qualified.name.of.MyOwnServerSocketFactory attribute on the Connector element. While I appreciate the response, that doesn't set the factory datamember in the Connector, and neither does it change the socketFactory in the protocolHandler. I appreciate your help on this -anton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Coyote's ServerSocketFactory problem
We have a similar need (though for a different reason) and extend CoyoteServerSocketFactory. We're running TC 4.1.29. Here's our Connector element: Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=7002 scheme=https secure=true address=127.0.0.1 enableLookups=false Factory className=nyw.catalina.NYWCoyoteServerSocketFactory clientAuth=true/ /Connector Works great. -Jim Anton Ushakov wrote: Hello Tomcat Developers! I'm working with Tomcat 4.1.29 and I'd like to use my own ServerSocketFactory, as I'm working on a custom implementation of httpg (HTTP over GSSAPI authenticated sockets). This seems impossible by design, which I think may be a bug. Instead of using the deprecated HttpConnector I'm trying to use the CoyoteConnector. The trouble is, with CoyoteConnector there is no way to override the ServerSocketFactory to be used. My CustomServerSocketFactory implements org.apache.catalina.net.ServerSocketFactory, and I tried using the following in server.xml: Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=6688 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=100 debug=50 connectionTimeout=2 scheme=httpg useURIValidationHack=false disableUploadTimeout=true Factory className=my.own.CustomServerSocketFactory principal=service/[EMAIL PROTECTED] keytab=/etc/keytab / /Connector This will successfully set the factory in CoyoteConnector, but it does NOT propagate to org.apache.coyote.http11.Http11Protocol, and the actual factory getting used at runtime is the default one in Http11Protocol. The CoyoteConnector's factory datamember is totally ignored. I would think that in org/apache/coyote/tomcat4/CoyoteConnector.java around lines -1135 there should be something to propagate the socket factory to the protocolHandler. However even then, Http11Protocol insists on using org.apache.tomcat.util.net.ServerSocketFactory, not the org.apache.catalina.net.ServerSocketFactory required by the CoyoteConnector. (?) Bottom line - how is one supposed to specify a custom ServerSocketFactory with the CoyoteConnector? Bill Barker has emailed me a suggestion of using the socketFactory=fully.qualified.name.of.MyOwnServerSocketFactory attribute on the Connector element. While I appreciate the response, that doesn't set the factory datamember in the Connector, and neither does it change the socketFactory in the protocolHandler. I appreciate your help on this -anton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Coyote's ServerSocketFactory problem
In CoyoteConnector.initialize() there's an assumption that if the factory is an instance of CoyoteServerSocketFactory, it's gonna be SSL, and it sets secure=true. Then in Http11ConnectionHandler.checkSocketFactory() in the Http11Protocol.java, it interprets that secure flag as SSL and uses SSLImplementation to get the socket factory. In our case, the scheme is not ssl, so unfortunately this doesn't work. Http11Protocol just wasn't written to accept a socket factory object, and the one it makes from the passed classname is of a different type than CoyoteConnector's socket factory. It's not enough to make the types the same, it really should take a whole factory object, since the factory's attributes need to be set from the conf. On Wed, 2004-03-24 at 16:03, Jim Hopp wrote: We have a similar need (though for a different reason) and extend CoyoteServerSocketFactory. We're running TC 4.1.29. Here's our Connector element: Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=7002 scheme=https secure=true address=127.0.0.1 enableLookups=false Factory className=nyw.catalina.NYWCoyoteServerSocketFactory clientAuth=true/ /Connector Works great. -Jim Anton Ushakov wrote: Hello Tomcat Developers! I'm working with Tomcat 4.1.29 and I'd like to use my own ServerSocketFactory, as I'm working on a custom implementation of httpg (HTTP over GSSAPI authenticated sockets). This seems impossible by design, which I think may be a bug. Instead of using the deprecated HttpConnector I'm trying to use the CoyoteConnector. The trouble is, with CoyoteConnector there is no way to override the ServerSocketFactory to be used. My CustomServerSocketFactory implements org.apache.catalina.net.ServerSocketFactory, and I tried using the following in server.xml: Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=6688 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=8443 acceptCount=100 debug=50 connectionTimeout=2 scheme=httpg useURIValidationHack=false disableUploadTimeout=true Factory className=my.own.CustomServerSocketFactory principal=service/[EMAIL PROTECTED] keytab=/etc/keytab / /Connector This will successfully set the factory in CoyoteConnector, but it does NOT propagate to org.apache.coyote.http11.Http11Protocol, and the actual factory getting used at runtime is the default one in Http11Protocol. The CoyoteConnector's factory datamember is totally ignored. I would think that in org/apache/coyote/tomcat4/CoyoteConnector.java around lines -1135 there should be something to propagate the socket factory to the protocolHandler. However even then, Http11Protocol insists on using org.apache.tomcat.util.net.ServerSocketFactory, not the org.apache.catalina.net.ServerSocketFactory required by the CoyoteConnector. (?) Bottom line - how is one supposed to specify a custom ServerSocketFactory with the CoyoteConnector? Bill Barker has emailed me a suggestion of using the socketFactory=fully.qualified.name.of.MyOwnServerSocketFactory attribute on the Connector element. While I appreciate the response, that doesn't set the factory datamember in the Connector, and neither does it change the socketFactory in the protocolHandler. I appreciate your help on this -anton - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
