This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | i18n - jsp files with multi-byte characters can't be acessed | ||
---|---|---|---|
Product: | serverplugins | Reporter: | Pavel Rehak <prehak> |
Component: | Sun Appserver 9 | Assignee: | Vince Kraemer <vkraemer> |
Status: | VERIFIED FIXED | ||
Severity: | blocker | CC: | kfrank, pjiricka, vkraemer |
Priority: | P2 | Keywords: | I18N |
Version: | 5.x | ||
Hardware: | All | ||
OS: | Windows XP | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: | required war |
Description
Pavel Rehak
2006-06-14 09:12:09 UTC
Reassigning to server plugin team for evaluation. I think some browsers can't handle mbyte in url name, but others can and convert to a %A7%B6 ... kind of notation. The question here might be that, given a browser that is ok with it, is the name of the file being given in correct encoding to the browser. Note that the project name of web projects makes the context root have __ instead of mbyte characters, as below http://localhost:8080/__Jot_WebApplication4__/とppと.jsp but it seems that the jsp file name should be able to have mbyte in it in any case. A related question - what does the browser msg requested resource is not available mean - is that from AS or browser itself; I've seen this msg in other instances. ken.frank@sun.com May be server side bug. Please attach the war file that demonstrates this issue. Created attachment 31498 [details]
required war
duplicated behavior "outside" NetBeans. filed https://glassfish.dev.java.net/issues/show_bug.cgi?id=797 I will keep this one open for tracking purposes. As this is applicable to NB 5.5, I am removing the NO55 keyword. Ken or Pavel, there is some progress in Glassfish issue 797 by Jan Luehe - can you please check whether this is the right way and whether the Glassfish behavior is acceptable now? Thanks. GF is still "broken" according to Jan's comment. The jsp with the multibyte character name doesn't compile. future (or whenever GlassFish runtime is fixed.) Nitya, please start the waive process. Thanks, The issue is dependent on fix in glassfish runtime. Cannot be resolved for this release. I just updated https://glassfish.dev.java.net/issues/show_bug.cgi?id=797 as follows (check that link for additional info): If I run my appserver in a Terminal window in the ja_JP.UTF-8 locale, which I open as follows: env LANG=ja_JP.UTF-8 LC_ALL=ja_JP.UTF-8 gnome-terminal the 500 error disappears, and the JSP both compiles and runs fine. Here are the contents of the directory with the generated servlet source and class files of the __Jot_WebApplication1__ application, as they show in my ja_JP.UTF-8 enabled Terminal window: __Jot_WebApplication1__ __Jot_WebApplication1__/tldCache.ser __Jot_WebApplication1__/org __Jot_WebApplication1__/org/apache __Jot_WebApplication1__/org/apache/jsp __Jot_WebApplication1__/org/apache/jsp/index_jsp.java __Jot_WebApplication1__/org/apache/jsp/index_jsp.class __Jot_WebApplication1__/org/apache/jsp/とa_jsp.java __Jot_WebApplication1__/org/apache/jsp/とa_jsp.class So it turns out that my earlier fix, which was to expose an HTTP connector's "uriEncoding" property and set it to "UTF-8" in the connector's domain.xml entry, has been sufficient. No further code changes are necessary. Notice that this scenario is different from another scenario that is still failing and being investigated, in that this scenario deploys a WAR file with an ASCII name, and only the name of the JSP resource is multi-byte, whereas the other scenario uses a WAR file with a multibyte name. The other scenario probably requires changes to the deployment code. My fix (to expose HTTP connector's "uriEncoding" property so it can be configured in domain.xml) has been available as of AS 9.1 b10. I'm about to backport it to AS 9.0peur1. Please verify the fix and mark this bug as FIXED when you get a chance. Vince, could you verify this please. Thanks Works for me now, thanks for fix. (verified with build 29/08/06) Ok, marking as fixed. verified: build 0927, Mozilla |