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.

Bug 77871 - i18n - jsp files with multi-byte characters can't be acessed
Summary: i18n - jsp files with multi-byte characters can't be acessed
Status: VERIFIED FIXED
Alias: None
Product: serverplugins
Classification: Unclassified
Component: Sun Appserver 9 (show other bugs)
Version: 5.x
Hardware: All Windows XP
: P2 blocker (vote)
Assignee: Vince Kraemer
URL:
Keywords: I18N
Depends on:
Blocks:
 
Reported: 2006-06-14 09:12 UTC by Pavel Rehak
Modified: 2007-10-02 16:57 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
required war (5.29 KB, application/octet-stream)
2006-06-29 09:01 UTC, Pavel Rehak
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pavel Rehak 2006-06-14 09:12:09 UTC
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.
Comment 1 Tomasz Slota 2006-06-14 09:41:54 UTC
Reassigning to server plugin team for evaluation.
  
Comment 2 Ken Frank 2006-06-24 21:10:26 UTC
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
Comment 3 Vince Kraemer 2006-06-28 16:56:30 UTC
May be server side bug. Please attach the war file that demonstrates this issue.
Comment 4 Pavel Rehak 2006-06-29 09:01:43 UTC
Created attachment 31498 [details]
required war
Comment 5 Vince Kraemer 2006-06-29 17:34:52 UTC
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.
Comment 6 Petr Jiricka 2006-07-13 09:20:21 UTC
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.
Comment 7 Vince Kraemer 2006-07-20 17:26:30 UTC
GF is still "broken" according to Jan's comment.  The jsp with the multibyte
character name doesn't compile.
Comment 8 _ ludo 2006-07-31 18:00:54 UTC
future (or whenever GlassFish runtime is fixed.)
Comment 9 _ ludo 2006-08-08 00:31:42 UTC
Nitya, please start the waive process.
Thanks,
Comment 10 Nitya Doraisamy 2006-08-08 21:34:28 UTC
The issue is dependent on fix in glassfish runtime. Cannot be resolved for this
release.
Comment 11 jluehe 2006-08-15 18:02:08 UTC
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.
Comment 12 Nitya Doraisamy 2006-08-16 01:01:19 UTC
Vince, could you verify this please. Thanks
Comment 13 Pavel Rehak 2006-08-31 09:02:17 UTC
Works for me now, thanks for fix.
(verified with build 29/08/06)
Comment 14 Petr Jiricka 2006-08-31 12:23:22 UTC
Ok, marking as fixed.
Comment 15 kaa 2007-10-02 16:57:29 UTC
verified: build 0927, Mozilla