Re: REST call failure on newer tomcat version/update
2014-12-19 20:49 GMT+03:00 Sean Dawson seandawson2...@gmail.com: Hello, We had a gwt app deployed and working with tomcat 7_42 and tried it recently in several configurations (Windows/Linux) with the latest update of 7 and it fails during a RestyGwt/RestEasy call to the server. Previous calls succeed but this particular one appears to get an http code of 200 but doesn't return any data (but it should) - and so the app never proceeds. There's no message, exception, etc - so the app just sits there. In running this on several clients (Firefox, Chrome, RestClient for FF, etc), I *have* received a couple messages on that call (in certain situations) such as... Error Code: 502 Proxy Error. A software error occurred for a Windows Internet extension application that is required for the current operation. and Error 415 Unsupported Media Type Does anyone have an idea what this might be? Why it changed? If I swap out the latest version for 41 or 42, and change nothing else, it works fine. Can't find anything in docs or searches online. What is your configuration? I guess that those 500 and 415 responses are not from Tomcat. Are they from IIS? Is that one up-to-date? Do you have access log configured in Tomcat? Are those requests mentioned in Tomcat access log? Does the issue happen randomly? Can you reproduce it? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.0.12 - unable to eliminate logs stating org.apache.catalina.webresources.Cache.getResource Unable to add the resource at [variousURLs] to the cache because there was insufficient free sp
For anyone else unable to find an answer to this problem, the answer seems to be as simple as adding this to your $SERVER_HOME/conf/context.xml inside the Context tag Resources cachingAllowed=false/ Kevin McKee Application Development Architect Goodyear Canada Inc. 388 Goodyear Rd, Napanee, ON K7R 3L2 phone.613.354.7850 krmc...@goodyear.com On 2014-12-16, 7:21 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Kevin, On 12/12/14 4:10 PM, Kevin McKee wrote: I have read the reference, but nowhere can I find an example of what it’s talking about. Not counting titles, headings, and the TOC, they are sentences #6 and #7 on the page, starting from 1. A Resources element MAY be nested inside a Context component. If it is not included, a default filesystem based Resources will be created automatically, which is sufficient for most requirements. My web.xml / context.xml don’t have a resource component in it that I can find, and nowhere can I find out what the syntax is or where to put it. If it is not included, a default filesystem based Resources will be created automatically, which is sufficient for most requirements. So, your Context element does not already have a Resources element because a) you wrote it yourself and b) you never noticed because a default filesystem based Resources was created automatically, which is sufficient for most requirements. Since you are stepping outside those requirements, it's time to define your own Resources element. This is why I’ve reached out to this group for help. If you can point me to an example or more detailed info I would appreciate it. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUkIZKAAoJEBzwKT+lPKRY15IQAJqWotAkdWLm6tcg1UKfFSzK zs5Mypz3ROfEVO2akeZl+BJ04oac4detZ9cZMKrqlyJsaVod8l5tIOCbX1EuLP/l MllgrtWlshO4wnrzHhQsRkLQ2KwV8SlIe8FR08P2WlHBeoCAXa32vuWbC9maalfY 8U75Kx8/PXAk3/WlmTXNsx9TFuylNXtJLoYKKSdRV4MRL8A54n9KOylebSlxOnEI JYVbarf5et33fXCXJewCmMQzlv1Nq74Po5rlQ2zP1ltIJhITduvieWPa/+OIdBBJ 3oFyl6s/6blcfeaJ73fQI4M4eEBFHVbB1jBUHENqrCSETTvzn22s49TVsg6wrjLX cN/U/XyXFZWtcFhzUzp4EcJdirAsQ1r1M1SKbGQZux6nkELaV3/OKTrn98RyXNMQ qhKTlEc0OKGR7pXQE0Gmacue+i4WMQiigXSDwPp1XXSlRSsqb6/LGo8l6aCQiqer q6rcIY6BBUkwQprMZFt7eTmlyWb13ue4IFDB7qEySCeP25T9XealATpLDYmmMiXx ISCgtokb85o0b6hPYApxX0iNzySFMiTWQvG6dCEsPrwfgQsmE+F0ftG/sVizVEUN /PIzfuinNaFz5NCCB/qSEEuDLIraPs3XEJugA5v4LX/Iq09ADjUTfilxtjD0mwtt BGEnU/8swDbeQQEzdIgK =zRiu -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.0.12 - unable to eliminate logs stating org.apache.catalina.webresources.Cache.getResource Unable to add the resource at [variousURLs] to the cache because there was insufficient free sp
On 12/22/2014 8:14 AM, Kevin McKee wrote: For anyone else unable to find an answer to this problem, the answer seems to be as simple as adding this to your $SERVER_HOME/conf/context.xml inside the Context tag Resources cachingAllowed=false/ As long as you don't need caching... Kevin McKee Application Development Architect Goodyear Canada Inc. 388 Goodyear Rd, Napanee, ON K7R 3L2 phone.613.354.7850 krmc...@goodyear.com On 2014-12-16, 7:21 PM, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Kevin, On 12/12/14 4:10 PM, Kevin McKee wrote: I have read the reference, but nowhere can I find an example of what it’s talking about. Not counting titles, headings, and the TOC, they are sentences #6 and #7 on the page, starting from 1. A Resources element MAY be nested inside a Context component. If it is not included, a default filesystem based Resources will be created automatically, which is sufficient for most requirements. My web.xml / context.xml don’t have a resource component in it that I can find, and nowhere can I find out what the syntax is or where to put it. If it is not included, a default filesystem based Resources will be created automatically, which is sufficient for most requirements. So, your Context element does not already have a Resources element because a) you wrote it yourself and b) you never noticed because a default filesystem based Resources was created automatically, which is sufficient for most requirements. Since you are stepping outside those requirements, it's time to define your own Resources element. This is why I’ve reached out to this group for help. If you can point me to an example or more detailed info I would appreciate it. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJUkIZKAAoJEBzwKT+lPKRY15IQAJqWotAkdWLm6tcg1UKfFSzK zs5Mypz3ROfEVO2akeZl+BJ04oac4detZ9cZMKrqlyJsaVod8l5tIOCbX1EuLP/l MllgrtWlshO4wnrzHhQsRkLQ2KwV8SlIe8FR08P2WlHBeoCAXa32vuWbC9maalfY 8U75Kx8/PXAk3/WlmTXNsx9TFuylNXtJLoYKKSdRV4MRL8A54n9KOylebSlxOnEI JYVbarf5et33fXCXJewCmMQzlv1Nq74Po5rlQ2zP1ltIJhITduvieWPa/+OIdBBJ 3oFyl6s/6blcfeaJ73fQI4M4eEBFHVbB1jBUHENqrCSETTvzn22s49TVsg6wrjLX cN/U/XyXFZWtcFhzUzp4EcJdirAsQ1r1M1SKbGQZux6nkELaV3/OKTrn98RyXNMQ qhKTlEc0OKGR7pXQE0Gmacue+i4WMQiigXSDwPp1XXSlRSsqb6/LGo8l6aCQiqer q6rcIY6BBUkwQprMZFt7eTmlyWb13ue4IFDB7qEySCeP25T9XealATpLDYmmMiXx ISCgtokb85o0b6hPYApxX0iNzySFMiTWQvG6dCEsPrwfgQsmE+F0ftG/sVizVEUN /PIzfuinNaFz5NCCB/qSEEuDLIraPs3XEJugA5v4LX/Iq09ADjUTfilxtjD0mwtt BGEnU/8swDbeQQEzdIgK =zRiu -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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
Hi Konstantin, Thanks for your reply. What details do you need of our config? Do you want the full files? Essentially it's a pretty straightforward install - extract tomcat, remove all the webapps, put our war somewhere, use Catalina/localhost/ROOT.xml to point to the war. It's a gwt app that makes some rpc calls and some REST calls to a different process (which could be on a different server) - everything seems to work up until the point of making this one REST PUT call with some data that's supposed to return some data. It's possible that it might have to do with json serialization or dto's - because it's the first call that uses them in the request and response. Exact same config with _42 works fine. Did not see anything in docs/etc that would affect us (but could have missed something). This happens with everything locally on Windows, and remotely on Amazon Linux cloud servers. The request is made, and the status is 200 - but fiddler shows no response data - and the app does not continue at that point (it should do an onSuccess, but it doesn't even do an onFailure). It happens ALL the time with the latest tomcat - never with the older. I can't seem to get any more data about what's going on when it happens. Most things just fail silently - it was only when I started changing up all the configurations (browser-clients/etc) that I got the other messages mentioned. On Mon, Dec 22, 2014 at 7:02 AM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2014-12-19 20:49 GMT+03:00 Sean Dawson seandawson2...@gmail.com: Hello, We had a gwt app deployed and working with tomcat 7_42 and tried it recently in several configurations (Windows/Linux) with the latest update of 7 and it fails during a RestyGwt/RestEasy call to the server. Previous calls succeed but this particular one appears to get an http code of 200 but doesn't return any data (but it should) - and so the app never proceeds. There's no message, exception, etc - so the app just sits there. In running this on several clients (Firefox, Chrome, RestClient for FF, etc), I *have* received a couple messages on that call (in certain situations) such as... Error Code: 502 Proxy Error. A software error occurred for a Windows Internet extension application that is required for the current operation. and Error 415 Unsupported Media Type Does anyone have an idea what this might be? Why it changed? If I swap out the latest version for 41 or 42, and change nothing else, it works fine. Can't find anything in docs or searches online. What is your configuration? I guess that those 500 and 415 responses are not from Tomcat. Are they from IIS? Is that one up-to-date? Do you have access log configured in Tomcat? Are those requests mentioned in Tomcat access log? Does the issue happen randomly? Can you reproduce it? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
On 12/22/2014 11:05 AM, Sean Dawson wrote: Hi Konstantin, Thanks for your reply. What details do you need of our config? Do you want the full files? Essentially it's a pretty straightforward install - extract tomcat, remove all the webapps, put our war somewhere, use Catalina/localhost/ROOT.xml to point to the war. It's a gwt app that makes some rpc calls and some REST calls to a different process (which could be on a different server) - everything seems to work up until the point of making this one REST PUT call with some data that's supposed to return some I don't use REST, so I may be off base here, but is a REST PUT like an HTTP PUT in that it's not expected to get any return data? In HTTP, you normally use either a POST or a GET if you want a response back. data. It's possible that it might have to do with json serialization or dto's - because it's the first call that uses them in the request and response. Exact same config with _42 works fine. Did not see anything in docs/etc that would affect us (but could have missed something). This happens with everything locally on Windows, and remotely on Amazon Linux cloud servers. The request is made, and the status is 200 - but fiddler shows no response data - and the app does not continue at that point (it should do an onSuccess, but it doesn't even do an onFailure). It happens ALL the time with the latest tomcat - never with the older. I can't seem to get any more data about what's going on when it happens. Most things just fail silently - it was only when I started changing up all the configurations (browser-clients/etc) that I got the other messages mentioned. On Mon, Dec 22, 2014 at 7:02 AM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2014-12-19 20:49 GMT+03:00 Sean Dawson seandawson2...@gmail.com: Hello, We had a gwt app deployed and working with tomcat 7_42 and tried it recently in several configurations (Windows/Linux) with the latest update of 7 and it fails during a RestyGwt/RestEasy call to the server. Previous calls succeed but this particular one appears to get an http code of 200 but doesn't return any data (but it should) - and so the app never proceeds. There's no message, exception, etc - so the app just sits there. In running this on several clients (Firefox, Chrome, RestClient for FF, etc), I *have* received a couple messages on that call (in certain situations) such as... Error Code: 502 Proxy Error. A software error occurred for a Windows Internet extension application that is required for the current operation. and Error 415 Unsupported Media Type Does anyone have an idea what this might be? Why it changed? If I swap out the latest version for 41 or 42, and change nothing else, it works fine. Can't find anything in docs or searches online. What is your configuration? I guess that those 500 and 415 responses are not from Tomcat. Are they from IIS? Is that one up-to-date? Do you have access log configured in Tomcat? Are those requests mentioned in Tomcat access log? Does the issue happen randomly? Can you reproduce it? Best regards, Konstantin Kolinko - 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: REST call failure on newer tomcat version/update
I don't think so. But perhaps that's the new/current thinking and something in the latest tomcat/libraries is enforcing that? I'll double-check/look-it-up. In any case, people do it - and it was working before. On Mon, Dec 22, 2014 at 11:12 AM, David kerber dcker...@verizon.net wrote: On 12/22/2014 11:05 AM, Sean Dawson wrote: Hi Konstantin, Thanks for your reply. What details do you need of our config? Do you want the full files? Essentially it's a pretty straightforward install - extract tomcat, remove all the webapps, put our war somewhere, use Catalina/localhost/ROOT.xml to point to the war. It's a gwt app that makes some rpc calls and some REST calls to a different process (which could be on a different server) - everything seems to work up until the point of making this one REST PUT call with some data that's supposed to return some I don't use REST, so I may be off base here, but is a REST PUT like an HTTP PUT in that it's not expected to get any return data? In HTTP, you normally use either a POST or a GET if you want a response back. data. It's possible that it might have to do with json serialization or dto's - because it's the first call that uses them in the request and response. Exact same config with _42 works fine. Did not see anything in docs/etc that would affect us (but could have missed something). This happens with everything locally on Windows, and remotely on Amazon Linux cloud servers. The request is made, and the status is 200 - but fiddler shows no response data - and the app does not continue at that point (it should do an onSuccess, but it doesn't even do an onFailure). It happens ALL the time with the latest tomcat - never with the older. I can't seem to get any more data about what's going on when it happens. Most things just fail silently - it was only when I started changing up all the configurations (browser-clients/etc) that I got the other messages mentioned. On Mon, Dec 22, 2014 at 7:02 AM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2014-12-19 20:49 GMT+03:00 Sean Dawson seandawson2...@gmail.com: Hello, We had a gwt app deployed and working with tomcat 7_42 and tried it recently in several configurations (Windows/Linux) with the latest update of 7 and it fails during a RestyGwt/RestEasy call to the server. Previous calls succeed but this particular one appears to get an http code of 200 but doesn't return any data (but it should) - and so the app never proceeds. There's no message, exception, etc - so the app just sits there. In running this on several clients (Firefox, Chrome, RestClient for FF, etc), I *have* received a couple messages on that call (in certain situations) such as... Error Code: 502 Proxy Error. A software error occurred for a Windows Internet extension application that is required for the current operation. and Error 415 Unsupported Media Type Does anyone have an idea what this might be? Why it changed? If I swap out the latest version for 41 or 42, and change nothing else, it works fine. Can't find anything in docs or searches online. What is your configuration? I guess that those 500 and 415 responses are not from Tomcat. Are they from IIS? Is that one up-to-date? Do you have access log configured in Tomcat? Are those requests mentioned in Tomcat access log? Does the issue happen randomly? Can you reproduce it? Best regards, Konstantin Kolinko - 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: REST call failure on newer tomcat version/update
We did try adding PUT to parseBodyMethods but didn't not change the issue. On Mon, Dec 22, 2014 at 11:24 AM, Sean Dawson seandawson2...@gmail.com wrote: I don't think so. But perhaps that's the new/current thinking and something in the latest tomcat/libraries is enforcing that? I'll double-check/look-it-up. In any case, people do it - and it was working before. On Mon, Dec 22, 2014 at 11:12 AM, David kerber dcker...@verizon.net wrote: On 12/22/2014 11:05 AM, Sean Dawson wrote: Hi Konstantin, Thanks for your reply. What details do you need of our config? Do you want the full files? Essentially it's a pretty straightforward install - extract tomcat, remove all the webapps, put our war somewhere, use Catalina/localhost/ROOT.xml to point to the war. It's a gwt app that makes some rpc calls and some REST calls to a different process (which could be on a different server) - everything seems to work up until the point of making this one REST PUT call with some data that's supposed to return some I don't use REST, so I may be off base here, but is a REST PUT like an HTTP PUT in that it's not expected to get any return data? In HTTP, you normally use either a POST or a GET if you want a response back. data. It's possible that it might have to do with json serialization or dto's - because it's the first call that uses them in the request and response. Exact same config with _42 works fine. Did not see anything in docs/etc that would affect us (but could have missed something). This happens with everything locally on Windows, and remotely on Amazon Linux cloud servers. The request is made, and the status is 200 - but fiddler shows no response data - and the app does not continue at that point (it should do an onSuccess, but it doesn't even do an onFailure). It happens ALL the time with the latest tomcat - never with the older. I can't seem to get any more data about what's going on when it happens. Most things just fail silently - it was only when I started changing up all the configurations (browser-clients/etc) that I got the other messages mentioned. On Mon, Dec 22, 2014 at 7:02 AM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2014-12-19 20:49 GMT+03:00 Sean Dawson seandawson2...@gmail.com: Hello, We had a gwt app deployed and working with tomcat 7_42 and tried it recently in several configurations (Windows/Linux) with the latest update of 7 and it fails during a RestyGwt/RestEasy call to the server. Previous calls succeed but this particular one appears to get an http code of 200 but doesn't return any data (but it should) - and so the app never proceeds. There's no message, exception, etc - so the app just sits there. In running this on several clients (Firefox, Chrome, RestClient for FF, etc), I *have* received a couple messages on that call (in certain situations) such as... Error Code: 502 Proxy Error. A software error occurred for a Windows Internet extension application that is required for the current operation. and Error 415 Unsupported Media Type Does anyone have an idea what this might be? Why it changed? If I swap out the latest version for 41 or 42, and change nothing else, it works fine. Can't find anything in docs or searches online. What is your configuration? I guess that those 500 and 415 responses are not from Tomcat. Are they from IIS? Is that one up-to-date? Do you have access log configured in Tomcat? Are those requests mentioned in Tomcat access log? Does the issue happen randomly? Can you reproduce it? Best regards, Konstantin Kolinko - 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: Initialise application once
On 12/21/2014 9:14 AM, Fabio Ricci wrote:
Yes that made it
THANK YOU very much!!!
Grazie mille!
Cheers
Fabio
Am 21.12.14 um 14:10 schrieb Alessandro Manzoni:
Il 21.12.2014 13.38, Fabio Ricci ha scritto:
Dear community
I developed a tomcat JSP servlet which - say - instantiates a class,
work with that class and gives some output back to the calling user
in the browser.
My point is instantiating the class ***once*** for every requests
coming after this instantiation. The reason is: the class loads
several components into memory and I would like not to do this at
every call of this JSP servlet but just once.
Where shell I put the initializing code for the heavy components?
Is this possible?
Thank you very much in advance!
Fabio
Try putting an attribute inside the servlet contex in a lazy way,
that will be in the scope of the whole application inside the same
VM.E.g.:
Object grosso = getServletContext().getAttribute(GROSSO);
if (grosso == null) {
grosso = new Grosso();
getServletContext().setAttribute(GROSSO, grosso);
}
If you want to limit the scope to a single session, put the same as a
session attribute.
You could also use a singleton that initializes itself in the same way.
Either way, the object and initialization should be thread safe.
Happy Holidays!
-Terence Bandoian
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
2014-12-22 19:05 GMT+03:00 Sean Dawson seandawson2...@gmail.com: Hi Konstantin, Thanks for your reply. Rules: http://tomcat.apache.org/lists.html#tomcat-users - 6. When replying, please write your text below the quoted one. What details do you need of our config? Do you want the full files? For starters, a good description of your system. My question is do you access Tomcat directly or via some proxy / front-end web server? Essentially it's a pretty straightforward install - extract tomcat, remove all the webapps, put our war somewhere, use Catalina/localhost/ROOT.xml to point to the war. It's a gwt app that makes some rpc calls and some REST calls to a different process (which could be on a different server) - everything seems to work up until the point of making this one REST PUT call with some data that's supposed to return some data. It's possible that it might have to do with json serialization or dto's - because it's the first call that uses them in the request and response. Exact same config with _42 works fine. Did not see anything in docs/etc that would affect us (but could have missed something). This happens with everything locally on Windows, and remotely on Amazon Linux cloud servers. The request is made, and the status is 200 - but fiddler shows no response data - and the app does not continue at that point (it should do an onSuccess, but it doesn't even do an onFailure). It happens ALL the time with the latest tomcat - never with the older. I can't seem to get any more data about what's going on when it happens. Most things just fail silently - it was only when I started changing up all the configurations (browser-clients/etc) that I got the other messages mentioned. On Mon, Dec 22, 2014 at 7:02 AM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2014-12-19 20:49 GMT+03:00 Sean Dawson seandawson2...@gmail.com: Hello, We had a gwt app deployed and working with tomcat 7_42 and tried it recently in several configurations (Windows/Linux) with the latest update of 7 and it fails during a RestyGwt/RestEasy call to the server. Previous calls succeed but this particular one appears to get an http code of 200 but doesn't return any data (but it should) - and so the app never proceeds. There's no message, exception, etc - so the app just sits there. In running this on several clients (Firefox, Chrome, RestClient for FF, etc), I *have* received a couple messages on that call (in certain situations) such as... Error Code: 502 Proxy Error. A software error occurred for a Windows Internet extension application that is required for the current operation. and Error 415 Unsupported Media Type Does anyone have an idea what this might be? Why it changed? If I swap out the latest version for 41 or 42, and change nothing else, it works fine. Can't find anything in docs or searches online. What is your configuration? I guess that those 500 and 415 responses are not from Tomcat. Are they from IIS? Is that one up-to-date? Do you have access log configured in Tomcat? Are those requests mentioned in Tomcat access log? Are those requests processed by Tomcat? Do you see them in Tomcat access log? Does the issue happen randomly? Can you reproduce it? Can you try the versions between 7.0.42 and current .57 (47, 50, 52, 53, 54, 55, 56)? Can you simplify your application to some simple example that fails? Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
On 12/22/2014 6:02 AM, Konstantin Kolinko wrote: 2014-12-19 20:49 GMT+03:00 Sean Dawson seandawson2...@gmail.com: Hello, We had a gwt app deployed and working with tomcat 7_42 and tried it recently in several configurations (Windows/Linux) with the latest update of 7 and it fails during a RestyGwt/RestEasy call to the server. Previous calls succeed but this particular one appears to get an http code of 200 but doesn't return any data (but it should) - and so the app never proceeds. There's no message, exception, etc - so the app just sits there. In running this on several clients (Firefox, Chrome, RestClient for FF, etc), I *have* received a couple messages on that call (in certain situations) such as... Error Code: 502 Proxy Error. A software error occurred for a Windows Internet extension application that is required for the current operation. and Error 415 Unsupported Media Type Does anyone have an idea what this might be? Why it changed? If I swap out the latest version for 41 or 42, and change nothing else, it works fine. Can't find anything in docs or searches online. What is your configuration? I guess that those 500 and 415 responses are not from Tomcat. Are they from IIS? Is that one up-to-date? Do you have access log configured in Tomcat? Are those requests mentioned in Tomcat access log? Does the issue happen randomly? Can you reproduce it? Best regards, Konstantin Kolinko Which app just sits there? Whichever it is, shouldn't the status and data in the response be validated? Not receiving the data expected with a given status would, in my mind, constitute an error. -Terence Bandoian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
On Mon, Dec 22, 2014 at 8:24 AM, Sean Dawson seandawson2...@gmail.com wrote: In any case, people do it - and it was working before. Uh, people do lots of objectively wrong things in web development, and works in some circumstances ≠ adheres to the spec :-) My reading of the RFC (http://tools.ietf.org/html/rfc7231#page-21) is that there's no reason to expect a response-body from a PUT, even if the mention of returning either 200 or 204 is a bit ambiguous. So it wouldn't surprise me to see a server implementation discard a response-body from a PUT as invalid. FWIW, -- Hassan Schroeder hassan.schroe...@gmail.com http://about.me/hassanschroeder twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
Am working on testing the 8 versions between the one that works and the one that doesn't. We use tomcat to host our gwt/restygwt app - gwt rpc calls work (as far as we've tested) - restygwt REST calls to another process (jetty server - RestEasy) work up to the point of that PUT request (which isn't alot of them, but it's getting to the server and some succeed). There's almost no info to go on when the gwt app doesn't proceed - fiddler says the call succeeded with a 200 - but no data returned - and so the gwt app that should proceed on onSuccess or onFailure, does not. So with the restygwt async calls, we're not receiving anything back - despite fiddler claiming that the call completed with 200 status (this can all be on the same machine - but once you put the two processes or different ones using different client browsers - sometimes get the other messages indicated). So the problem might lie with RestyGwt - but that's not what changes between the working and non-working scenario. Thanks for info from the spec. On Mon, Dec 22, 2014 at 1:53 PM, Hassan Schroeder hassan.schroe...@gmail.com wrote: On Mon, Dec 22, 2014 at 8:24 AM, Sean Dawson seandawson2...@gmail.com wrote: In any case, people do it - and it was working before. Uh, people do lots of objectively wrong things in web development, and works in some circumstances ≠ adheres to the spec :-) My reading of the RFC (http://tools.ietf.org/html/rfc7231#page-21) is that there's no reason to expect a response-body from a PUT, even if the mention of returning either 200 or 204 is a bit ambiguous. So it wouldn't surprise me to see a server implementation discard a response-body from a PUT as invalid. FWIW, -- Hassan Schroeder hassan.schroe...@gmail.com http://about.me/hassanschroeder twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
So it works with all of them up to _52 but fails for all of them after that. I had a theory related to tomcat creating a webapps/ROOT dir in the newer versions that it didn't in the older one (when pointing to the war from Catalina/local/ROOT.xml) as a possible difference/change but _52 does this and it works there. We have a fairly simple (java servlet) proxy to pass the gwt REST requests along - is there anything I could look at... redirects, (not) caching params, etc ? Will have a look at the changes to the config files between working and non-working tomcat installs - and also the release notes. On Mon, Dec 22, 2014 at 2:15 PM, Sean Dawson seandawson2...@gmail.com wrote: Am working on testing the 8 versions between the one that works and the one that doesn't. We use tomcat to host our gwt/restygwt app - gwt rpc calls work (as far as we've tested) - restygwt REST calls to another process (jetty server - RestEasy) work up to the point of that PUT request (which isn't alot of them, but it's getting to the server and some succeed). There's almost no info to go on when the gwt app doesn't proceed - fiddler says the call succeeded with a 200 - but no data returned - and so the gwt app that should proceed on onSuccess or onFailure, does not. So with the restygwt async calls, we're not receiving anything back - despite fiddler claiming that the call completed with 200 status (this can all be on the same machine - but once you put the two processes or different ones using different client browsers - sometimes get the other messages indicated). So the problem might lie with RestyGwt - but that's not what changes between the working and non-working scenario. Thanks for info from the spec. On Mon, Dec 22, 2014 at 1:53 PM, Hassan Schroeder hassan.schroe...@gmail.com wrote: On Mon, Dec 22, 2014 at 8:24 AM, Sean Dawson seandawson2...@gmail.com wrote: In any case, people do it - and it was working before. Uh, people do lots of objectively wrong things in web development, and works in some circumstances ≠ adheres to the spec :-) My reading of the RFC (http://tools.ietf.org/html/rfc7231#page-21) is that there's no reason to expect a response-body from a PUT, even if the mention of returning either 200 or 204 is a bit ambiguous. So it wouldn't surprise me to see a server implementation discard a response-body from a PUT as invalid. FWIW, -- Hassan Schroeder hassan.schroe...@gmail.com http://about.me/hassanschroeder twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
On 12/22/2014 2:56 PM, Sean Dawson wrote: So it works with all of them up to _52 but fails for all of them after that. I had a theory related to tomcat creating a webapps/ROOT dir in the newer versions that it didn't in the older one (when pointing to the war from Catalina/local/ROOT.xml) as a possible difference/change but _52 does this and it works there. We have a fairly simple (java servlet) proxy to pass the gwt REST requests along - is there anything I could look at... redirects, (not) caching params, etc ? Will have a look at the changes to the config files between working and non-working tomcat installs - and also the release notes. How about changing the PUT to a POST, and see what that does for you? On Mon, Dec 22, 2014 at 2:15 PM, Sean Dawson seandawson2...@gmail.com wrote: Am working on testing the 8 versions between the one that works and the one that doesn't. We use tomcat to host our gwt/restygwt app - gwt rpc calls work (as far as we've tested) - restygwt REST calls to another process (jetty server - RestEasy) work up to the point of that PUT request (which isn't alot of them, but it's getting to the server and some succeed). There's almost no info to go on when the gwt app doesn't proceed - fiddler says the call succeeded with a 200 - but no data returned - and so the gwt app that should proceed on onSuccess or onFailure, does not. So with the restygwt async calls, we're not receiving anything back - despite fiddler claiming that the call completed with 200 status (this can all be on the same machine - but once you put the two processes or different ones using different client browsers - sometimes get the other messages indicated). So the problem might lie with RestyGwt - but that's not what changes between the working and non-working scenario. Thanks for info from the spec. On Mon, Dec 22, 2014 at 1:53 PM, Hassan Schroeder hassan.schroe...@gmail.com wrote: On Mon, Dec 22, 2014 at 8:24 AM, Sean Dawson seandawson2...@gmail.com wrote: In any case, people do it - and it was working before. Uh, people do lots of objectively wrong things in web development, and works in some circumstances ≠ adheres to the spec :-) My reading of the RFC (http://tools.ietf.org/html/rfc7231#page-21) is that there's no reason to expect a response-body from a PUT, even if the mention of returning either 200 or 204 is a bit ambiguous. So it wouldn't surprise me to see a server implementation discard a response-body from a PUT as invalid. FWIW, -- Hassan Schroeder hassan.schroe...@gmail.com http://about.me/hassanschroeder twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
On Mon, Dec 22, 2014 at 3:01 PM, David kerber dcker...@verizon.net wrote: On 12/22/2014 2:56 PM, Sean Dawson wrote: So it works with all of them up to _52 but fails for all of them after that. I had a theory related to tomcat creating a webapps/ROOT dir in the newer versions that it didn't in the older one (when pointing to the war from Catalina/local/ROOT.xml) as a possible difference/change but _52 does this and it works there. We have a fairly simple (java servlet) proxy to pass the gwt REST requests along - is there anything I could look at... redirects, (not) caching params, etc ? Will have a look at the changes to the config files between working and non-working tomcat installs - and also the release notes. How about changing the PUT to a POST, and see what that does for you? Similar result - 200 status, not proceeding - however fiddler seems to show some data. Will remote debug this to see if we're making it to onSuccess or onFailure (doubt it since it should either make another REST call, or show an exception message). On that call, Fiddler said Content-Length response header MUSTNOT be present when Transfer-Encoding is used. In the release notes between _53, here's the only thing I saw that I thought applied to our situation... 56190: The response should be closed (i.e. no further output is permitted) when a call to AsyncContext.complete() takes effect. (markt) Still going to check config file diffs. On Mon, Dec 22, 2014 at 2:15 PM, Sean Dawson seandawson2...@gmail.com wrote: Am working on testing the 8 versions between the one that works and the one that doesn't. We use tomcat to host our gwt/restygwt app - gwt rpc calls work (as far as we've tested) - restygwt REST calls to another process (jetty server - RestEasy) work up to the point of that PUT request (which isn't alot of them, but it's getting to the server and some succeed). There's almost no info to go on when the gwt app doesn't proceed - fiddler says the call succeeded with a 200 - but no data returned - and so the gwt app that should proceed on onSuccess or onFailure, does not. So with the restygwt async calls, we're not receiving anything back - despite fiddler claiming that the call completed with 200 status (this can all be on the same machine - but once you put the two processes or different ones using different client browsers - sometimes get the other messages indicated). So the problem might lie with RestyGwt - but that's not what changes between the working and non-working scenario. Thanks for info from the spec. On Mon, Dec 22, 2014 at 1:53 PM, Hassan Schroeder hassan.schroe...@gmail.com wrote: On Mon, Dec 22, 2014 at 8:24 AM, Sean Dawson seandawson2...@gmail.com wrote: In any case, people do it - and it was working before. Uh, people do lots of objectively wrong things in web development, and works in some circumstances ≠ adheres to the spec :-) My reading of the RFC (http://tools.ietf.org/html/rfc7231#page-21) is that there's no reason to expect a response-body from a PUT, even if the mention of returning either 200 or 204 is a bit ambiguous. So it wouldn't surprise me to see a server implementation discard a response-body from a PUT as invalid. FWIW, -- Hassan Schroeder hassan.schroe...@gmail.com http://about.me/hassanschroeder twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
2014-12-22 23:29 GMT+03:00 Sean Dawson seandawson2...@gmail.com: On Mon, Dec 22, 2014 at 3:01 PM, David kerber dcker...@verizon.net wrote: On 12/22/2014 2:56 PM, Sean Dawson wrote: So it works with all of them up to _52 but fails for all of them after that. I had a theory related to tomcat creating a webapps/ROOT dir in the newer versions that it didn't in the older one (when pointing to the war from Catalina/local/ROOT.xml) as a possible difference/change but _52 does this and it works there. We have a fairly simple (java servlet) proxy to pass the gwt REST requests along - is there anything I could look at... redirects, (not) caching params, etc ? Will have a look at the changes to the config files between working and non-working tomcat installs - and also the release notes. How about changing the PUT to a POST, and see what that does for you? Similar result - 200 status, not proceeding - however fiddler seems to show some data. Will remote debug this to see if we're making it to onSuccess or onFailure (doubt it since it should either make another REST call, or show an exception message). On that call, Fiddler said Content-Length response header MUSTNOT be present when Transfer-Encoding is used. Content-Length header must not be present if Transfer-Encoding: chunked is used. If it is in a request, Tomcat 7.0.47 and later shall reject such requests per CVE-2013-4286, http://tomcat.apache.org/security-7.html#Fixed_in_Apache_Tomcat_7.0.47 If it is in a response, I wonder how one can produce that. Tomcat does not enable chunked encoding if ContentLength is set on response (AbstractHttp11Processor.prepareResponse()). Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
Sean Dawson wrote: Am working on testing the 8 versions between the one that works and the one that doesn't. We use tomcat to host our gwt/restygwt app - gwt rpc calls work (as far as we've tested) - restygwt REST calls to another process (jetty server - RestEasy) work up to the point of that PUT request (which isn't alot of them, but it's getting to the server and some succeed). There's almost no info to go on when the gwt app doesn't proceed - fiddler says the call succeeded with a 200 - but no data returned - and so the gwt app that should proceed on onSuccess or onFailure, does not. So with the restygwt async calls, we're not receiving anything back - despite fiddler claiming that the call completed with 200 status (this can all be on the same machine - but once you put the two processes or different ones using different client browsers - sometimes get the other messages indicated). So the problem might lie with RestyGwt - but that's not what changes between the working and non-working scenario. Thanks for info from the spec. Sean, a word of advice : for someone not on your system, and not immersed in your application and your setup, your explanation of the configuration you are using, what is where, and what happens where when, is less than clear. That makes it more difficult to really help you. In addition, whislt I have not consulted right now the corresponding applicable RFCs, and have just browsed the starting page of GWT right now for the first time, it seems to me that you are making some assumptions that may not be valid, and may lead you to surmise the wrong thing or look in the wrong place. I believe that everyone understands that you are trying to figure out why your whole thing seems to work with some versions of Tomcat and not others. As a couple of people have already mentioned, it does not seem guaranteed that a PUT request to a webserver, no matter in what context, would always return a response *body*. You say : fiddler says the call succeeded with a 200. That is not exactly true : Fiddler (apparently) shows you that a response was received from the webserver; that this response consists only of a HTTP status line; and that this status line includes a status code 200, which from a HTTP protocol perspective should mean OK. Fiddler does not tell you anything else. It does not know what happened after the PUT request was received by Tomcat, nor if the webapp really succeded in doing what it was supposed to do. It just shows you the content of the received status line. A HTTP response consists of, in that order, - a HTTP status line (always) - possibly, immediately following the status line, some additional HTTP response header lines - possibly, a blank line followed by a response body (what you call data) (So basically, a HTTP response /could/ consist of a single status line, and be perfectly valid from a pure HTTP perspective - and thus from a Tomcat HTTP server perspective). We are further guessing that the Fiddler which you are mentioning sits between the browser and Tomcat - it is not extremely clear, because you are also at other times talking about Jetty, then about a Proxy webapp, then about RESTy calls which sometimes succeed and sometime not etc.. And - at least as far as I am concerned- we are supposing that the GWT application of which you are talking runs inside of a browser page, and makes some kind of HTTP calls to Tomcat. We will also suppose that the webapp which you occasionally mention, runs on that same Tomcat server, and that it is the one supposed to answer these HTTP calls from the GWT application which lives in the browser. Well, guess what ? unless I am deeply mistaken - which is always a serious possibility - I do not believe that Tomcat per se contains any code which actually handles a PUT request and responds to it. So in all likelihood, it is that webapp which you barely mention which controls what the PUT actually does on the server, and which also controls the response that is being sent back to the browser (or not, as the case may be). From other bits of your explanation, I also surmise that the GWT code in the browser, after receiving the HTTP 200 status line response, expects additional HTTP headers and/or a HTTP response body with data in it, that it is not receiving such a response body, and that in consequence it blocks, waiting for it. (Which may or may not be its expected behaviour, we also don't know that.) Very little of all the above actually happens in Tomcat code, which in this case merely passes things back and forth between the browser and the web application. And this Tomcat code has no idea what your GWT code on the one hand, and the webapp code on the other, expect from eachother beyond the HTTP spec. So, as long as what goes through appears relatively HTTP-standard, and as long as the webapp does not really misbehave (aka, crash), Tomcat has no particular reason to log anything.
Re: Help! Tomcat crashing on takeoff
On the Tomcat Users List, Pete Helgren wrote: Also, are you sure that Java 6 on this box is current with PTF's and that the profile this is running under is picking up the correct JVM version when it runs? My money is on a J9 JVM PTF but an issue with permissions or JVM version could be a possibility.. and on the Java400 list at Midrange.com, Marshall Dunbar wrote: In my experience, if you just loaded a new JDK and have not loaded the java group PTF, java may have ³unpredictable results². I bet things will magically work as soon as the java group PTF is loaded. Just got word that the customer had successfully loaded the PTF, but there's no change at all in the behavior. The CATALINA job still crashes on takeoff (albeit with a message that it had completed normally), the spool file from STDOUT shows Using CATALINA_BASE: /wintouch/tomcat Using CATALINA_HOME: /wintouch/tomcat Using CATALINA_TMPDIR: /wintouch/tomcat/temp Using JRE_HOME:/QOpenSys/QIBM/ProdData/JavaVM/jdk60/32bit Using CLASSPATH: /wintouch/tomcat/bin/bootstrap.jar:/wintouch/tomcat/bin/tomcat-juli.jar Tomcat started. (which exactly matches what it says on our own box, on which Tomcat works just fine), and catalina.out shows: java.lang.ClassNotFoundException: org.apache.catalina.startup.Catalina at java.net.URLClassLoader.findClass(URLClassLoader.java:419) at java.lang.ClassLoader.loadClass(ClassLoader.java:643) at java.lang.ClassLoader.loadClass(ClassLoader.java:609) at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:235) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:425) If I do /wintouch/tomcat/bin/startup.sh from an interactive QSHELL session (after my STRTOMCAT CL program had already set the environment variable to select the correct JVM), I get the same STDOUT as before. Then again, I'm not entirely sure they actually DID install any Java PTFs. Their latest 5761JV1 PTF is dated November of 2013. On the one hand, that's a good deal more recent than the latest one on our system; on the other hand, it's over a year ago, and a Google search shows PTFs for 5761JV1 that are as recent as less than a WEEK ago. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: REST call failure on newer tomcat version/update
Ok after many hours, here's all the information as I know it - as clearly and thoroughly as I can give it... One physical machine - Windows 7 Gwt 2.6.1 App deployed to tomcat 7 (either 52 or 53) built with maven 3.1.1 uses RestyGwt 1.4 uses ProxyServlet to pass REST calls to other process REST server deployed with Jetty 8.1.7 built with same maven uses RestEasy 3.0.8.Final Tomcat setup... - download apache-tomcat-7.0.5[2/3]-windows-x64.zip - extract - clear webapps dir - create conf/Catalina/localhost/ROOT.xml with: Context docBase=C:\path\ROOT.war .. [app specific params] /Context - start Chrome Version 39.0.2171.95 m - all history cleared between every run. With 52, all calls seem to work and return quickly, fiddler doesn't show any errors/warning. With 53, the one PUT call seems to return status code 0 on client (hard to debug, in RestyGwt/javascript), with fiddler running, PUT call seems to take a lot longer, get HTTP protocol violation report about Content-Length MUSTNOT be present, also when attempting to decode the response data: The HTTP response body was malformed - the chunked content is corrupt, chunk length was malformed Offset: 14. Type System.IO.InvalidDataException... I don't see anything in the tomcat logs, or the REST server ones, to indicate an issue. Most of the request/response data in each situation are the same, except... [Transformer view] working case: Response body: 142 bytes, Chunked is checked failure case: Response body: 133 bytes, Chunked is checked [Raw view] working case: Transfer-Encoding: chunked, Transfer-Encoding: chunked (seems to be listed twice) failure case: Transfer-Encoding: chunked, Content-Length: 133 Request seems to be identical in both cases (except for a different JSESSIONID/cookie value) What else I've done: - compared all the config files between both version - seem similar enough - copied ecj-4.3.1.jar from 52 and put it in as ecj-P20140317-1600.jar in 53 - problem still exists - copied the 2 jars in bin that changed between version, and all the libs from 52 install to 53 install (everything else in 53 being original install) - problem no longer exists - attempted to remote debug Gwt client, attempted to debug servlets, attempted to switch PUT to POST, attempted to run REST server in eclipse (with Jetty runner), compared log files - no more info gathered On Mon, Dec 22, 2014 at 4:12 PM, André Warnier a...@ice-sa.com wrote: Sean Dawson wrote: Am working on testing the 8 versions between the one that works and the one that doesn't. We use tomcat to host our gwt/restygwt app - gwt rpc calls work (as far as we've tested) - restygwt REST calls to another process (jetty server - RestEasy) work up to the point of that PUT request (which isn't alot of them, but it's getting to the server and some succeed). There's almost no info to go on when the gwt app doesn't proceed - fiddler says the call succeeded with a 200 - but no data returned - and so the gwt app that should proceed on onSuccess or onFailure, does not. So with the restygwt async calls, we're not receiving anything back - despite fiddler claiming that the call completed with 200 status (this can all be on the same machine - but once you put the two processes or different ones using different client browsers - sometimes get the other messages indicated). So the problem might lie with RestyGwt - but that's not what changes between the working and non-working scenario. Thanks for info from the spec. Sean, a word of advice : for someone not on your system, and not immersed in your application and your setup, your explanation of the configuration you are using, what is where, and what happens where when, is less than clear. That makes it more difficult to really help you. In addition, whislt I have not consulted right now the corresponding applicable RFCs, and have just browsed the starting page of GWT right now for the first time, it seems to me that you are making some assumptions that may not be valid, and may lead you to surmise the wrong thing or look in the wrong place. I believe that everyone understands that you are trying to figure out why your whole thing seems to work with some versions of Tomcat and not others. As a couple of people have already mentioned, it does not seem guaranteed that a PUT request to a webserver, no matter in what context, would always return a response *body*. You say : fiddler says the call succeeded with a 200. That is not exactly true : Fiddler (apparently) shows you that a response was received from the webserver; that this response consists only of a HTTP status line; and that this status line includes a status code 200, which from a HTTP protocol perspective should mean OK. Fiddler does not tell you anything else. It does not know what happened after the PUT request was received by Tomcat, nor if the webapp really succeded in doing what it was supposed to do. It just shows you the
