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 166753

Summary: I18N : outputs from GlassFish V2 are garbled because different JDK are used
Product: serverplugins Reporter: Masaki Katakai <masaki>
Component: Sun Appserver 9Assignee: Vince Kraemer <vkraemer>
Status: NEW ---    
Severity: blocker CC: g11n, issues, pjiricka
Priority: P4    
Version: 6.x   
Hardware: Macintosh   
OS: All   
Issue Type: DEFECT Exception Reporter:
Attachments: screenshot

Description Masaki Katakai 2009-06-09 07:01:36 UTC
When NetBeans 6.7 is installed into Mac, NetBeans will use JDK of system default
by fixing bug 159846. netbeans_jdkhome in etc/netbeans.conf is commented out.

etc/netbeans.conf:

#netbeans_jdkhome="/path/to/jdk"

For GlassFish V2, it looks still use JDK5 on my environment even I set the
default to JDK6 on my Mac. Here is the entry in 

config/asenv.conf:

AS_JAVA="/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home"

In this case, NetBeans and GlassFish V2 are running with different JDK.
There is no problem in Windows and Solaris, however, encoding of JDK are
different in JDK6 and JDK5 on Mac. JDK6 uses Shift JIS as output and input.
JDK5 uses UTF-8. So outputs from GlassFish are garbled on NetBeans output window.

I'm not sure if NetBeans installer could change AS_JAVA in asenv.conf,
but it should use system default as well. 

Tomcat and GlassFish V3 look OK. I can see outputs correctly.
Comment 1 Masaki Katakai 2009-06-09 07:07:20 UTC
Created attachment 83340 [details]
screenshot
Comment 2 dlipin 2009-06-09 15:57:20 UTC
Well... I tend to think that it should be fixed somehow on the serverplugins side since the main issue is that "outputs 
from GlassFish are garbled on NetBeans output window".

Imagine the situation when the user installs GlassFish v2.1 (or Sun GlassFish ... v2.1) using the JDK5 by its own 
installer and the runs NetBeans using the JDK6 : in that case he bumps into this bug.

Another thing is that currently NB is not configured to use particular JDK during the installation but the NetBeans 
itself determines the default JDK when NetBeans starts. Even though we configure JDK6 for glassfish usage, another user 
on the same system can run NB with JDK5 been his default Java and thus been used by IDE. In that case he again bumps 
into this bug again.

And we can`t leave AS_JAVA unconfigured - glassfish does not work without it been set.
Comment 3 Masaki Katakai 2009-06-10 04:06:36 UTC
Thank you Dmitry for evaluation.

> Imagine the situation when the user installs GlassFish v2.1 (or Sun GlassFish ... v2.1) using the JDK5 by its own 
> installer and the runs NetBeans using the JDK6 : in that case he bumps into this bug.

Yes, it's true. I agree the point.

This Mac issue - inconsistent encoding in JDKs on Mac is a well-known issue
so people who try to register own glassfish will/should care it.
My point is, using NetBeans installer will install both NetBeans and
glassfish V2 together at same time so people would not pay attention.
People expect that glassfish V2 will be registered and work perfectly
after the installation.

> And we can`t leave AS_JAVA unconfigured - glassfish does not work without it been set.

So is there any common way to get the system JDK location on Mac?
Comment 4 dlipin 2009-06-10 09:00:53 UTC
> So is there any common way to get the system JDK location on Mac?
There is no such term as "system JDK location" on Mac. On Mac each user can define its own (default) JDK location. If 
not defined, JDK5 is used (as for now). As the result, "java -version" run under different users can return different 
versions.

The tricky thing is that installer is running under root user, and usually JDK is not overridden for that user.
In other words, JDK5 will be used for the GlassFish in most cases.
Comment 5 dlipin 2009-06-10 09:11:05 UTC
I`ve filed a different issue on installer (Issue 166834) with some explanation of the steps required to determine the 
JDK from the current user (not the "root" user which installer is run under).
Comment 6 Vince Kraemer 2009-06-10 16:15:37 UTC
This is going to be tricky to address from the plugin, since the fix looks like it requires that we change AS_JAVA or
the environment as part of the 'start server'...
Comment 7 Quality Engineering 2009-07-15 07:19:38 UTC
Integrated into 'main-golden', will be available in build *200907150249* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/4bf94be987c8
User: vince kraemer <vkraemer@netbeans.org>
Log: #166753: character encoding problem
Comment 8 Vince Kraemer 2009-07-15 08:58:39 UTC
the change I just added may address the issue that you are seeing... Since I haven't got an environment configured that
would let me replicate the issue easily, the change is a bit blind...

Please give it a try and re-open if there is still a problem.  If it is still broken, I can invest in building an
environment where I can replicate the issue.
Comment 9 Masaki Katakai 2009-07-16 06:34:25 UTC
Hi Vince, thank you very much for taking.

Just changing reading encoding to UTF-8 would not be working perfectly
for all environments. Actually it's not working on Japanese Windows
because SJIS encoding is used. Usually it will use the default
encoding so specifying "UTF-8" should be removed.

I think this case is special and actually there is no way to specify
AS_JAVA from IDE. So let's back out the fix and leave this issue as open
or close as WONTFIX. I'll try to describe the workaround in FAQ.
Comment 10 Vince Kraemer 2009-07-17 09:13:13 UTC
I have pushed the revert.  I am not going to close this, as the filer suggested... but will lower it to P4.
Comment 11 Vince Kraemer 2010-03-08 09:34:54 UTC
i am not active on this issue right now.