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.
Product Version = NetBeans 5.5 Dev (Build 200606090200) Operating System = Windows XP version 5.1 running on x86 Java; VM; Vendor; Home = 1.5.0_07; Java HotSpot(TM) Client VM 1.5.0_07-b02; Sun Microsystems Inc.; F:\Java\jdk1.5.0_07\jre System Locale; Encoding = ja_JP (nb); MS932 -- i'm using jappanise presudolocalized nb5,5 glassfish web server sniplet of code: <a href="とppと.jsp">link1</a> <a href="a.jsp">link2</a> (first href contains multibyte characters - such a file exists in my project) but when i execute my project and click on link1 it fails: The requested resource () is not available. link in web browser is correct: http://localhost:8080/__Jot_WebApplication4__/とppと.jsp all works fine for link2.
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