Re: Weird problem: slow upload via Manager
On 06.07.2018 19:49, Chris Cheshire wrote: On Jul 6, 2018, at 12:56 PM, James H. H. Lampert wrote: Forgive the top-post. The reason why this particular case of an extremely slow Manager upload sticks out is because we've done, by now, hundreds of uploads of this same WAR file (or earlier versions of it), via Manager, on over a dozen different installations, most of them AS/400s, and none of the others have taken even half this long. The problem might be deeper than tomcat then. +1 Have you ruled out IO problems writing the WAR? Is the HD/SSD failing and trying to resolve bad blocks? Is the network device failing causing dropped packets? Has another process on the machine run amok and causing IO contention, or paging issues? With the information available so far, it is a bit hard to make a qualified guess. If you can do this, and you have a choice of WARs to upload to the same system, and as a first simple way of getting more information, I would try uploading e.g. a WAR that is 50% or 25% or 10% the size of that original one, and see if the times are consistent with your 50 MB WAR. And do this several times, to see if the times are consistent for the same size, or they vary widely over time. Uploading another WAR will use exactly the same steps and elements as your first try, varying only one item at a time : the size of the upload. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Weird problem: slow upload via Manager
> On Jul 6, 2018, at 12:56 PM, James H. H. Lampert > wrote: > > Forgive the top-post. > > The reason why this particular case of an extremely slow Manager upload > sticks out is because we've done, by now, hundreds of uploads of this same > WAR file (or earlier versions of it), via Manager, on over a dozen different > installations, most of them AS/400s, and none of the others have taken even > half this long. > The problem might be deeper than tomcat then. Have you ruled out IO problems writing the WAR? Is the HD/SSD failing and trying to resolve bad blocks? Is the network device failing causing dropped packets? Has another process on the machine run amok and causing IO contention, or paging issues? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Weird problem: slow upload via Manager
Forgive the top-post. The reason why this particular case of an extremely slow Manager upload sticks out is because we've done, by now, hundreds of uploads of this same WAR file (or earlier versions of it), via Manager, on over a dozen different installations, most of them AS/400s, and none of the others have taken even half this long. On 7/6/18, 12:54 AM, André Warnier (tomcat) wrote: - when a browser POSTs a file, the content is first Base64-encoded, which typically increases the size in bytes by some 30-50%. Of course the receiving server has to Base64-decode the received data, to restore the original file. - it is not unusual for encoding/decoding code to process all the data in memory, as a block. This is usually the fastest way, until some treshold is reached where the data does not fit anymore in memory all at once. And then there can be a sudden dramatic slowdown, as either there is some frantic allocation of additional memory, or swapping taking place. You might want to have a look at tomcat's JVM garbage collection statistics while such an upload is going on. - also, whatever is POSTed to a webserver, is usually first accumulated somewhere, until the POST is complete. And then the whole POST is processed, parsed into parts, decoded if need be, and made available to the web application. - if this all happens via HTTP, it is also quite possible that there is some firewall/virus scanning going on, which would add another round of decoding and examining the POSTed data, which may also be quite sensitive to the size of things. What I mean is that there is a lot more going on behind the scenes, as compared to a simple file transfer via FTP or so. And if each step introduce some additional overhead depending on the original POST size, you may have something that looks exponentially (or asymptotically) worse in the end. Like 10 MB = 10s., 40 MB = 40s., 50 MB = 50s., 51 MB = 10 minutes. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Weird problem: slow upload via Manager
On 06.07.2018 01:23, James H. H. Lampert wrote: Earlier this week, on a customer AS/400 installation (Tomcat 7.0.67), we experienced the slowest WAR file upload we've ever encountered: several HOURS to install a roughly 100M WAR file (we customarily increase the max-file-size and max-request-size in manager/WEB-INF/web.xml from 50M to 500M). This on a system in which a 10M FTP download typically takes anywhere from 15 seconds to a minute or so. Has anybody ever heard of anything like this happening? Could there be something in the customer's firewall that's slowing down what Manager uses to transfer WAR files (I'm guessing either HTTP POST or PUT)? Any suggestions on alternate ways of getting WAR files onto the box? Not about that, but maybe some basic info : - a browser does not natively do PUTs, so I guess POST it is - when a browser POSTs a file, the content is first Base64-encoded, which typically increases the size in bytes by some 30-50%. Of course the receiving server has to Base64-decode the received data, to restore the original file. - it is not unusual for encoding/decoding code to process all the data in memory, as a block. This is usually the fastest way, until some treshold is reached where the data does not fit anymore in memory all at once. And then there can be a sudden dramatic slowdown, as either there is some frantic allocation of additional memory, or swapping taking place. You might want to have a look at tomcat's JVM garbage collection statistics while such an upload is going on. - also, whatever is POSTed to a webserver, is usually first accumulated somewhere, until the POST is complete. And then the whole POST is processed, parsed into parts, decoded if need be, and made available to the web application. - if this all happens via HTTP, it is also quite possible that there is some firewall/virus scanning going on, which would add another round of decoding and examining the POSTed data, which may also be quite sensitive to the size of things. What I mean is that there is a lot more going on behind the scenes, as compared to a simple file transfer via FTP or so. And if each step introduce some additional overhead depending on the original POST size, you may have something that looks exponentially (or asymptotically) worse in the end. Like 10 MB = 10s., 40 MB = 40s., 50 MB = 50s., 51 MB = 10 minutes. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Weird problem: slow upload via Manager
If you are not remote, can you just copy them to the IFS folder? On 6 July 2018 at 00:23, James H. H. Lampert wrote: > Earlier this week, on a customer AS/400 installation (Tomcat 7.0.67), we > experienced the slowest WAR file upload we've ever encountered: several > HOURS to install a roughly 100M WAR file (we customarily increase the > max-file-size and max-request-size in manager/WEB-INF/web.xml from 50M to > 500M). This on a system in which a 10M FTP download typically takes > anywhere from 15 seconds to a minute or so. > > Has anybody ever heard of anything like this happening? Could there be > something in the customer's firewall that's slowing down what Manager uses > to transfer WAR files (I'm guessing either HTTP POST or PUT)? > > Any suggestions on alternate ways of getting WAR files onto the box? > > -- > James H. H. Lampert > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Weird problem: slow upload via Manager
Earlier this week, on a customer AS/400 installation (Tomcat 7.0.67), we experienced the slowest WAR file upload we've ever encountered: several HOURS to install a roughly 100M WAR file (we customarily increase the max-file-size and max-request-size in manager/WEB-INF/web.xml from 50M to 500M). This on a system in which a 10M FTP download typically takes anywhere from 15 seconds to a minute or so. Has anybody ever heard of anything like this happening? Could there be something in the customer's firewall that's slowing down what Manager uses to transfer WAR files (I'm guessing either HTTP POST or PUT)? Any suggestions on alternate ways of getting WAR files onto the box? -- James H. H. Lampert - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: More, Re: Weird problem: browsers refusing to connect; more "fun with ciphers clauses on the connector tag"
On 10/19/17, 10:02 AM, Christopher Schultz wrote: The browser tells the server what cipher suites it supports during the initial handshake, and the server decides which algorithm to use. The client doesn't try multiple different connections to see which one sticks. The server either replies saying "okay, were using "suite X" or "go away, we can't talk to each other because we don't have any algorithms in common". That actually makes a certain amount of sense, if the JVM somehow *thinks* it can handle certain ciphers (e.g., the ECDHE ciphers), but can't. And if the Midrange box JVMs are deferring cipher implementation to the OS, rather than implementing it internally, I can see how that could happen. I'll note that the ones that have ECDHE ciphers enabled, and aren't blowing up not only Chrome 60 but a bunch of simulated browser handshakes, are all on a much newer revision of the OS, one that, I think, supports ECDHE at the OS level, whereas the ones on which I had to disable ECDHE are on an OS revision that does NOT support it at the OS level. Some pretty big assumptions, but if they're right, it would explain much. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: More, Re: Weird problem: browsers refusing to connect; more "fun with ciphers clauses on the connector tag"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 James, On 10/16/17 2:35 PM, James H. H. Lampert wrote: > I just got finished going through 20 other customer Tomcat > installations we administer. > > First, I found that most of them were accepting the DHE ciphers > I'd disabled on the problem installation, and SSLLabs was giving > them bad ratings for doing so. Just for completeness, there's nothing wrong with DHE other than that it's slow. Your previous post showed that it was using "weak primes" which IS a concern, but unfortunately there are very old clients that don't support larger primes (I'm looking at YOU, Java 1.6) and so options are limited. > Second, I found that two of the other installations were accepting > the ECDHE ciphers I'd disabled, and yet they were working just fine > in Chrome 60 (one of them still on a "test" certificate that was > self-signed, wrong domain, and expired! -- we can encourage them to > pick a CA, and let us help them install a signed cert, but we can't > MAKE them do it). You should enable ECDHE. It's the best per-CPU-cycle key-agreement algorithm available today. EC keys (for authentication) are a little less useful than RSA these days, but if you can support both, I would recommend doing ahead to support both. A thought just occurred to me: are some clients using libtcnative/APR and others not? I believe Tomcat still prefers APR/tcnative to the Java NIO connector is the libraries are available. For Tomcat 7, the configuration is sensitive to the type of connector being used, so if you "disabled a cipher suite" and it seems to be still enabled (e.g. ECDHE) that could be an explanation. > That one is running on an AS/400 at V7R3, with a JVM that IDs in > Manager as "jvmap3270sr10fp1-20170215_012.6"; the other one that's > working fine with the ECDHE certs active is an AS/400 at V7R1, with > a JVM that IDs as "jvmap3260sr16fp15-20151029_01." I think most of that is going to be meaningless to us, unfortunately. The output of "java -version" is going to be more useful. > In all cases, SSL is via JSSE, not OpenSSL (we've never even heard > of anybody getting Tomcat running via OpenSSL on an AS/400). Okay, that's good to know. > Could it be that the browser is trying to use the ECDHE ciphers, > and something in the OS or the JVM is blowing up when it tries to > use them? The browser tells the server what cipher suites it supports during the initial handshake, and the server decides which algorithm to use. The client doesn't try multiple different connections to see which one sticks. The server either replies saying "okay, were using "suite X" or "go away, we can't talk to each other because we don't have any algorithms in common". Is this just happening at a single client? Oh, maybe not, because you said you tried to use Google Chrome yourself and it didn't work. I was thinking "maybe some group policy disabled a whole swath of cipher suites in the org" but that's unlikely to be the case unless your Chrome instance was also affected. Is it possible that the browsers within the org are contacting a DIFFERENT server than the Tomcat itself? Perhaps a load-balancer or reverse-proxy that was broken, and it only *appears* like Tomcat is broken? You ran SSLLabs tool against the site and it says it supports RSA-AES/CBC-SHA which is definitely a decent algorithm (though GCM should be preferred over CBC mode in nearly all cases). Honestly, your server should be supporting more than just those two protocols, but those two should be sufficient to establish a connection with a server that only supports those two. Did you know that Qualys/SSLLabs also has a *client test* as well? Try pointing your Google Chrome instance at this page and see what it says: https://www.ssllabs.com/ssltest/viewMyClient.html I just tried it with my Firefox 56 on Macos and these two cipher suites are supported (as well as many other, of course): TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) TLS_RSA_WITH_AES_256_CBC_SHA (0x35) I did the same with Chrome 60 (latest) and is says it supports a virtually identical list of cipher suites that Firefox does. I didn't check any old versions. Maybe have someone from inside the client's org share their screen with you and have them run SSLLabs test against the hostname as they see it from within. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlno2pEACgkQHPApP6U8 pFhDGBAAk9FcFLmeNy/tScYF9S5SB557qHpGoCfcHMvMTGVy3n8eKsqv2OPT3mSq JwYxDdil2opagLh061Pa1TiNBMfXqWOMdQi573bBeHdWgMrAllfd+hDVSUSqHpIL 3AqhTZI2NDC1Yvg8mAnoF7vbVFSDVnGVs5duyAjcbCJ+nrjBGK+oGteFAC2RiTN5 e4fZmte01Gie+9ihAWeTLc4YQlJT/cygIA1l4EJO0vwJJonwaR/1QGa8PhPxnIgj XXL5zgg3KS6MEf9ioyhZKEJDjCACigal0OIwOGpDHHHkHjwKOHJQ2eJsUz24Ub6U TNCKq1MJJ7yZ1PsBQJZ3QsHZNvkJ6vcXOY70M+t6mvdDGYalw8xTcnUFcdbT2RbZ O+Q/rT0RhTQJaOkg3Jivd81KYdfxhE1+DX8Xz6E7e4Ygpblwa0hZokGk9fosttkK yAMRJqD6zu
More, Re: Weird problem: browsers refusing to connect; more "fun with ciphers clauses on the connector tag"
I just got finished going through 20 other customer Tomcat installations we administer. First, I found that most of them were accepting the DHE ciphers I'd disabled on the problem installation, and SSLLabs was giving them bad ratings for doing so. Second, I found that two of the other installations were accepting the ECDHE ciphers I'd disabled, and yet they were working just fine in Chrome 60 (one of them still on a "test" certificate that was self-signed, wrong domain, and expired! -- we can encourage them to pick a CA, and let us help them install a signed cert, but we can't MAKE them do it). That one is running on an AS/400 at V7R3, with a JVM that IDs in Manager as "jvmap3270sr10fp1-20170215_012.6"; the other one that's working fine with the ECDHE certs active is an AS/400 at V7R1, with a JVM that IDs as "jvmap3260sr16fp15-20151029_01." In all cases, SSL is via JSSE, not OpenSSL (we've never even heard of anybody getting Tomcat running via OpenSSL on an AS/400). Could it be that the browser is trying to use the ECDHE ciphers, and something in the OS or the JVM is blowing up when it tries to use them? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Weird problem: browsers refusing to connect; more "fun with ciphers clauses on the connector tag"
On 16/10/17 17:57, James H. H. Lampert wrote: > Can somebody explain what just happened? > > This morning, we got a call from a customer whose Tomcat server (on > their own hardware) we administer. > > It seems that suddenly, and without any advance warning, all but the > oldest browsers were refusing to connect to the server, without offering > any override option. Dozens of their users were "left out in the cold," > and unable to do their work. What changed? > I ran some tests of my own. Firefox 17 (Mac), for which I've blocked all > updates, connected just fine; Chrome 60 (Mac) was refusing to connect, > with extreme prejudice. I tried the same with our own Tomcat server, and > both browsers connected without complaint. > > I then ran both sites through https://www.ssllabs.com/ssltest, and found > that our own Tomcat supported cipher suites > >> TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) >> TLS_RSA_WITH_AES_256_CBC_SHA (0x35) > > while theirs supported > >> TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) >> TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 1024 bits FS WEAK >> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH secp256r1 (eq. 3072 >> bits RSA) FS >> TLS_RSA_WITH_AES_256_CBC_SHA (0x35) >> TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 1024 bits FS WEAK >> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH secp521r1 (eq. >> 15360 bits RSA) FS > > Both were running Tomcat 7, both under Java 1.6. So I compared the > connector tags in the respective server.xml files, found that ours had a > "ciphers" clause restricting it to the two listed for it, while theirs > did not. > > The obvious next step was to try removing the two DH ciphers, so I gave > them a "ciphers" clause accepting the other four protocols, restarted > Tomcat, cleared my Chrome cache, and tried connecting again. Still > refusing to connect, with extreme prejudice. Even tried shutting Chrome > down, relaunching it, clearing the cache, shutting it down again, and > relaunching it again, and still no change in behavior. > > Finally, when I gave them the same "ciphers" clause we have on our > server, and restarted Tomcat again, everything started working properly. > > I'll also note that the "Handshake Simulation" section of the SSLLabs > test showed 12 "Server sent fatal alert: internal_error" results for > both the "no ciphers clause" case and the "ECDHE" enabled case, but only > one (IE8/XP) for the "same ciphers clause as our own server" case. > > But that leaves me with three big unanswered questions: > > 1. Why would a browser care about unsupported protocols if supported > ones were available? It is the server that appears to be rejecting the connection. Without knowing what has changed it is hard to speculate what might be triggering this. > 2. My understanding is that DH is old, and considered weak, while ECDHE > is new, and considered extremely strong. So why do the ECDHE ciphers > still get rejected with extreme prejudice? See previous response. > 3. (and excuse me for screaming my head off; I'm not screaming AT > anybody) WHY DID THIS "REJECTION WITH EXTREME PREJUDICE" HAPPEN WITH > NEARLY ALL OF THE USERS OVER A WEEKEND, WITH NO WARNING AT ALL? What changed? Something must have. Client update? OS update? Java update? Tomcat update? Certificate expiry? Getting to the bottom of what changed would be the first step in finding what went on over the weekend. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Weird problem: browsers refusing to connect; more "fun with ciphers clauses on the connector tag"
Can somebody explain what just happened? This morning, we got a call from a customer whose Tomcat server (on their own hardware) we administer. It seems that suddenly, and without any advance warning, all but the oldest browsers were refusing to connect to the server, without offering any override option. Dozens of their users were "left out in the cold," and unable to do their work. I ran some tests of my own. Firefox 17 (Mac), for which I've blocked all updates, connected just fine; Chrome 60 (Mac) was refusing to connect, with extreme prejudice. I tried the same with our own Tomcat server, and both browsers connected without complaint. I then ran both sites through https://www.ssllabs.com/ssltest, and found that our own Tomcat supported cipher suites TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) TLS_RSA_WITH_AES_256_CBC_SHA (0x35) while theirs supported TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 1024 bits FS WEAK TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH secp256r1 (eq. 3072 bits RSA) FS TLS_RSA_WITH_AES_256_CBC_SHA (0x35) TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 1024 bits FS WEAK TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH secp521r1 (eq. 15360 bits RSA) FS Both were running Tomcat 7, both under Java 1.6. So I compared the connector tags in the respective server.xml files, found that ours had a "ciphers" clause restricting it to the two listed for it, while theirs did not. The obvious next step was to try removing the two DH ciphers, so I gave them a "ciphers" clause accepting the other four protocols, restarted Tomcat, cleared my Chrome cache, and tried connecting again. Still refusing to connect, with extreme prejudice. Even tried shutting Chrome down, relaunching it, clearing the cache, shutting it down again, and relaunching it again, and still no change in behavior. Finally, when I gave them the same "ciphers" clause we have on our server, and restarted Tomcat again, everything started working properly. I'll also note that the "Handshake Simulation" section of the SSLLabs test showed 12 "Server sent fatal alert: internal_error" results for both the "no ciphers clause" case and the "ECDHE" enabled case, but only one (IE8/XP) for the "same ciphers clause as our own server" case. But that leaves me with three big unanswered questions: 1. Why would a browser care about unsupported protocols if supported ones were available? 2. My understanding is that DH is old, and considered weak, while ECDHE is new, and considered extremely strong. So why do the ECDHE ciphers still get rejected with extreme prejudice? 3. (and excuse me for screaming my head off; I'm not screaming AT anybody) WHY DID THIS "REJECTION WITH EXTREME PREJUDICE" HAPPEN WITH NEARLY ALL OF THE USERS OVER A WEEKEND, WITH NO WARNING AT ALL? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Weird problem with WebSockets
Hi! I have developed an app using websocket. I am using servers to upload my app in DigitalOcean but here the websockets doesnt work but using another server server4U everuthing is fine. I am using Tomcat 8.5.3 somebody has any cluee, any, about this behavour , the only thing that I think is DigitalOcean myabe has any proxy in front of their servers , Tomcat is so weird with this, and server4U dont. I tested my app with WildFly in DigitalOcean and it works fine. I know maybe this is not a problem or who knows but I want just a cluee. Thks In Advance
Re: Weird problem: Two apparent copies of app started
Well, I said it would be DUH!, didn't I. Thanks a lot guys. Have a good weekend, Ken Caldarale, Charles R wrote: From: Ken Bowen [mailto:[EMAIL PROTECTED] Subject: Re: Weird problem: Two apparent copies of app started If I put my context element in META-INF/context.xml, how is it associated with a particular virtual HOST? But if: conf/server.xml defines two virtual hosts: Host1 and Host2 Each should have a unique setting for its appBase attribute, and the appropriate webapps should be placed in the corresponding appBase directory. If multiple elements use the same appBase setting, all webapps under that directory will be deployed in each . - 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 start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Weird problem: Two apparent copies of app started
Ken Bowen wrote: > how does one ensure (if one can?) that myapp is an application running > in Host2, > but not in Host1 ?? Each host has its own appBase. Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Weird problem: Two apparent copies of app started
> From: Ken Bowen [mailto:[EMAIL PROTECTED] > Subject: Re: Weird problem: Two apparent copies of app started > > If I put my context element in META-INF/context.xml, how is it > associated with a particular virtual HOST? > > But if: > conf/server.xml defines two virtual hosts: Host1 and Host2 Each should have a unique setting for its appBase attribute, and the appropriate webapps should be placed in the corresponding appBase directory. If multiple elements use the same appBase setting, all webapps under that directory will be deployed in each . - 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 start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Weird problem: Two apparent copies of app started
Chuck, PID: Thanks for the replies and pointers -- they're a real help. Now, I'm sure the following is going to turn out to be a DUH! moment for me, BUT: If I put my context element in META-INF/context.xml, how is it associated with a particular virtual HOST? It's obvious how this happens if one utilizes: "in individual files (with a ".xml" extension) in the " $CATALINA_HOME/conf/[enginename]/[hostname]/ directory. But if: conf/server.xml defines two virtual hosts: Host1 and Host2 webapps/myapp is *any* webapp (with or without META-INF/context.xml ) how does one ensure (if one can?) that myapp is an application running in Host2, but not in Host1 ?? Thanks, Ken - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Weird problem: Two apparent copies of app started
> From: Ken Bowen [mailto:[EMAIL PROTECTED] > Subject: Re: Weird problem: Two apparent copies of app started > > So what I'm confused about is this: Exactly what should > appear in Host and what in META-INF/context.xml?? > The "A Word on Contexts" in > http://tomcat.apache.org/tomcat-5.5-doc/deployer-howto.html > doesn't give any details. Unfortunately, not all of the Tomcat doc has been updated to reflect the current recommended usage of placing elements in your webapp's META-INF/context.xml file. As Pid pointed out, the most accurate description is here: http://tomcat.apache.org/tomcat-5.5-doc/config/context.html Even that has some discrepancies (e.g., use of the path attribute in the Access Logs and Request Filters examples). To summarize the rules: 1) Never put entries in server.xml. 2) Never use a path attribute in a element. 3) Only use a docBase attribute when the element is in conf/Catalina/[host]/[appname].xml and the webapp is stored outside of the 's appBase directory. 4) Use the name ROOT for the default webapp of each . - 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 start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Weird problem: Two apparent copies of app started
> From: Pid [mailto:[EMAIL PROTECTED] > Subject: Re: Weird problem: Two apparent copies of app started > > DO NOT use the path or docBase attribute in a Context defined > outside of server.xml. One exception to that: if the webapp is placed outside of the appBase directory, your entry must be placed in conf/Catalina/[host]/[appname].xml, and it must contain a docBase attribute that points to the location of the webapp directory or .war file. > If you want to store the files outside of the tomcat directory, just > alter the appBase attribute of the host. The problem with that is you lose the built-in apps that come with Tomcat, which may or may not be a concern. I'd recommend leaving the appBase setting alone, and use the method I described above for any webapps to be located outside of the appBase directory. - 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 start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Weird problem: Two apparent copies of app started
Ken Bowen wrote: > Sorry about thatsome kind of sloppiness on my part. > > I've realize the problem must lie in the relationship between my app's > META-INF/context.xml and what is configured in Tomcat's conf/server.xml. > IIn the latter, found there was an old Context entry in the Host element: > > autoDeploy="true"> > > www.strong-brain.com > 216.154.215.173 > reloadable="true" cookies="true"/> docBase="/opt/tomcat5/server/webapps/manager" privileged="true" debug="0"/> > docBase="/opt/tomcat5/server/webapps/admin" privileged="true" debug="0"/> > prefix="strong-brain.com." suffix=".txt" timestamp="true"/> > > > So what I'm confused about is this: Exactly what should appear in Host > and what in META-INF/context.xml?? > The "A Word on Contexts" in > http://tomcat.apache.org/tomcat-5.5-doc/deployer-howto.html doesn't give > any details. http://tomcat.apache.org/tomcat-5.5-doc/config/context.html Context definitions in server.xml are strongly discouraged in recent releases of Tomcat. Remove the definition with the empty path attribute. (We'll address the admin/manager apps later). DO NOT use the path or docBase attribute in a Context defined outside of server.xml. (The path is determined from the WAR or deployed application directory.) The default Context for a Host is known as the ROOT Context, this is a special name and the capitalisation is important. If you're deploying your app as the default, you should rename the WAR (or the directory if it's unpacked/deployed) accordingly. your/webapps/ROOT.war your/webapps/ROOT/ << unpacked files If you want to store the files outside of the tomcat directory, just alter the appBase attribute of the host. The following illustrates this: /my/sites/www.domain.com/webapps/ROOT /my/sites/www.domain.com/webapps/ROOT/META-INF/context.xml p > Thanks, > Ken > > Caldarale, Charles R wrote: >>> From: Ken Bowen [mailto:[EMAIL PROTECTED] Subject: Weird problem: Two >>> apparent copies of app started >>> >>> strongbrain/WEB-INF/lib/servlet-api.jar >>> >> >> One obvious error: you must not put the servlet-api.jar inside your >> webapp - the container supplies that. Remove it and see if it helps. >> >> - 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 start a new topic, e-mail: users@tomcat.apache.org >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> > > - > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Weird problem: Two apparent copies of app started
Sorry about thatsome kind of sloppiness on my part. I've realize the problem must lie in the relationship between my app's META-INF/context.xml and what is configured in Tomcat's conf/server.xml. IIn the latter, found there was an old Context entry in the Host element: autoDeploy="true"> www.strong-brain.com 216.154.215.173 reloadable="true" cookies="true"/> docBase="/opt/tomcat5/server/webapps/manager" privileged="true" debug="0"/> docBase="/opt/tomcat5/server/webapps/admin" privileged="true" debug="0"/> prefix="strong-brain.com." suffix=".txt" timestamp="true"/> So what I'm confused about is this: Exactly what should appear in Host and what in META-INF/context.xml?? The "A Word on Contexts" in http://tomcat.apache.org/tomcat-5.5-doc/deployer-howto.html doesn't give any details. Thanks, Ken Caldarale, Charles R wrote: From: Ken Bowen [mailto:[EMAIL PROTECTED] Subject: Weird problem: Two apparent copies of app started strongbrain/WEB-INF/lib/servlet-api.jar One obvious error: you must not put the servlet-api.jar inside your webapp - the container supplies that. Remove it and see if it helps. - 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 start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Weird problem: Two apparent copies of app started
> From: Ken Bowen [mailto:[EMAIL PROTECTED] > Subject: Weird problem: Two apparent copies of app started > > strongbrain/WEB-INF/lib/servlet-api.jar One obvious error: you must not put the servlet-api.jar inside your webapp - the container supplies that. Remove it and see if it helps. - 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 start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Weird problem: Two apparent copies of app started
Hello All, I have an application using data source pooling configured in META-INF/context.xml. I set up up the data sources and the classes accessing them in an AppListener. This app works fine on Tomcat 5.5.9 running on Windows and 5.5.25 running on Linux/CentOS 5. I am attempting to bring this app up on a Tomcat 5.5.15 running on a version of Linux/CentOS 4/5 running at an ISP. In this setting, at startup, the app fails in the AppListener, throwing the following exception (in catalina.out): [I'll provide more details below.] com.strongbrain Error: Name jdbc is not bound in this Context javax.naming.NameNotFoundException: Name jdbc is not bound in this Context BUT, then it appears as if Tomcat re-starts the app, and this time the AppListener runs as usual, setting up data sources and the (singleton) classes accessing them correctly (which amounts to storing the datasource in a private instance variable accessed by a public method: getConnection(). FINALLY, when a connection to the app is made, the access via getConnection() behaves as if the instance variable holding the datasource had NOT been instantiated, leading me to feel like there are two copies of the app running. Ok, here are the details. The app is named StrongBrain. First comes a section of the catalina.out log with [POINTs A/B/C] marked for reference: [POINT A] INFO | jvm 1| 2007/09/28 18:07:58 | StrongBrain AppListener: ENTER INFO | jvm 1| 2007/09/28 18:07:58 | com.strongbrain Error: Name jdbc is not bound in this Context INFO | jvm 1| 2007/09/28 18:07:58 | javax.naming.NameNotFoundException: Name jdbc is not bound in this Context INFO | jvm 1| 2007/09/28 18:07:58 | at org.apache.naming.NamingContext.lookup(NamingContext.java:769) INFO | jvm 1| 2007/09/28 18:07:58 | at org.apache.naming.NamingContext.lookup(NamingContext.java:152) INFO | jvm 1| 2007/09/28 18:07:58 | at com.strongbrain.listener.AppListener.contextInitialized(AppListener.java:41) INFO | jvm 1| 2007/09/28 18:07:58 | at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3729) INFO | jvm 1| 2007/09/28 18:07:58 | at org.apache.catalina.core.StandardContext.start(StandardContext.java:4183) INFO | jvm 1| 2007/09/28 18:07:58 | at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013) INFO | jvm 1| 2007/09/28 18:07:58 | at org.apache.catalina.core.StandardHost.start(StandardHost.java:718) INFO | jvm 1| 2007/09/28 18:07:58 | at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013) INFO | jvm 1| 2007/09/28 18:07:58 | at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442) INFO | jvm 1| 2007/09/28 18:07:58 | at org.apache.catalina.core.StandardService.start(StandardService.java:450) INFO | jvm 1| 2007/09/28 18:07:58 | at org.apache.catalina.core.StandardServer.start(StandardServer.java:709) INFO | jvm 1| 2007/09/28 18:07:58 | at org.apache.catalina.startup.Catalina.start(Catalina.java:551) INFO | jvm 1| 2007/09/28 18:07:58 | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) INFO | jvm 1| 2007/09/28 18:07:58 | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) INFO | jvm 1| 2007/09/28 18:07:58 | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) INFO | jvm 1| 2007/09/28 18:07:58 | at java.lang.reflect.Method.invoke(Method.java:585) INFO | jvm 1| 2007/09/28 18:07:58 | at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:275) INFO | jvm 1| 2007/09/28 18:07:58 | at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) INFO | jvm 1| 2007/09/28 18:07:58 | at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) INFO | jvm 1| 2007/09/28 18:07:58 | at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) INFO | jvm 1| 2007/09/28 18:07:58 | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) INFO | jvm 1| 2007/09/28 18:07:58 | at java.lang.reflect.Method.invoke(Method.java:585) INFO | jvm 1| 2007/09/28 18:07:58 | at org.tanukisoftware.wrapper.WrapperStartStopApp.run(WrapperStartStopApp.java:159) INFO | jvm 1| 2007/09/28 18:07:58 | at java.lang.Thread.run(Thread.java:595) INFO | jvm 1| 2007/09/28 18:07:58 | StrongBrain AppListener: EXIT INFO | jvm 1| 2007/09/28 18:08:12 | Sep 28, 2007 6:08:12 PM org.apache.catalina.loader.WebappClassLoader validateJarFile INFO | jvm 1| 2007/09/28 18:08:12 | INFO: validateJarFile(/opt/tomcat5/webapps/strongbrain/WEB-INF/lib/servlet-api.jar) - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class: javax/se
AW: Weird problem
here is the complete server.xml with only the problematic context (myapp) in it: /Axel - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Weird problem
Leucht, Axel wrote: > Hi, > > I'm currently in desparate search for a problem I'm facing... Please provide the context and host configuration for this web app. Mark - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Weird problem
Hi, I'm currently in desparate search for a problem I'm facing... I do have a struts-webapp running under Tomcat 4 without any problems. I started to port the application to Tomcat 5 which gives me problems. The app start ok and everything looks ok. But when I try to call one specific action, Tomcat gives me "The requested resource (Invalid path was requested) is not available." The action is mapped to a JSP-file which in turn calls another action, which under tomcat 5 doesn't happen! In ToggleOverviewMap.jsp String url = "refresh.do?caller=" + caller + "&instanceNumber=" +instNrStr; RequestDispatcher rd = request.getRequestDispatcher(url); rd.forward(request, response); The breakpoint on the execute-method in the Refresh-action is never reached, instead the above mentioned execption is raised. Does anyone have a clue on what the problem mght be? As I said, the app runs fine under tomcat 4 but doesn't work under tomcat 5 Any help is greatly appreciated. /Axel - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: weird problem
You are right. If I remove xercesImpl.jar from the class path then it works also. But there is another observation which is weird. Its that if I have my application anywhere on C: drive then it works. It also works if I have it on D:\Program Files\. If I have it on D:\ then it gives this error. What is the reason for this? How does the discovery mechanism works in reference to drives? Regards, Khurram. On 7/10/07, David Delbecq <[EMAIL PROTECTED]> wrote: Hi, javax.xml.parsers.FactoryConfigurationError loads a implementation of xml parsers using a J2SE discovery mecanism. This discovery mecanism uses hints provided in .jars META-INF/ folder. Since you exploded your jar of XercesImpl, this JAR does not take part anymore in the discovery mecanism and jvm falls back to the core xml parser provided by tomcat. Behaviours is then same as if you simply removed Xerces jar from your application. You should not provide your own xml parser inside your webapplication, because jvm will always try to use the core parser (with or without success, considering the conflict that can arise with class names depending on classloader used). See http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html, "XML Parsers and J2SE 1.4" En l'instant précis du 10/07/07 11:54, kz s'exprimait en ces termes: > Hi, > > Im getting the following error while the starting of Tomcat. I have > version > 5.5.23 of Tomcat and its an embedded version. > > I had xercesImpl.jar in my classpath which conatins this class. > > INFO: Error registering > javax.xml.parsers.FactoryConfigurationError: Provider > org.apache.xerces.jaxp.DocumentBuilderFactoryImpl not found > > The problem is that when I un-jar xercesImpl.jar and set the class > path of > that un-jarred folder then it worked all fine. What is the possible > difference in jar file and accessing flat classes?? > > > > Regards, > > Khurram. > - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: weird problem
Hi, javax.xml.parsers.FactoryConfigurationError loads a implementation of xml parsers using a J2SE discovery mecanism. This discovery mecanism uses hints provided in .jars META-INF/ folder. Since you exploded your jar of XercesImpl, this JAR does not take part anymore in the discovery mecanism and jvm falls back to the core xml parser provided by tomcat. Behaviours is then same as if you simply removed Xerces jar from your application. You should not provide your own xml parser inside your webapplication, because jvm will always try to use the core parser (with or without success, considering the conflict that can arise with class names depending on classloader used). See http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html, "XML Parsers and J2SE 1.4" En l'instant précis du 10/07/07 11:54, kz s'exprimait en ces termes: > Hi, > > Im getting the following error while the starting of Tomcat. I have > version > 5.5.23 of Tomcat and its an embedded version. > > I had xercesImpl.jar in my classpath which conatins this class. > > INFO: Error registering > javax.xml.parsers.FactoryConfigurationError: Provider > org.apache.xerces.jaxp.DocumentBuilderFactoryImpl not found > > The problem is that when I un-jar xercesImpl.jar and set the class > path of > that un-jarred folder then it worked all fine. What is the possible > difference in jar file and accessing flat classes?? > > > > Regards, > > Khurram. > - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
weird problem
Hi, Im getting the following error while the starting of Tomcat. I have version 5.5.23 of Tomcat and its an embedded version. I had xercesImpl.jar in my classpath which conatins this class. INFO: Error registering javax.xml.parsers.FactoryConfigurationError: Provider org.apache.xerces.jaxp.DocumentBuilderFactoryImpl not found The problem is that when I un-jar xercesImpl.jar and set the class path of that un-jarred folder then it worked all fine. What is the possible difference in jar file and accessing flat classes?? Regards, Khurram.
Re: [OT] hi, [weird] problem? add 0 into [a list] but get 1 as a result!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter, Peter wrote: > I have come into a very [weird] problem. [snip] > List alist =new ArrayList(); > alist.add(0); put 0 into it > alist.get(0); get 1 as result. > > it occurs when i using JBuilder2006 to complie it and run under tomcat > 5.5.20. Are you sure that JBuilder is compiling your class? I've seen IDEs fail to compile source and leave you with an old version of the binary with little indication. If your class isn't compiling properly, maybe it's running something you wrote in the past. Can you verify that the class file isn't an old one? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGUhgP9CaO5/Lv0PARAp01AJ4ycdAbxtZbbUtULcnDMWc+2ikvRwCeP+UE q1WjP3e/cO270YyiQdPeWvo= =YNCb -END PGP SIGNATURE- - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Weird problem with Tomcat 5.5.17 and j_security_check
When starting a new thread (ie sending a message to the list about a new topic) please do not reply to an existing message and change the subject line. To many of the list archiving services and mail clients used by list subscribers this makes your new message appear as part of the old thread. This makes it harder for other users to find relevant information when searching the lists. This is known as thread hijacking and is that is frowned upon on this list. Frequent offenders will be removed from the list. It should also be noted that many list subscribers automatically ignore any messages that hijack another thread. The correct procedure is to create a new message with a new subject. This will start a new thread. Mark tomcat-user-owner - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Weird problem with Tomcat 5.5.17 and j_security_check
Hello Everyone, I have just installed a clean server with windows 2003 Standard, Java JDK 1.5.0_06 and tomcat 5.5.17. I moved my application that i created on tomcat 5.0 to this server and set the application up as a site. When I access the site, it askes for the user name and password (normally done). But after you are successfully authenticated, it goes to a 404 cannot find favicon.ico. So I googled and found that was an issue with Firefox, so I tried IE and I can get into the application. But now, when I put a favicon.ico in the applications root and I log in. With firefox, right after I log in, I get a page that displays my favicon.ico, but it never gets to my index.jsp. I have to go to the url and delete the /favicon.ico and hit enter and then I'm into the application. In IE, after I log in, it takes me to my application, but it doesn't show the favicon.ico in the address bar. Has anyone else experienced this or could you point me to another posting that shows how this was resolved. I thank you in advance for any advice I can get. Respectfully, Dean Searle Computing Oasis Caro, Michigan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat 4.1.31, Weird problem. Once in a while an attribute i n the session is not found... look like a RACE?! Is that possible????
Hum I tried and haven't be able to reproduce.. but so far that the best explanation about what can cause the race... Thanks I will put some code in to avoid double submit! Regards /David Tobias Meyer wrote: >Just a thought - What would happen to your application if the user >double-clicked the login button? (or whatever causes the page to load) > >We also sometimes see such errors if some page loads too slow and the user >gets annoyed and logges in again (the login screen invalidates the old >session in our application) >When the slow thread then reaches the point where it wants to read the >attribute it's gone as the session is invalidated. > >Hth, >Tobias > > >>-Original Message- >>From: David Gagnon [mailto:[EMAIL PROTECTED] >>Sent: Monday, December 19, 2005 3:46 PM >>To: Tomcat Users List >>Subject: Re: Tomcat 4.1.31, Weird problem. Once in a while an >>attribute in the session is not found... look like a RACE?! >>Is that possible >> >> >>Hi, >> >> >>In catalina.out I get nothing more than the null pointer exception. I >>also included the log from localhost_log.2005-12-15 where we >>can see the >>actual request. >> >>Thanks for you help! >>Regards >>/David >> >> >>localhost_log.2005-12-15 >>2005-12-15 15:19:56 StandardContext[/webCatalog]: Mapped to servlet >>'action' with servlet path '/logon.do' and path info 'null' >>and update=true >>2005-12-15 15:20:07 Authenticator[/webCatalog]: Security checking >>request POST /webCatalog/publicPages/j_security_check >>2005-12-15 15:20:07 Authenticator[/webCatalog]: We have >>cached auth type >>FORM for principal GenericPrincipal[cabg] >>2005-12-15 15:20:07 Authenticator[/webCatalog]: Already >>authenticated 'cabg' >>2005-12-15 15:20:07 Authenticator[/webCatalog]: Checking constraint >>'SecurityConstraint[Access-Authentication-Authorization Test Area]' >>against POST /publicPages/j_security_check --> false >>2005-12-15 15:20:07 Authenticator[/webCatalog]: No applicable >>constraint >>located >>2005-12-15 15:20:07 Authenticator[/webCatalog]: Not subject to any >>constraint >>2005-12-15 15:20:07 StandardContext[/webCatalog]: Mapping >>contextPath='/webCatalog' with >>requestURI='/webCatalog/publicPages/j_security_check' and >>relativeURI='/publicPages/j_security_check' >>2005-12-15 15:20:07 StandardContext[/webCatalog]: Trying exact match >>2005-12-15 15:20:07 StandardContext[/webCatalog]: Trying prefix match >>2005-12-15 15:20:07 StandardContext[/webCatalog]: Trying >>extension match >>2005-12-15 15:20:07 StandardContext[/webCatalog]: Trying default match >>2005-12-15 15:20:07 StandardContext[/webCatalog]: Mapped to servlet >>'default' with servlet path '/publicPages/j_security_check' and path >>info 'null' and update=true >>2005-12-15 15:20:07 StandardContext[/webCatalog]: Mapping >>contextPath='/webCatalog' with >>requestURI='/webCatalog/publicPages/index.jsp' and >>relativeURI='/publicPages/index.jsp' >>2005-12-15 15:20:07 StandardContext[/webCatalog]: Trying exact match >>2005-12-15 15:20:07 StandardContext[/webCatalog]: Mapped to servlet >>'publicPages.index_jsp' with servlet path '/publicPages/index.jsp' and >>path info 'null' and update=true >>2005-12-15 15:20:07 Authenticator[/webCatalog]: Security checking >>request GET /webCatalog/graphics/webSite/BG_LightBeige.gif >>2005-12-15 15:20:07 Authenticator[/webCatalog]: We have >>cached auth type >>FORM for principal GenericPrincipal[cabg] >>2005-12-15 15:20:07 Authenticator[/webCatalog]: Checking constraint >>'SecurityConstraint[Access-Authentication-Authorization Test Area]' >>against GET /graphics/webSite/BG_LightBeige.gif --> false >>2005-12-15 15:20:07 Authenticator[/webCatalog]: No applicable >>constraint >>located >>2005-12-15 15:20:07 Authenticator[/webCatalog]: Not subject to any >>constraint >>2005-12-15 15:20:07 StandardContext[/webCatalog]: Mapping >>contextPath='/webCatalog' with >>requestURI='/webCatalog/graphics/webSite/BG_LightBeige.gif' and >>relativeURI='/graphics/webSite/BG_LightBeige.gif' >>2005-12-15 15:20:07 StandardContext[/webCatalog]: Trying exact match >>2005-12-15 15:20:07 StandardContext[/webCatalog]: Trying prefix match >>2005-12-15 15:20:07 StandardContext[/webCatalog]: Trying >>extension
RE: Tomcat 4.1.31, Weird problem. Once in a while an attribute i n the session is not found... look like a RACE?! Is that possible????
Just a thought - What would happen to your application if the user double-clicked the login button? (or whatever causes the page to load) We also sometimes see such errors if some page loads too slow and the user gets annoyed and logges in again (the login screen invalidates the old session in our application) When the slow thread then reaches the point where it wants to read the attribute it's gone as the session is invalidated. Hth, Tobias > -Original Message- > From: David Gagnon [mailto:[EMAIL PROTECTED] > Sent: Monday, December 19, 2005 3:46 PM > To: Tomcat Users List > Subject: Re: Tomcat 4.1.31, Weird problem. Once in a while an > attribute in the session is not found... look like a RACE?! > Is that possible > > > Hi, > > > In catalina.out I get nothing more than the null pointer exception. I > also included the log from localhost_log.2005-12-15 where we > can see the > actual request. > > Thanks for you help! > Regards > /David > > > localhost_log.2005-12-15 > 2005-12-15 15:19:56 StandardContext[/webCatalog]: Mapped to servlet > 'action' with servlet path '/logon.do' and path info 'null' > and update=true > 2005-12-15 15:20:07 Authenticator[/webCatalog]: Security checking > request POST /webCatalog/publicPages/j_security_check > 2005-12-15 15:20:07 Authenticator[/webCatalog]: We have > cached auth type > FORM for principal GenericPrincipal[cabg] > 2005-12-15 15:20:07 Authenticator[/webCatalog]: Already > authenticated 'cabg' > 2005-12-15 15:20:07 Authenticator[/webCatalog]: Checking constraint > 'SecurityConstraint[Access-Authentication-Authorization Test Area]' > against POST /publicPages/j_security_check --> false > 2005-12-15 15:20:07 Authenticator[/webCatalog]: No applicable > constraint > located > 2005-12-15 15:20:07 Authenticator[/webCatalog]: Not subject to any > constraint > 2005-12-15 15:20:07 StandardContext[/webCatalog]: Mapping > contextPath='/webCatalog' with > requestURI='/webCatalog/publicPages/j_security_check' and > relativeURI='/publicPages/j_security_check' > 2005-12-15 15:20:07 StandardContext[/webCatalog]: Trying exact match > 2005-12-15 15:20:07 StandardContext[/webCatalog]: Trying prefix match > 2005-12-15 15:20:07 StandardContext[/webCatalog]: Trying > extension match > 2005-12-15 15:20:07 StandardContext[/webCatalog]: Trying default match > 2005-12-15 15:20:07 StandardContext[/webCatalog]: Mapped to servlet > 'default' with servlet path '/publicPages/j_security_check' and path > info 'null' and update=true > 2005-12-15 15:20:07 StandardContext[/webCatalog]: Mapping > contextPath='/webCatalog' with > requestURI='/webCatalog/publicPages/index.jsp' and > relativeURI='/publicPages/index.jsp' > 2005-12-15 15:20:07 StandardContext[/webCatalog]: Trying exact match > 2005-12-15 15:20:07 StandardContext[/webCatalog]: Mapped to servlet > 'publicPages.index_jsp' with servlet path '/publicPages/index.jsp' and > path info 'null' and update=true > 2005-12-15 15:20:07 Authenticator[/webCatalog]: Security checking > request GET /webCatalog/graphics/webSite/BG_LightBeige.gif > 2005-12-15 15:20:07 Authenticator[/webCatalog]: We have > cached auth type > FORM for principal GenericPrincipal[cabg] > 2005-12-15 15:20:07 Authenticator[/webCatalog]: Checking constraint > 'SecurityConstraint[Access-Authentication-Authorization Test Area]' > against GET /graphics/webSite/BG_LightBeige.gif --> false > 2005-12-15 15:20:07 Authenticator[/webCatalog]: No applicable > constraint > located > 2005-12-15 15:20:07 Authenticator[/webCatalog]: Not subject to any > constraint > 2005-12-15 15:20:07 StandardContext[/webCatalog]: Mapping > contextPath='/webCatalog' with > requestURI='/webCatalog/graphics/webSite/BG_LightBeige.gif' and > relativeURI='/graphics/webSite/BG_LightBeige.gif' > 2005-12-15 15:20:07 StandardContext[/webCatalog]: Trying exact match > 2005-12-15 15:20:07 StandardContext[/webCatalog]: Trying prefix match > 2005-12-15 15:20:07 StandardContext[/webCatalog]: Trying > extension match > 2005-12-15 15:20:07 StandardContext[/webCatalog]: Trying default match > 2005-12-15 15:20:07 StandardContext[/webCatalog]: Mapped to servlet > 'default' with servlet path '/graphics/webSite/BG_LightBeige.gif' and > path info 'null' and update=true > 2005-12-15 15:20:07 StandardContext[/webCatalog]: Mapping > contextPath='/webCatalog' with > requestURI='/webCatalog/publicPages/index.jsp' and > relativeURI='/publicPages/index.jsp
Re: Tomcat 4.1.31, Weird problem. Once in a while an attribute in the session is not found... look like a RACE?! Is that possible????
dWrapperValve.invoke(StandardWrapperValve.java:209) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:144) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:504) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:594) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2358) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:133) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:118) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:594) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:116) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:594) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:127) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:152) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683) at java.lang.Thread.run(Thread.java:534) Martin Gainty wrote: >Good Morning David- > >What does the log say? > >Martin- >- Original Message - >From: "David Gagnon" <[EMAIL PROTECTED]> >To: "Tomcat Users List" >Sent: Monday, December 19, 2005 7:40 AM >Subject: Tomcat 4.1.31, Weird problem. Once in a while an attribute in the >session is not found... look like a RACE?! Is that possible > > > > >>Hi all, >> >>I have a really wreird problem. I have a web site and I get a >>NullPointerException once in a while because the >>WcPresentationConstants.CURRENT_RESOURCE is null. >> >>UkResource resource = (UkResource) >>param.request.getSession().getAttribute(WcPresentationConstants.CURRENT_RESOURCE); >> >> >>But this code arrive just after the user logs in. And just after we set >>the attribute. This error occurs every 3 or 4 weeks and I cannot >>reproduce it (So 99% of the time everything works just fine). This code >>is always run just after the user log in so there is no user interaction >>involved. If the error occurs I have a bug report sent and I print the >>object in the report. In the last bug the Attribute was in the REPORT >>?!?! (I remeber have seen a report where the same attribute was null). >>For me it`s look like a race .. but all occurs in the same thread. >> >>Is tomcat can do copy of session object behind de scene.. (maybe becaus >>of session reload ???) or is there anything in tomcat that can explain >>this (If yes, how can I avoid it )? I just don`t get it I chasing this >>bug for months now ... >> >>Thanks for your help >> >>- >>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: Tomcat 4.1.31, Weird problem. Once in a while an attribute in the session is not found... look like a RACE?! Is that possible????
Good Morning David- What does the log say? Martin- - Original Message - From: "David Gagnon" <[EMAIL PROTECTED]> To: "Tomcat Users List" Sent: Monday, December 19, 2005 7:40 AM Subject: Tomcat 4.1.31, Weird problem. Once in a while an attribute in the session is not found... look like a RACE?! Is that possible > Hi all, > > I have a really wreird problem. I have a web site and I get a > NullPointerException once in a while because the > WcPresentationConstants.CURRENT_RESOURCE is null. > > UkResource resource = (UkResource) > param.request.getSession().getAttribute(WcPresentationConstants.CURRENT_RESOURCE); > > > But this code arrive just after the user logs in. And just after we set > the attribute. This error occurs every 3 or 4 weeks and I cannot > reproduce it (So 99% of the time everything works just fine). This code > is always run just after the user log in so there is no user interaction > involved. If the error occurs I have a bug report sent and I print the > object in the report. In the last bug the Attribute was in the REPORT > ?!?! (I remeber have seen a report where the same attribute was null). > For me it`s look like a race .. but all occurs in the same thread. > > Is tomcat can do copy of session object behind de scene.. (maybe becaus > of session reload ???) or is there anything in tomcat that can explain > this (If yes, how can I avoid it )? I just don`t get it I chasing this > bug for months now ... > > Thanks for your help > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Tomcat 4.1.31, Weird problem. Once in a while an attribute in the session is not found... look like a RACE?! Is that possible????
Hi all, I have a really wreird problem. I have a web site and I get a NullPointerException once in a while because the WcPresentationConstants.CURRENT_RESOURCE is null. UkResource resource = (UkResource) param.request.getSession().getAttribute(WcPresentationConstants.CURRENT_RESOURCE); But this code arrive just after the user logs in. And just after we set the attribute. This error occurs every 3 or 4 weeks and I cannot reproduce it (So 99% of the time everything works just fine). This code is always run just after the user log in so there is no user interaction involved. If the error occurs I have a bug report sent and I print the object in the report. In the last bug the Attribute was in the REPORT ?!?! (I remeber have seen a report where the same attribute was null). For me it`s look like a race .. but all occurs in the same thread. Is tomcat can do copy of session object behind de scene.. (maybe becaus of session reload ???) or is there anything in tomcat that can explain this (If yes, how can I avoid it )? I just don`t get it I chasing this bug for months now ... Thanks for your help - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: inserting data (A weird problem)
Claudio, I'm sorry but I have a bit of trouble following your explanation (I just do not know your object model/domain well enough to follow the explanation). But I'm still wondering if this is not a problem of ill-formed JavaBeans. Are you aware of the rules for naming JavaBeans classes and their properties/mutators (getters and setters)? In summary: - your instance variables should all start with lowercase letters (e.g. "apellido"); - the getter and setter should be getApellido() and setApellido(String apellido) respectively. Look at Sun's Java site (or other good Java reference) for the JavaBean naming standards. The rule on instance variables starting with lower case letters is more of a convention. What really matters is that if you have methods getApellido and setApellido then in your JSP code you can simply refer to "apellido" most frameworks will translate this into a call to getApellido. If this does not provide some insight into the problem, you need to provide a bit more detail of a simplified version of your object model - something like a simple character/line drawing or indented class outline with instance variables. Then your description of what is happening might make a bit more sense to some of us and you might get a better answer. Hope this helps - Richard -Original Message- From: Claudio Martn Veas [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 14, 2005 5:50 AM To: Tomcat Users List Subject: Re: inserting data (A weird problem) Hello all, and thanks for writing about my problem, I found the solution but Im note very confortable because I dont understand the reason why it fails. When this error started to show several times even if I tried the same thing a lot of times I started to think about the reason of all this erros so Í thought that maybe (since Im very new to all this) beans had a limit in the porperties or set methods so that was the reason that when ever I delete all the "apellido" logic all worked fine but I decided to try another example so I took out another of the properties I believe it was mail and I let the "apellido" logic stay, but the error didnt leave. After hours of thinking a (lets say stupid idea) came into my mind (oh I forgot to tell you that Itried to replace "apellido" with "algo" but the logic was the same and I did this to see if the naming of the propertie/method had anything to d with this) I thought, hey maybe beans arent supposed to have properties / methods starting with an "a" so I tried without the "apellido" logic to make work the example but I replace "Numero" with "aNumero" in all the places just like with the other example, and the error showed up so I decided to put "Numero" back and I put all the "apellido" logic again but in english this time "Lastname" AND IT WORKED so Im parcially happyu about the fact that I made it work but I dont like not knowing what is the problem, i dont like the idea of taking something for granted as if it were some kind of magic "Tomcat and beans with properties starting with 'a' dont match" "why not?" "because they dont" jaja so if you find out why this is a problem just let me know Thanks for all you attention Thanks on Advance Claudio Veas ___ 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar - 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: inserting data (A weird problem)
Hello all, and thanks for writing about my problem, I found the solution but Im note very confortable because I dont understand the reason why it fails. When this error started to show several times even if I tried the same thing a lot of times I started to think about the reason of all this erros so Í thought that maybe (since Im very new to all this) beans had a limit in the porperties or set methods so that was the reason that when ever I delete all the "apellido" logic all worked fine but I decided to try another example so I took out another of the properties I believe it was mail and I let the "apellido" logic stay, but the error didnt leave. After hours of thinking a (lets say stupid idea) came into my mind (oh I forgot to tell you that Itried to replace "apellido" with "algo" but the logic was the same and I did this to see if the naming of the propertie/method had anything to d with this) I thought, hey maybe beans arent supposed to have properties / methods starting with an "a" so I tried without the "apellido" logic to make work the example but I replace "Numero" with "aNumero" in all the places just like with the other example, and the error showed up so I decided to put "Numero" back and I put all the "apellido" logic again but in english this time "Lastname" AND IT WORKED so Im parcially happyu about the fact that I made it work but I dont like not knowing what is the problem, i dont like the idea of taking something for granted as if it were some kind of magic "Tomcat and beans with properties starting with 'a' dont match" "why not?" "because they dont" jaja so if you find out why this is a problem just let me know Thanks for all you attention Thanks on Advance Claudio Veas ___ 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: inserting data (A weird problem)
Looking at the attached jsp I can see it does
cto.setapellido(request.getParameter("apellido"));
which is correct for the supplied bean code.
As the NoSuchMethodError is occuring at runtime rather than at jsp
compile time I would say you have probably changed the bean code since
the jsp was last compiled.
Have a look in the tomcat logs for jsp compilation errors.
Make sure the compiled class of the bean is correct version of the code.
And, if worst comes to worst, try deleting tomcat's work directory to
clear out any stale jsp class files.
Jon Wingfield wrote:
This is how I read the error: There is no method with the signature
void setapellido(String[] values)
which (given your code sample) there isn't.
Is the insertar.jsp doing something like
contacto.setapellido(request.getParameterValues("name"));
instead of
contacto.setapellido(request.getParameter("name"));
HTH,
Jon
Claudio Veas wrote:
Hello, Im trying to insert data in my mysql server with a JSP and a
Bean with an example I found in the internet, Im very new to all this
but this error I get its really strange.
I created a table contacto (contact) in the mysql server,
create table contacto (numero int,
nombre varchar (20),
apellido varchar(20),
Telefono int,
Email varchar(50)
)
I made the bean acording to the example and I made a form so I can
Input the data and the job of the bean would be to save this info in
the database. But the problem is that I got an Error
javax.servlet.ServletException:
DB.contacto.setapellido(Ljava/lang/String;)V
org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageContextImpl.java:848)
org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:781)
org.apache.jsp.colors.insertar_jsp._jspService(org.apache.jsp.colors.insertar_jsp:85)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
*causa raíz*
java.lang.NoSuchMethodError: DB.contacto.setapellido(Ljava/lang/String;)V
org.apache.jsp.colors.insertar_jsp._jspService(org.apache.jsp.colors.insertar_jsp:59)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
so I decided to take out all the logic of the "apellido" field in the
database and I took it out of the form and from the JSP file and guess
what it
Worked so I put all the "apellido" stuffs back with extra care of no
making any mistakes
this time, Idouble checked it with the other fields because hey they
work but guess what
the error showed up again and I dont really know what the problem is,
all I know its something related
to the get statement.
Hope You can Help me
Thanks on Advance
Claudio Veas
Please Excuse my english
Add FUN to your email - CLICK HERE!
package DB;
import java.sql.*;
import java.io.*;
public class contacto {
private String dbURL =
"jdbc:mysql://localhost:3306/test?user=jonas&password=jonas";
private String dbDriver = "com.mysql.jdbc.Driver";
private Connection dbCon;
String Numero =null;
String Nombre = null;
String apellido =null;
String Telefono = null;
String Email = null;
public contacto() {
super();
}
public String getNumero() {
return this.Numero;
}
public String getNombre() {
return this.Nombre;
}
public String getapellido(){
return this.apellido;
}
public String getTelefono() {
return this.Telefono;
}
public String getEmail() {
return this.Email;
}
public void setNumero(String Numero) {
this.Numero = Numero;
}
public void setNombre(String Nombre) {
this.Nombre = Nombre;
}
public void setapellido(String apellido) {
this.apellido = apellido;
}
public void setTelefono(String Telefono) {
this.Telefono = Telefono;
}
public void setEmail(String Email) {
this.Email = Email;
}
public void doInsert() throws ClassNotFoundException, SQLException {
Class
RE: inserting data (A weird problem)
If DB.contacto is a regular JavaBean, then maybe the method call should be "setApellido(...)", instead of "setapellido(...)"? HTH - Richard _ From: Claudio Veas [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 13, 2005 9:24 PM To: Tomcat Users List Subject: inserting data (A weird problem) Hello, Im trying to insert data in my mysql server with a JSP and a Bean with an example I found in the internet, Im very new to all this but this error I get its really strange. I created a table contacto (contact) in the mysql server, create table contacto (numero int, nombre varchar (20), apellido varchar(20), Telefono int, Email varchar(50) ) I made the bean acording to the example and I made a form so I can Input the data and the job of the bean would be to save this info in the database. But the problem is that I got an Error javax.servlet.ServletException: DB.contacto.setapellido(Ljava/lang/String;)V org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageContextI mpl.java:848) org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImp l.java:781) org.apache.jsp.colors.insertar_jsp._jspService(org.apache.jsp.colors.inserta r_jsp:85) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:3 22) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) causa raíz java.lang.NoSuchMethodError: DB.contacto.setapellido(Ljava/lang/String;)V org.apache.jsp.colors.insertar_jsp._jspService(org.apache.jsp.colors.inserta r_jsp:59) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:3 22) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) so I decided to take out all the logic of the "apellido" field in the database and I took it out of the form and from the JSP file and guess what it Worked so I put all the "apellido" stuffs back with extra care of no making any mistakes this time, Idouble checked it with the other fields because hey they work but guess what the error showed up again and I dont really know what the problem is, all I know its something related to the get statement. Hope You can Help me Thanks on Advance Claudio Veas Please Excuse my english <http://www.incredimail.com/index.asp?id=96769> Add FUN to your email - CLICK HERE!
Re: inserting data (A weird problem)
This is how I read the error: There is no method with the signature
void setapellido(String[] values)
which (given your code sample) there isn't.
Is the insertar.jsp doing something like
contacto.setapellido(request.getParameterValues("name"));
instead of
contacto.setapellido(request.getParameter("name"));
HTH,
Jon
Claudio Veas wrote:
Hello, Im trying to insert data in my mysql server with a JSP and a Bean
with an example I found in the internet, Im very new to all this but
this error I get its really strange.
I created a table contacto (contact) in the mysql server,
create table contacto (numero int,
nombre varchar (20),
apellido varchar(20),
Telefono int,
Email varchar(50)
)
I made the bean acording to the example and I made a form so I can Input
the data and the job of the bean would be to save this info in the
database. But the problem is that I got an Error
javax.servlet.ServletException: DB.contacto.setapellido(Ljava/lang/String;)V
org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageContextImpl.java:848)
org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:781)
org.apache.jsp.colors.insertar_jsp._jspService(org.apache.jsp.colors.insertar_jsp:85)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
*causa raíz*
java.lang.NoSuchMethodError: DB.contacto.setapellido(Ljava/lang/String;)V
org.apache.jsp.colors.insertar_jsp._jspService(org.apache.jsp.colors.insertar_jsp:59)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
so I decided to take out all the logic of the "apellido" field in the
database and I took it out of the form and from the JSP file and guess what it
Worked so I put all the "apellido" stuffs back with extra care of no making any mistakes
this time, Idouble checked it with the other fields because hey they work but
guess what
the error showed up again and I dont really know what the problem is, all I
know its something related
to the get statement.
Hope You can Help me
Thanks on Advance
Claudio Veas
Please Excuse my english
Add FUN to your email - CLICK HERE!
package DB;
import java.sql.*;
import java.io.*;
public class contacto {
private String dbURL =
"jdbc:mysql://localhost:3306/test?user=jonas&password=jonas";
private String dbDriver = "com.mysql.jdbc.Driver";
private Connection dbCon;
String Numero =null;
String Nombre = null;
String apellido =null;
String Telefono = null;
String Email = null;
public contacto() {
super();
}
public String getNumero() {
return this.Numero;
}
public String getNombre() {
return this.Nombre;
}
public String getapellido(){
return this.apellido;
}
public String getTelefono() {
return this.Telefono;
}
public String getEmail() {
return this.Email;
}
public void setNumero(String Numero) {
this.Numero = Numero;
}
public void setNombre(String Nombre) {
this.Nombre = Nombre;
}
public void setapellido(String apellido) {
this.apellido = apellido;
}
public void setTelefono(String Telefono) {
this.Telefono = Telefono;
}
public void setEmail(String Email) {
this.Email = Email;
}
public void doInsert() throws ClassNotFoundException, SQLException {
Class.forName(dbDriver);
dbCon = DriverManager.getConnection(dbURL);
Statement s = dbCon.createStatement();
String sql = "INSERT INTO contactos values (" + this.Numero;
sql = sql + ", '" + this.Nombre;
sql = sql + "', " + this.Telefono + ", '" + this.Email;
sql = sql + "')";
int insertResult = s.executeUpdate(sql);
dbCon.close();
}
}
---
inserting data (A weird problem)
Hello, Im trying to insert data in my mysql server with a JSP and a Bean with an example I found in the internet, Im very new to all this but this error I get its really strange.
I created a table contacto (contact) in the mysql server,
create table contacto (numero int,
nombre varchar (20),
apellido varchar(20),
Telefono int,
Email varchar(50)
)
I made the bean acording to the example and I made a form so I can Input the data and the job of the bean would be to save this info in the database. But the problem is that I got an Error
javax.servlet.ServletException: DB.contacto.setapellido(Ljava/lang/String;)V
org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageContextImpl.java:848)
org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:781)
org.apache.jsp.colors.insertar_jsp._jspService(org.apache.jsp.colors.insertar_jsp:85)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
causa raíz java.lang.NoSuchMethodError: DB.contacto.setapellido(Ljava/lang/String;)V
org.apache.jsp.colors.insertar_jsp._jspService(org.apache.jsp.colors.insertar_jsp:59)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:322)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
so I decided to take out all the logic of the "apellido" field in the database and I took it out of the form and from the JSP file and guess what it Worked so I put all the "apellido" stuffs back with extra care of no making any mistakes this time, Idouble checked it with the other fields because hey they work but guess whatthe error showed up again and I dont really know what the problem is, all I know its something relatedto the get statement. Hope You can Help meThanks on AdvanceClaudio VeasPlease Excuse my english
insertar.jsp
Description: unknown/unknown
package DB;
import java.sql.*;
import java.io.*;
public class contacto {
private String dbURL = "jdbc:mysql://localhost:3306/test?user=jonas&password=jonas";
private String dbDriver = "com.mysql.jdbc.Driver";
private Connection dbCon;
String Numero =null;
String Nombre = null;
String apellido =null;
String Telefono = null;
String Email = null;
public contacto() {
super();
}
public String getNumero() {
return this.Numero;
}
public String getNombre() {
return this.Nombre;
}
public String getapellido(){
return this.apellido;
}
public String getTelefono() {
return this.Telefono;
}
public String getEmail() {
return this.Email;
}
public void setNumero(String Numero) {
this.Numero = Numero;
}
public void setNombre(String Nombre) {
this.Nombre = Nombre;
}
public void setapellido(String apellido) {
this.apellido = apellido;
}
public void setTelefono(String Telefono) {
this.Telefono = Telefono;
}
public void setEmail(String Email) {
this.Email = Email;
}
public void doInsert() throws ClassNotFoundException, SQLException {
Class.forName(dbDriver);
dbCon = DriverManager.getConnection(dbURL);
Statement s = dbCon.createStatement();
String sql = "INSERT INTO contactos values (" + this.Numero;
sql = sql + ", '" + this.Nombre;
sql = sql + "', " + this.Telefono + ", '" + this.Email;
sql = sql + "')";
int insertResult = s.executeUpdate(sql);
dbCon.close();
}
}-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
