response.sendError() problem on Tomcat 5.5.9
In MyHTTPServlet.service() (extends HttpServlet.service()), I catch an
exception and try to send back an error, like this:
catch(final MissingResourceException missingResourceException)
{
response.sendError(404);//send back a 500 Internal Server Error
}
This code gets called, and I've logged that Java makes it to the
response.sendError() but not past it. Firefox WebDeveloper 0.9.3 tells
me I'm getting back a 200 OK rather than a 404.
Is there a Tomcat problem, or am I missing something really obvious?
Cheers,
Garret
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to disable directory listing
You can't do it in your app's web.xml---unless you install another servlet (which can be the Tomcat default servlet) mapped to root in your own web.xml. But then you have to cart around all the Tomcat servlet jars in your webapp, because the one that is really the default was loaded by another classloader. Garret Phillip Qin wrote: Do it in your app's web.xml -Original Message- From: Lee Chin Khiong [mailto:[EMAIL PROTECTED] Sent: November 24, 2004 1:29 AM To: 'Tomcat Users List' Subject: RE: How to disable directory listing Is there any better way to configure Tomcat 5 to no Directory listing just like IIS ? -Original Message- From: Quinton Delpeche [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 24, 2004 2:19 PM To: tomcat-user@jakarta.apache.org Subject: Re: How to disable directory listing On Wednesday 24 November 2004 08:09, Lee Chin Khiong wrote: How to disable directory listing under Tomcat 5 ? I use a blank index.html file and put it in all the directories that I don't want to have listed. :) Q - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache, Tomcat, WebDAV, and Web Folders... Oh, my!
Garret Wilson wrote: Apparently the whole PROPFIND / and Apache proxy things were red herrings. The central issue seems to be that MS Web Folders doesn't know what to do with a 401 Unauthorized response to an OPTIONS request on the WebDAV root folder (when it finally gets around to checking). I reconfigured my WebDAV servlet to bypass authorization for OPTIONS requests (as a test), and once MS Web Folders requested OPTIONS and my servlet sent them back, it issued a PROPFIND and correctly popped up the authorization dialog. (But there are more problems---see below.) This seems to be related: http://support.microsoft.com/?kbid=831805 So... if I put workarounds in my WebDAV servlet to work with MS Web Folders from XP SP2, will it still fail with XP SP1, because SP1 won't even send an OPTIONS except to the root? http://greenbytes.de/tech/webdav/webdav-redirector-list.html I wrote *my* WebDAV servlet reading from the RFCs. What in the world did MS coders use when they wrote MS Web Folders? Surely not the actual WebDAV specification... This is all just plain ridiculous. Garret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache, Tomcat, WebDAV, and Web Folders... Oh, my!
While I'm tracking down the domain authentication problem, here's another problem to be aware of. IE 5, Office 2000, and Office XP only support WebDAV BASIC authentication, but not DIGEST: http://support.microsoft.com/default.aspx?scid=kb;en-us;321932 You upgrade to Windows XP, and by default it only supports WebDAV DIGEST authentication, but not BASIC: http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2netwk.mspx#EFAA Sheer brilliance. I'm guessing this has nothing to do with my authentication problem, because XP Web Folders handled DIGEST authentication just fine on localhost---but Dorothy, we're not on localhost anymore... Garret Garret Wilson wrote: Here's new news: Apparently the whole PROPFIND / and Apache proxy things were red herrings. The central issue seems to be that MS Web Folders doesn't know what to do with a 401 Unauthorized response to an OPTIONS request on the WebDAV root folder (when it finally gets around to checking). I reconfigured my WebDAV servlet to bypass authorization for OPTIONS requests (as a test), and once MS Web Folders requested OPTIONS and my servlet sent them back, it issued a PROPFIND and correctly popped up the authorization dialog. (But there are more problems---see below.) Requiring OPTIONS to forsake authorization is a security risk. If I can't return 401 Unauthorized for OPTIONS, then a client can issue OPTIONS at will and find out which resources exist and which are collections. But let's say that I open up OPTIONS for all my realms, just to make MS Web Folders work. I'm still not out of the clear. Once MS Web Folders tries to do a PROPFIND and I enter my name and password, it doesn't work. In fact, MS Web Folder doesn't even send back my credentials! It apparently sends an identical PROPFIND request as the one that just failed, and then shows another dialog box with "user" changed to "www.example.com\user1". (The servers is a virtual host on Apache, proxied to Tomcat.) Now, this I've seen before, with Apache mod_dav on a virtual host. I never found the source of the problem. (I have Apache mod_dav working fine with non-virtual-host SSL domains.) Now I've opened up a security risk, and there's still another problem to track down. Thanks for your pointers, and for being a wonderful audience. ;) Garret Garret Wilson wrote: Yeah, that's what I *assume*, anyway. But Ethereal doesn't work on localhost, so I can only assume. There are these possibilities: * Tomcat returns something other than 501 Not Implemented when configured on localhost. (Not likely.) * MS Web Folders does different checks when accessing the Internet-at-large than when accessing localhost. (Likely? I don't know what to expect with MS Web Folders anymore.) I'm guessing the latter is happening, especially as two MS user agents get into the act: "Microsoft-WebDAV-MiniRedir/5.1.2600" and "Microsoft Data Access Internet Publishing Provider Protocol Discovery" And here's more news: I created a new DefaultServlet mapped to "/" that for PROPFIND simply returns 403 Forbidden. Something different happens. First, "Microsoft-WebDAV-MiniRedir/5.1.2600" does a PROPFIND on /webapp (which gets redirected to /webapp/). MyDefaultServlet returns 403 Forbidden. Fine. Can you guess what "Microsoft-WebDAV-MiniRedir/5.1.2600" does? "Microsoft-WebDAV-MiniRedir/5.1.2600" then tries to do another PROPFIND on /webapp! And another---for a total of five times! (It's forbidden, you idiot---and /webapp is none of your business anyway; you're supposed to be accessing /webapp/webdav/! Arggg!!!) Then "Microsoft Data Access Internet Publishing Provider Protocol Discovery" comes along and does its little OPTIONS / (200 OK) OPTIONS /webapp/webdav (401 Unauthorized) dance for three times, and then goes into the FrontPage mumbo-jumbo. What is left to do---issue a 401 Unauthorized on PROPFIND /webapp ? Issue a 401 Unauthorized on OPTIONS / ? Rewrite the operating system? (Yeah, the latter is probably what I'll have to do to fix all this mess.) (Grumble grumble grumble...) Any suggestions on what to do next? Garret Varley, Roger wrote: About the only thing left to try is to allow the PROPFIND on /webapp/ . So here's the Tomcat question---how can I allow a PROPFIND on /webapp/ and return, for example, a 403 forbidden, rather than a 501 Not Implemented? Do I have to override org.apache.catalina.servlets.DefaultServlet? (There goes container independence.) But surely Tomcat returns 501 when accessed via Localhost and you've already said that scenario works. Regards Roger __ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also b
Re: Apache, Tomcat, WebDAV, and Web Folders... Oh, my!
Here's new news: Apparently the whole PROPFIND / and Apache proxy things were red herrings. The central issue seems to be that MS Web Folders doesn't know what to do with a 401 Unauthorized response to an OPTIONS request on the WebDAV root folder (when it finally gets around to checking). I reconfigured my WebDAV servlet to bypass authorization for OPTIONS requests (as a test), and once MS Web Folders requested OPTIONS and my servlet sent them back, it issued a PROPFIND and correctly popped up the authorization dialog. (But there are more problems---see below.) Requiring OPTIONS to forsake authorization is a security risk. If I can't return 401 Unauthorized for OPTIONS, then a client can issue OPTIONS at will and find out which resources exist and which are collections. But let's say that I open up OPTIONS for all my realms, just to make MS Web Folders work. I'm still not out of the clear. Once MS Web Folders tries to do a PROPFIND and I enter my name and password, it doesn't work. In fact, MS Web Folder doesn't even send back my credentials! It apparently sends an identical PROPFIND request as the one that just failed, and then shows another dialog box with "user" changed to "www.example.com\user1". (The servers is a virtual host on Apache, proxied to Tomcat.) Now, this I've seen before, with Apache mod_dav on a virtual host. I never found the source of the problem. (I have Apache mod_dav working fine with non-virtual-host SSL domains.) Now I've opened up a security risk, and there's still another problem to track down. Thanks for your pointers, and for being a wonderful audience. ;) Garret Garret Wilson wrote: Yeah, that's what I *assume*, anyway. But Ethereal doesn't work on localhost, so I can only assume. There are these possibilities: * Tomcat returns something other than 501 Not Implemented when configured on localhost. (Not likely.) * MS Web Folders does different checks when accessing the Internet-at-large than when accessing localhost. (Likely? I don't know what to expect with MS Web Folders anymore.) I'm guessing the latter is happening, especially as two MS user agents get into the act: "Microsoft-WebDAV-MiniRedir/5.1.2600" and "Microsoft Data Access Internet Publishing Provider Protocol Discovery" And here's more news: I created a new DefaultServlet mapped to "/" that for PROPFIND simply returns 403 Forbidden. Something different happens. First, "Microsoft-WebDAV-MiniRedir/5.1.2600" does a PROPFIND on /webapp (which gets redirected to /webapp/). MyDefaultServlet returns 403 Forbidden. Fine. Can you guess what "Microsoft-WebDAV-MiniRedir/5.1.2600" does? "Microsoft-WebDAV-MiniRedir/5.1.2600" then tries to do another PROPFIND on /webapp! And another---for a total of five times! (It's forbidden, you idiot---and /webapp is none of your business anyway; you're supposed to be accessing /webapp/webdav/! Arggg!!!) Then "Microsoft Data Access Internet Publishing Provider Protocol Discovery" comes along and does its little OPTIONS / (200 OK) OPTIONS /webapp/webdav (401 Unauthorized) dance for three times, and then goes into the FrontPage mumbo-jumbo. What is left to do---issue a 401 Unauthorized on PROPFIND /webapp ? Issue a 401 Unauthorized on OPTIONS / ? Rewrite the operating system? (Yeah, the latter is probably what I'll have to do to fix all this mess.) (Grumble grumble grumble...) Any suggestions on what to do next? Garret Varley, Roger wrote: About the only thing left to try is to allow the PROPFIND on /webapp/ . So here's the Tomcat question---how can I allow a PROPFIND on /webapp/ and return, for example, a 403 forbidden, rather than a 501 Not Implemented? Do I have to override org.apache.catalina.servlets.DefaultServlet? (There goes container independence.) But surely Tomcat returns 501 when accessed via Localhost and you've already said that scenario works. Regards Roger __ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. __ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands
Re: Apache, Tomcat, WebDAV, and Web Folders... Oh, my!
That would be nice. It would have to be an IIS box configured so that: * http://www.example.com/ does not support WebDAV (or everything is forbidden) * http://www.example.com/webapp/ supports WebDAV, but everything is forbidden * http://www.example.com/webapp/webdav/ supports WebDAV with DIGEST authentication. I actually have different webdav/realm/ subdirectories, so it doesn't even make sense for me to authenticate in the parent directories---there would be no valid realm for me to send as a DIGEST challenge! (This is why it's so crazy---and potentially show-stopping---that MS Web Folders is even accessing directories up the hierarchy.) Garret Parsons Technical Services wrote: Does anyone have an IIS box you can connect to to see what happens. Then maybe you can mimic it. Doug - Original Message ----- From: "Garret Wilson" <[EMAIL PROTECTED]> To: "Tomcat Users List" Sent: Tuesday, January 11, 2005 1:12 PM Subject: Re: Apache, Tomcat, WebDAV, and Web Folders... Oh, my! Yeah, that's what I *assume*, anyway. But Ethereal doesn't work on localhost, so I can only assume. There are these possibilities: * Tomcat returns something other than 501 Not Implemented when configured on localhost. (Not likely.) * MS Web Folders does different checks when accessing the Internet-at-large than when accessing localhost. (Likely? I don't know what to expect with MS Web Folders anymore.) I'm guessing the latter is happening, especially as two MS user agents get into the act: "Microsoft-WebDAV-MiniRedir/5.1.2600" and "Microsoft Data Access Internet Publishing Provider Protocol Discovery" And here's more news: I created a new DefaultServlet mapped to "/" that for PROPFIND simply returns 403 Forbidden. Something different happens. First, "Microsoft-WebDAV-MiniRedir/5.1.2600" does a PROPFIND on /webapp (which gets redirected to /webapp/). MyDefaultServlet returns 403 Forbidden. Fine. Can you guess what "Microsoft-WebDAV-MiniRedir/5.1.2600" does? "Microsoft-WebDAV-MiniRedir/5.1.2600" then tries to do another PROPFIND on /webapp! And another---for a total of five times! (It's forbidden, you idiot---and /webapp is none of your business anyway; you're supposed to be accessing /webapp/webdav/! Arggg!!!) Then "Microsoft Data Access Internet Publishing Provider Protocol Discovery" comes along and does its little OPTIONS / (200 OK) OPTIONS /webapp/webdav (401 Unauthorized) dance for three times, and then goes into the FrontPage mumbo-jumbo. What is left to do---issue a 401 Unauthorized on PROPFIND /webapp ? Issue a 401 Unauthorized on OPTIONS / ? Rewrite the operating system? (Yeah, the latter is probably what I'll have to do to fix all this mess.) (Grumble grumble grumble...) Any suggestions on what to do next? Garret Varley, Roger wrote: About the only thing left to try is to allow the PROPFIND on /webapp/ . So here's the Tomcat question---how can I allow a PROPFIND on /webapp/ and return, for example, a 403 forbidden, rather than a 501 Not Implemented? Do I have to override org.apache.catalina.servlets.DefaultServlet? (There goes container independence.) But surely Tomcat returns 501 when accessed via Localhost and you've already said that scenario works. Regards Roger __ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. __ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache, Tomcat, WebDAV, and Web Folders... Oh, my!
Yeah, that's what I *assume*, anyway. But Ethereal doesn't work on localhost, so I can only assume. There are these possibilities: * Tomcat returns something other than 501 Not Implemented when configured on localhost. (Not likely.) * MS Web Folders does different checks when accessing the Internet-at-large than when accessing localhost. (Likely? I don't know what to expect with MS Web Folders anymore.) I'm guessing the latter is happening, especially as two MS user agents get into the act: "Microsoft-WebDAV-MiniRedir/5.1.2600" and "Microsoft Data Access Internet Publishing Provider Protocol Discovery" And here's more news: I created a new DefaultServlet mapped to "/" that for PROPFIND simply returns 403 Forbidden. Something different happens. First, "Microsoft-WebDAV-MiniRedir/5.1.2600" does a PROPFIND on /webapp (which gets redirected to /webapp/). MyDefaultServlet returns 403 Forbidden. Fine. Can you guess what "Microsoft-WebDAV-MiniRedir/5.1.2600" does? "Microsoft-WebDAV-MiniRedir/5.1.2600" then tries to do another PROPFIND on /webapp! And another---for a total of five times! (It's forbidden, you idiot---and /webapp is none of your business anyway; you're supposed to be accessing /webapp/webdav/! Arggg!!!) Then "Microsoft Data Access Internet Publishing Provider Protocol Discovery" comes along and does its little OPTIONS / (200 OK) OPTIONS /webapp/webdav (401 Unauthorized) dance for three times, and then goes into the FrontPage mumbo-jumbo. What is left to do---issue a 401 Unauthorized on PROPFIND /webapp ? Issue a 401 Unauthorized on OPTIONS / ? Rewrite the operating system? (Yeah, the latter is probably what I'll have to do to fix all this mess.) (Grumble grumble grumble...) Any suggestions on what to do next? Garret Varley, Roger wrote: About the only thing left to try is to allow the PROPFIND on /webapp/ . So here's the Tomcat question---how can I allow a PROPFIND on /webapp/ and return, for example, a 403 forbidden, rather than a 501 Not Implemented? Do I have to override org.apache.catalina.servlets.DefaultServlet? (There goes container independence.) But surely Tomcat returns 501 when accessed via Localhost and you've already said that scenario works. Regards Roger __ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. __ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache, Tomcat, WebDAV, and Web Folders... Oh, my!
Here's an update---I'm narrowing it down. I tried to connect directly to Tomcat without Apache in-between. Same problem. So this probably isn't something Apache is doing to mess up communications. I recompiled Apache so that I could add headers, and I added: DAV: 1,2 MS-Author-Via: DAV Allow: OPTIONS, PROPFIND, GET, HEAD This way, even error messages and redirects will show WebDAV support, and even an OPTIONS request for "/" will show WebDAV method support. It still doesn't work. The *only* thing that isn't exactly what a WebDAV server would send back is when MS Web Folders tries to do a PROPFIND on /webapp/ and Tomcat sends back: "501 Method PROPFIND is not defined in RFC 2068 and is not supported by the Servlet API." (Again, MS Web Folders shouldn't even try to access /webapp/ directly---it should try to access /webapp/webdav/ .) About the only thing left to try is to allow the PROPFIND on /webapp/ . So here's the Tomcat question---how can I allow a PROPFIND on /webapp/ and return, for example, a 403 forbidden, rather than a 501 Not Implemented? Do I have to override org.apache.catalina.servlets.DefaultServlet? (There goes container independence.) Why is it that nothing in this world is straightforward? (That's a rhetorical question---don't feel obliged to answer.) Cheers, Garret Garret Wilson wrote: Some more info: When Web Folders first tries to access http://www.example.com/webapp/webdav/ , user agent "Microsoft-WebDAV-MiniRedir/5.1.2600" tries to do a PROPFIND on http://www.example.com/webapp . Apache (from Tomcat?) redirects with 302 to http://www.example.com/webapp/ . "Microsoft-WebDAV-MiniRedir/5.1.2600" tries to do a PROPFIND on http://www.example.com/webapp/ . Apache sends back (from Tomcat, I suppose) a 501 "I don't know what the heck a PROPFIND is" type of response. (MS never should have tried to touch http://www.example.com/webapp/ , as that's a parent directory to what I requested.) Again "Microsoft-WebDAV-MiniRedir/5.1.2600" tries to do a PROPFIND on http://www.example.com/webapp and goes through the whole procedure again. Finally it gets tired and issues an OPTIONS request on "/", to which Apache/Tomcat issues a 202 OK (but with no DAV header). So then "Microsoft Data Access Internet Publishing Provider Protocol Discovery" gets into the action and issues its own OPTIONS on "/". (Why MS can't simply try to access http://www.example.com/webapp/webdav/ like I asked in the first place, I'll never know.) Another 200 OK response. Finally MS gets around to doing an OPTIONS on http://www.example.com/webapp/webdav (which it should have done in the very first request). Tomcat (through Apache) issues its 401 Unauthorized response (as it should), along with the DAV: 1,2 header (as it should). MS decides, "Oh, well, I'll issue an OPTIONS on the root path '/' again" and goes through the entire process. Then I see various attempts at GET /_vti_inf.html and POST /_vti_bin/shtml.exe , indicating that MS Web Folders didn't recognize WebDAV and is trying to use FrontPage extension witchraft. Sending back a MS-Author-Via: DAV header should stop this---but my WebDAV servlet never got the chance because MS Web Folders wouldn't authenticate in the presence of a 401 Unauthorized. I know that IE, Web Folders, and the whole shebang is a load of (insert expletive here), but I've managed to work around everything else so that it works on pure Tomcat on localhost. There's some little thing that's throwing things off in the Tomcat-behind-Apache-on-Internet scenario, and if I can just find out what it is, I can cut off this last MS bug and get this to working. Does it have something to do with Apache modifying a HTTP request or response to or from Tomcat? Does it have something to do with the server being located somewhere other than localhost, altering the behavior of Microsoft-WebDAV-MiniRedir/5.1.2600 or Microsoft Data Access Internet Publishing Provider Protocol Discovery? An inquiring mind wants to know---but really has to get some sleep right now. Thanks again to Doug and everyone else for your time. Garret Garret Wilson wrote: I've written a custom WebDAV servlet which works fine configured on Windows XP Professional localhost with Tomcat 5.5.4. I upload everything to a http://www.example.com/webapp/webdav/ . The domain is served on Red Hat 6 by Apache 2.0.49, which forwards to Tomcat using ProxyPass and ProxyPassReverse. I try to connect via Microsoft Windows XP Professional Web Folders. (My WebDAV servlet works around all the various Microsoft redirection bugs, and works fine with Web Folders on localhost.) Web Folders doesn't recognize the folder. I whip out Ethereal, and here's what I find: User agent "Microsoft
Re: Apache, Tomcat, WebDAV, and Web Folders... Oh, my!
Some more info: When Web Folders first tries to access http://www.example.com/webapp/webdav/ , user agent "Microsoft-WebDAV-MiniRedir/5.1.2600" tries to do a PROPFIND on http://www.example.com/webapp . Apache (from Tomcat?) redirects with 302 to http://www.example.com/webapp/ . "Microsoft-WebDAV-MiniRedir/5.1.2600" tries to do a PROPFIND on http://www.example.com/webapp/ . Apache sends back (from Tomcat, I suppose) a 501 "I don't know what the heck a PROPFIND is" type of response. (MS never should have tried to touch http://www.example.com/webapp/ , as that's a parent directory to what I requested.) Again "Microsoft-WebDAV-MiniRedir/5.1.2600" tries to do a PROPFIND on http://www.example.com/webapp and goes through the whole procedure again. Finally it gets tired and issues an OPTIONS request on "/", to which Apache/Tomcat issues a 202 OK (but with no DAV header). So then "Microsoft Data Access Internet Publishing Provider Protocol Discovery" gets into the action and issues its own OPTIONS on "/". (Why MS can't simply try to access http://www.example.com/webapp/webdav/ like I asked in the first place, I'll never know.) Another 200 OK response. Finally MS gets around to doing an OPTIONS on http://www.example.com/webapp/webdav (which it should have done in the very first request). Tomcat (through Apache) issues its 401 Unauthorized response (as it should), along with the DAV: 1,2 header (as it should). MS decides, "Oh, well, I'll issue an OPTIONS on the root path '/' again" and goes through the entire process. Then I see various attempts at GET /_vti_inf.html and POST /_vti_bin/shtml.exe , indicating that MS Web Folders didn't recognize WebDAV and is trying to use FrontPage extension witchraft. Sending back a MS-Author-Via: DAV header should stop this---but my WebDAV servlet never got the chance because MS Web Folders wouldn't authenticate in the presence of a 401 Unauthorized. I know that IE, Web Folders, and the whole shebang is a load of (insert expletive here), but I've managed to work around everything else so that it works on pure Tomcat on localhost. There's some little thing that's throwing things off in the Tomcat-behind-Apache-on-Internet scenario, and if I can just find out what it is, I can cut off this last MS bug and get this to working. Does it have something to do with Apache modifying a HTTP request or response to or from Tomcat? Does it have something to do with the server being located somewhere other than localhost, altering the behavior of Microsoft-WebDAV-MiniRedir/5.1.2600 or Microsoft Data Access Internet Publishing Provider Protocol Discovery? An inquiring mind wants to know---but really has to get some sleep right now. Thanks again to Doug and everyone else for your time. Garret Garret Wilson wrote: I've written a custom WebDAV servlet which works fine configured on Windows XP Professional localhost with Tomcat 5.5.4. I upload everything to a http://www.example.com/webapp/webdav/ . The domain is served on Red Hat 6 by Apache 2.0.49, which forwards to Tomcat using ProxyPass and ProxyPassReverse. I try to connect via Microsoft Windows XP Professional Web Folders. (My WebDAV servlet works around all the various Microsoft redirection bugs, and works fine with Web Folders on localhost.) Web Folders doesn't recognize the folder. I whip out Ethereal, and here's what I find: User agent "Microsoft Data Access Internet Publishing Provider Protocol Discovery" sends an HTTP OPTIONS request to "/". Apache sends back a 200 OK. Then Microsoft Web Folders sends an OPTIONS request to /webapp/webdav/. My servlet sends back a 401 Unauthorized, asking for digest credentials. So far, so good. Then Microsoft Web Folders starts over again, sending an HTTP OPTIONS request to "/", and then an OPTIONS request to /webapp/webdav/ (never asking me for my username/password), until it finally gives up and says that there must not be a valid WebDAV server at the requested location. Why doesn't Microsoft Web Folders ask my for my password? Why does it ignore the 401 Unauthorized and go back to asking for OPTIONS on the root? Does this have something to do with using Apache to proxy to Tomcat? Why did a non-proxied Tomcat work find on my Windows XP Professional machine? (If it has anything to do with it, I'm testing this in a cafe going through Surf and Sip WiFi.) Thanks in advance for any insight. Garret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache, Tomcat, WebDAV, and Web Folders... Oh, my!
Parsons Technical Services wrote: Why is MS Web Folders doing this strange OPTIONS thing with "/" and ignoring my 401 Unauthorized HTTP response? Did you close all IE windows prior to this last step? If not, then it never destroyed the session. I have now---same result. (Why would I care if it had destroyed the session or not?) As for the other, Google has several sites that simply say replace IE. Good answer. I came up with that one a long time ago. But the problem goes beyond IE---Web Folders is the root problem, here. I know, replace the OS. While we're at it, I'd like to redesign HTTP... (Folding LWS? What were they thinking?) And WebDAV. (Did no one realize that "DAV:" is not a valid URI and therefore not a valid XML namespace? What were they thinking?) ;) But past that there is one issue on M$ that has to do with the message you are getting from IE but doesn't match you setup. Might give you some ideas. http://support.microsoft.com/default.aspx?scid=kb;en-us;290227 No luck. On IE5 there was an error file (WecErr.txt file in your TEMP folder ). You might find one on IE6. It doesn't seem to be there. Thanks, Garret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apache, Tomcat, WebDAV, and Web Folders... Oh, my!
Parsons Technical Services wrote: It may be that the login request is not getting back to you intact. Do you have another app that is protected and triggers a login prompt? Web Folders works without problems when Tomcat is running on localhost. The password dialog pops up just fine. I use Firefox to browse the directory of http://www.example.com/webapp/webdav/ using GET, which goes through my WebDAV servlet. Firefox pops up an authentication dialog and, after I enter the correct username and password, displays a directory list generated by my WebDAV servlet. I use DavExplorer 0.90 to open http://www.example.com/webapp/webdav/ . DavExplorer pops up a DIGEST authentication dialog and, after I enter the correct username and password, allows me to access the entire WebDAV tree. I use Microsoft Internet Explorer 6 to browse to http://www.example.com/webapp/webdav/ using HTTP GET. After a dialog pops up and I enter the correct username and password, the WebDAV servlet-generated directory list appears. Still using MS IE 6, I try to open http://www.example.com/webapp/webdav/ as a Web Folder using File|Open... (as Web Folder). IE reports that it is unable to open the location as a Web Folder---would I like to see the default view? If I answer in the affirmative, IE sends a GET and shows me the directory listing. Why is MS Web Folders doing this strange OPTIONS thing with "/" and ignoring my 401 Unauthorized HTTP response? If all else fails, would form auth over SSL work? Just a thought, yeah I know, and so are nightmares. Form authorization with WebDAV? But the answer is no---I want to find out what this isn't working. Thanks anyway! Garret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Apache, Tomcat, WebDAV, and Web Folders... Oh, my!
I've written a custom WebDAV servlet which works fine configured on Windows XP Professional localhost with Tomcat 5.5.4. I upload everything to a http://www.example.com/webapp/webdav/ . The domain is served on Red Hat 6 by Apache 2.0.49, which forwards to Tomcat using ProxyPass and ProxyPassReverse. I try to connect via Microsoft Windows XP Professional Web Folders. (My WebDAV servlet works around all the various Microsoft redirection bugs, and works fine with Web Folders on localhost.) Web Folders doesn't recognize the folder. I whip out Ethereal, and here's what I find: User agent "Microsoft Data Access Internet Publishing Provider Protocol Discovery" sends an HTTP OPTIONS request to "/". Apache sends back a 200 OK. Then Microsoft Web Folders sends an OPTIONS request to /webapp/webdav/. My servlet sends back a 401 Unauthorized, asking for digest credentials. So far, so good. Then Microsoft Web Folders starts over again, sending an HTTP OPTIONS request to "/", and then an OPTIONS request to /webapp/webdav/ (never asking me for my username/password), until it finally gives up and says that there must not be a valid WebDAV server at the requested location. Why doesn't Microsoft Web Folders ask my for my password? Why does it ignore the 401 Unauthorized and go back to asking for OPTIONS on the root? Does this have something to do with using Apache to proxy to Tomcat? Why did a non-proxied Tomcat work find on my Windows XP Professional machine? (If it has anything to do with it, I'm testing this in a cafe going through Surf and Sip WiFi.) Thanks in advance for any insight. Garret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: solved: timeout when reading 401 response [was: persistent HTTP 1.1 connectionswith Tomcat 5.5.4?]
Wade Chandler wrote: Actually what is happening is this You are using a buffered stream. It is reading past the amount returnedand then the tcp/ip socket is blocking because you have it open as a keep alive. You have to only read the number of bytes available and not keep trying to squeeze the blood out of the turnip... ;-) I'll almost bet you money that is what is happening. Try to not use a buffered input stream and see what you get. If I'm wrong I'm wrong let me know. Hope it works. Wade, thanks so very much for responding. I was sitting here dumbfounded wondering what in the world could be happening. But you're wrong. ;) I had already thrown out the BufferedInputStream to eliminate that. I switched to straight sockets. I set up a simple loop that simply read bytes until receiving a timeout. The timeout occurred after the CRLF divider, even though the Content-Length said 952. Accessing the site from Firefox showed all the content. Puzzled? Yeah, so was I. Then I realized that in my Java client I was testing my new HTTP routines with the HEAD method! (You can start the ridicule, now...) The whole point of the HEAD method is that it doesn't send content---it simply sends a Content-Length indicating how long the content would have been. In fact, RFC 2616 says that "the server MUST NOT return a message-body in the response" for the HEAD method (9.4). Now, what threw me off is that the response was an error status, a 401 Unauthorized. The Content-Length is in line with the spec, returning the length of the content which would have been returned if a GET had been used. As an error was returned, however, the Content-Length was returning the length of the error message---the error message that would have been returned had a GET been used. Now, all this is technically to the letter of RFC 2616, but I wonder what would happen if a server were to send back a 405 Method Not Allowed for HEAD. There would be no way to get at the error message, because HEAD doesn't send back content. Using GET would succeed, so technically the Content-Length of HEAD in this case wouldn't be the content length of a response from GET. I'm thinking that RFC 2616 should probably have made an exception to the no content rule for HEAD when an error condition is being reported. But that's the least of my worries. I just need to tell my client to ignore all content in a response to HEAD. Oddly, though, this means that a thread can't simply pull HTTP responses down from a persistent connection without knowing to which request each response belongs---i.e. whether to trust the Content-Length or not! In any case, thanks for the input. It looks like your responses will be useful when I finally switch over to non-blocking I/O support. Garret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: timeout when reading 401 response [was: persistent HTTP 1.1 connections with Tomcat 5.5.4?]
So this is getting stranger. Just to preclude any error on my part, I did a simple loop that output every character received from the response. The HTTP response status line and headers come down fine, including the CRLF that separates the headers from the body. And then---timeout after 15 seconds. But the strange part is that if I connect using Firefox, I can view the entire response---an HTML document including the 401 status code. This document length is---you guessed it---952 bytes long, just like the Content-Length header says. Why can't I read the body from Java, yet Firefox can read it? Is there a bug with Channels.newInputStream()? Garret Garret Wilson wrote: It looks like the timeout is occurring when the first response is being read, so this changes the problem. I'm receiving a 401 Unauthorized response with the following headers: Server: Apache-Coyote/1.1 WWW-Authenticate: [...] Content-Type: text/html;charset=utf-8 Content-Length: 952 Date: Thu, 06 Jan 2005 19:47:43 GMT I try to read the 952 bytes, and that's when I get the 15-second hang before a timeout. The response is generated on the server with: response.sendError(401); Where are those 952 bytes, and why can't I read them, I wonder? Garret Garret Wilson wrote: Does Tomcat 5.5.4 support HTTP 1.1 persistent connections? I'm connecting to a Tomcat servlet from a custom Java client, and the first request/response goes fine: socketAddress=new InetSocketAddress(host, port); channel=SocketChannel.open(socketAddress); inputStream=new BufferedInputStream(newInputStream(channel)); outputStream=new BufferedOutputStream(newOutputStream(channel)); The response headers do *not* have a "Connection: close" header, which means the connection should stay open. The response is a 401 Unauthorized, so I place credentials in the request and send it again to the same output stream. Then I try to read another response from the same input stream. My program hangs until the connection times out. What the matter with persistent connections here? Thanks, Garret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Does anyone know this boy?
If you're talking about this boy: http://www.virtualtourist.com/f/p/1e331/ http://analiticamenteincorrecto.blogspot.com/ His family has already been found: http://www.phuket-inter-hospital.co.th/siriroj.html Garret Jan Behrens wrote: Hi list, I know this is OT but I do believe that everyone out there should take the time to read this, if one does know him it will be worth more than all email in the world... Cheers, Jan PLEASE DO FOWARD TO YOUR INTERNATIONAL OPERATORS AND CONTACTS HE MUST HAVE BOUGHT IS TRIP IN SOME TRAVEL AGENCY IN EUROPE... Looking for his family. The boy about 2 years, from Khoa Lak is missing his parents. Nobody knows what country he comes from. If anybody known him please contact us by phone 076-249400-4 ext. 1336, 1339 or e- mail : [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: timeout when reading 401 response [was: persistent HTTP 1.1 connections with Tomcat 5.5.4?]
It looks like the timeout is occurring when the first response is being read, so this changes the problem. I'm receiving a 401 Unauthorized response with the following headers: Server: Apache-Coyote/1.1 WWW-Authenticate: [...] Content-Type: text/html;charset=utf-8 Content-Length: 952 Date: Thu, 06 Jan 2005 19:47:43 GMT I try to read the 952 bytes, and that's when I get the 15-second hang before a timeout. The response is generated on the server with: response.sendError(401); Where are those 952 bytes, and why can't I read them, I wonder? Garret Garret Wilson wrote: Does Tomcat 5.5.4 support HTTP 1.1 persistent connections? I'm connecting to a Tomcat servlet from a custom Java client, and the first request/response goes fine: socketAddress=new InetSocketAddress(host, port); channel=SocketChannel.open(socketAddress); inputStream=new BufferedInputStream(newInputStream(channel)); outputStream=new BufferedOutputStream(newOutputStream(channel)); The response headers do *not* have a "Connection: close" header, which means the connection should stay open. The response is a 401 Unauthorized, so I place credentials in the request and send it again to the same output stream. Then I try to read another response from the same input stream. My program hangs until the connection times out. What the matter with persistent connections here? Thanks, Garret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
persistent HTTP 1.1 connections with Tomcat 5.5.4?
Does Tomcat 5.5.4 support HTTP 1.1 persistent connections? I'm connecting to a Tomcat servlet from a custom Java client, and the first request/response goes fine: socketAddress=new InetSocketAddress(host, port); channel=SocketChannel.open(socketAddress); inputStream=new BufferedInputStream(newInputStream(channel)); outputStream=new BufferedOutputStream(newOutputStream(channel)); The response headers do *not* have a "Connection: close" header, which means the connection should stay open. The response is a 401 Unauthorized, so I place credentials in the request and send it again to the same output stream. Then I try to read another response from the same input stream. My program hangs until the connection times out. What the matter with persistent connections here? Thanks, Garret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebDAV and redirects
Mark, Mark Thomas wrote: TC4 and TC5 handle requests for http://www.example.com/folder differently. TC4 does a forward to http://www.example.com/folder/ whereas TC5 issues a redirect. ... For TC4 - returns response for ../folder/ For TC5 mapped to "/" issues a 302 For TC5 mapped to "/*" returns response for .../folder/ ... Uses a mapping that means 302s are never issued. Thanks so much for the response. If I could just summarize here, I think what you're saying is that, with the correct servlet mapping, the Tomcat WebDAV servlet will *always* do the equivalent of a forward from http://www.example.com/folder to http://www.example.com/folder/ , and this seems to be a consequence of using the Tomcat-derived directory context as a source of the files on the back-end. This is compliant with the letter of RFC 2518 (5.2): There is a standing convention that when a collection is referred to by its name without a trailing slash, the trailing slash is automatically appended. Due to this, a resource may accept a URI without a trailing "/" to point to a collection. In this case it SHOULD return a content-location header in the response pointing to the URI ending with the "/". For example, if a client invokes a method on http://foo.bar/blah (no trailing slash), the resource http://foo.bar/blah/ (trailing slash) may respond as if the operation were invoked on it, and should return a content-location header with http://foo.bar/blah/ in it. In general clients SHOULD use the "/" form of collection names. The problem with this approach, as explained on the thread http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0190.html , is that http://www.example.com/folder and http://www.example.com/folder/ could represent distinct resources. Well-behaved WebDAV clients could distinguish between the two---this is why Apache apparently uses redirect-carefully *only* for enumerated broken user agents. The Tomcat WebDAV servlet as you've described, however, forces this behavior for *all* user agents, meaning that even completely compliant WebDAV clients would not be able to distinguish between an existing http://www.example.com/folder/ collection and a non-existent http://www.example.com/folder resource. (Presumably a nice client would be able to create a http://www.example.com/folder with the Tomcat WebDAV servlet even if the http://www.example.com/folder/ collection existed, but that's just a guess---and that ignores the Linux limitation of file/directory name equality, but that's a deployment issue.) In my implementation, I'm trying to be rigorous with http://www.example.com/folder and http://www.example.com/folder/ distinction. (I'm actually using WebDAV to serve an RDF-based repository, which could have a file system, a database, or anything on the back-end, so any URI is theoretically possible.) I'll probably wind up sending back a 301 permanent redirect for everyone but a few listed rogue clients, which means that unfortunately I'll have to consider even updated MS clients as rogue as they give no version number in their User-Agent header. Cheers, Garret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
WebDAV and redirects
I've been struggling with the whole issue of Microsoft WebDAV clients
failing to including a trailing slash in collection URIs even when I ask
nicely. It looks like I can fix this with redirects, but that opens up
another can of worms: the Microsoft client redirect bug. I'm trying to
get the last word on this, and it looks like Mark Thomas or others may
be able to set the record straight.
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgId=2007923
Basically, Microsoft clients will issue a PROPFIND for
http://www.example.com/folder instead of http://www.example.com/folder/
, even though the latter is the true name of the collection and the
former is a file that doesn't exist. WebDAV servers get around this by
issuing a redirect from http://www.example.com/folder to
http://www.example.com/folder/ .
It appears that some Microsoft WebFolder implementations will follow up
the redirect with a GET instead of a PROPFIND, breaking WebDAV access.
For this reason Apache has a redirect-carefully option for user agents
such as "Microsoft Data Access Internet Publishing Provider".
So here are my questions:
* What's the most appropriate redirect to send to redirect from
http://www.example.com/folder to http://www.example.com/folder/ ? A 301
(permanent) or 302 (temporary)? Which does Apache do? Which does the
Tomcat WebDAV servlet do?
* For those clients that do not follow redirects properly, what should
be done as a workaround? Should the server simply act as if
http://www.example.com/folder/ were requested when
http://www.example.com/folder is requested, if the user agent is one of
those recognized as buggy? Is this what Apache does for
redirect-carefully? What does the Tomcat WebDAV servlet do?
* Currently, in my implementation I'm sending back a 302 redirect, and
Microsoft WebFolders handles it fine on Windows XP Professional SP2. But
is it true that other versions do not follow redirects? As all versions
send the same user agent identification ("Microsoft Data Access Internet
Publishing Provider"), what should the WebDAV server do---implement the
redirect-carefully hack even with those clients that properly follow
redirects, as the server can't tell the difference? What does the Tomcat
WebDAV servlet do?
A lot of this information seems to be on the Internet, but as little
pieces scattered about.
Thanks in advance,
Garret
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
questions on WebDAV implementation
Mark Thomas and others,
I started out trying to determine how to allow the Tomcat WebDAV servlet
to serve a filesystem tree outside the webapp. I've determined it will
be easier for me to just roll my own WebDAV servlet from scratch,
allowing me to do custom operations (such as security checks) more
easily anyway.
In the process, though, I'm getting to know the Tomcat WebDAV source
pretty well, and I have a few questions that hopefully will help make
the Tomcat WebDAV servlet better.
* In DefaultServlet, after doGet() serves a resource, the servlet checks
the exception and, if its message contains the words "Broken pipe", the
exception is ignored:
} catch( IOException ex ) {
// we probably have this check somewhere else too.
if( ex.getMessage() != null
&& ex.getMessage().indexOf("Broken pipe") >= 0 ) {
// ignore it.
}
throw ex;
I'm guessing this is supposed to simply ignore clients that go away in
the middle of the stream, but matching a substring of the error message
doesn't seem the best way to do this. For one, it is dependent on the
JVM implementation. Secondly, it ignores localization issues, which
might result in messages in Korean, for example.
What is the real source of this exception, and how could we check the
exception itself (a code or a class) rather than the message? Maybe
there's somewhere deeper where we can do this check?
* I note that WebDAVServlet keeps a static SimpleDateFormat around for
quickly formatting the creation date/time. The Java API docs for
DateFormat indicate that date formats are not synchronized. Does this
raise the potential for corrupted date printing, should multiple threads
try to simultaneously serve WebDAV requests?
* The WebDAV servlet gets the creation date and last modified date from
the directory object. But Java has no way of actually retrieving a
file's creation date. Do these two values ultimately end up being the same?
If this is helpful, I'll report any other issues I find. Your responses
will be appreciated and helpful to my effort.
Cheers,
Garret
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: extra directory in WebDAV servlet listing
Mark, Mark Thomas wrote: The webdav servlet is based around accessing the file system through a JNDI DirContext for the current webapp. I've officially started working on the configured-filesystem-root feature. The ProxyDirContext gets configured either by getting the "org.apache.catalina.resources" attribute from the servlet context, or the "java:/comp/Resources" JNDI setting. Question: Which of these is used in the default configuration, and where is that value actually configured? Thanks, Garret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: extra directory in WebDAV servlet listing
Mark, Mark Thomas wrote: I'll look at the arbitrary file system root next. Thanks! I'll get to it as soon as I get more pressing things out of the way, but that may be a week or two. I currently do a file store in another part of the project and make the results available via URIs. I have two variables: baseDirectory baseURI In essence, when a request for a URI comes in, I simply relativize the URI to baseURI, and then resolve it to baseDirectory. Getting the URI of a file in the filesystem requires the reverse process. For the WebDAV servlet, base URI is "configured" by the servlet mapping: "webdav/*" would essentially set the base URI to "http://example.com/webapp/webdav/";. As we've discussed, the base directory would need to be set in a configuration somewhere. Personally, I'd put the configuration in a context parameter, such as: I would *not* put it in the web.xml file, because I want to take the .war and simply drop it on my server. The WebDAV parameter is a system-specific variable, and if I develop on Windows but deploy on Linux, the WebDAV base directory is going to be different on each system. Let me know if I can provide more help or input. Garret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: extra directory in WebDAV servlet listing
Mark, Mark Thomas wrote: If I can get this to work as you expect it to, it should provide a solution for "how do I use webdav to manage my webapp?" - something that is far from easy at the moment. I would imagine the solution might also be related to, "how do I use WebDAV and yet keep users far away from my webapp?"---something that is impossible at the moment. In other words, allow the root directory to be configured to an arbitrary file system location. I'd be glad to start work on this, but it would help to have some details on exactly what I should be looking at. (See my previous post.) I hesitate to take days out of my project just learning a new framework. I just had a terrible experience with the Jakarta Slide WebDAV client library, which has been arbitrarily thrown together. It took days out of my schedule to learn that 1) creating a WebdavResource for a non-existent file will immediately throw an exception because it checks properties and fails if the file is not on the server; 2) WebdavResource.exists() doesn't work automatically---you have to call headMethod() and check the result; 3) mkcolMethod() with a relative path doesn't work---you must have the full path from root; etc. (Sorry I had to vent.) Garret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
WebDAV servlet and sub-webapp collection creation
Trying to get @#$! Jakarta Slide to work, I created a routine that would go through the elements of a URI path and create all collections that didn't exist (using the WebDAV MKCOL method). The first time I tried it out, it worked fine---but I had forgotten that I was using the Tomcat WebDAV servlet, which means the first part of the path is virtual: "http://localhost/webapp/webdav/existing/new/file.txt"; In other words, "webapp" is my webapp and the Tomcat WebDAV servlet is mapped to "/webdav/*". "existing" already exists, but "new" does not. The result of my test was surprising: "http://localhost/webapp/"; did not exist; created successfully "http://localhost/webapp/webdav/"; did not exist; created successfully "http://localhost/webapp/webdav/existing/"; exists "http://localhost/webapp/webdav/existing/new/"; did not exist; created successfully The last two I expected---"existing" existed, and "new" didn't exist, yet was created successfully. However, I didn't expect the servlet to think that "webapp" and "webdav" did not exist---and I certainly didn't expect the Tomcat WebDAV servlet to actually create them! It turns out the Tomcat WebDAV servlet created the "webdav" directory inside my webapp root directory. This is incorrect, as "webdav" is a virtual directory mapped to the servlet---it makes no sense to create it, and it should probably show it as existing. Stranger still is the successful creation of the "webapp" directory. Where did the Tomcat WebDAV servlet create this directory? I can't find it anywhere, and there's nowhere it would even make sense to create it, as it's simply a virtual directory mapped to my web app! Garret P.S. Tomcat 5.5.4; J2SE 5.0; WinXP Pro SP2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: extra directory in WebDAV servlet listing
Mark, Mark Thomas wrote: Tomcat version? 5.5.4. JVM version? 5.0. OS? Windows XP Professional SP2. Garret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
extra directory in WebDAV servlet listing
I have the WebDAV servlet set to /webdav/*. Listing is turned on. I have a subdirectory in my webapp named "base", which contains "dir1", "dir2", and "dir3". "dir1" contains "test1" and "test2". When I get a WebDAV directory listing of http://localhost/webapp/webdav/base/dir1/ , I get back: dir1 test1 test2 In other words, the WebDAV servlet is for some reason returning the directory itself as one of its own subdirectories! Trying to select that directory gives a 404 not found. In fact, it does this for every subdirectory, listing the directory itself directory as if it were a subdirectory. This bug is exhibited by accessing the servlet from Windows XP Professional as well as from DAVExplorer. Garret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
wrongly URI-decoded request.getPathInfo()
I'm using Tomcat 5.5.4. I have an HTTP servlet mapped to /servlet/*. I send a request to the servlet on localhost like this: http://localhost/webapp/servlet/test/encoded%2Ffilename Here's what I get from the servlet request: request URI: /webapp/servlet/test/encoded%2Ffilename request URL: http://localhost/webapp/servlet/test/encoded%2Ffilename path info: /test/encoded/filename Why did Tomcat unencode my filename for request.getPathInfo()? This really throws a kink into things---I'm going to have to ignore path info and do a lot of work with the request URI and/or URL to find out the actual path passed to my servlet! Why on earth would Tomcat unencode my URI? How can I get the *real* path info? Garret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: webdav servlet file path; documentation
Mark, Thanks for giving me a place to start. I've had a half-our glance at the source code; let me know if I'm going in the right direction. Doesn't this simply entail making sure that the ProxyDirContext resources object created in DefaultServlet has the correct file system root? Would that have anything to do with the vPath of a wrapped ProxyDirContext? I'll look into this more in a couple of days. (I've noticed that others have requested this same feature.) Garret Mark Thomas wrote: From: Garret Wilson [mailto:[EMAIL PROTECTED] I can't imagine why this wouldn't be a simple change to the Tomcat WebDAV code---probably just five or ten lines. You start with a file system base directory right? Just get it from the context parameter. Not quite that simple ;) I'll gladly take a look at the code---can you tell me where to start? org.apache.catalina.servlets.WebdavServlet I'd be happy to look at anything you come up with. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
WebDAV servlet bug for UTF-8 characters
I have a file with the character RIGHT SINGLE QUOTATION MARK U+2019 in the title. The file is listed fine when I browse to the Tomcat WebDAV enabled directory with a browser. Clicking on the file attempts to browse to the file, with the character UTF-8 encoded as %E2%80%99, but Tomcat indicates that the file is unavailable. I don't know if this is a Tomcat or a Tomcat WebDAV servlet bug. Garret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: webdav servlet file path; documentation
Garret Wilson wrote: By default the servlet accesses the file system inside the web context. (That is, a servlet mapped to /context/webapp/* will show files in /context/webapp/ .) Ack! Apparently the servlet will allow access to files in /context/ , which is much worse? 3. How do I map the servlet to an absolute file on the server machine? (I meant "directory" of course.) This question is even more important, now... Garret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
webdav servlet file path; documentation
I just stumbled upon the Tomcat webdav servlet, which *almost* meets all my needs. 1. Is there some more complete documentation somewhere? By default the servlet accesses the file system inside the web context. (That is, a servlet mapped to /context/webapp/* will show files in /context/webapp/ .) 2. What happens when I deploy my webapp as a .war---surely webdav methods won't modify the contents of the .war, will they? 3. How do I map the servlet to an absolute file on the server machine? The need for this is obvious in relation to the second question---I'd like to deploy my web application (the "code" in the .war) independently of the webdav-accessible documents (the "data"). 4. I'm sure I'll get into this once I get more documentation, but where should I start looking regarding implementing custom security methods? That is, rather than defining static users and passwords, I'd like my web application to dynamically validate all webdav accesses. Thanks, Garret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: using character entities and JSF XML
Eric, Eric Suen wrote: I didn't know that XML required internal document types to declare the root element. see bug: http://issues.apache.org/bugzilla/show_bug.cgi?id=28207 seems tomcat guys like this stupid feature very much, even it is very easy add an option to disable those kind validation in production env. I think the validation is necessary in developing, but in production env, for performance, maybe we want to disable validation, I just dont understand why jsp 2.0 force us to validation the xml file even it can not do it well. Thanks so much for this helpful link! First, the element is really cool---no more ! Secondly, I think I see how this whole two-step process of translating character entities works---I need to define a character entity with the ampersand escaped. Thirdly, if I can define a DOCTYPE for my entire JSP file and stick it away in a file and just reference it from all my JSPs, this would be ultra-cool: * I could define all my doubly-escaped character entities that I now realize I need. * I can even specify the root namespace declaration attributes as #FIXED, so that I never have to define them. The little problem is that I don't understand why Tomcat is requiring that *every* element be defined---does XML require that, if an internal or external DTD is present, it must define each and every element in the document? I didn't think so---can't one have just an external DOCTYPE with only character entities defined? If this is an XML requirement, then it's the way Tomcat should go. Now I need to track down the official JSF and JSP element DTDs, combine them in one file with my doubly-escaped character entities, and I'll be ready to go. (Something will probably come up, though.) Hey, wait a minute---doesn't Tomcat already tell me if certain JSF and JSP tags don't have attributes that the DTD requires? Where is Tomcat getting *that* information---is it processing some DTD in the background? Will my custom DTD conflict? These questions and more will have to be answered after I get some sleep... Garret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
using character entities and JSF XML
So I'm trying to use the ™ character entity in a pure XML JavaServer faces file, and it doesn't let me, because it isn't defined. Fair enough; I add this: ]> http://java.sun.com/jstl/core"; xmlns:jsp="http://java.sun.com/JSP/Page"; xmlns:jsf="http://java.sun.com/jsf/core"; xmlns:html="http://java.sun.com/jsf/html";> I get: org.apache.jasper.JasperException: /documents.jsp(9,44) Element type "jsp:root" must be declared. I didn't know that XML required internal document types to declare the root element. Strangely enough, I hit "refesh" and sometimes Tomcat 5.5.2 will show the *old* cached page, before I added the ™ character entity. I keep hitting "refresh" and it randomly shows an error and the old cached page. Garret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: valid XHTML 1.1, Tomcat, text/xml, and @!&* IE
Hassan Schroeder wrote: Garret Wilson wrote: Thanks for the example. Note, however, that you're example doesn't enumerate *all* the accept headers, which means it won't work if a browser decides to sent each accept string as a separate header. True -- is that legal? I just looked at RFC2616 and it doesn't seem to be explicitly specified, so... Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded. (RFC 2616, 32) (I ran into several years ago working on a SIP processor, but that's another story.) I know I've never seen a UA do that but if it's possible, Murphy will make it happen at the worst possible time :-) Well, considering 9X% of the market is using Murphysoft browsers, we better code for that possibility... ;) I found an article that gives a nice overview of the situation we've been discussing: http://www.greytower.net/en/archive/articles/xhtmlcontent.html Best, Garret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: valid XHTML 1.1, Tomcat, text/xml, and @!&* IE
Hassan Schroeder wrote: 3. Use a Filter -- here's a quick example, you may need to tweak it for your particular situation -- I was *just* about to check into filters (or go insane, one or the other). Thanks for the example. Note, however, that you're example doesn't enumerate *all* the accept headers, which means it won't work if a browser decides to sent each accept string as a separate header. Garret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: valid XHTML 1.1, Tomcat, text/xml, and @!&* IE
Oh, this is just a nightmare.
Using JavaServer Faces, here are the options:
1. Just add a JSP directive:
Of course, that turns *all* pages into text/html, which we don't want to
do for non-broken browsers such as Firefox and Mozilla.
2. Add a script to check for what the browser accepts:
String contentType="text/html";
final Enumeration httpAcceptEnumeration=request.getHeaders("accept");
while(httpAcceptEnumeration.hasMoreElements())
{
if(((String)httpAcceptEnumeration.nextElement()).indexOf("application/xhtml+xml")>=0)
{
contentType="application/xhtml+xml";
break;
}
}
response.setContentType(contentType); //set the content type to
whatever we decided upon
That works really well; on Firefox it returns application/xhtml+xml, and
for buggy browsers (and browsers that don't support XML at all, IE being
the former) it returns text/html.
But do I want to put all of that junk in all of my JavaServer Faces
files? I don't think so. Inclusion sounds perfect, but here's the
problem: if I include the code statically, it doesn't get executed. If I
include it dynamically, it doesn't correctly set the content-type header
because its output is fed into the main page, which is working with the
real HTTP request/response.
Anyone have an idea on this really nasty situation? Or should I just go
back to sending out HTML 3.x?
Garret
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: jstl:import---static information?
Garret Wilson wrote: Shouldn't the imported information be merged into the JSF component tree, rather than just spitting out the JSF tags (and all other tags) as if they were serialized literally? I've discovered several things. First, it appears you must have something like this in your included file: <%@ taglib uri="http://java.sun.com/jsf/core"; prefix="jsf" %> <%@ taglib uri="http://java.sun.com/jsf/html"; prefix="html" %> Using standards-compliant JavaServer Faces-compatible stuff like defining namespaces doesn't seem to work: http://java.sun.com/jstl/core"; xmlns:jsp="http://java.sun.com/JSP/Page"; xmlns:jsf="http://java.sun.com/jsf/core"; xmlns:html="http://java.sun.com/jsf/html";> With the <%@ taglib>s, the information is correctly processed and folded into the component tree instead of being included statically. Secondly, don't create an entire HTML file in the included file. Even though _Professional JavaServer Faces_ (page 189) shows an entire HTML file in an included file, doing so will cause those elements to be included in the original file---resulting in a duplicate inside and the like. (Sorry if this should have went to a JavaServer Faces list---I didn't know if this was a Tomcat bug at first.) Garret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: valid XHTML 1.1, Tomcat, text/xml, and @!&* IE
Morten Liebach wrote: The nicest solution is to follow the tips in this article: http://www.xml.com/pub/a/2003/03/19/dive-into-xml.html Basically , if the HTTP_ACCEPT variable contains the string "application/xhtml+xml" set MIME-Type to that, otherwise set it to "text/html". And no, I have no idea how you do that in Java/JSP, I'm too much of a newbie yet, but eventually I'll have to do something like that myself. Thanks for the nice tip. It seems like this checking is something you would do on the server---Tomcat. You could probably get it done somewhere in the internals of the JavaServer Faces implementation, too. I found in web.xml and tried setting the "faces" extension to return text/html. No luck. Then I tried the "jsp" extension. No luck there, either. The _Java™ Servlet Specification Version 2.4_ is no help. Neither is _Professional Apache Tomcat 5_. Can Tomcat handle this? Is there something I can put in my JSF page to handle this? Rather than placing hacks throughout my pages, though, I'd like to just tell Tomcat to serve text/html for now---how do I do that? Garret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jstl:import---static information?
According to the JSF and JSTL documentation (and two JSF books), should dynamically import information. I have: ... ... However, everything from navigation.jsp is included literally---including all JSF tags and everything in the imported JSP. This happens both on Tomcat 5.5.2 and 5.0.28, so I must be doing something wrong---yet I'm using examples almost verbatim (pun not intended) from _Core JavaServer Faces_ and _Mastering JavaServer Faces_. Shouldn't the imported information be merged into the JSF component tree, rather than just spitting out the JSF tags (and all other tags) as if they were serialized literally? Garret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: valid XHTML 1.1, Tomcat, text/xml, and @!&* IE
No, please, tell me it's all a bad dream... Doesn't that workaround mean that all browsers, even ones that support XHTML 1.1 (such as Firefox), will suddenly start applying an XSL transformation to the entire web page? Wouldn't it be a much less nasty hack just to tell Tomcat to serve these pages as text/html? How can I do that? Garret Mark Eggers wrote: On Fri, 2004-09-17 at 17:55, Garret Wilson wrote: With Tomcat 5.5.2, JSF, and JSP, I'm serving up pure, standards-compliant XHTML 1.1 that starts out with: http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd";> http://www.w3.org/1999/xhtml";> That works just fine with FireFox, but with IE (the very latest and greatest available), I get: Parameter entity must be defined before it is used. Error processing resource 'http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd... %xhtml-prefw-redecl.mod; -^ Yep - known bug that IE cannot handle this. Apparently there is a work-around detailed at: http://www.w3.org/MarkUp/2004/xhtml-faq#texthtml I haven't tried it yet. /mde/ just my two cents . . . . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
valid XHTML 1.1, Tomcat, text/xml, and @!&* IE
With Tomcat 5.5.2, JSF, and JSP, I'm serving up pure, standards-compliant XHTML 1.1 that starts out with: http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd";> http://www.w3.org/1999/xhtml";> That works just fine with FireFox, but with IE (the very latest and greatest available), I get: Parameter entity must be defined before it is used. Error processing resource 'http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd... %xhtml-prefw-redecl.mod; -^ Apparently, it's because of an IE bug that chokes if the content is served as text/xml. See: http://lists.w3.org/Archives/Public/www-math/2002Apr/0002.html http://www.biglist.com/lists/xsl-list/archives/200405/msg00106.html http://www.intertwingly.net/blog/1626.html How do I tell Tomcat to serve JavaServer Faces files as text/html (or application/html+xml, but maybe that's asking for too much) so that IE users can access content that's apparently too standards-compliant for their browsers? Garret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NullPointerException loading JavaServer Faces web application
Shapira, Yoav wrote: - Go get Tomcat 5.5.2 and try it out if you can. Hmmm... that seems to have fixed it. Thanks for letting me know that another release was already available. Garret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: NullPointerException loading JavaServer Faces web application
Hiroshi Iwatani wrote: Tell us about whole structure of you application based on the JSF. For example, where have you put what and what? Not much to tell. I have C:\jakarta-tomcat-5.5.1\conf\Catalina\localhost\test.xml : I have C:\test\www\WEB-INF\web.xml : http://java.sun.com/j2ee/dtds/web-app_2_2.dtd";> Web Application Web Application Faces Servlet javax.faces.webapp.FacesServlet 1 Faces Servlet *.faces default.jsp index.html In C:\jakarta-tomcat-5.5.1\common\lib I have: 08/27/2004 12:57 PM 118,757 commons-beanutils.jar 08/27/2004 12:57 PM 170,902 commons-collections.jar 08/27/2004 12:57 PM 109,131 commons-digester.jar 09/07/2004 12:56 PM 112,341 commons-el.jar 08/27/2004 12:57 PM31,638 commons-logging.jar 09/07/2004 12:56 PM 916,757 jasper-compiler-jdt.jar 09/07/2004 12:56 PM 363,184 jasper-compiler.jar 09/07/2004 12:56 PM75,798 jasper-runtime.jar 08/27/2004 12:59 PM 364,470 jsf-api.jar 08/27/2004 12:59 PM 698,542 jsf-impl.jar 09/07/2004 12:56 PM50,493 jsp-api.jar 08/31/2004 02:22 PM16,905 jstl.jar 09/07/2004 12:56 PM26,002 naming-common.jar 09/07/2004 12:56 PM 154,101 naming-factory-dbcp.jar 09/07/2004 12:56 PM14,751 naming-factory.jar 09/07/2004 12:56 PM 1,826 naming-java.jar 09/07/2004 12:56 PM45,448 naming-resources.jar 12/12/2002 04:23 PM 262,152 org.hsqldb.jar 09/07/2004 12:56 PM97,693 servlet-api.jar 08/31/2004 02:22 PM 293,750 standard.jar I have C:\jakarta-tomcat-5.5.1\shared\lib\my.shared.routines.jar There's not much more to tell, really... Garret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
NullPointerException loading JavaServer Faces web application
In Tomcat 5.5.0 I have a simple application using the JavaServer Faces 1.1 reference implementation. http://java.sun.com/j2ee/dtds/web-app_2_2.dtd";> Web Application Web Application Faces Servlet javax.faces.webapp.FacesServlet 1 Faces Servlet *.faces default.jsp index.html The application loads fine on Tomcat 5.5.0. After installing the exact same configuration in Tomcat 5.5.1, I get the following error: Sep 14, 2004 2:51:47 PM org.apache.catalina.core.ApplicationContext log SEVERE: StandardWrapper.Throwable java.lang.NullPointerException at javax.faces.webapp.FacesServlet.init(FacesServlet.java:144) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper. java:1003) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:83 6) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContex t.java:3823) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4 128) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase .java:755) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:73 9) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.ja va:587) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.j ava:535) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:470 ) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1076) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java :310) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Lifecycl eSupport.java:119) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1011) at org.apache.catalina.core.StandardHost.start(StandardHost.java:718) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1003) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:420 ) at org.apache.catalina.core.StandardService.start(StandardService.java:4 50) at org.apache.catalina.core.StandardServer.start(StandardServer.java:196 7) at org.apache.catalina.startup.Catalina.start(Catalina.java:541) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:271) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:409) Sep 14, 2004 2:51:48 PM org.apache.catalina.core.ApplicationContext log SEVERE: Servlet /class threw load() exception javax.servlet.ServletException: Servlet.init() for servlet Faces Servlet threw e xception at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper. java:1045) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:83 6) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContex t.java:3823) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4 128) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase .java:755) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:73 9) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.ja va:587) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.j ava:535) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:470 ) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1076) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java :310) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Lifecycl eSupport.java:119) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1011) at org.apache.catalina.core.StandardHost.start(StandardHost.java:718) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1003) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:420 ) at org.apache.catalina.core.StandardService.start(StandardService.java:4 50) at org.apache.catalina.core.StandardServer.start(StandardServer.java:196 7) at org.apache.catalina.startup.Catalina.start(Catalina.java:541) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAcces
Re: missing resource bundle shouldn't be---solved
QM wrote: On Mon, Sep 06, 2004 at 02:55:13PM -0700, Garret Wilson wrote: : I was planning on using the same set of libraries for multiple web : apps---the jar in question had more than just servlets for a single web app. There's no need to do this, really. Webapps are supposed to be self-contained. My inner C++ developer says I should share common code, similar to shared libraries; but C and C++ != Java. =) I tend to leave common/lib/ alone, so only the Tomcat-provided JARs exist there. I just downloaded an electronic copy of _Professional Apache Tomcat 5_, which has a wonderful "Chapter 9: Class Loaders." It turns out that there's one classloader for common/lib and common/classes, and another for shared/lib and shared/classes. My common routines apparently should go into the latter pair---the former pair are intended for API libraries like jsp-api.jar and jsf-api.jar. My servlets, though, should go in WEB-INF/lib and WEB-INF/classes---which use yet another classloader, the same one used by JSPs. I transferred my servlet jar to WEB-INF/lib, and everything worked like a charm. I know that I reported that I had already tried this. I thought I did. Then again, there's so many /lib directories running around that maybe I picked the wrong one when I was trying 1,001 possible solutions. Thanks so much for your and George's feedback, pointing me in the right direction. I definitely also recommend _Professional Apache Tomcat 5_. Cheers, Garret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: missing resource bundle shouldn't be
QM wrote: : Then what's the solution? I've tried moving the jar from common/lib to : WEB-INF/lib, but that didn't help. Unjarring the files into : WEB-INF/classes didn't work, either. When you say "the jar," you mean "the jar containing my servlet classes," correct? Right. > That should work. You restarted Tomcat after this change, right? And restarted and shutdown and started and restarted... :) You could also clear the work/ dir to be certain. I'll try that---it wouldn't cache a jar, would it? -and if I may ask, why'd you put the servlet classes in common/lib? I was planning on using the same set of libraries for multiple web apps---the jar in question had more than just servlets for a single web app. But, to take this issue out of the equation, I've tried putting the jar in WEB-INF/lib (where I assume you would say it should go) to no avail. : How can I programmatically reference the appropriate classloader from : within my servlet so that I can access property files in : WEB-INF/classes? You don't. =) That would, in some sense, defeat the purpose of having each webapp live in its own classloader. Now this doesn't make sense to me. Let's say I have the following JSP: /index.jsp This index.jsp file can load resources just fine from WEB-INF/classes. Now let's say I delete index.jsp and create a class called IndexServlet, and map it to /index . From that servlet, I attempt to load a resource bundle from WEB-INF/classes---it doesn't work! But in the first instance the web container takes index.jsp and creates its own servlet---*that* is what really gets called from the container. If I look in work/ and find the servlet behind index.jsp, I see the same code to load a resource bundle from WEB-INF/classes, which works. So let me restate my question: how can I allow my servlets to load the same resource bundle (from the same location) that my JSP can load? Because, after all, behind the scenes a JSP *is* a servlet! Surely the web container doesn't use a different classloader for container-generated servlets and user-created servlets in the same context---does it? (And if it does, where should I put my resource bundles so that the user-created servlets can access them?) Garret - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: missing resource bundle shouldn't be
George,
George Sexton wrote:
Different class loader. The JSP's are running in a class-loader with the
application, while the common/lib jars are in a different class-loader where
the WEB-INF/classes are not part of the search path.
Then what's the solution? I've tried moving the jar from common/lib to
WEB-INF/lib, but that didn't help. Unjarring the files into
WEB-INF/classes didn't work, either.
How can I programmatically reference the appropriate classloader from
within my servlet so that I can access property files in
WEB-INF/classes? Or should I put my resource bundles somewhere else? It
seems a shame that my JSP files can access the resource bundles, but my
servlets can't---when the JSP files get compiled into servlets, anyway.
Garret
-----Original Message-
From: Garret Wilson [mailto:[EMAIL PROTECTED]
Sent: Monday, September 06, 2004 11:40 AM
To: [EMAIL PROTECTED]
Subject: Re: missing resource bundle shouldn't be
Oh, and I'm using JDK 1.5 RC.
Garret
Garret Wilson wrote:
I just installed Tomcat 5.5.0 on Windows XP Professional
SP2. I have an
existing application that worked under Tomcat 4.x. It consists of a
servlet in a jar file located here:
\tomcat\common\lib\myservlet.jar
That jar contains a servlet mapped to, for example:
myservlet
/myservlet/test
I have a resource bundle installed here:
...mywebapp\WEB-INF\classes\myresourcebundle.properties
My JSP files do the following with no problem:
ResourceBundle.getBundle("myresourcebundle");
However, when my servlet in my jar tries to execute the
exact same code,
I get:
java.util.MissingResourceException: Can't find bundle for base name
myresourcebundle, locale en_US
java.util.ResourceBundle.throwMissingResourceException(Resourc
eBundle.java:837)
java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:727)
java.util.ResourceBundle.getBundle(ResourceBundle.java:577)
[etc.]
* I've tried taking my servlet out of a jar and putting it in
...mywebapp\WEB-INF\classes\
* I've tried copying my resource bundles to
...mywebapp\WEB-INF\classes\
to the same subdirectory as the actual classfiles (even
though I'm using
a non-hierarchical resource bundle name: "myresourcebundle")
* I've tried creating an explicit myresourcebundle_en_US.properties
The only thing that works is to comment out the
ResourceBundle.getBundle(); line from my servlet.
I've looked at the generated JSP source code from Tomcat,
and they have
the same ResourceBundle.getBundle(); as does my servlet.
Why can my JSP files find my resource bundle, yet my servlet can't?
Garret
P.S. I'm sure that this worked under Tomcat 4.x. Then
again, Tomcat 4.x
didn't issue an error when my JSP files imported a class
but didn't use
it, either.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: missing resource bundle shouldn't be
Oh, and I'm using JDK 1.5 RC.
Garret
Garret Wilson wrote:
I just installed Tomcat 5.5.0 on Windows XP Professional SP2. I have an
existing application that worked under Tomcat 4.x. It consists of a
servlet in a jar file located here:
\tomcat\common\lib\myservlet.jar
That jar contains a servlet mapped to, for example:
myservlet
/myservlet/test
I have a resource bundle installed here:
...mywebapp\WEB-INF\classes\myresourcebundle.properties
My JSP files do the following with no problem:
ResourceBundle.getBundle("myresourcebundle");
However, when my servlet in my jar tries to execute the exact same code,
I get:
java.util.MissingResourceException: Can't find bundle for base name
myresourcebundle, locale en_US
java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:837)
java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:727)
java.util.ResourceBundle.getBundle(ResourceBundle.java:577)
[etc.]
* I've tried taking my servlet out of a jar and putting it in
...mywebapp\WEB-INF\classes\
* I've tried copying my resource bundles to ...mywebapp\WEB-INF\classes\
to the same subdirectory as the actual classfiles (even though I'm using
a non-hierarchical resource bundle name: "myresourcebundle")
* I've tried creating an explicit myresourcebundle_en_US.properties
The only thing that works is to comment out the
ResourceBundle.getBundle(); line from my servlet.
I've looked at the generated JSP source code from Tomcat, and they have
the same ResourceBundle.getBundle(); as does my servlet.
Why can my JSP files find my resource bundle, yet my servlet can't?
Garret
P.S. I'm sure that this worked under Tomcat 4.x. Then again, Tomcat 4.x
didn't issue an error when my JSP files imported a class but didn't use
it, either.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
missing resource bundle shouldn't be
I just installed Tomcat 5.5.0 on Windows XP Professional SP2. I have an
existing application that worked under Tomcat 4.x. It consists of a
servlet in a jar file located here:
\tomcat\common\lib\myservlet.jar
That jar contains a servlet mapped to, for example:
myservlet
/myservlet/test
I have a resource bundle installed here:
...mywebapp\WEB-INF\classes\myresourcebundle.properties
My JSP files do the following with no problem:
ResourceBundle.getBundle("myresourcebundle");
However, when my servlet in my jar tries to execute the exact same code,
I get:
java.util.MissingResourceException: Can't find bundle for base name
myresourcebundle, locale en_US
java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:837)
java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:727)
java.util.ResourceBundle.getBundle(ResourceBundle.java:577)
[etc.]
* I've tried taking my servlet out of a jar and putting it in
...mywebapp\WEB-INF\classes\
* I've tried copying my resource bundles to ...mywebapp\WEB-INF\classes\
to the same subdirectory as the actual classfiles (even though I'm using
a non-hierarchical resource bundle name: "myresourcebundle")
* I've tried creating an explicit myresourcebundle_en_US.properties
The only thing that works is to comment out the
ResourceBundle.getBundle(); line from my servlet.
I've looked at the generated JSP source code from Tomcat, and they have
the same ResourceBundle.getBundle(); as does my servlet.
Why can my JSP files find my resource bundle, yet my servlet can't?
Garret
P.S. I'm sure that this worked under Tomcat 4.x. Then again, Tomcat 4.x
didn't issue an error when my JSP files imported a class but didn't use
it, either.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
