Re: Tomcat 7 manager quirk?
On 27/10/2012 04:45, Caldarale, Charles R wrote: From: Josh Gooding [mailto:josh.good...@gmail.com] Subject: Tomcat 7 manager quirk? Is there a way that I can get tomcat to NOT start auto-deploying immediately when the manager is invoked with a deploy / update command? When I run the command: curl -k --upload-file ROOT.war The usual trick is to upload the file with a different extension, then rename it to .war - but that might be difficult if your only access is via curl. I don't like the idea of .war uploads via the Manager app to a production server, myself... p -- [key:62590808] signature.asc Description: OpenPGP digital signature
Re: SSL BIO/NIO setup with openssl CA puzzle
On 26/10/12 16:12, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian, On 10/26/12 5:11 AM, Brian Burch wrote: I have another system with java-7-openjdk-i386, but I haven't yet done any work on it. This openjdk does not ship with a keytool program, and so I presume it will use openssl. I dunno about the i386 version, but I have /usr/bin/keytool installed by Debian package openjdk-7-jre-headless (x86_64). Thanks for pointing that out Chris, I was just wrong when I said it wasn't there - I was looking at a different machine. The system under investigation has both keytool executables installed: brian@shiraz:/usr/bin$ ls -l keytool lrwxrwxrwx 1 root root 25 Jun 15 2008 keytool - /etc/alternatives/keytool then, following that symlink like this... brian@shiraz:/etc/alternatives$ ls -l keytool lrwxrwxrwx 1 root root 39 Apr 24 2009 keytool - /usr/lib/jvm/java-6-sun/jre/bin/keytool also, just to make 100% sure... brian@shiraz:/etc/alternatives$ sudo update-alternatives --display keytool keytool - manual mode link currently points to /usr/lib/jvm/java-6-sun/jre/bin/keytool /usr/lib/jvm/java-6-openjdk-i386/jre/bin/keytool - priority 1061 slave keytool.1.gz: /usr/lib/jvm/java-6-openjdk-i386/jre/man/man1/keytool.1.gz /usr/lib/jvm/java-6-sun/jre/bin/keytool - priority 63 slave keytool.1.gz: /usr/lib/jvm/java-6-sun/jre/man/man1/keytool.1.gz Current 'best' version is '/usr/lib/jvm/java-6-openjdk-i386/jre/bin/keytool'. in other words, if I run keytool WITHOUT an explicit path, I get the sun version. However, I used an explicit path to java-6-sun in my tests. Thanks very much for your comment. It prompted me to explicitly run both keytools against both the faulty pkcs12 and the good JKS keystores. Much to my alarm BOTH tests on the good JKS failed with... keytool error: java.lang.Exception: Keystore file does not exist: www2-java-JKS-keystore Happily, it didn't take me long to discover that this was due to a permissions problem: running the identical commands under sudo worked fine. I'll conclude this educational branch of my thread by confidently restating that both keytools are able to list both keystores successfully, even though the pkcs12 keystore cannot be opened by tomcat 7 under java-6-sun (I haven't tried it under java-6-openssl). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCKqFYACgkQ9CaO5/Lv0PB7wACgoQsJwEBd0ZBbjDyEpcD9U+kq UZMAnj32nxYKFq6hK4zJZ7LDEEKAyOow =wZbM -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Detect in an authenticator whether a connection is persistent or not
Hi, several authentication mechanisms require a session (*not* HTTP session) or connection being initiated when authentication is performed and principal cached for subsquent requests [1], [2]. Now, I want to patch our SPNEGO authenticator in Tomcat 6 to behave stateful. I once contributed that code to Apache in bug 48465 [3] which does not behave like that. I like to align both authenticators. This issue initially popped up while fixing an issue in libserf [4] for the upcoming Apache Subversion version 1.8.0. How do I access that information in an authenticator? I do not intend to create a HTTP session for that for two reasons: 1. Creation of sessions should be upto the webapp. 2. There is no guarantee that the client will present the session cookie on a subsequent request. Thanks, Michael [1] http://www.chromium.org/spdy/spdy-authentication [2] http://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html [3] https://issues.apache.org/bugzilla/show_bug.cgi?id=48685 [4] http://code.google.com/p/serf/issues/detail?id=89#c11 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Detect in an authenticator whether a connection is persistent or not
On 27/10/2012 14:50, Michael-O wrote: Hi, several authentication mechanisms require a session (*not* HTTP session) or connection being initiated when authentication is performed and principal cached for subsquent requests [1], [2]. Now, I want to patch our SPNEGO authenticator in Tomcat 6 to behave stateful. I once contributed that code to Apache in bug 48465 [3] which does not behave like that. I like to align both authenticators. This issue initially popped up while fixing an issue in libserf [4] for the upcoming Apache Subversion version 1.8.0. How do I access that information in an authenticator? I do not intend to create a HTTP session for that for two reasons: 1. Creation of sessions should be upto the webapp. 2. There is no guarantee that the client will present the session cookie on a subsequent request. The only mechanism to maintain state between HTTP requests is the HTTP session. You might be able to hack something together (in a non-portable way) on a per connection basis but that is likely to require some rather major internal surgery for Tomcat (and may be rejected by the committers). It isn't unreasonable for use of an authentication to require an HTTP session. FORM auth does that so I don't immediately see why SPNEGO can't. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Detect in an authenticator whether a connection is persistent or not
Am 2012-10-27 16:57, schrieb Mark Thomas: On 27/10/2012 14:50, Michael-O wrote: Hi, several authentication mechanisms require a session (*not* HTTP session) or connection being initiated when authentication is performed and principal cached for subsquent requests [1], [2]. Now, I want to patch our SPNEGO authenticator in Tomcat 6 to behave stateful. I once contributed that code to Apache in bug 48465 [3] which does not behave like that. I like to align both authenticators. This issue initially popped up while fixing an issue in libserf [4] for the upcoming Apache Subversion version 1.8.0. How do I access that information in an authenticator? I do not intend to create a HTTP session for that for two reasons: 1. Creation of sessions should be upto the webapp. 2. There is no guarantee that the client will present the session cookie on a subsequent request. The only mechanism to maintain state between HTTP requests is the HTTP session. You might be able to hack something together (in a non-portable way) on a per connection basis but that is likely to require some rather major internal surgery for Tomcat (and may be rejected by the committers). Is there no way to tell that subsequent n requests come from the very same socket connection? HTTP is just on top of TCP/IP. Something like this should be transparent to HTTP though? I am curious, since I know server implementations which indeed DO maintain state without HTTP sessions but I do not know how they do that. At least the chromium link says how this can be done. Apache HTTP Cient does that too. Why not Tomcat? It isn't unreasonable for use of an authentication to require an HTTP session. FORM auth does that so I don't immediately see why SPNEGO can't. FORM auth works very different compared to header-based auth. Form is meant for human interaction with a browser which will always pass cookies. I cannot expect that from a machine client nor can the client actively say destroy that session unless a specific URL is called. Connection: close can do that. Mike - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Detect in an authenticator whether a connection is persistent or not
On 27/10/2012 16:28, Michael-O wrote: Am 2012-10-27 16:57, schrieb Mark Thomas: The only mechanism to maintain state between HTTP requests is the HTTP session. You might be able to hack something together (in a non-portable way) on a per connection basis but that is likely to require some rather major internal surgery for Tomcat (and may be rejected by the committers). Is there no way to tell that subsequent n requests come from the very same socket connection? HTTP is just on top of TCP/IP. Something like this should be transparent to HTTP though? I am curious, since I know server implementations which indeed DO maintain state without HTTP sessions but I do not know how they do that. It is easy if the same request object is reused for each request processed for a given connection. Tomcat doesn't do this. When a connection has data to process, first a processor is taken from the processor pool to process the data. The processor has a request object that is re-used. Each time an HTTP request is processed, a different processor and request object may be used. (This does vary slightly between the different connections but lets not complicate things). Undoing this is the major internal surgery I was referring to. You might be able to add an API to store/retrieve data to/from the connection (similar to notes on the session, but at the connection level) and access this from the authenticator (that is a lot further up the stack). That could still end up being pretty invasive. At least the chromium link says how this can be done. Apache HTTP Cient does that too. Why not Tomcat? I didn't say it couldn't be done. See above. It isn't unreasonable for use of an authentication to require an HTTP session. FORM auth does that so I don't immediately see why SPNEGO can't. FORM auth works very different compared to header-based auth. Form is meant for human interaction with a browser which will always pass cookies. I cannot expect that from a machine client nor can the client actively say destroy that session unless a specific URL is called. Connection: close can do that. Yes there are differences and it places requirements on the client but that doesn't make it a complete non-starter. I agree, if this can be done per connection it would be a lot better. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Detect in an authenticator whether a connection is persistent or not
Am 2012-10-27 18:38, schrieb Mark Thomas: On 27/10/2012 16:28, Michael-O wrote: Am 2012-10-27 16:57, schrieb Mark Thomas: The only mechanism to maintain state between HTTP requests is the HTTP session. You might be able to hack something together (in a non-portable way) on a per connection basis but that is likely to require some rather major internal surgery for Tomcat (and may be rejected by the committers). Is there no way to tell that subsequent n requests come from the very same socket connection? HTTP is just on top of TCP/IP. Something like this should be transparent to HTTP though? I am curious, since I know server implementations which indeed DO maintain state without HTTP sessions but I do not know how they do that. It is easy if the same request object is reused for each request processed for a given connection. Tomcat doesn't do this. When a connection has data to process, first a processor is taken from the processor pool to process the data. The processor has a request object that is re-used. Each time an HTTP request is processed, a different processor and request object may be used. (This does vary slightly between the different connections but lets not complicate things). Undoing this is the major internal surgery I was referring to. You might be able to add an API to store/retrieve data to/from the connection (similar to notes on the session, but at the connection level) and access this from the authenticator (that is a lot further up the stack). That could still end up being pretty invasive. OK that's a statement. Tomcat does fully support persistent connections but there is no state information maintained, right? The answer would be: There is clearly no way to store any information for a given connection context and retrieve throughout the Tomcat code. Is this something worth being filed in Bugzilla as a longterm goal for Tomcat 8? Thanks for the quick response, Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Detect in an authenticator whether a connection is persistent or not
On 27/10/2012 17:56, Michael-O wrote: Am 2012-10-27 18:38, schrieb Mark Thomas: On 27/10/2012 16:28, Michael-O wrote: Am 2012-10-27 16:57, schrieb Mark Thomas: The only mechanism to maintain state between HTTP requests is the HTTP session. You might be able to hack something together (in a non-portable way) on a per connection basis but that is likely to require some rather major internal surgery for Tomcat (and may be rejected by the committers). Is there no way to tell that subsequent n requests come from the very same socket connection? HTTP is just on top of TCP/IP. Something like this should be transparent to HTTP though? I am curious, since I know server implementations which indeed DO maintain state without HTTP sessions but I do not know how they do that. It is easy if the same request object is reused for each request processed for a given connection. Tomcat doesn't do this. When a connection has data to process, first a processor is taken from the processor pool to process the data. The processor has a request object that is re-used. Each time an HTTP request is processed, a different processor and request object may be used. (This does vary slightly between the different connections but lets not complicate things). Undoing this is the major internal surgery I was referring to. You might be able to add an API to store/retrieve data to/from the connection (similar to notes on the session, but at the connection level) and access this from the authenticator (that is a lot further up the stack). That could still end up being pretty invasive. OK that's a statement. Tomcat does fully support persistent connections but there is no state information maintained, right? Correct. Tomcat fully supports HTTP/1.1 and that requires keep-alive support. The answer would be: There is clearly no way to store any information for a given connection context and retrieve throughout the Tomcat code. Currently, yes. Is this something worth being filed in Bugzilla as a longterm goal for Tomcat 8? Sure, but without a proposed patch I suspect it will sit there for a few years and then closed as WONTFIX. With a patch, it still might not get fixed but at least you'll know for sure and if the patch isn't too invasive (for the benefit it provides) it is likely to be applied. Thanks for the quick response, You are welcome. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Detect in an authenticator whether a connection is persistent or not
Am 2012-10-27 19:25, schrieb Mark Thomas: Is this something worth being filed in Bugzilla as a longterm goal for Tomcat 8? Sure, but without a proposed patch I suspect it will sit there for a few years and then closed as WONTFIX. With a patch, it still might not get fixed but at least you'll know for sure and if the patch isn't too invasive (for the benefit it provides) it is likely to be applied. That seems to be very tough. I hacked Tomcat code several times but wouldn't claim that I am firm enough to implement such a tremendous improvement. Interesting though that no one else yet requested such an improvement. I have no usecase for this at the moment :-(, I only provide patches for stuff I suffer from at work. As this [1] draft lays out Negotiate and Kerberos may apply to connection or request level auth. We are just lucky that the first gss_accept_sec_context makes the context complete in the SPNEGO authenticator. Some clients maintain the state and rely on the server to maintain the connection state too. Tomcat does not do that which means that the current SPNEGO authenticator has to issue a Connection: close after successful auth. Otherwise the client will reuse the connection and keep sending requests w/o reauthenticating eventhough Tomcat requires to do so. In this case I have a Wireshark capture where this exactly happens and the clients traps in an endless loop and issues thousands of requests performs a DoS. Thanks, Mike [1] http://tools.ietf.org/html/draft-montenegro-httpbis-multilegged-auth-01#section-1 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Detect in an authenticator whether a connection is persistent or not
On 27/10/2012 18:57, Michael-O wrote: Am 2012-10-27 19:25, schrieb Mark Thomas: Is this something worth being filed in Bugzilla as a longterm goal for Tomcat 8? Sure, but without a proposed patch I suspect it will sit there for a few years and then closed as WONTFIX. With a patch, it still might not get fixed but at least you'll know for sure and if the patch isn't too invasive (for the benefit it provides) it is likely to be applied. That seems to be very tough. I hacked Tomcat code several times but wouldn't claim that I am firm enough to implement such a tremendous improvement. Interesting though that no one else yet requested such an improvement. Yes, we are fairly tough on adding new features. We really don't want to add what, for most users, is bloat. We are usually happy to add hooks if folks need them to implement their particular itch. I wouldn't worry about the quality of the patch. The first one I wrote for Tomcat was (rightly) ripped to pieces by the committers at the time but the feature was implemented and is still there today. If a committer can see a cleaner way of doing the same thing then they'll either give you some pointers or just fix it and apply it. The main point is that if there is a change you want to see, then you need do be the driving force. Adding connection level notes shouldn't be too hard. The trickier part is exposing them to the high-level components that need them. Passing through the request is probably the way to go. I have no usecase for this at the moment :-(, I only provide patches for stuff I suffer from at work. The below looks like a use case to me. As this [1] draft lays out Negotiate and Kerberos may apply to connection or request level auth. We are just lucky that the first gss_accept_sec_context makes the context complete in the SPNEGO authenticator. Some clients maintain the state and rely on the server to maintain the connection state too. Tomcat does not do that which means that the current SPNEGO authenticator has to issue a Connection: close after successful auth. Otherwise the client will reuse the connection and keep sending requests w/o reauthenticating eventhough Tomcat requires to do so. In this case I have a Wireshark capture where this exactly happens and the clients traps in an endless loop and issues thousands of requests performs a DoS. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Detect in an authenticator whether a connection is persistent or not
Am 2012-10-27 20:22, schrieb Mark Thomas: On 27/10/2012 18:57, Michael-O wrote: Am 2012-10-27 19:25, schrieb Mark Thomas: Is this something worth being filed in Bugzilla as a longterm goal for Tomcat 8? Sure, but without a proposed patch I suspect it will sit there for a few years and then closed as WONTFIX. With a patch, it still might not get fixed but at least you'll know for sure and if the patch isn't too invasive (for the benefit it provides) it is likely to be applied. That seems to be very tough. I hacked Tomcat code several times but wouldn't claim that I am firm enough to implement such a tremendous improvement. Interesting though that no one else yet requested such an improvement. Yes, we are fairly tough on adding new features. We really don't want to add what, for most users, is bloat. We are usually happy to add hooks if folks need them to implement their particular itch. I wouldn't worry about the quality of the patch. The first one I wrote for Tomcat was (rightly) ripped to pieces by the committers at the time but the feature was implemented and is still there today. If a committer can see a cleaner way of doing the same thing then they'll either give you some pointers or just fix it and apply it. The main point is that if there is a change you want to see, then you need do be the driving force. Adding connection level notes shouldn't be too hard. The trickier part is exposing them to the high-level components that need them. Passing through the request is probably the way to go. As long as there is general interest in such a feature I will keep that in mind and might take a look at it over Christmas. I have no usecase for this at the moment :-(, I only provide patches for stuff I suffer from at work. The below looks like a use case to me. As this [1] draft lays out Negotiate and Kerberos may apply to connection or request level auth. We are just lucky that the first gss_accept_sec_context makes the context complete in the SPNEGO authenticator. Some clients maintain the state and rely on the server to maintain the connection state too. Tomcat does not do that which means that the current SPNEGO authenticator has to issue a Connection: close after successful auth. Otherwise the client will reuse the connection and keep sending requests w/o reauthenticating eventhough Tomcat requires to do so. In this case I have a Wireshark capture where this exactly happens and the clients traps in an endless loop and issues thousands of requests performs a DoS. Well, as long as there is support for connection storage should I file a bug about that? The connector has to close the connection in my opinion. Mike - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Detect in an authenticator whether a connection is persistent or not
Yes W8 is here but HPQ is still plummeting. Get rid of your CEO and get someone who can improve your stock price! Date: Sat, 27 Oct 2012 19:57:30 +0200 From: 1983-01...@gmx.net To: users@tomcat.apache.org Subject: Re: Detect in an authenticator whether a connection is persistent or not Am 2012-10-27 19:25, schrieb Mark Thomas: Is this something worth being filed in Bugzilla as a longterm goal for Tomcat 8? Sure, but without a proposed patch I suspect it will sit there for a few years and then closed as WONTFIX. With a patch, it still might not get fixed but at least you'll know for sure and if the patch isn't too invasive (for the benefit it provides) it is likely to be applied. That seems to be very tough. I hacked Tomcat code several times but wouldn't claim that I am firm enough to implement such a tremendous improvement. Interesting though that no one else yet requested such an improvement. I have no usecase for this at the moment :-(, I only provide patches for stuff I suffer from at work. As this [1] draft lays out Negotiate and Kerberos may apply to connection or request level auth. We are just lucky that the first gss_accept_sec_context makes the context complete in the SPNEGO authenticator. Some clients maintain the state and rely on the server to maintain the connection state too. Tomcat does not do that which means that the current SPNEGO authenticator has to issue a Connection: close after successful auth. Otherwise the client will reuse the connection and keep sending requests w/o reauthenticating eventhough Tomcat requires to do so. In this case I have a Wireshark capture where this exactly happens and the clients traps in an endless loop and issues thousands of requests performs a DoS. Thanks, Mike [1] http://tools.ietf.org/html/draft-montenegro-httpbis-multilegged-auth-01#section-1 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Detect in an authenticator whether a connection is persistent or not
On Sat, Oct 27, 2012 at 11:36 AM, ken dias kend...@hotmail.com wrote: Yes W8 is here but HPQ is still plummeting. Get rid of your CEO and get someone who can improve your stock price! Que? -- Hassan Schroeder hassan.schroe...@gmail.com http://about.me/hassanschroeder twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Detect in an authenticator whether a connection is persistent or not
On 27/10/2012 19:32, Michael-O wrote: Am 2012-10-27 20:22, schrieb Mark Thomas: On 27/10/2012 18:57, Michael-O wrote: Am 2012-10-27 19:25, schrieb Mark Thomas: Is this something worth being filed in Bugzilla as a longterm goal for Tomcat 8? Sure, but without a proposed patch I suspect it will sit there for a few years and then closed as WONTFIX. With a patch, it still might not get fixed but at least you'll know for sure and if the patch isn't too invasive (for the benefit it provides) it is likely to be applied. That seems to be very tough. I hacked Tomcat code several times but wouldn't claim that I am firm enough to implement such a tremendous improvement. Interesting though that no one else yet requested such an improvement. Yes, we are fairly tough on adding new features. We really don't want to add what, for most users, is bloat. We are usually happy to add hooks if folks need them to implement their particular itch. I wouldn't worry about the quality of the patch. The first one I wrote for Tomcat was (rightly) ripped to pieces by the committers at the time but the feature was implemented and is still there today. If a committer can see a cleaner way of doing the same thing then they'll either give you some pointers or just fix it and apply it. The main point is that if there is a change you want to see, then you need do be the driving force. Adding connection level notes shouldn't be too hard. The trickier part is exposing them to the high-level components that need them. Passing through the request is probably the way to go. As long as there is general interest in such a feature I will keep that in mind and might take a look at it over Christmas. I'd certainly be prepared to look at it, both for SPNEGO and SPDY. I have no usecase for this at the moment :-(, I only provide patches for stuff I suffer from at work. The below looks like a use case to me. As this [1] draft lays out Negotiate and Kerberos may apply to connection or request level auth. We are just lucky that the first gss_accept_sec_context makes the context complete in the SPNEGO authenticator. Some clients maintain the state and rely on the server to maintain the connection state too. Tomcat does not do that which means that the current SPNEGO authenticator has to issue a Connection: close after successful auth. Otherwise the client will reuse the connection and keep sending requests w/o reauthenticating eventhough Tomcat requires to do so. In this case I have a Wireshark capture where this exactly happens and the clients traps in an endless loop and issues thousands of requests performs a DoS. Well, as long as there is support for connection storage should I file a bug about that? Go for it. The connector has to close the connection in my opinion. Not sure what you mean by that. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Detect in an authenticator whether a connection is persistent or not
I have no usecase for this at the moment :-(, I only provide patches for stuff I suffer from at work. The below looks like a use case to me. As this [1] draft lays out Negotiate and Kerberos may apply to connection or request level auth. We are just lucky that the first gss_accept_sec_context makes the context complete in the SPNEGO authenticator. Some clients maintain the state and rely on the server to maintain the connection state too. Tomcat does not do that which means that the current SPNEGO authenticator has to issue a Connection: close after successful auth. Otherwise the client will reuse the connection and keep sending requests w/o reauthenticating eventhough Tomcat requires to do so. In this case I have a Wireshark capture where this exactly happens and the clients traps in an endless loop and issues thousands of requests performs a DoS. Well, as long as there is support for connection storage should I file a bug about that? Go for it. The connector has to close the connection in my opinion. Not sure what you mean by that. I guess there is a misunderstanding here. There are two issues to be filed: 1. The long-term support for a connection-based store. 2. The above described behavior of the current SPNEGO connector in Tomcat 7. A DoS is possible when a client expects that the server has a connection context on a persistent connection. I was referring to the latter in the first place. Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
JNDI datasource error upgrading from Tomcat 7.0.23 to 7.0.27
Greetings, I've researched this problem for several days, but I must be doing something wrong. I'm trying to upgrade from Tomcat 7.0.23 to 7.0.27 (actually running Liferay). I'm getting the following exception when trying to access a datasource via Hibernate: 16:28:27,694 ERROR [http-bio-8080-exec-1][DatasourceConnectionProvider:110] Could not find datasource: java:/comp/env/jdbc/MySqlDS javax.naming.NameNotFoundException: Name [java:/comp/env/jdbc/MySqlDS] is not bound in this Context. Unable to find [java:]. at org.apache.naming.NamingContext.lookup(NamingContext.java:820) at org.apache.naming.NamingContext.lookup(NamingContext.java:168) at org.apache.naming.SelectorContext.lookup(SelectorContext.java:158) at javax.naming.InitialContext.lookup(InitialContext.java:392) at org.hibernate.connection.DatasourceConnectionProvider.configure(DatasourceCo nnectionProvider.java:75) at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(Con nectionProviderFactory.java:143) at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(Con nectionProviderFactory.java:84) at org.hibernate.cfg.SettingsFactory.createConnectionProvider(SettingsFactory.j ava:459) at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:90) at org.hibernate.cfg.Configuration.buildSettingsInternal(Configuration.java:286 3) at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2859) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1870) The exact same code runs fine in 7.0.23 (I can drop the WAR file in either instance). Here is my $CATALINA_HOME/conf/context.xml file (comments removed): ?xml version='1.0' encoding='utf-8'? !-- The contents of this file will be loaded for each web application -- Context !-- Default set of monitored resources -- WatchedResourceWEB-INF/web.xml/WatchedResource Resource name=jdbc/MySqlDS auth=Container type=javax.sql.DataSource driverClassName=com.mysql.jdbc.Driver username=xxx password=xxx url=jdbc:mysql://localhost:3306/xx?useUnicode=trueamp;characterEncoding=UT F-8amp;relaxAutoCommit=true maxActive=200 maxIdle=30 maxWait=1 minIdle=3 testWhileIdle=true testOnBorrow=true timeBetweenEvictionRunsMillis=12 minEvictableIdleTimeMillis=60 validationQuery=select 1 / /Context The web.xml from the application: ?xml version=1.0? web-app version=2.4 xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; servlet servlet-nameHibernateServlet/servlet-name servlet-classcom.liferay.samplehibernate.servlet.HibernateServlet/servlet -class /servlet servlet-mapping servlet-nameHibernateServlet/servlet-name url-pattern/servlet/*/url-pattern /servlet-mapping jsp-config taglib taglib-urihttp://java.sun.com/portlet_2_0/taglib-uri taglib-location /WEB-INF/tld/liferay-portlet.tld /taglib-location /taglib /jsp-config resource-ref descriptiondata source/description res-ref-namejdbc/MySqlDS/res-ref-name res-typejavax.sql.DataSource/res-type res-authContainer/res-auth /resource-ref /web-app And finally the the hibernate.cfg.xml file: ?xml version=1.0? !DOCTYPE hibernate-configuration PUBLIC -//Hibernate/Hibernate Configuration DTD 3.0//EN http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd; hibernate-configuration session-factory property name=current_session_context_classthread/property !-- Mappings -- property name=connection.datasourcejava:/comp/env/jdbc/MySqlDS/property property name=dialect org.hibernate.dialect.MySQLDialect /property mapping resource=com/liferay/samplehibernate/model/FoodItem.hbm.xml / /session-factory /hibernate-configuration Did a bit more research. On vanilla versions of Tomcat 7.0.27 and the corresponding Liferay bundle, I can make a global definition using the same resource in server.xml. I can see the
Re: JNDI datasource error upgrading from Tomcat 7.0.23 to 7.0.27
2012/10/28 Bob Dietrich b...@bobd.biz: Greetings, I've researched this problem for several days, but I must be doing something wrong. I'm trying to upgrade from Tomcat 7.0.23 to 7.0.27 (actually running Liferay). I'm getting the following exception when trying to access a datasource via Hibernate: 16:28:27,694 ERROR [http-bio-8080-exec-1][DatasourceConnectionProvider:110] Could not find datasource: java:/comp/env/jdbc/MySqlDS javax.naming.NameNotFoundException: Name [java:/comp/env/jdbc/MySqlDS] is not bound in this Context. Unable to find [java:]. at org.apache.naming.NamingContext.lookup(NamingContext.java:820) at org.apache.naming.NamingContext.lookup(NamingContext.java:168) at org.apache.naming.SelectorContext.lookup(SelectorContext.java:158) at javax.naming.InitialContext.lookup(InitialContext.java:392) at org.hibernate.connection.DatasourceConnectionProvider.configure(DatasourceCo nnectionProvider.java:75) at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(Con nectionProviderFactory.java:143) at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(Con nectionProviderFactory.java:84) at org.hibernate.cfg.SettingsFactory.createConnectionProvider(SettingsFactory.j ava:459) at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:90) at org.hibernate.cfg.Configuration.buildSettingsInternal(Configuration.java:286 3) at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2859) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1870) The exact same code runs fine in 7.0.23 (I can drop the WAR file in either instance). Here is my $CATALINA_HOME/conf/context.xml file (comments removed): ?xml version='1.0' encoding='utf-8'? !-- The contents of this file will be loaded for each web application -- Context !-- Default set of monitored resources -- WatchedResourceWEB-INF/web.xml/WatchedResource Resource name=jdbc/MySqlDS auth=Container type=javax.sql.DataSource driverClassName=com.mysql.jdbc.Driver username=xxx password=xxx url=jdbc:mysql://localhost:3306/xx?useUnicode=trueamp;characterEncoding=UT F-8amp;relaxAutoCommit=true maxActive=200 maxIdle=30 maxWait=1 minIdle=3 testWhileIdle=true testOnBorrow=true timeBetweenEvictionRunsMillis=12 minEvictableIdleTimeMillis=60 validationQuery=select 1 / /Context The web.xml from the application: ?xml version=1.0? web-app version=2.4 xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; servlet servlet-nameHibernateServlet/servlet-name servlet-classcom.liferay.samplehibernate.servlet.HibernateServlet/servlet -class /servlet servlet-mapping servlet-nameHibernateServlet/servlet-name url-pattern/servlet/*/url-pattern /servlet-mapping jsp-config taglib taglib-urihttp://java.sun.com/portlet_2_0/taglib-uri taglib-location /WEB-INF/tld/liferay-portlet.tld /taglib-location /taglib /jsp-config resource-ref descriptiondata source/description res-ref-namejdbc/MySqlDS/res-ref-name res-typejavax.sql.DataSource/res-type res-authContainer/res-auth /resource-ref /web-app And finally the the hibernate.cfg.xml file: ?xml version=1.0? !DOCTYPE hibernate-configuration PUBLIC -//Hibernate/Hibernate Configuration DTD 3.0//EN http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd; hibernate-configuration session-factory property name=current_session_context_classthread/property !-- Mappings -- property name=connection.datasourcejava:/comp/env/jdbc/MySqlDS/property property name=dialect org.hibernate.dialect.MySQLDialect /property mapping resource=com/liferay/samplehibernate/model/FoodItem.hbm.xml / /session-factory /hibernate-configuration Did a bit more research. On vanilla versions of Tomcat 7.0.27 and the corresponding Liferay bundle, I can
Re: JNDI datasource error upgrading from Tomcat 7.0.23 to 7.0.27
Hello, I am mot familiar with Hibernate or Liferay, but I ran into what appear to be similar. Look onto the thread titled JDBCRealm conection timeout failure on getPassword in thus list. It may help. Aladin On Oct 27, 2012, at 6:28 PM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2012/10/28 Bob Dietrich b...@bobd.biz: Greetings, I've researched this problem for several days, but I must be doing something wrong. I'm trying to upgrade from Tomcat 7.0.23 to 7.0.27 (actually running Liferay). I'm getting the following exception when trying to access a datasource via Hibernate: 16:28:27,694 ERROR [http-bio-8080-exec-1][DatasourceConnectionProvider:110] Could not find datasource: java:/comp/env/jdbc/MySqlDS javax.naming.NameNotFoundException: Name [java:/comp/env/jdbc/MySqlDS] is not bound in this Context. Unable to find [java:]. at org.apache.naming.NamingContext.lookup(NamingContext.java:820) at org.apache.naming.NamingContext.lookup(NamingContext.java:168) at org.apache.naming.SelectorContext.lookup(SelectorContext.java:158) at javax.naming.InitialContext.lookup(InitialContext.java:392) at org.hibernate.connection.DatasourceConnectionProvider.configure(DatasourceCo nnectionProvider.java:75) at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(Con nectionProviderFactory.java:143) at org.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(Con nectionProviderFactory.java:84) at org.hibernate.cfg.SettingsFactory.createConnectionProvider(SettingsFactory.j ava:459) at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:90) at org.hibernate.cfg.Configuration.buildSettingsInternal(Configuration.java:286 3) at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2859) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1870) The exact same code runs fine in 7.0.23 (I can drop the WAR file in either instance). Here is my $CATALINA_HOME/conf/context.xml file (comments removed): ?xml version='1.0' encoding='utf-8'? !-- The contents of this file will be loaded for each web application -- Context !-- Default set of monitored resources -- WatchedResourceWEB-INF/web.xml/WatchedResource Resource name=jdbc/MySqlDS auth=Container type=javax.sql.DataSource driverClassName=com.mysql.jdbc.Driver username=xxx password=xxx url=jdbc:mysql://localhost:3306/xx?useUnicode=trueamp;characterEncoding=UT F-8amp;relaxAutoCommit=true maxActive=200 maxIdle=30 maxWait=1 minIdle=3 testWhileIdle=true testOnBorrow=true timeBetweenEvictionRunsMillis=12 minEvictableIdleTimeMillis=60 validationQuery=select 1 / /Context The web.xml from the application: ?xml version=1.0? web-app version=2.4 xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; servlet servlet-nameHibernateServlet/servlet-name servlet-classcom.liferay.samplehibernate.servlet.HibernateServlet/servlet -class /servlet servlet-mapping servlet-nameHibernateServlet/servlet-name url-pattern/servlet/*/url-pattern /servlet-mapping jsp-config taglib taglib-urihttp://java.sun.com/portlet_2_0/taglib-uri taglib-location /WEB-INF/tld/liferay-portlet.tld /taglib-location /taglib /jsp-config resource-ref descriptiondata source/description res-ref-namejdbc/MySqlDS/res-ref-name res-typejavax.sql.DataSource/res-type res-authContainer/res-auth /resource-ref /web-app And finally the the hibernate.cfg.xml file: ?xml version=1.0? !DOCTYPE hibernate-configuration PUBLIC -//Hibernate/Hibernate Configuration DTD 3.0//EN http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd; hibernate-configuration session-factory property name=current_session_context_classthread/property !-- Mappings -- property name=connection.datasourcejava:/comp/env/jdbc/MySqlDS/property property name=dialect org.hibernate.dialect.MySQLDialect /property mapping
Re: Implementing SSL and error invocating https://localhost:8443/ (Tomcat 7.0 on Windows 7)
I have reached IE accepts my certificate as a valid certificate but when I open IE with link https://localhost:8443/ appears below message: There is a problem with the security certificate for this site Go to this website (not recommended). When I clicked on this message (Go to this website (not recommended), it is showed Tomcat page but in the IE's toolbar indicates Certificate Error with red color. My question here is how do I disappear this annoying indication?. Regards - Original Message - From: Igor Cicimov icici...@gmail.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, October 26, 2012 7:43:05 PM Subject: Re: Implementing SSL and error invocating https://localhost:8443/ (Tomcat 7.0 on Windows 7) On 27/10/2012 11:22 AM, Gabriel Huerta Araujo huert...@hildebrando.com wrote: Is it enough with putting a line into this file like this?: 192.168.30.73 logangha Where 192.168.30.73 is my IP 192.168.30.73 logangha THE-DOMAIN-NAME-FROM-THE-CERTIFICATE This should work.eg: 192.168.30.73 logangha mydomai.com And access with: http://mydomain.com - Original Message - From: Gabriel Huerta Araujo huert...@hildebrando.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, October 26, 2012 7:15:26 PM Subject: Re: Implementing SSL and error invocating https://localhost:8443/(Tomcat 7.0 on Windows 7) This is my hosts file's content: 10.254.5.1 sigcbd01#10.192.19.1 sigc 10.254.4.63 sdswbd01#10.192.17.66sadigeo 10.254.2.248nsisba01 None of these IP's is my domain. How do I configure dns resolution for such name on my computer to point to the ip of my laptop? As I am testing I am using my laptop with Windows 7 installed. Regards. - Original Message - From: Igor Cicimov icici...@gmail.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, October 26, 2012 6:21:49 PM Subject: Re: Implementing SSL and error invocating https://localhost:8443/(Tomcat 7.0 on Windows 7) On 27/10/2012 10:09 AM, Gabriel Huerta Araujo huert...@hildebrando.com wrote: I used logangha(which is my computer name) instead of localhost but again I had to click the Information bar to display the content (not recommended). So you got the cert for logangha??? Again, you should match the name of the domain you got the certificate for not the server name. Meaning you need dns resolution for that name on your server or local network to point to the ip of the server. Thats easy done in linux by editing the /etc/hosts file, not sure about windows. Google is your friend i think there should be simmilar file too. Regards. - Original Message - From: Igor Cicimov icici...@gmail.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, October 26, 2012 5:41:59 PM Subject: Re: Implementing SSL and error invocating https://localhost:8443/(Tomcat 7.0 on Windows 7) On 27/10/2012 9:37 AM, Gabriel Huerta Araujo huert...@hildebrando.com wrote: I have followed below steps: 1.- Erase keytore keytool -delete -keystore .keystore -storepass x_men_gha 2.- List to verify if it has been deleted. keytool -list -storepass x_men_gha Tipo de almacÚn de claves: JKS Proveedor de almacÚn de claves: SUN Su almacÚn de claves contiene 0 entradas 3.- Create as stated: keytool -genkey -alias tomcat -keyalg RSA Escriba la contrase±a del almacÚn de claves: La contrase±a del almacÚn de claves es demasiado corta, debe tener al menos 6 ca racteres Escriba la contrase±a del almacÚn de claves: ┐Cußles son su nombre y su apellido? [Unknown]: Gabriel Huerta ┐Cußl es el nombre de su unidad de organizaci¾n? [Unknown]: Desarrollo ┐Cußl es el nombre de su organizaci¾n? [Unknown]: Hildebrando ┐Cußl es el nombre de su ciudad o localidad? [Unknown]: Queretaro ┐Cußl es el nombre de su estado o provincia? [Unknown]: Santiago ┐Cußl es el c¾digo de paÝs de dos letras de la unidad? [Unknown]: MX ┐Es correcto CN=Gabriel Huerta, OU=Desarrollo, O=Hildebrando, L=Queretaro, ST=Sa ntiago, C=MX? [no]: y Escriba la contrase±a clave para tomcat (INTRO si es la misma contrase±a que la del almacÚn de claves): 4.- List to verify it: C:\Users\Gabriel Huertakeytool -list Escriba la contrase±a del almacÚn de claves: Tipo de almacÚn de claves: JKS Proveedor de almacÚn de claves: SUN Su almacÚn de claves contiene entrada 1 tomcat, 26/10/2012, PrivateKeyEntry, Huella digital de certificado (MD5): 00:37:8B:7F:F1:A4:B6:EE:8F:00:69:95:0A:A8:AD:14 5.- Import certificate as stated for Tomcat documentation: For Verisign.com trial certificates go to: http://www.verisign.com/support/verisign-intermediate-ca/Trial_Secure_Server_Root/index.html Once there I followed instructions where says Click here to go to the Installation
