if you install tomcat or a web application in a directory with spaces in the name, for example "C:\Program Files\vds\tomcat" for tomcat or "C:\Program Files\vds\console" for a web application. the TLD files that are inside the META-INF directory of the jar files will not be loaded. the problem is is the file treatment inside the TldConfig class ... I have attached a patch with the correction. this bug is found in Tomcat 6 too
Created attachment 20023 [details] a patch that fixes this bug
If you could explain how this patch is a good idea and solves something, I would be interested :)
in the current code tomcat gets all the URLs from the URLClassloader, and call the getFile() method to get the file name, after it creates a File object and gets the CanonicalName to create the final File object that will be used later ... but the CanonicalName when it is running on windows and has spaces on the name, is some thing like: Program%20Files/... when the file object is created, and the exists method is called it returns false because the File object does not know how to convert %20 to " " ... if you look at the code in the patch, instead of calling the getFile, creating a File object, getCanonicalName, create another File object that does not know how to handle %20 ... I just take the original URL object, call the toURI method and pass it to the apropriate File constructor that will handle the %20 correctly ... with this patch it works fine, and loads the TLDs from the applications that are in directories with spaces in the names ...
Ok, but your patch was not good (not all URLs are %xx encoded).
but the URI class understand all URI formats, being it %xx encoded or not ...
How about stopping using "..." ? The issue has been fixed in the 6 branch, but not using your patch.
Ok, I'll not use "..." the fix is already in the trunk? I have just tested it and it still not working
testes in tomcat 6 trunk and the bug still there.
This is not the case. Please do not reopen this bug report.
so this bug will not bi fixed? change it to wont be fixed, but not to fixed, because it is not fixed.
If you're out there to post nonsense, then I suggest you do not post (it is very easy to verify the patch I committed will fix the problem you reported, and I have also tested the fix). This is a bug report, not your blog.
sorry, it appears that I was having a problem with the proxy I'm behind here. I updated twice the sources and it was not downloading did not had your patch. I had to download all again from another network without a proxy to get the sources with your patch applied. Sorry again.