which java ?
Hi. I am in the process of installing a new system at a customer, Tomcat 6 being part of the mix. This is a Suse Enterprise Linux (SEL) system, and the sysadmins at the customer very strongly favor using the pre-packaged software available with that distribution. (A position which which I can sympathise, being myself the sysadmin for a bunch of systems). Anyway, the question is not directly about Tomcat, but about the Java JVM. Under that version of SEL, the standard Java package is not the Oracle/Sun JVM, but this one : Java 1.6.0 IBM SR10.1-0.3.1 My question is : are there any kinds of problems/differences to be expected running Tomcat 6 over that JVM, as compared to the comparable Oracle/Sun version which I otherwise use everywhere else ? And if yes, in which area could the differences show up ? The Tomcat applications to be run on that system are minimal, but there are a couple for which I do not have (and cannot get) the sources. Or to phrase the question otherwise : are there strong reasons to push for installing instead an Oracle/Sun 1.6 JVM on that system (outside the SEL package management system and thus risking to inconvenience the sysadmins) to run Tomcat 6 on it ? Thanks for any information. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why @WebServlet annotation is not processed when web.xml is version 2.5?
Hi, As the Servlet 3.0 expert group shed some lighthttp://java.net/projects/servlet-spec/lists/users/archive/2012-05/message/1upon this question I would like to raise it here again. So do you plan revising the current processing of annotations (based on the web.xml version) as it contradicts the clarification from the expert group saying: *“If you are using a Java EE 6 compatible implementation and use the Servlet 3.0 feature / annotation, it should work independent of the version of the descriptor.”* May be the default behavior should be preserved and only *org.apache.catalina. STRICT_SERVLET_COMPLIANCE* should be extended with an additional property that controls the questioned handling? What do you think? Thanks and Regards, Maria 2012/4/18 Pid p...@pidster.com On 18/04/2012 11:27, Konstantin Kolinko wrote: 18 апреля 2012 г. 12:15 пользователь maria petrova mims8...@googlemail.com написал: Hi, Thanks for the clarification. I agree that the specification is not absolutely clear on this matter in the given extract. Anyway, I simply would like to ask you, as Tomcat experts, for hints or ideas how to configure my Tomcat to make it pass the Servlet 3.0 CTS. I know that Tomcat 7.x regularly covers the complete Servlet 3.0 CTS and probably there is a hidden property that I'm missing? An obvious thing: http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true As far as I remember, specifics of TCK cannot be discussed on a public list. I think mine was better [sniff] p -- [key:62590808]
Re: Fix for java.lang.VerifyError in tomcat 7.0.19 all the way thru tomcat 7.0.27!!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/06/2012 03:38, Anjan Bacchu wrote: Hi Chris, Thank you. Do you/they need any additional info to help fix the bug ? The following are required to confirm exactly where the bug is: - - The JSP the causes the problem - - The .java file (in CATALINA_BASE/work) generated from the JSP - - The .class file (also in CATALINA_BASE/work) generated from the .java file Please open a BZ entry and attach all three files. Mark Thanks again, BR, ~A On Thu, May 31, 2012 at 11:42 PM, Christopher Schultz ch...@christopherschultz.net wrote: Anjan, On 5/31/12 12:28 PM, Anjan Bacchu wrote: Do you suggest that the Eclipse compiler developers be told about this bug so they can fix it in the next release ? You're talking to them already ;) -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPyJgyAAoJEBDAHFovYFnnxngQAOvhJwfVwFbTkotHgGVyuI9q 5lnNLEuq1mTLKgVqz+vmTi1WJBat20vE4Pni1GsaBK0XWUPnQzfTmJYSFSQF3kUn hTfjSmeUimCVG358ufote6qS9N5fl2rRobwBG20La7bvG2Ay4RMElNbHPt5lj1th VLJYioIQb48kZhW5yW1wVjDHhbcUXeFx22edmSO35D+7Q+0ldUFQ4GOu/XdIdZtC pdYJotlms8uxcEg3rvXID11+9DdfBcJts9v3JAe420QDru5V91Ah+Qgtsy5W+LSA z2Cwf02OZa6nTHocJN8Ebp74GfQutvtH0oW570gW6qhv74kwUyCMK/7z68ckZvVh x7iiUhei/f1mLzn7SP3cWw/3/hZWBKIJgm1Srli6ki7Idu5ljQjFPDxYGdm7qfwV 7mrZVSzcGEkghrJnKLUa/qCHWglvzSBLFbjfbobsNiZ7YuXTx9mzD7bpC+JzLUsn hoHlMWOBkmDycXGky2O5fPmzYFlLr+E+ZXDi2EFXu06zjDbWqtdrHkTP2H0ir5B2 jVBtZ+kinWquWCn+r1kRBh3zEKxOxxjni7RaY6VNC7iwxjDji2iK8KaOtQfD5wOh dPGsu2d15saofcIo19orY0HSXfU83eJseHDaJOooyP7ZVTJZg2qk6y59EkW8f0Q2 p51kCT5SQagEQdNlnyif =qyBE -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Connecting to Tomcat APR Connector with TLSv1 fails with Java HttpsURLConnection
Hi folks, I am on Tomcat 6.0.35, Java 6, HP-UX, Tomcat Native 1.1.22. Recenly, I had to switch my Http11AprProtocol connector to TLSv1 due to a security scans in our company. After that a CLI client with Java's HttpsURLConnection failed to connect to that server: Exception in thread main javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source) at sun.net.www.protocol.https.HttpsClient.afterConnect(Unknown Source) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(Unknown Source) at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) at java.net.HttpURLConnection.getResponseCode(Unknown Source) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(Unknown Source) at com.siemens.smartld.kerberos_request.App.main(App.java:80) Caused by: java.io.EOFException: SSL peer shut down incorrectly at com.sun.net.ssl.internal.ssl.InputRecord.read(Unknown Source) ... 10 more After a short analysis, I have realized that the client sends: main, WRITE: TLSv1 Handshake, length = 75 main, WRITE: SSLv2 client hello message, length = 101 Since the server does not support any form of SSL, it aborts the handshake. After a bit of Goole I found these [1], [2] SO threads saying that this is correct due to the RFC to retain backwards compat with older servers. According to Oracle's docs, this has been dropped in Java 7 [3] and [4]: Area: API: JSSE Synopsis: Support for TLS 1.1 has been added to the SunJSSE provider, and the SSLv2Hello pseudo protocol is no longer active by default in the SunJSSE provider. And Area: Runtime Synopsis: The SSLv2Hello Handshake Protocol is Now Disabled by Default Description: The SSLv2Hello handshake protocol, which was used by SSLv3 server implementations to communicate with [...] Java 7 is not an option here at the moment. What you can do is to explicitly disable SSLv2Hello message with a system property [5] but still, other folks will stumble upon this problem anyway doing the same research as I did and waste their time. I retried the same setup with OpenSSL as in my server.xml: openssl s_server -cert /etc/opt/ssl/cert/server.crt \ -key /etc/opt/ssl/key/server.key -tls1 -cipher HIGH Fails just as same as Tomcat. Though adding -ssl3 fails too. To alleviate this issue for the Java client, I have patched Tomcat to allow SSLv3+TLSv1 [6] to make both work, the connection does not fail anymore. Now, according to the citation in this SO answer [7] my question is: Should Tomcat ignore the SSLv2Hello wrapped compat message (which is a actually a SSLv3/TLSv1 version message according to Wireshark) and continue with the TLSv1 handshake? Shall I presume that both OpenSSL s_server and Tomcat are incorrect or is this some inconsistency in the RFC? [1] http://stackoverflow.com/questions/10196436/ssl-handshaking-with-older-clients-using-sslengine-jsse [2] http://stackoverflow.com/questions/4682957/why-does-javas-sslsocket-send-a-version-2-client-hello [3] http://www.oracle.com/technetwork/java/javase/jdk7-relnotes-418459.html [4] http://www.oracle.com/technetwork/java/javase/compatibility-417013.html [5] http://docs.oracle.com/javase/1.4.2/docs/guide/plugin/developer_guide/faq/troubleshooting.html [6] https://issues.apache.org/bugzilla/show_bug.cgi?id=53344 [7] http://stackoverflow.com/a/10198268/696632 With best regards, Michael Osipov
Re: WebApp on Tomcat recognize automaticely uploaded file
I know is strange but webAppA, started to work suddenly. The only thing I have done this days is a lot of restarts when deploying stuff for webAppB. Now seems that each image uploaded through webAppB, inside c:/pathtoDocbase/webAppA/uploads/ (or pasted directly in file system) is been replied(showed in the browser) correctly when doing a http request like http://servername/webAppA/uploads/1.jpg Maybe is a configuration parameter that I have changed without noticing it, but I am not sure. Thank you for your reply. 2012/5/19 André Warnier a...@ice-sa.com Ermal Aliraj wrote: Yes, I say webAppA do not recognize the images because do not serve them through the browser via URL I did the following scneario and writing down in case can make the situation more clear uploaded manualy the following files on: webAppA/uploads/1.jpg webAppB/uploads/1.jpg requesting the files through URL i have the following: www.localhost/webAppA/uploads/**1.jpg --- no reply no reply cannot be. What /exactly/ happens when you enter that URL ? Have you verified that the user under which tomcat runs has permissions to read what is in webAppA ? www.localhost/webAppB/uploads/**1.jpg -- photo visualized --**--**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Question about resetting datasources and changes to the BasicDataSource.close() method
-Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, May 31, 2012 5:23 PM Yup: the solution is to just synchronize all the methods. If restart() is synchronized, it will only operate while other methods are not actively checking-out or checking-in connections. The big problem with the concept of a restart is that there could be connections that are currently checked- out during the call to recycle()... those need to be handled in some special way -- probably added to a queue that will be processed later to destroy the connections. That's what I will submit to commons-dbcp, then. On the one hand, synchronizing these methods should not be necessary because Java boolean values are defined to be 32-bit integers which feature atomic assignment (that is, no thread ever sees only 8-bits of the 32-bit value being assigned and 24-bits of the old value). On the other hand, threads are allowed to keep cached copies of certain data under certain conditions. Using the keyword 'volatile' /should/, in recent JVMs, make the use of 'synchronized' completely unnecessary, while older JVMs may even ignore 'volatile' making 'synchronized' mandatory. Use of 'synchronized' is the safest bet because it definitely causes a 'memory barrier' to be crossed in any version of JVM: that means that the thread is required to synchronize (perhaps a bad choice of words) its cache with main memory which means that all variables get the latest copies of the real data. Yep. That was my point too. What does it really matter anyway whether you are able to lock this in a getter. When you ask for the value, you are just asking for what is current. You have to protect yourself from non-initialized/null in any case. It just adds some unnecessary overhead ( to the JVM and brain ) to synchronize your getter when it doesn't mutate the data - unless I am missing something. --Brooke
Re: Where do I store Images in tomcat structure so that I can retrive it properly in all browsers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kiran, On 5/31/12 10:37 PM, Kiran Badi wrote: Ok I did it this way in TC 7.0.27 as I decided not to touch Netbeans setup with 7.0.11( I had messed up TC7.0.11 after doing several trial and error stuff,felt real pain) I have TC7.0.27 running as window service which I use it deploy my latest build everyday. In server xml, I added below context between host tags Context path=/myapp/UploadedImages docBase=c:\UploadedImages reloadable=true crossContext=true / You shouldn't put Context elements in server.xml. Also, using a docBase that has files appear at random can be problematic when it comes to caching, etc. and users often have problems. so I did not use aliases at all, is this good solution or I am missing something again. Presumably you have an existing webapp that does the upload part: make C:\UploadedImages into an alias for that webapp instead of creating a second webapp for it. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/I5l0ACgkQ9CaO5/Lv0PCtJwCgrGbdhRjeSetyRz8Zr3Bvzkt0 mU0AnidgFANsdy8ZFNoo8/SPLCCY11+E =7Q6w -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Question about resetting datasources and changes to the BasicDataSource.close() method
2012/5/30 Hedrick, Brooke - 43 brooke.hedr...@rainhail.com: (...) Next, I looked at the new datasource org.apache.tomcat.jdbc.pool.DataSource. I have not found any methods to close/reset the pools and the JMX attributes are readonly. This prevents us both from resetting and resizing our connection pools. By the way: fix bug53254/bug (rev1340160/rev): Add in the ability to purge connections from the pool (fhanik) /fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53254 It will be in Tomcat JDBC pool in 7.0.28. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Question about resetting datasources and changes to the BasicDataSource.close() method
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brooke, On 6/1/12 11:54 AM, Hedrick, Brooke - 43 wrote: -Original Message- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Thursday, May 31, 2012 5:23 PM That's what I will submit to commons-dbcp, then. On the one hand, synchronizing these methods should not be necessary because Java boolean values are defined to be 32-bit integers which feature atomic assignment (that is, no thread ever sees only 8-bits of the 32-bit value being assigned and 24-bits of the old value). On the other hand, threads are allowed to keep cached copies of certain data under certain conditions. Using the keyword 'volatile' /should/, in recent JVMs, make the use of 'synchronized' completely unnecessary, while older JVMs may even ignore 'volatile' making 'synchronized' mandatory. Use of 'synchronized' is the safest bet because it definitely causes a 'memory barrier' to be crossed in any version of JVM: that means that the thread is required to synchronize (perhaps a bad choice of words) its cache with main memory which means that all variables get the latest copies of the real data. Yep. That was my point too. What does it really matter anyway whether you are able to lock this in a getter. When you ask for the value, you are just asking for what is current. You have to protect yourself from non-initialized/null in any case. It just adds some unnecessary overhead ( to the JVM and brain ) to synchronize your getter when it doesn't mutate the data - unless I am missing something. Locking this makes sure that the thread's local copy of whatever-you-are-getting is updated properly and not stale-cached. If you synchronize the setter, it is a very good idea to synchronize the getter too. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/I6xcACgkQ9CaO5/Lv0PA87wCeLBo6OzS2H/oEq9pEEduhYNnV xFEAn1sPEI8bUvvC2HSQKKb9Z5tpMQ4b =vMfh -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Question about resetting datasources and changes to the BasicDataSource.close() method
From: Christopher Schultz [mailto:ch...@christopherschultz.net] Subject: Re: Question about resetting datasources and changes to the BasicDataSource.close() method Locking this makes sure that the thread's local copy of whatever-you-are-getting is updated properly and not stale-cached. If you synchronize the setter, it is a very good idea to synchronize the getter too. Also, unless you're absolutely certain that the entity being retrieved is a primitive type, you must synchronize to insure that the structure you're fiddling with is not in an undefined state. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Question about resetting datasources and changes to the BasicDataSource.close() method
-Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Friday, June 01, 2012 11:06 AM By the way: fix bug53254/bug (rev1340160/rev): Add in the ability to purge connections from the pool (fhanik) /fix https://issues.apache.org/bugzilla/show_bug.cgi?id=53254 It will be in Tomcat JDBC pool in 7.0.28. Thank you Konstantin. You inspired me to put my own request in for resizing MaxActive as well. https://issues.apache.org/bugzilla/show_bug.cgi?id=53346 --Brooke - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: which java ?
2012/6/1 André Warnier a...@ice-sa.com: Hi. I am in the process of installing a new system at a customer, Tomcat 6 being part of the mix. This is a Suse Enterprise Linux (SEL) system, and the sysadmins at the customer very strongly favor using the pre-packaged software available with that distribution. (A position which which I can sympathise, being myself the sysadmin for a bunch of systems). Anyway, the question is not directly about Tomcat, but about the Java JVM. Under that version of SEL, the standard Java package is not the Oracle/Sun JVM, but this one : Java 1.6.0 IBM SR10.1-0.3.1 My question is : are there any kinds of problems/differences to be expected running Tomcat 6 over that JVM, as compared to the comparable Oracle/Sun version which I otherwise use everywhere else ? And if yes, in which area could the differences show up ? The Tomcat applications to be run on that system are minimal, but there are a couple for which I do not have (and cannot get) the sources. Or to phrase the question otherwise : are there strong reasons to push for installing instead an Oracle/Sun 1.6 JVM on that system (outside the SEL package management system and thus risking to inconvenience the sysadmins) to run Tomcat 6 on it ? 1. The memory leaks protection code (in JreMemoryLeakPreventionListener and in WebappClassLoader) is written based on analysis of flaws in Sun/Oracle implementation of JRE. Your experience with other JVMs might be different. I would not say that this is a critical feature though, as many are still using 5.5 where no such protection was ever implemented. Look for issue 52850:in Tomcat 7 changelog. I think it was not ported to 6.0, as changelog of 6.0 does not mention it. 2. Testing, testing, testing... I would try to run Tomcat 7 testsuite on that JDK to see if there are any noticeable failures. There is no such suite for 6.0 though. Maybe you can use some automated tests from some web applications. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: which java ?
Konstantin Kolinko wrote: 2012/6/1 André Warnier a...@ice-sa.com: Hi. I am in the process of installing a new system at a customer, Tomcat 6 being part of the mix. This is a Suse Enterprise Linux (SEL) system, and the sysadmins at the customer very strongly favor using the pre-packaged software available with that distribution. (A position which which I can sympathise, being myself the sysadmin for a bunch of systems). Anyway, the question is not directly about Tomcat, but about the Java JVM. Under that version of SEL, the standard Java package is not the Oracle/Sun JVM, but this one : Java 1.6.0 IBM SR10.1-0.3.1 My question is : are there any kinds of problems/differences to be expected running Tomcat 6 over that JVM, as compared to the comparable Oracle/Sun version which I otherwise use everywhere else ? And if yes, in which area could the differences show up ? The Tomcat applications to be run on that system are minimal, but there are a couple for which I do not have (and cannot get) the sources. Or to phrase the question otherwise : are there strong reasons to push for installing instead an Oracle/Sun 1.6 JVM on that system (outside the SEL package management system and thus risking to inconvenience the sysadmins) to run Tomcat 6 on it ? 1. The memory leaks protection code (in JreMemoryLeakPreventionListener and in WebappClassLoader) is written based on analysis of flaws in Sun/Oracle implementation of JRE. Your experience with other JVMs might be different. I would not say that this is a critical feature though, as many are still using 5.5 where no such protection was ever implemented. Look for issue 52850:in Tomcat 7 changelog. I think it was not ported to 6.0, as changelog of 6.0 does not mention it. 2. Testing, testing, testing... I would try to run Tomcat 7 testsuite on that JDK to see if there are any noticeable failures. There is no such suite for 6.0 though. Maybe you can use some automated tests from some web applications. Thanks Konstantin. So far, it seems to run, and I have not yet seen any scary out-of-place messages in the logs. But I only have a tiny test app for now. I'll run some heavier tests next week. I'll look up issue 52850. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: which java ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 6/1/12 4:44 AM, André Warnier wrote: Or to phrase the question otherwise : are there strong reasons to push for installing instead an Oracle/Sun 1.6 JVM on that system (outside the SEL package management system and thus risking to inconvenience the sysadmins) to run Tomcat 6 on it ? Sun/Oracle seems to be the most compatible JVM out there, but the IVM JVM has already been very good. It used to be (10 years ago?) that the IBM JVM was measurably faster than the Sun JVM, though it tended to eat-up memory more quickly. OpenJDK is also a very solid JVM these days. I believe Oracle recently changed the redistribution license for the JDK/JRE such that Linux package managers either cannot or choose not to provide the Sun/Oracle JVM anymore. Most of the time, I see OpenJDK as the default. If the IBM JVM is already installed, give it a try. If you have nothing installed already, you might want to see if the OpenJDK JVM is an option and go with that. The more users the better. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/JClYACgkQ9CaO5/Lv0PCYsQCdGfM/9aileiiIRN6X0BOiJYuc 37gAoJMSn6sVI1wMhhIkBQNSiqRVU6/G =qazt -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: tomcat jdbc pool, creating a pool of pools, single connection memory footprint
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ahmed, On 5/31/12 9:33 AM, S Ahmed wrote: It would be easier if all databases were hosted by a single instance of MySQL -- then you could use Tomcat-pool's feature of being able to provide credentials when obtaining connections from the pool -- and get the right database. That way, a much smaller number of connections could be maintained with roughly the same semantics. Can you expand on how I could do this? Well, first you have to accept that the same MySQL instance (with perhaps different databases) will be hosting all your data. If that's not okay with you, then you can forget this suggestion (or, maybe it just changes the suggestion slightly because you could always have N databases and maybe 4 MySQL instances when them split across the 4... but then you'd have to figure out which connection pool to grab before getting a connection or you'd never get connected). Next, you'd have to switch to tomcat-pool because commons-dbcp (the default CP in Tomcat) does not support obtaining pooled connections with credentials. Next, you remove the database name from the JDBC URL (or maybe change it to something everyone can access, like the 'test' database or 'information_schema' depending on your version of MySQL). Then, you have your code call DataSource.getConnection(username,password) instead of calling DataSource.getConnection(). This gets you the right credentials for your target database. Finally, make sure you issue a query to set the database for the connection: 'USE databasename;' Then, you set your connection pool to have however many connections you want (100?) and every client (thread) shares those connections with every client database that runs in a particular MySQL instance. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/JC8wACgkQ9CaO5/Lv0PBEpgCghI3t8gpE+SBSNV/pYjyLqqwq 2hwAoIY8mYqGGG+owxzsFPQ+CFa2cVeL =Fh/Y -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
ROOT.xml problem
I am using Tomcat 7 and wish to have my app open as the default page. I have googled and basically found the following recommendation, but its not working. Wondering what I am missing? ROOT.xml code…. ?xml version=1.0 encoding=utf-8? Context docBase=corda.war path=/corda reloadable=true /Context ……. Thanks in advance. Kevin - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: ROOT.xml problem
2012/6/1 Kevin Marx simplyfema...@gmail.com: I am using Tomcat 7 and wish to have my app open as the default page. I have googled and basically found the following recommendation, but its not working. Wondering what I am missing? ROOT.xml code…. ?xml version=1.0 encoding=utf-8? Context docBase=corda.war path=/corda reloadable=true /Context Just rename corda.war to ROOT.war. That is all. Note, that it is in the FAQ, http://wiki.apache.org/tomcat/HowTo#How_do_I_make_my_web_application_be_the_Tomcat_default_application.3F - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Why @WebServlet annotation is not processed when web.xml is version 2.5?
On 01/06/2012 09:55, maria petrova wrote: Hi, As the Servlet 3.0 expert group shed some lighthttp://java.net/projects/servlet-spec/lists/users/archive/2012-05/message/1upon this question I would like to raise it here again. So do you plan revising the current processing of annotations (based on the web.xml version) as it contradicts the clarification from the expert group saying: *“If you are using a Java EE 6 compatible implementation and use the Servlet 3.0 feature / annotation, it should work independent of the version of the descriptor.”* May be the default behavior should be preserved and only *org.apache.catalina. STRICT_SERVLET_COMPLIANCE* should be extended with an additional property that controls the questioned handling? What do you think? I think that while the intent of the 3.0 EG is clear, the current EG has identified several issues with the current approach and the discussion on those has yet to conclude. I'd rather wait to see the final conclusion before making any changes. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: ROOT.xml problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevin, On 6/1/12 2:40 PM, Kevin Marx wrote: I am using Tomcat 7 and wish to have my app open as the default page. I have googled and basically found the following recommendation, but its not working. Wondering what I am missing? ROOT.xml code…. Where is your ROOT.xml file? ?xml version=1.0 encoding=utf-8? Context docBase=corda.war path=/corda Obviously, you don't want the path to be set to /corda if you want the context path to actually be . The path attribute is illegal in this context anyway, so remove it entirely. You should probably have the above file in META-INF/context.xml with *no docBase* inside your WAR file. Just name your WAR file ROOT.war (note that ROOT must be uppercase, even on a case-insensitive filesystem like NTFS). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/JG1MACgkQ9CaO5/Lv0PClxwCgrpPttvcivjKAG24kqs6VkWA7 rb0AoLdNxTQQYdhGZgshEfxOUOqUIBmZ =A0p8 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: ROOT.xml problem
The ROOT.xml file is in the Catalina/localhost folder Renaming the folder didn't work BTW. I have the /corda folder located in the /webapps folder I'd like the /corda to be the default app when I don't have the ROOT.xml file, I can go to the browser and enter http://localhost/corda and everything works fine I'd like it to work so that when I enter http://localhost I get the corda as the default. (without having to use the /corda in the URL) I know there is a way to do this without renaming things to ROOT, that's what I'm looking for. How do I set up the ROOT.xml file so that it makes the /corda the default rather than /ROOT as the default? Kevin On Jun 1, 2012, at 12:43 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevin, On 6/1/12 2:40 PM, Kevin Marx wrote: I am using Tomcat 7 and wish to have my app open as the default page. I have googled and basically found the following recommendation, but its not working. Wondering what I am missing? ROOT.xml code…. Where is your ROOT.xml file? ?xml version=1.0 encoding=utf-8? Context docBase=corda.war path=/corda Obviously, you don't want the path to be set to /corda if you want the context path to actually be . The path attribute is illegal in this context anyway, so remove it entirely. You should probably have the above file in META-INF/context.xml with *no docBase* inside your WAR file. Just name your WAR file ROOT.war (note that ROOT must be uppercase, even on a case-insensitive filesystem like NTFS). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/JG1MACgkQ9CaO5/Lv0PClxwCgrpPttvcivjKAG24kqs6VkWA7 rb0AoLdNxTQQYdhGZgshEfxOUOqUIBmZ =A0p8 -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
Re: ROOT.xml problem
On 01/06/2012 22:22, Kevin Marx wrote: The ROOT.xml file is in the Catalina/localhost folder Renaming the folder didn't work BTW. I have the /corda folder located in the /webapps folder I'd like the /corda to be the default app when I don't have the ROOT.xml file, I can go to the browser and enter http://localhost/corda and everything works fine I'd like it to work so that when I enter http://localhost I get the corda as the default. (without having to use the /corda in the URL) I know there is a way to do this without renaming things to ROOT, that's what I'm looking for. How do I set up the ROOT.xml file so that it makes the /corda the default rather than /ROOT as the default? Move the /corda directory outside of webapps and then set the docBase in ROOT.xml Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: ROOT.xml problem
OK… here's what I've done. ROOT.xml located in /conf/Catalina/localhost contents of Root.xml ?xml version=1.0 encoding=ISO-8859-1? Context docBase=C:\Corda\CenterView4\Server\corda path= reloadable=true / http://localhost:8080 entered on a browser Lost session info before entering the auth filter shown as result I have also tried including path=\corda and received the same results. Kevin On Jun 1, 2012, at 2:27 PM, Mark Thomas wrote: On 01/06/2012 22:22, Kevin Marx wrote: The ROOT.xml file is in the Catalina/localhost folder Renaming the folder didn't work BTW. I have the /corda folder located in the /webapps folder I'd like the /corda to be the default app when I don't have the ROOT.xml file, I can go to the browser and enter http://localhost/corda and everything works fine I'd like it to work so that when I enter http://localhost I get the corda as the default. (without having to use the /corda in the URL) I know there is a way to do this without renaming things to ROOT, that's what I'm looking for. How do I set up the ROOT.xml file so that it makes the /corda the default rather than /ROOT as the default? Move the /corda directory outside of webapps and then set the docBase in ROOT.xml Mark - 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
Re: ROOT.xml problem
On 01/06/2012 22:53, Kevin Marx wrote: OK… here's what I've done. ROOT.xml located in /conf/Catalina/localhost contents of Root.xml Case matters. Which is it? ?xml version=1.0 encoding=ISO-8859-1? Context docBase=C:\Corda\CenterView4\Server\corda path= reloadable=true / Remove the path attribute, it is invalid here as the message in the logs tells you. http://localhost:8080 entered on a browser Lost session info before entering the auth filter shown as result That would be an application error you need to debug, not a Tomcat error. I have also tried including path=\corda and received the same results. Yep, that won't help and may make things worse. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: ROOT.xml problem
From: Kevin Marx [mailto:simplyfema...@gmail.com] Subject: Re: ROOT.xml problem ROOT.xml located in /conf/Catalina/localhost ?xml version=1.0 encoding=ISO-8859-1? Context docBase=C:\Corda\CenterView4\Server\corda path= reloadable=true / As you've been told before, remove the path attribute; it's not allowed here. http://localhost:8080 entered on a browser Lost session info before entering the auth filter shown as result Shown where? That's not a message Tomcat displays, so it may well be coming from your webapp. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: ROOT.xml problem
OK, response to last two (Thomas and Charles) ROOT.xml (understood the case matters comment, it is capitals ROOT.xml) removed the path= contents now are: ?xml version=1.0 encoding=ISO-8859-1? Context docBase=C:\Corda\CenterView4\Server\corda reloadable=true / Same message showing in the browser (Lost session info…..) When the /corda folder is located within the /webapps folder, I can use the URL localhost/corda and everything works fine so I am assuming the app is ok. I just checked with the vendor for the webapp and they indicated that it should be able to exist outside the /webapps folder. Thoughts? Kevin On Jun 1, 2012, at 2:56 PM, Mark Thomas wrote: On 01/06/2012 22:53, Kevin Marx wrote: OK… here's what I've done. ROOT.xml located in /conf/Catalina/localhost contents of Root.xml Case matters. Which is it? ?xml version=1.0 encoding=ISO-8859-1? Context docBase=C:\Corda\CenterView4\Server\corda path= reloadable=true / Remove the path attribute, it is invalid here as the message in the logs tells you. http://localhost:8080 entered on a browser Lost session info before entering the auth filter shown as result That would be an application error you need to debug, not a Tomcat error. I have also tried including path=\corda and received the same results. Yep, that won't help and may make things worse. Mark - 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
Re: ROOT.xml problem
OK, response to last two (Thomas and Charles) ROOT.xml (understood the case matters comment, it is capitals ROOT.xml) removed the path= contents now are: ?xml version=1.0 encoding=ISO-8859-1? Context docBase=C:\Corda\CenterView4\Server\corda reloadable=true / Same message showing in the browser (Lost session info…..) When the /corda folder is located within the /webapps folder, I can use the URL localhost/corda and everything works fine so I am assuming the app is ok. I just checked with the vendor for the webapp and they indicated that it should be able to exist outside the /webapps folder. Thoughts? Kevin On Jun 1, 2012, at 2:56 PM, Mark Thomas wrote: On 01/06/2012 22:53, Kevin Marx wrote: OK… here's what I've done. ROOT.xml located in /conf/Catalina/localhost contents of Root.xml Case matters. Which is it? ?xml version=1.0 encoding=ISO-8859-1? Context docBase=C:\Corda\CenterView4\Server\corda path= reloadable=true / Remove the path attribute, it is invalid here as the message in the logs tells you. http://localhost:8080 entered on a browser Lost session info before entering the auth filter shown as result That would be an application error you need to debug, not a Tomcat error. I have also tried including path=\corda and received the same results. Yep, that won't help and may make things worse. Mark - 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
Re: ROOT.xml problem
On 01/06/2012 22:22, Kevin Marx wrote: I know there is a way to do this without renaming things to ROOT, that's what I'm looking for. Why make your life so difficult, what's wrong with just calling it ROOT.war? /baffled If you're really desperate to see that it's called 'corda', call the app: ROOT##corda.war p signature.asc Description: OpenPGP digital signature
Re: Where do I store Images in tomcat structure so that I can retrive it properly in all browsers
On 6/1/2012 9:27 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kiran, On 5/31/12 10:37 PM, Kiran Badi wrote: Ok I did it this way in TC 7.0.27 as I decided not to touch Netbeans setup with 7.0.11( I had messed up TC7.0.11 after doing several trial and error stuff,felt real pain) I have TC7.0.27 running as window service which I use it deploy my latest build everyday. In server xml, I added below context between host tags Context path=/myapp/UploadedImages docBase=c:\UploadedImages reloadable=true crossContext=true / You shouldn't putContext elements in server.xml. Also, using a docBase that has files appear at random can be problematic when it comes to caching, etc. and users often have problems. Kiran : I had never thought about caching , and caching is one of key features which I am planning to implement. so I did not use aliases at all, is this good solution or I am missing something again. Presumably you have an existing webapp that does the upload part: make C:\UploadedImages into an alias for that webapp instead of creating a second webapp for it. Ok I will give try to create alias and see how it goes. Thanks. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/I5l0ACgkQ9CaO5/Lv0PCtJwCgrGbdhRjeSetyRz8Zr3Bvzkt0 mU0AnidgFANsdy8ZFNoo8/SPLCCY11+E =7Q6w -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
getting frustrated with web sockets
I am trying to build an android app that connects to tomcat web sockets. I need a few java classes that can interact with tomcat websockets. I have tried 3 different implementations (strumsoft, jwebsockets and something else also) but neither one can talk to tomcat correctly. The issue seems to be protocol incompatibility between tomcat as server and any existing java websockets client. I even compiled jwebsockets swing based test client and that also cannot talk to tomcat. Surprisingly all javascript based clients can talk to tomcat, only java based cannot. So having done all that research, I wonder if somebody can help me identify java classes that will work with tomcat. Does tomcat have a client jar I can use? Help! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
