Re: Cors-Filter
> On Feb 26, 2016, at 3:40 PM, Christopher Schultz > <ch...@christopherschultz.net> wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Jose, > > On 2/26/16 7:08 AM, Jose María Zaragoza wrote: >> 2016-02-26 9:08 GMT+01:00 RICHARD DOUST <rdo...@mac.com>: >>> My question is, why doesn't it work, or, how can I debug it? >> >> Are you tested to allow to all origins (default option) ? Only for >> testing purpose, I mean: >> >> cors.allowed.origins >> * >> >> At first sight, your settings should work, but ... > > This is exactly what I was going to suggest. > > Also, what HTTP METHOD are you actually using? POST? POST > > If you are using https://, I would make sure that https:// URLs > actually appear in your configuration (you only have HTTP URLs). The origin of the request is http://, that’s why I put it in there. Do I also need to put https:// in there? Seems counter-intuitive, but okay. I’ll try it. Thanks. > > - -chris > >>> I guess I'm going to have to figure out how to get the code for >>> org.apache associated with the jar file so that I can see the >>> source in Eclipse and set a breakpoint. I have read elsewhere >>> that any http page that attempts to mix in https content is as >>> insecure as the page that uses http exclusively, being subject to >>> man in the middle attacks and that once you need https everything >>> needs to be https, but in a large SPA, that seems to me to mean a >>> lot of potentially unnecessary overhead. I'd like to know what >>> some experts think. >>> >>> Thanks >>> >>> Sent from my iPad >>> >>>> On Feb 26, 2016, at 2:42 AM, André Warnier (tomcat) >>>> <a...@ice-sa.com> wrote: >>>> >>>>> On 25.02.2016 22:59, RICHARD DOUST wrote: Hi, >>>>> >>>>> I’m running Tomcat 7.0. Can’t find the version.bat file, so I >>>>> don’t know more than that. It’s installed on a Windows >>>>> computer running Windows Server 2003 DataCenter Edition. >>>>> (How’s that for refusing to upgrade?) Anyway, it’s a client’s >>>>> box. I’m trying to migrate an application to JavaScript from >>>>> GWT, but that’s beside the point. The problem is, I’m unable >>>>> to send an XMLHttpRequest to this Tomcat instance via https. >>>>> The site is being served by the same domain, but via http. >>>>> >>>>> I get: >>>>> >>>>> Failed to load resource: Origin http://www.domain.com is not >>>>> allowed by Access-Control-Allow-Origin. >>>>> https://www.domain.com/application/api/request XMLHttpRequest >>>>> cannot load https://www.domain.com/application/api/reqeuest. >>>>> Origin http://www.domain.com is not allowed by >>>>> Access-Control-Allow-Origin. >>>>> >>>>> This is an excerpt my web.xml file for the war: >>>>> >>>>>> CorsFilter >>>>>> org.apache.catalina.filters.CorsFilter> >>>>>> >>>>>> > >>>>>> cors.allowed.origins >>>>>> http://www.domain.com, http://beta.domain.com:8080, >>>>>> http://localhost:8080 >>>>>> cors.allowed.methods >>>>>> GET,POST,HEAD,OPTIONS,PUT >>>>>> >>>>>> >>>>>> CorsFilter >>>>>> /api/* >>>>> >>>>> >>>>> I’d like to debug this, but I don’t know how to go about it. >>>>> Am I suffering from a basic misunderstanding? Does cors not >>>>> allow http to https? Anyway, any help would be appreciated. >>>>> >>>> >>>> Honestly, I don't know much about CORS, but I looked at the >>>> specs, here : http://tools.ietf.org/html/rfc6454 (*) and it >>>> seems to me indeed that in 3.2, Q: Why not just use the host?, >>>> it indeed says that the scheme "http" or "https", is part of >>>> the origin. I interpret this as meaning that if the HTML page >>>> was obtained from "http://www.domain.com;, a call made from >>>> within it, to "https://www.domain.com; would not qualify as >>>> "from the same origin". >>>> >>>> Further in 3.2.1, it gives some examples : >>>> >>>> Each of the following resources has a dif
Re: Cors-Filter
There's no doubt in my mind that this is considered a cross-domain request. The question is, why is it not being allowed given the configuration. The domain that requested the original page (via http) is specifically set to be allowed to access the site in a cross-domain scenario. My question is, why doesn't it work, or, how can I debug it? I guess I'm going to have to figure out how to get the code for org.apache associated with the jar file so that I can see the source in Eclipse and set a breakpoint. I have read elsewhere that any http page that attempts to mix in https content is as insecure as the page that uses http exclusively, being subject to man in the middle attacks and that once you need https everything needs to be https, but in a large SPA, that seems to me to mean a lot of potentially unnecessary overhead. I'd like to know what some experts think. Thanks Sent from my iPad > On Feb 26, 2016, at 2:42 AM, André Warnier (tomcat) <a...@ice-sa.com> wrote: > >> On 25.02.2016 22:59, RICHARD DOUST wrote: >> Hi, >> >> I’m running Tomcat 7.0. Can’t find the version.bat file, so I don’t know >> more than that. It’s installed on a Windows computer running Windows Server >> 2003 DataCenter Edition. (How’s that for refusing to upgrade?) Anyway, it’s >> a client’s box. I’m trying to migrate an application to JavaScript from GWT, >> but that’s beside the point. The problem is, I’m unable to send an >> XMLHttpRequest to this Tomcat instance via https. The site is being served >> by the same domain, but via http. >> >> I get: >> >> Failed to load resource: Origin http://www.domain.com is not allowed by >> Access-Control-Allow-Origin. >> https://www.domain.com/application/api/request >> XMLHttpRequest cannot load https://www.domain.com/application/api/reqeuest. >> Origin http://www.domain.com is not allowed by Access-Control-Allow-Origin. >> >> This is an excerpt my web.xml file for the war: >> >>> >>>CorsFilter >>>org.apache.catalina.filters.CorsFilter >>> >>>cors.allowed.origins >>> http://www.domain.com, >>> http://beta.domain.com:8080, http://localhost:8080 >>> >>> >>>cors.allowed.methods >>>GET,POST,HEAD,OPTIONS,PUT >>> >>> >>> >>> >>> CorsFilter >>> /api/* >>> >> >> >> I’d like to debug this, but I don’t know how to go about it. Am I suffering >> from a basic misunderstanding? Does cors not allow http to https? Anyway, >> any help would be appreciated. >> > > Honestly, I don't know much about CORS, but I looked at the specs, here : > http://tools.ietf.org/html/rfc6454 (*) > and it seems to me indeed that in > 3.2, Q: Why not just use the host?, > it indeed says that the scheme "http" or "https", is part of the origin. > I interpret this as meaning that if the HTML page was obtained from > "http://www.domain.com;, a call made from within it, to > "https://www.domain.com; would not qualify as "from the same origin". > > Further in 3.2.1, it gives some examples : > > Each of the following resources has a different origin from the > others. > > http://example.com/ > http://example.com:8080/ > http://www.example.com/ > https://example.com:80/ > https://example.com/ > http://example.org/ > > > (*) pointed at by the on-line Tomcat documentation : > https://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#CORS_Filter > -> cors.allowed.origins -> "origin" > > > - > 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
Cors-Filter
Hi, I’m running Tomcat 7.0. Can’t find the version.bat file, so I don’t know more than that. It’s installed on a Windows computer running Windows Server 2003 DataCenter Edition. (How’s that for refusing to upgrade?) Anyway, it’s a client’s box. I’m trying to migrate an application to JavaScript from GWT, but that’s beside the point. The problem is, I’m unable to send an XMLHttpRequest to this Tomcat instance via https. The site is being served by the same domain, but via http. I get: Failed to load resource: Origin http://www.domain.com is not allowed by Access-Control-Allow-Origin. https://www.domain.com/application/api/request XMLHttpRequest cannot load https://www.domain.com/application/api/reqeuest. Origin http://www.domain.com is not allowed by Access-Control-Allow-Origin. This is an excerpt my web.xml file for the war: > > CorsFilter > > org.apache.catalina.filters.CorsFilter > > cors.allowed.origins >http://www.domain.com, > http://beta.domain.com:8080, http://localhost:8080 > > > cors.allowed.methods > GET,POST,HEAD,OPTIONS,PUT > > > > > CorsFilter > /api/* > I’d like to debug this, but I don’t know how to go about it. Am I suffering from a basic misunderstanding? Does cors not allow http to https? Anyway, any help would be appreciated. Thanks, Richard
Re: IIS 6.0 isapi_redirect 1.2.40 Tomcat 7.0 403 Forbidden
After getting the debugging worked out I found that, even though I thought I'd removed the Cors Filter, it was still being invoked. Not sure why, but that's different issue that I'll look into later. The Cors Filter was denying access to the resource. I had thought that the Cors Filter was there to check for cross domain requests, but it appears that it's checking all requests. Even though this particular request is not cross domain, the filter was not configured to allow the origin (because I didn't think I needed to), so it denied access based on origin. Thanks for your help in resolving the issue Konstantin. Richard On Feb 9, 2015, at 2:12 PM, RICHARD DOUST rdo...@me.com wrote: I have removed the CORS Filter from the web.xml, redeployed, and the behavior is the same. Still get the 403 Forbidden return code. The instructions on that web site say that I should attach source to the jar file for Tomcat. It's not clear to me how to do that. How do I select the jar file? It's running remotely. Thanks, Richard On Feb 9, 2015, at 10:47 AM, RICHARD DOUST rdo...@me.com wrote: Ok. Found the archives for source. Now all I've got to do is figure out how to get Eclipse to look at the source when I'm running Tomcat remotely. I'll review that page you sent the link to. Richard On Feb 9, 2015, at 10:14 AM, RICHARD DOUST rdo...@me.com wrote: We are running 7.0.57. I have not tried to debug yet, but am willing to give it a try. I have gone to the apache site to download the source for that version but can only find 7.0.59. If you can tell me how to get the source for 7.0.57, I'll take it down, otherwise, I'll update the executable and use the source for 7.0.59. I will try removing the CORS filter from the deployment and see if that changes the behavior. I'll update this thread when I know the results. Thanks for your input. Richard On Feb 6, 2015, at 6:29 PM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2015-02-06 23:30 GMT+03:00 RICHARD DOUST rdo...@me.com mailto:rdo...@me.com: Hi, I've got an application that ran well with Tomcat 6.0, but is causing me problems on Tomcat 7.0. The front end is IIS (listening on port 80, passing requests to the isapi_redirect (1.2.40) filter which is configured to send some urls on to ajp13, then to port 8009 were Tomcat is listening), all running on Windows Server 2003. I know the isapi filter is working because I've configured mappings to the Tomcat docs and manager web apps and can get to them without any problems (via IIS). I have a servlet deployed to Tomcat that I'm POSTing to via an XMLHttpRequest in a browser. For the life of me, I cannot get it to respond to me with anything but a 403 and I can't figure out why. It is not a cross-domain request, so a CORS Filter (which is installed in support of a rewrite of the application which is underway) can't be having any effect. I have added an init-param to the servlet definition in the web.xml to make sure that it's not an issue having to do with the fact that it's a POST: servlet , . . init-param param-namereadonly/param-name param-valuefalse/param-value /init-param /servlet In the isapi_redirect.log I can see that the request is being passed to the ajp13 connector. The request is well formed. Everything is as it should be. The war file is configured as it was configured with Tomcat 6.0, in terms of its deployment descriptor with the above minor difference. Here is an excerpt from the isapi_redirect log with the request itself preceding what's shown here: 00 00 00 - ManagerRqst (Tail end of request XML) [Fri Feb 06 14:08:35.328 2015] [1128:4744] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1403): received from ajp13 pos=0 len=38 max=8192 [Fri Feb 06 14:08:35.343 2015] [1128:4744] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 04 01 93 00 09 46 6F 72 62 69 64 64 65 6E 00 00 - .Forbidden.. [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 001002 A0 01 00 0A 74 65 78 74 2F 70 6C 61 69 6E 00 - .text/plain. [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 0020A0 03 00 01 30 00 00 00 00 00 00 00 00 00 00 00 - 0... [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] ajp_unmarshal_response::jk_ajp_common.c (705): status = 403 [Fri Feb 06 14:08:35.375 2015] [1128:4744] [debug] ajp_unmarshal_response::jk_ajp_common.c (712): Number of headers is = 2 [Fri Feb 06 14:08:35.375 2015] [1128:4744] [debug] ajp_unmarshal_response::jk_ajp_common.c (768): Header[0] [Content-Type] = [text/plain] [Fri Feb 06 14:08:35.390 2015] [1128:4744] [debug] ajp_unmarshal_response::jk_ajp_common.c (768): Header[1] [Content-Length] = [0] [Fri Feb 06 14:08:35.406 2015] [1128:4744] [debug
Re: IIS 6.0 isapi_redirect 1.2.40 Tomcat 7.0 403 Forbidden
We are running 7.0.57. I have not tried to debug yet, but am willing to give it a try. I have gone to the apache site to download the source for that version but can only find 7.0.59. If you can tell me how to get the source for 7.0.57, I'll take it down, otherwise, I'll update the executable and use the source for 7.0.59. I will try removing the CORS filter from the deployment and see if that changes the behavior. I'll update this thread when I know the results. Thanks for your input. Richard On Feb 6, 2015, at 6:29 PM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2015-02-06 23:30 GMT+03:00 RICHARD DOUST rdo...@me.com mailto:rdo...@me.com: Hi, I've got an application that ran well with Tomcat 6.0, but is causing me problems on Tomcat 7.0. The front end is IIS (listening on port 80, passing requests to the isapi_redirect (1.2.40) filter which is configured to send some urls on to ajp13, then to port 8009 were Tomcat is listening), all running on Windows Server 2003. I know the isapi filter is working because I've configured mappings to the Tomcat docs and manager web apps and can get to them without any problems (via IIS). I have a servlet deployed to Tomcat that I'm POSTing to via an XMLHttpRequest in a browser. For the life of me, I cannot get it to respond to me with anything but a 403 and I can't figure out why. It is not a cross-domain request, so a CORS Filter (which is installed in support of a rewrite of the application which is underway) can't be having any effect. I have added an init-param to the servlet definition in the web.xml to make sure that it's not an issue having to do with the fact that it's a POST: servlet , . . init-param param-namereadonly/param-name param-valuefalse/param-value /init-param /servlet In the isapi_redirect.log I can see that the request is being passed to the ajp13 connector. The request is well formed. Everything is as it should be. The war file is configured as it was configured with Tomcat 6.0, in terms of its deployment descriptor with the above minor difference. Here is an excerpt from the isapi_redirect log with the request itself preceding what's shown here: 00 00 00 - ManagerRqst (Tail end of request XML) [Fri Feb 06 14:08:35.328 2015] [1128:4744] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1403): received from ajp13 pos=0 len=38 max=8192 [Fri Feb 06 14:08:35.343 2015] [1128:4744] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 04 01 93 00 09 46 6F 72 62 69 64 64 65 6E 00 00 - .Forbidden.. [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 001002 A0 01 00 0A 74 65 78 74 2F 70 6C 61 69 6E 00 - .text/plain. [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 0020A0 03 00 01 30 00 00 00 00 00 00 00 00 00 00 00 - 0... [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] ajp_unmarshal_response::jk_ajp_common.c (705): status = 403 [Fri Feb 06 14:08:35.375 2015] [1128:4744] [debug] ajp_unmarshal_response::jk_ajp_common.c (712): Number of headers is = 2 [Fri Feb 06 14:08:35.375 2015] [1128:4744] [debug] ajp_unmarshal_response::jk_ajp_common.c (768): Header[0] [Content-Type] = [text/plain] [Fri Feb 06 14:08:35.390 2015] [1128:4744] [debug] ajp_unmarshal_response::jk_ajp_common.c (768): Header[1] [Content-Length] = [0] [Fri Feb 06 14:08:35.406 2015] [1128:4744] [debug] start_response::jk_isapi_plugin.c (1025): Starting response for URI '/bbmwebapi_set15ul/api/xml' (protocol HTTP/1.1) [Fri Feb 06 14:08:35.406 2015] [1128:4744] [debug] start_response::jk_isapi_plugin.c (1134): Not using Keep-Alive [Fri Feb 06 14:08:35.421 2015] [1128:4744] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1403): received from ajp13 pos=0 len=2 max=8192 [Fri Feb 06 14:08:35.437 2015] [1128:4744] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 05 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - [Fri Feb 06 14:08:35.437 2015] [1128:4744] [debug] ajp_process_callback::jk_ajp_common.c (2054): AJP13 protocol: Reuse is OK [Fri Feb 06 14:08:35.453 2015] [1128:4744] [debug] HttpExtensionProc::jk_isapi_plugin.c (2317): service() returned OK [Fri Feb 06 14:08:35.468 2015] [1128:4744] [debug] ajp_reset_endpoint::jk_ajp_common.c (810): (ajp13) resetting endpoint with socket 2300 [Fri Feb 06 14:08:35.468 2015] [1128:4744] [debug] ajp_done::jk_ajp_common.c (3144): recycling connection pool for worker ajp13 and socket 2300 I have a breakpoint set in the servlet's doPost method. It gets hit if I use the rewrite which bypasses IIS and goes direct to port 8080 to hit Tomcat directly. It does not get hit when the request is sent via IIS. I have no insight into what or where the problem
Re: IIS 6.0 isapi_redirect 1.2.40 Tomcat 7.0 403 Forbidden
Ok. Found the archives for source. Now all I've got to do is figure out how to get Eclipse to look at the source when I'm running Tomcat remotely. I'll review that page you sent the link to. Richard On Feb 9, 2015, at 10:14 AM, RICHARD DOUST rdo...@me.com wrote: We are running 7.0.57. I have not tried to debug yet, but am willing to give it a try. I have gone to the apache site to download the source for that version but can only find 7.0.59. If you can tell me how to get the source for 7.0.57, I'll take it down, otherwise, I'll update the executable and use the source for 7.0.59. I will try removing the CORS filter from the deployment and see if that changes the behavior. I'll update this thread when I know the results. Thanks for your input. Richard On Feb 6, 2015, at 6:29 PM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2015-02-06 23:30 GMT+03:00 RICHARD DOUST rdo...@me.com mailto:rdo...@me.com: Hi, I've got an application that ran well with Tomcat 6.0, but is causing me problems on Tomcat 7.0. The front end is IIS (listening on port 80, passing requests to the isapi_redirect (1.2.40) filter which is configured to send some urls on to ajp13, then to port 8009 were Tomcat is listening), all running on Windows Server 2003. I know the isapi filter is working because I've configured mappings to the Tomcat docs and manager web apps and can get to them without any problems (via IIS). I have a servlet deployed to Tomcat that I'm POSTing to via an XMLHttpRequest in a browser. For the life of me, I cannot get it to respond to me with anything but a 403 and I can't figure out why. It is not a cross-domain request, so a CORS Filter (which is installed in support of a rewrite of the application which is underway) can't be having any effect. I have added an init-param to the servlet definition in the web.xml to make sure that it's not an issue having to do with the fact that it's a POST: servlet , . . init-param param-namereadonly/param-name param-valuefalse/param-value /init-param /servlet In the isapi_redirect.log I can see that the request is being passed to the ajp13 connector. The request is well formed. Everything is as it should be. The war file is configured as it was configured with Tomcat 6.0, in terms of its deployment descriptor with the above minor difference. Here is an excerpt from the isapi_redirect log with the request itself preceding what's shown here: 00 00 00 - ManagerRqst (Tail end of request XML) [Fri Feb 06 14:08:35.328 2015] [1128:4744] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1403): received from ajp13 pos=0 len=38 max=8192 [Fri Feb 06 14:08:35.343 2015] [1128:4744] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 04 01 93 00 09 46 6F 72 62 69 64 64 65 6E 00 00 - .Forbidden.. [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 001002 A0 01 00 0A 74 65 78 74 2F 70 6C 61 69 6E 00 - .text/plain. [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 0020A0 03 00 01 30 00 00 00 00 00 00 00 00 00 00 00 - 0... [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] ajp_unmarshal_response::jk_ajp_common.c (705): status = 403 [Fri Feb 06 14:08:35.375 2015] [1128:4744] [debug] ajp_unmarshal_response::jk_ajp_common.c (712): Number of headers is = 2 [Fri Feb 06 14:08:35.375 2015] [1128:4744] [debug] ajp_unmarshal_response::jk_ajp_common.c (768): Header[0] [Content-Type] = [text/plain] [Fri Feb 06 14:08:35.390 2015] [1128:4744] [debug] ajp_unmarshal_response::jk_ajp_common.c (768): Header[1] [Content-Length] = [0] [Fri Feb 06 14:08:35.406 2015] [1128:4744] [debug] start_response::jk_isapi_plugin.c (1025): Starting response for URI '/bbmwebapi_set15ul/api/xml' (protocol HTTP/1.1) [Fri Feb 06 14:08:35.406 2015] [1128:4744] [debug] start_response::jk_isapi_plugin.c (1134): Not using Keep-Alive [Fri Feb 06 14:08:35.421 2015] [1128:4744] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1403): received from ajp13 pos=0 len=2 max=8192 [Fri Feb 06 14:08:35.437 2015] [1128:4744] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 05 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - [Fri Feb 06 14:08:35.437 2015] [1128:4744] [debug] ajp_process_callback::jk_ajp_common.c (2054): AJP13 protocol: Reuse is OK [Fri Feb 06 14:08:35.453 2015] [1128:4744] [debug] HttpExtensionProc::jk_isapi_plugin.c (2317): service() returned OK [Fri Feb 06 14:08:35.468 2015] [1128:4744] [debug] ajp_reset_endpoint::jk_ajp_common.c (810): (ajp13) resetting endpoint with socket 2300 [Fri Feb 06 14:08:35.468 2015] [1128:4744] [debug] ajp_done::jk_ajp_common.c (3144): recycling connection pool for worker ajp13
Re: IIS 6.0 isapi_redirect 1.2.40 Tomcat 7.0 403 Forbidden
I have removed the CORS Filter from the web.xml, redeployed, and the behavior is the same. Still get the 403 Forbidden return code. The instructions on that web site say that I should attach source to the jar file for Tomcat. It's not clear to me how to do that. How do I select the jar file? It's running remotely. Thanks, Richard On Feb 9, 2015, at 10:47 AM, RICHARD DOUST rdo...@me.com wrote: Ok. Found the archives for source. Now all I've got to do is figure out how to get Eclipse to look at the source when I'm running Tomcat remotely. I'll review that page you sent the link to. Richard On Feb 9, 2015, at 10:14 AM, RICHARD DOUST rdo...@me.com wrote: We are running 7.0.57. I have not tried to debug yet, but am willing to give it a try. I have gone to the apache site to download the source for that version but can only find 7.0.59. If you can tell me how to get the source for 7.0.57, I'll take it down, otherwise, I'll update the executable and use the source for 7.0.59. I will try removing the CORS filter from the deployment and see if that changes the behavior. I'll update this thread when I know the results. Thanks for your input. Richard On Feb 6, 2015, at 6:29 PM, Konstantin Kolinko knst.koli...@gmail.com wrote: 2015-02-06 23:30 GMT+03:00 RICHARD DOUST rdo...@me.com mailto:rdo...@me.com: Hi, I've got an application that ran well with Tomcat 6.0, but is causing me problems on Tomcat 7.0. The front end is IIS (listening on port 80, passing requests to the isapi_redirect (1.2.40) filter which is configured to send some urls on to ajp13, then to port 8009 were Tomcat is listening), all running on Windows Server 2003. I know the isapi filter is working because I've configured mappings to the Tomcat docs and manager web apps and can get to them without any problems (via IIS). I have a servlet deployed to Tomcat that I'm POSTing to via an XMLHttpRequest in a browser. For the life of me, I cannot get it to respond to me with anything but a 403 and I can't figure out why. It is not a cross-domain request, so a CORS Filter (which is installed in support of a rewrite of the application which is underway) can't be having any effect. I have added an init-param to the servlet definition in the web.xml to make sure that it's not an issue having to do with the fact that it's a POST: servlet , . . init-param param-namereadonly/param-name param-valuefalse/param-value /init-param /servlet In the isapi_redirect.log I can see that the request is being passed to the ajp13 connector. The request is well formed. Everything is as it should be. The war file is configured as it was configured with Tomcat 6.0, in terms of its deployment descriptor with the above minor difference. Here is an excerpt from the isapi_redirect log with the request itself preceding what's shown here: 00 00 00 - ManagerRqst (Tail end of request XML) [Fri Feb 06 14:08:35.328 2015] [1128:4744] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1403): received from ajp13 pos=0 len=38 max=8192 [Fri Feb 06 14:08:35.343 2015] [1128:4744] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 04 01 93 00 09 46 6F 72 62 69 64 64 65 6E 00 00 - .Forbidden.. [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 001002 A0 01 00 0A 74 65 78 74 2F 70 6C 61 69 6E 00 - .text/plain. [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 0020A0 03 00 01 30 00 00 00 00 00 00 00 00 00 00 00 - 0... [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] ajp_unmarshal_response::jk_ajp_common.c (705): status = 403 [Fri Feb 06 14:08:35.375 2015] [1128:4744] [debug] ajp_unmarshal_response::jk_ajp_common.c (712): Number of headers is = 2 [Fri Feb 06 14:08:35.375 2015] [1128:4744] [debug] ajp_unmarshal_response::jk_ajp_common.c (768): Header[0] [Content-Type] = [text/plain] [Fri Feb 06 14:08:35.390 2015] [1128:4744] [debug] ajp_unmarshal_response::jk_ajp_common.c (768): Header[1] [Content-Length] = [0] [Fri Feb 06 14:08:35.406 2015] [1128:4744] [debug] start_response::jk_isapi_plugin.c (1025): Starting response for URI '/bbmwebapi_set15ul/api/xml' (protocol HTTP/1.1) [Fri Feb 06 14:08:35.406 2015] [1128:4744] [debug] start_response::jk_isapi_plugin.c (1134): Not using Keep-Alive [Fri Feb 06 14:08:35.421 2015] [1128:4744] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1403): received from ajp13 pos=0 len=2 max=8192 [Fri Feb 06 14:08:35.437 2015] [1128:4744] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 05 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - [Fri Feb 06 14:08:35.437 2015] [1128:4744] [debug] ajp_process_callback::jk_ajp_common.c (2054): AJP13 protocol: Reuse is OK
IIS 6.0 isapi_redirect 1.2.40 Tomcat 7.0 403 Forbidden
Hi, I've got an application that ran well with Tomcat 6.0, but is causing me problems on Tomcat 7.0. The front end is IIS (listening on port 80, passing requests to the isapi_redirect (1.2.40) filter which is configured to send some urls on to ajp13, then to port 8009 were Tomcat is listening), all running on Windows Server 2003. I know the isapi filter is working because I've configured mappings to the Tomcat docs and manager web apps and can get to them without any problems (via IIS). I have a servlet deployed to Tomcat that I'm POSTing to via an XMLHttpRequest in a browser. For the life of me, I cannot get it to respond to me with anything but a 403 and I can't figure out why. It is not a cross-domain request, so a CORS Filter (which is installed in support of a rewrite of the application which is underway) can't be having any effect. I have added an init-param to the servlet definition in the web.xml to make sure that it's not an issue having to do with the fact that it's a POST: servlet , . . init-param param-namereadonly/param-name param-valuefalse/param-value /init-param /servlet In the isapi_redirect.log I can see that the request is being passed to the ajp13 connector. The request is well formed. Everything is as it should be. The war file is configured as it was configured with Tomcat 6.0, in terms of its deployment descriptor with the above minor difference. Here is an excerpt from the isapi_redirect log with the request itself preceding what's shown here: 00 00 00 - ManagerRqst (Tail end of request XML) [Fri Feb 06 14:08:35.328 2015] [1128:4744] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1403): received from ajp13 pos=0 len=38 max=8192 [Fri Feb 06 14:08:35.343 2015] [1128:4744] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 04 01 93 00 09 46 6F 72 62 69 64 64 65 6E 00 00 - .Forbidden.. [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 001002 A0 01 00 0A 74 65 78 74 2F 70 6C 61 69 6E 00 - .text/plain. [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 0020A0 03 00 01 30 00 00 00 00 00 00 00 00 00 00 00 - 0... [Fri Feb 06 14:08:35.359 2015] [1128:4744] [debug] ajp_unmarshal_response::jk_ajp_common.c (705): status = 403 [Fri Feb 06 14:08:35.375 2015] [1128:4744] [debug] ajp_unmarshal_response::jk_ajp_common.c (712): Number of headers is = 2 [Fri Feb 06 14:08:35.375 2015] [1128:4744] [debug] ajp_unmarshal_response::jk_ajp_common.c (768): Header[0] [Content-Type] = [text/plain] [Fri Feb 06 14:08:35.390 2015] [1128:4744] [debug] ajp_unmarshal_response::jk_ajp_common.c (768): Header[1] [Content-Length] = [0] [Fri Feb 06 14:08:35.406 2015] [1128:4744] [debug] start_response::jk_isapi_plugin.c (1025): Starting response for URI '/bbmwebapi_set15ul/api/xml' (protocol HTTP/1.1) [Fri Feb 06 14:08:35.406 2015] [1128:4744] [debug] start_response::jk_isapi_plugin.c (1134): Not using Keep-Alive [Fri Feb 06 14:08:35.421 2015] [1128:4744] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1403): received from ajp13 pos=0 len=2 max=8192 [Fri Feb 06 14:08:35.437 2015] [1128:4744] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1403): 05 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - [Fri Feb 06 14:08:35.437 2015] [1128:4744] [debug] ajp_process_callback::jk_ajp_common.c (2054): AJP13 protocol: Reuse is OK [Fri Feb 06 14:08:35.453 2015] [1128:4744] [debug] HttpExtensionProc::jk_isapi_plugin.c (2317): service() returned OK [Fri Feb 06 14:08:35.468 2015] [1128:4744] [debug] ajp_reset_endpoint::jk_ajp_common.c (810): (ajp13) resetting endpoint with socket 2300 [Fri Feb 06 14:08:35.468 2015] [1128:4744] [debug] ajp_done::jk_ajp_common.c (3144): recycling connection pool for worker ajp13 and socket 2300 I have a breakpoint set in the servlet's doPost method. It gets hit if I use the rewrite which bypasses IIS and goes direct to port 8080 to hit Tomcat directly. It does not get hit when the request is sent via IIS. I have no insight into what or where the problem might be. Somewhere between ajp13 and Tomcat. The application works without a problem if I hit it from a browser running on the same computer as is running IIS and Tomcat. It doesn't work if I hit it from a client from outside. I've been banging my head against this for 2 days. Any help would be appreciated. Thanks.
Re: mod_jk for OS X PPC
Alex, Before I do this, I was just hoping for a quick confirmation from you that 'x86_64' is the correct value when it's a PowerPC architecture. Thanks, Richard On Oct 30, 2007, at 7:56 AM, Alex Fuller wrote: Richard Doust wrote: Hi. ... I upgraded my Mac's OS on Saturday to OS X 10.5 (Leopard). ... When I install the resultant mod_jk.so, Apache complains that it found mod_jk mach-o, but it is for the wrong architecture. If anyone has already done this, I'd love to hear from you. Hi Richard, The problem is that Apache 2 on Mac OS 10.5 Leopard runs in 64-bit mode on machines which are 64-bit capable (Mac Pros and MacBook Pros for sure). You have to compile mod_jk to run on a 64-bit architecture, which would be straightforward - except that for compatibility, Apple has left 32- bit mode on all machines as default unless an application specifically invokes 64-bit. Hence the configure command when building mod_jk detects a 32-bit architecture and has to be specifically instructed to use 64-bit. At least that's my best understanding of it, it may be inaccurate! Anyway - on to the solution (it worked for me anyway): Go into the 'native' folder of your mod_jk source and type the following: make clean ./configure CFLAGS='-arch x86_64' APXSLDFLAGS='-arch x86_64' --with-apxs=/usr/sbin/apxs make sudo make install (assuming you're not compiling as root, if you are, you won't need the sudo at the end) Hope that helps! Alex -- View this message in context: http://www.nabble.com/mod_jk-for-OS-X-PPC-tf4712890.html#a13486972 Sent from the Tomcat - User mailing list archive at Nabble.com. - 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: mod_jk for OS X PPC
Chris, I just read this on Apple's website: Mac OS X Tiger breaks the limitations of 32-bit computing and allows developers to create command-line applications, servers, and computation engines that can work with mind-blowing amounts of memory. Previous versions of Mac OS X have been able to take advantage of more than 4GB of system memory when running on a G5-equipped Mac, but each application was still subject to the 4GB limit imposed by a 32-bit address space. Tiger obliterates that restriction and allows applications to access a 64-bit address space when running on the PowerPC G5. Better yet, this support comes with no compromise in the ability to run current 32-bit applications. So, it seems that at least the 64-bit part of Alex's post could be on the right track? Thanks, Richard On Oct 30, 2007, at 9:22 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alex, Alex Fuller wrote: At least that's my best understanding of it, it may be inaccurate! Anyway - on to the solution (it worked for me anyway): Er, the OP is using 32-bit PowerPC (see the subject line), not 64-bit Intel chips. :( - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHJzAN9CaO5/Lv0PARAhgOAKCMjlXDOgVhrGGjNmRVGl610baQ4QCfRQMF vRb1qXd1t5wKE4TEYvWOBno= =HMhy -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] - 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: mod_jk for OS X PPC
Thanks Chuck. I thought that was the gist of the Apple text. Richard On Oct 30, 2007, at 9:53 AM, Caldarale, Charles R wrote: From: Christopher Schultz [mailto:[EMAIL PROTECTED] Subject: Re: mod_jk for OS X PPC unless Apple's loader now includes x64 emulation on 32-bit PPC hardware, which I find unlikely. Uhhh... G5 is a 64-bit processor... - 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: mod_jk for OS X PPC
Alex, QuadG5:native jboss$ ./configure CFLAGS='arch ppc64' APXSLDFLAGS='arch ppc64' --with-apxs=/usr/sbin/apxs . . . checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. I also tried ppc_64. I'm looking for the right value now. I looked in the configure.log file and did a man on gcc and came to the understanding that: Ah, okay, -arch ppc64 is a valid parameter to the compiler, so I did: ./configure cflags='-arch ppc64' APXSLDFLAGS='-arch ppc64' --with- apxs=/usr/sbin/apxs and that made some makefiles which I then used to compile mod_jk.so. Now I'm dealing with some apache configuration parameters in my old config that are apparently no longer valid (AddModule). I'll take it from here. Thanks an awful lot for the help! This also explains why the old mod_jk.so generated the same error. It's looking at 32-bit vs. 64-bit before it gets to the api. Richard On Oct 30, 2007, at 9:44 AM, Alex Fuller wrote: Alex Fuller wrote: it should come back with (for a G5): /usr/libexec/apache2/mod_alias.so (for architecture ppc64): Mach-O 64-bit bundle ppc64 Whereas I suspect on the one you're currently building you'd get: /usr/libexec/apache2/mod_alias.so (for architecture ppc7400): Mach-O bundle ppc Ha ha - obviously you would see a different path to the mod_jk.so file, I was using the Apple-built mod_alias.so as an example to check the reported architecture key :-/ Alex -- View this message in context: http://www.nabble.com/mod_jk-for-OS-X-PPC-tf4712890.html#a13488683 Sent from the Tomcat - User mailing list archive at Nabble.com. - 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: mod_jk for OS X PPC
Dale, So what are you saying? It's working with that compile. Should I build it with some other set of options? Richard On Oct 30, 2007, at 12:28 PM, BuildSmart wrote: On Oct 30, 2007, at 10:37:13, Richard Doust wrote: Alex, QuadG5:native jboss$ ./configure CFLAGS='arch ppc64' APXSLDFLAGS='arch ppc64' --with-apxs=/usr/sbin/apxs . . . checking for gcc... gcc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. I also tried ppc_64. I'm looking for the right value now. I looked in the configure.log file and did a man on gcc and came to the understanding that: Ah, okay, -arch ppc64 is a valid parameter to the compiler, so I did: ./configure cflags='-arch ppc64' APXSLDFLAGS='-arch ppc64' --with- apxs=/usr/sbin/apxs and that made some makefiles which I then used to compile mod_jk.so. Now I'm dealing with some apache configuration parameters in my old config that are apparently no longer valid (AddModule). I'll take it from here. Thanks an awful lot for the help! This also explains why the old mod_jk.so generated the same error. It's looking at 32-bit vs. 64-bit before it gets to the api. Not likely, that isn't how it works, apache isn't compiled for ppc64 only and it's not recommended to generate a ppc64 only module unless you strip all of the 32bit architecture from all of the binaries and force it to run in 64bit only which wont happen if you examine some of the libraries in /usr/lib. Richard On Oct 30, 2007, at 9:44 AM, Alex Fuller wrote: Alex Fuller wrote: it should come back with (for a G5): /usr/libexec/apache2/mod_alias.so (for architecture ppc64): Mach- O 64-bit bundle ppc64 Whereas I suspect on the one you're currently building you'd get: /usr/libexec/apache2/mod_alias.so (for architecture ppc7400): Mach-O bundle ppc Ha ha - obviously you would see a different path to the mod_jk.so file, I was using the Apple-built mod_alias.so as an example to check the reported architecture key :-/ Alex -- -- Dale - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk for OS X PPC
Hi. I'm a developer of a JBoss/Tomcat app. I work on a Mac. I upgraded my Mac's OS on Saturday to OS X 10.5 (Leopard). Prior to the upgrade I was using the version of Apache that came with 10.4, which I think was 1.3. Apple is shipping 2.2.6 with 10.5. They don't include the mod_jk module built for the OS with the non-server version of the OS. (I guess they might with the server version, I'm not sure.) Anyway, I need mod_jk in order for Apache to talk to Tomcat, so I went to the Tomcat Connectors pages and found that mod_jk is only available in an x86 version as a binary. So I downloaded the source, installed the XCode tools so that I could try to compile it. I'm unable to find apxs2 on my hard drive, but I have a apxs file in my /usr/sbin directory, so I thought I would try to build using: ./configure --with-apxs=/usr/sbin/apxs When I install the resultant mod_jk.so, Apache complains that it found mod_jk mach-o, but it is for the wrong architecture. If anyone has already done this, I'd love to hear from you. Thank you, Richard - 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: mod_jk for OS X PPC
Rainer, Thanks for looking at my question. In case that image doesn't get through, (and to make this text searchable) it says: Cannot load /usr/libexec/apache2/mod_jk.so into server: dlopen(/usr/ libexec/apache2/mod_jk.so, 10): no suitable image found. Did find /usr/ libexec/apache2/mod_jk.so: mach-o, but wrong architecture. That's what I get. I tried using the mod_jk.so that I had working with the 1.3 version of Apache just for hahas and get the same error, so I'm not sure what's going on. I was hoping some kind soul might have a working version of mod_jk.so for the PowerPC architecture. Any light you can help shed on the subject would be appreciated. Oh, the apxs file in /usr/sbin has a timestamp that leads me to believe it came with the new version of Apache. Thanks again. Richard On Oct 29, 2007, at 4:59 PM, Rainer Jung wrote: Sorry, I've no direct solution. If /usr/sbin/apxs belongs to your Apache 2.2.6, the way you are doing it seems right. What exactly is the error text, that you get from Apache during startup? Regards, Rainer Richard Doust wrote: Hi. I'm a developer of a JBoss/Tomcat app. I work on a Mac. I upgraded my Mac's OS on Saturday to OS X 10.5 (Leopard). Prior to the upgrade I was using the version of Apache that came with 10.4, which I think was 1.3. Apple is shipping 2.2.6 with 10.5. They don't include the mod_jk module built for the OS with the non- server version of the OS. (I guess they might with the server version, I'm not sure.) Anyway, I need mod_jk in order for Apache to talk to Tomcat, so I went to the Tomcat Connectors pages and found that mod_jk is only available in an x86 version as a binary. So I downloaded the source, installed the XCode tools so that I could try to compile it. I'm unable to find apxs2 on my hard drive, but I have a apxs file in my /usr/sbin directory, so I thought I would try to build using: ./configure --with-apxs=/usr/sbin/apxs When I install the resultant mod_jk.so, Apache complains that it found mod_jk mach-o, but it is for the wrong architecture. If anyone has already done this, I'd love to hear from you. Thank you, Richard - 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: mod_jk for OS X PPC
uname -a : Darwin QuadG5.local 9.0.0 Darwin Kernel Version 9.0.0: Tue Oct 9 21:37:58 PDT 2007; root:xnu-1228~1/RELEASE_PPC Power Macintosh file /usr/libexec/apache2/mod_jk.so : /usr/libexec/apache2/mod_jk.so: Mach-O bundle ppc cc -v: Using built-in specs. Target: powerpc-apple-darwin9 Configured with: /var/tmp/gcc/gcc-5465~16/src/configure --disable- checking -enable-werror --prefix=/usr --mandir=/share/man --enable- languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/ $/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/ lib --build=i686-apple-darwin9 --program-prefix= --host=powerpc-apple- darwin9 --target=powerpc-apple-darwin9 Thread model: posix gcc version 4.0.1 (Apple Inc. build 5465) Confusing, right? Looks good I'd say (with my total lack of knowledge). Thanks again, Richard On Oct 29, 2007, at 5:14 PM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Richard, Richard Doust wrote: In case that image doesn't get through, (and to make this text searchable) it says: Thanks for posting the text: the image did not come through; mailing lists rarely accept non-text attachments (and sometimes not even then). Cannot load /usr/libexec/apache2/mod_jk.so into server: dlopen(/usr/libexec/apache2/mod_jk.so, 10): no suitable image found. Did find /usr/libexec/apache2/mod_jk.so: mach-o, but wrong architecture. Can you run these on your system, please? $ uname -a $ file /path/to/mod_jk.so ?? That should give us some technical details that should help. Also, the version of your compiler would be helpful, too (usually 'cc -v' or something similar). That's what I get. I tried using the mod_jk.so that I had working with the 1.3 version of Apache just for hahas and get the same error, so I'm not sure what's going on. That's a little odd... it seems that Apache is complaining about the architecture, instead of the httpd API version mismatch. The 1.3 binary will certainly not work. I was hoping some kind soul might have a working version of mod_jk.so for the PowerPC architecture. Any light you can help shed on the subject would be appreciated. Oh, the apxs file in /usr/sbin has a timestamp that leads me to believe it came with the new version of Apache. Good to know. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHJk0o9CaO5/Lv0PARAnO/AKCUn8Pu2QDquIA14+1qZU/s5jHQNACdH96F SzaQwwi9GMsABmrZC5henx4= =wGkY -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] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Client request times out
I have a problem with a servlet running longer than 5 minutes. The client's browser is delivered an error response from somewhere on the server in an Apache/JBoss/Tomcat stack at the 5 minute mark. Does anyone know what properties/attributes in what configuration files might allow the servlet to run for longer than 5 minutes? I have tried: TimeOut (in apache config) disableUploadTimeout (in Connector attribute settings, server.xml for Tomcat 5.5) socket_timeout (in workers.properties) None seem to have the desired effect. Any help would be appreciated. Thanks. - 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: Client request times out
Well, it's a complicated report used by a purchaser to generate a purchase order based on need for a product dependent on customer demand. It's accessing a LOT of data. That's not to say that I can't speed it up with indexes, or break it up into a request that's passed off to a server process that generates data that it then writes to the database for later retrieval by the client. But it wasn't designed that way and such a change would be substantial. It has worked for a few years, and what I'm looking to do right now is get around the 5 min. barrier before spending more time looking at the underlying problem and ways to solve it. Thanks for your suggestion. On Dec 8, 2006, at 10:42 AM, Robert Harper wrote: I think the bigger question is why does it take that long to run? I can't think of too many people that are willing to wait that long for information. Personally I'd give you 30 seconds and then I'll never use something that slow again. If you are accessing data, try adding indexes or a data redesign to speed things up. A simple index based on key data can speed up searches exponentially. Just a thought. Most of my problems have been my problems not something Tomcat was doing wrong. Robert S. Harper Information Access Technology, Inc. -Original Message- From: Richard Doust [mailto:[EMAIL PROTECTED] Sent: Friday, December 08, 2006 8:23 AM To: Tomcat Users List Subject: Client request times out I have a problem with a servlet running longer than 5 minutes. The client's browser is delivered an error response from somewhere on the server in an Apache/JBoss/Tomcat stack at the 5 minute mark. Does anyone know what properties/attributes in what configuration files might allow the servlet to run for longer than 5 minutes? I have tried: TimeOut (in apache config) disableUploadTimeout (in Connector attribute settings, server.xml for Tomcat 5.5) socket_timeout (in workers.properties) None seem to have the desired effect. Any help would be appreciated. Thanks. - 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]
Timeout on request to response
I'm having an issue using Apache with mod_jk (ajp13) to Tomcat under JBoss having to do with a request that is taking longer than one of those pieces thinks is reasonable to produce a result for the client. I have found an attribute of the Connector called connectionTimeout specified in service.xml in the jbossweb-tomcat55.sar directory, along with another value called disableUploadTimeout. It seems to me that between the two of these parameters, given their descriptions, I should be able to get around the problem, but I've changed their values and can't seem to get to a point where the changes I make have any impact on the problem. Ordinarily, I wouldn't have a request that takes longer than 5 minutes to execute, but this one is producing a very valuable report and it just has to take that long. Somebody is sending an error back to the client after 5 minutes have expired. It's pretty clear that the server is continuing to chug away at producing the report, but by the time it's done, no one is listening for it any more. Does anyone have any insight as to how to make the timeout in this case longer than 5 minutes? Is there some other parameter in Apache that's overriding the one I've found in the Connector? The documentation for disableUploadTimeout says: This flag allows the servlet container to use a different, longer connection timeout while a servlet is being executed, which in the end allows either the servlet a longer amount of time to complete its execution, or a longer timeout during data upload. If not specified, this attribute is set to false. But it doesn't say where the longer connection timeout is specified. The fact that it says it makes it possible for the servlet container to use a different, longer connection timeout, makes me think it means a longer connection timeout than the one specified by the attribute called connectionTimeout, but it doesn't say that specifically. Help please. Thanks.
Tomcat under JBoss
I need help getting Tomcat to process JSTL tags when an ear is deployed to JBoss 4.0.4 with Tomcat 5.5.17. The same application that works with JBoss 4.0.1 and Jetty 5.1.4 does not work with JBoss 4.0.4 with Tomcat 5.5.17. JSTL tags are sent to the client's browser unprocessed. Tomcat does not seem to be honoring the contract for the servlet container. I am packaging the standard.jar and jstl.jar files in my WEB-INF/lib directory. I know they're being found, because if I remove them I get Class Not Found exceptions for the tag support classes. However, maybe there's some underlying support file that's available with Jetty that isn't with Tomcat that I also need in my WEB-INF/lib that I don't have there. I don't know. I'm pulling my hair out. I've spent 24 hours trying everything I can think of. Nothing works. No error messages or other useful information seems to be available. Can anyone help me with this please. - 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: Tomcat under JBoss
Does not work means that the tags don't get processed. There are no error logs. The tags show up in the html page that's delivered to the client. On Jul 5, 2006, at 10:38 AM, Pid wrote: error logs? config files? define does not work with some more precision and we might be able to help... Richard Doust wrote: I need help getting Tomcat to process JSTL tags when an ear is deployed to JBoss 4.0.4 with Tomcat 5.5.17. The same application that works with JBoss 4.0.1 and Jetty 5.1.4 does not work with JBoss 4.0.4 with Tomcat 5.5.17. JSTL tags are sent to the client's browser unprocessed. Tomcat does not seem to be honoring the contract for the servlet container. I am packaging the standard.jar and jstl.jar files in my WEB-INF/lib directory. I know they're being found, because if I remove them I get Class Not Found exceptions for the tag support classes. However, maybe there's some underlying support file that's available with Jetty that isn't with Tomcat that I also need in my WEB-INF/lib that I don't have there. I don't know. I'm pulling my hair out. I've spent 24 hours trying everything I can think of. Nothing works. No error messages or other useful information seems to be available. Can anyone help me with this please. - 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: Tomcat under JBoss
Config files are straight out of the box as Tomcat is deployed under JBoss 4.0.4. The web.xml file for the application has the obligatory: jsp-config taglib taglib-urihttp://java.sun.com/jsp/jstl/core/taglib-uri /taglib taglib taglib-urihttp://java.sun.com/jsp/jstl/fmt/taglib-uri /taglib /jsp-config Thanks for any help. If you need more information, please ask. I had thought that someone must know of some manner in which Tomcat's support for JSTL differs from Jetty's. On Jul 5, 2006, at 10:38 AM, Pid wrote: error logs? config files? define does not work with some more precision and we might be able to help... Richard Doust wrote: I need help getting Tomcat to process JSTL tags when an ear is deployed to JBoss 4.0.4 with Tomcat 5.5.17. The same application that works with JBoss 4.0.1 and Jetty 5.1.4 does not work with JBoss 4.0.4 with Tomcat 5.5.17. JSTL tags are sent to the client's browser unprocessed. Tomcat does not seem to be honoring the contract for the servlet container. I am packaging the standard.jar and jstl.jar files in my WEB-INF/lib directory. I know they're being found, because if I remove them I get Class Not Found exceptions for the tag support classes. However, maybe there's some underlying support file that's available with Jetty that isn't with Tomcat that I also need in my WEB-INF/lib that I don't have there. I don't know. I'm pulling my hair out. I've spent 24 hours trying everything I can think of. Nothing works. No error messages or other useful information seems to be available. Can anyone help me with this please. - 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: Tomcat under JBoss
Yes. Definitely. As I said, the code works in JBoss 4.0.1 with Jetty 5.1.4. I'm thinking that there's some kind of conflict with a jar file somewhere. Some class loader issue at run-time. It would be nice if some of the software would let me know about it. I'm just trying to check all of the jars that I use and make sure there are no conflicts with jars deployed by JBoss and Tomcat in this newer version. On Jul 5, 2006, at 12:10 PM, Pid wrote: And the taglibs are definitely being imported on the page in question? Richard Doust wrote: Config files are straight out of the box as Tomcat is deployed under JBoss 4.0.4. The web.xml file for the application has the obligatory: jsp-config taglib taglib-urihttp://java.sun.com/jsp/jstl/core/taglib-uri /taglib taglib taglib-urihttp://java.sun.com/jsp/jstl/fmt/taglib-uri /taglib /jsp-config Thanks for any help. If you need more information, please ask. I had thought that someone must know of some manner in which Tomcat's support for JSTL differs from Jetty's. On Jul 5, 2006, at 10:38 AM, Pid wrote: error logs? config files? define does not work with some more precision and we might be able to help... Richard Doust wrote: I need help getting Tomcat to process JSTL tags when an ear is deployed to JBoss 4.0.4 with Tomcat 5.5.17. The same application that works with JBoss 4.0.1 and Jetty 5.1.4 does not work with JBoss 4.0.4 with Tomcat 5.5.17. JSTL tags are sent to the client's browser unprocessed. Tomcat does not seem to be honoring the contract for the servlet container. I am packaging the standard.jar and jstl.jar files in my WEB-INF/lib directory. I know they're being found, because if I remove them I get Class Not Found exceptions for the tag support classes. However, maybe there's some underlying support file that's available with Jetty that isn't with Tomcat that I also need in my WEB-INF/ lib that I don't have there. I don't know. I'm pulling my hair out. I've spent 24 hours trying everything I can think of. Nothing works. No error messages or other useful information seems to be available. Can anyone help me with this please. --- -- 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] - 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: Tomcat under JBoss
2.4 On Jul 5, 2006, at 12:34 PM, Mark Sutton wrote: What version of the servlet API are you specifying in the web.xml of the application? Mark On 05/07/06, Pid [EMAIL PROTECTED] wrote: Can you execute an arbitrary JSP scriptlet in the page, or does that get ignored too? Pid wrote: And the taglibs are definitely being imported on the page in question? Richard Doust wrote: Config files are straight out of the box as Tomcat is deployed under JBoss 4.0.4. The web.xml file for the application has the obligatory: jsp-config taglib taglib-urihttp://java.sun.com/jsp/jstl/core/ taglib-uri /taglib taglib taglib-urihttp://java.sun.com/jsp/jstl/fmt/taglib- uri /taglib /jsp-config Thanks for any help. If you need more information, please ask. I had thought that someone must know of some manner in which Tomcat's support for JSTL differs from Jetty's. On Jul 5, 2006, at 10:38 AM, Pid wrote: error logs? config files? define does not work with some more precision and we might be able to help... Richard Doust wrote: I need help getting Tomcat to process JSTL tags when an ear is deployed to JBoss 4.0.4 with Tomcat 5.5.17. The same application that works with JBoss 4.0.1 and Jetty 5.1.4 does not work with JBoss 4.0.4 with Tomcat 5.5.17. JSTL tags are sent to the client's browser unprocessed. Tomcat does not seem to be honoring the contract for the servlet container. I am packaging the standard.jar and jstl.jar files in my WEB-INF/lib directory. I know they're being found, because if I remove them I get Class Not Found exceptions for the tag support classes. However, maybe there's some underlying support file that's available with Jetty that isn't with Tomcat that I also need in my WEB- INF/lib that I don't have there. I don't know. I'm pulling my hair out. I've spent 24 hours trying everything I can think of. Nothing works. No error messages or other useful information seems to be available. Can anyone help me with this please. - 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] - 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: Tomcat under JBoss
I'm going to finish what I'm doing with jars and then find out the answer to this question. On Jul 5, 2006, at 12:23 PM, Pid wrote: Can you execute an arbitrary JSP scriptlet in the page, or does that get ignored too? Pid wrote: And the taglibs are definitely being imported on the page in question? Richard Doust wrote: Config files are straight out of the box as Tomcat is deployed under JBoss 4.0.4. The web.xml file for the application has the obligatory: jsp-config taglib taglib-urihttp://java.sun.com/jsp/jstl/core/taglib- uri /taglib taglib taglib-urihttp://java.sun.com/jsp/jstl/fmt/taglib-uri /taglib /jsp-config Thanks for any help. If you need more information, please ask. I had thought that someone must know of some manner in which Tomcat's support for JSTL differs from Jetty's. On Jul 5, 2006, at 10:38 AM, Pid wrote: error logs? config files? define does not work with some more precision and we might be able to help... Richard Doust wrote: I need help getting Tomcat to process JSTL tags when an ear is deployed to JBoss 4.0.4 with Tomcat 5.5.17. The same application that works with JBoss 4.0.1 and Jetty 5.1.4 does not work with JBoss 4.0.4 with Tomcat 5.5.17. JSTL tags are sent to the client's browser unprocessed. Tomcat does not seem to be honoring the contract for the servlet container. I am packaging the standard.jar and jstl.jar files in my WEB-INF/lib directory. I know they're being found, because if I remove them I get Class Not Found exceptions for the tag support classes. However, maybe there's some underlying support file that's available with Jetty that isn't with Tomcat that I also need in my WEB- INF/lib that I don't have there. I don't know. I'm pulling my hair out. I've spent 24 hours trying everything I can think of. Nothing works. No error messages or other useful information seems to be available. Can anyone help me with this please. -- --- 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] - 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: Tomcat under JBoss
I have some good news. I'm deploying an ear that contains a war that has this problem. I have another war that depends on some of the code that's in the ear. I thought I'd wait until I got the ear working before trying the war. I decided on a lark to see what happens with the war. It works fine. All of the JSTL tags are handled as expected. Now I guess I just have to figure out what's wrong with my ear. On Jul 5, 2006, at 12:23 PM, Pid wrote: Can you execute an arbitrary JSP scriptlet in the page, or does that get ignored too? Pid wrote: And the taglibs are definitely being imported on the page in question? Richard Doust wrote: Config files are straight out of the box as Tomcat is deployed under JBoss 4.0.4. The web.xml file for the application has the obligatory: jsp-config taglib taglib-urihttp://java.sun.com/jsp/jstl/core/taglib- uri /taglib taglib taglib-urihttp://java.sun.com/jsp/jstl/fmt/taglib-uri /taglib /jsp-config Thanks for any help. If you need more information, please ask. I had thought that someone must know of some manner in which Tomcat's support for JSTL differs from Jetty's. On Jul 5, 2006, at 10:38 AM, Pid wrote: error logs? config files? define does not work with some more precision and we might be able to help... Richard Doust wrote: I need help getting Tomcat to process JSTL tags when an ear is deployed to JBoss 4.0.4 with Tomcat 5.5.17. The same application that works with JBoss 4.0.1 and Jetty 5.1.4 does not work with JBoss 4.0.4 with Tomcat 5.5.17. JSTL tags are sent to the client's browser unprocessed. Tomcat does not seem to be honoring the contract for the servlet container. I am packaging the standard.jar and jstl.jar files in my WEB-INF/lib directory. I know they're being found, because if I remove them I get Class Not Found exceptions for the tag support classes. However, maybe there's some underlying support file that's available with Jetty that isn't with Tomcat that I also need in my WEB- INF/lib that I don't have there. I don't know. I'm pulling my hair out. I've spent 24 hours trying everything I can think of. Nothing works. No error messages or other useful information seems to be available. Can anyone help me with this please. -- --- 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] - 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: Tomcat under JBoss
More good news. It appears that it's really only one page that has this problem!! (Or one that I've found so far.) I'm amazed that I didn't see this at first. Now I have to figure out what's wrong with that page. On Jul 5, 2006, at 12:23 PM, Pid wrote: Can you execute an arbitrary JSP scriptlet in the page, or does that get ignored too? Pid wrote: And the taglibs are definitely being imported on the page in question? Richard Doust wrote: Config files are straight out of the box as Tomcat is deployed under JBoss 4.0.4. The web.xml file for the application has the obligatory: jsp-config taglib taglib-urihttp://java.sun.com/jsp/jstl/core/taglib- uri /taglib taglib taglib-urihttp://java.sun.com/jsp/jstl/fmt/taglib-uri /taglib /jsp-config Thanks for any help. If you need more information, please ask. I had thought that someone must know of some manner in which Tomcat's support for JSTL differs from Jetty's. On Jul 5, 2006, at 10:38 AM, Pid wrote: error logs? config files? define does not work with some more precision and we might be able to help... Richard Doust wrote: I need help getting Tomcat to process JSTL tags when an ear is deployed to JBoss 4.0.4 with Tomcat 5.5.17. The same application that works with JBoss 4.0.1 and Jetty 5.1.4 does not work with JBoss 4.0.4 with Tomcat 5.5.17. JSTL tags are sent to the client's browser unprocessed. Tomcat does not seem to be honoring the contract for the servlet container. I am packaging the standard.jar and jstl.jar files in my WEB-INF/lib directory. I know they're being found, because if I remove them I get Class Not Found exceptions for the tag support classes. However, maybe there's some underlying support file that's available with Jetty that isn't with Tomcat that I also need in my WEB- INF/lib that I don't have there. I don't know. I'm pulling my hair out. I've spent 24 hours trying everything I can think of. Nothing works. No error messages or other useful information seems to be available. Can anyone help me with this please. -- --- 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] - 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: Tomcat under JBoss
It looks like the problem has to do with the extension of the jsp source file. It doesn't have the jsp extension, it's got a jspf extension. I have about 4 of them, and they all have the same problem. Now I just have to figure out how to tell Tomcat to treat a .jspf file as a .jsp file. Shouldn't be too tough. On Jul 5, 2006, at 12:23 PM, Pid wrote: Can you execute an arbitrary JSP scriptlet in the page, or does that get ignored too? Pid wrote: And the taglibs are definitely being imported on the page in question? Richard Doust wrote: Config files are straight out of the box as Tomcat is deployed under JBoss 4.0.4. The web.xml file for the application has the obligatory: jsp-config taglib taglib-urihttp://java.sun.com/jsp/jstl/core/taglib- uri /taglib taglib taglib-urihttp://java.sun.com/jsp/jstl/fmt/taglib-uri /taglib /jsp-config Thanks for any help. If you need more information, please ask. I had thought that someone must know of some manner in which Tomcat's support for JSTL differs from Jetty's. On Jul 5, 2006, at 10:38 AM, Pid wrote: error logs? config files? define does not work with some more precision and we might be able to help... Richard Doust wrote: I need help getting Tomcat to process JSTL tags when an ear is deployed to JBoss 4.0.4 with Tomcat 5.5.17. The same application that works with JBoss 4.0.1 and Jetty 5.1.4 does not work with JBoss 4.0.4 with Tomcat 5.5.17. JSTL tags are sent to the client's browser unprocessed. Tomcat does not seem to be honoring the contract for the servlet container. I am packaging the standard.jar and jstl.jar files in my WEB-INF/lib directory. I know they're being found, because if I remove them I get Class Not Found exceptions for the tag support classes. However, maybe there's some underlying support file that's available with Jetty that isn't with Tomcat that I also need in my WEB- INF/lib that I don't have there. I don't know. I'm pulling my hair out. I've spent 24 hours trying everything I can think of. Nothing works. No error messages or other useful information seems to be available. Can anyone help me with this please. -- --- 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] - 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]
JSTL tags not processed
I would appreciate it if anyone can give me a lead on how to resolve my problem. I am trying to switch from Jetty 5.1.4 to Tomcat 5.5.17 as the servlet container within JBoss. No changes to code or configuration files, the JSP pages do not produce the expected output. The JSTL tags are not being processed. They are producing their literal content as though they are being completely ignored. I would very much appreciate any help as I am supposed to take this live by Friday. Thanks in advance. Rich - 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: Apache Tomcat - Apache Tomcat -- Mailing Lists
I've just deployed an application that worked like a charm on JBoss 4.0.1 with Jetty to JBoss 4.0.4 with Tomcat 5.5.17. I'm working through some problems. The one that's got me scratching my head now is that none of my jstl tags produce anything other than themselves, exactly as originally written. No errors, just tag content in the middle of the page instead of the normal results of the processing of the tags. I thought maybe I had too many copies of jstl.jar in the classpath at runtime, so I removed the one I had from my WEB-INF/lib directory and tried it that way because I saw that Tomcat has one under its jbossweb-tomcat55.sar/jsf-libs directory. That produced an error that http://java.sun.com/jsp/jstl/core couldn't be found at run-time. Can anyone help me figure out why this is happening?
