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.
Mac OS X 10.5.8 1. Register WebLogic under the services node 2. Go to the server properties, Platform tab The value of Java Home is set to "", and as a result WebLogic does not start. Furthermore, the value is not editable, so I can not corrected manually. The correct Java Home on my machine is: /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home Here is the error in the output tab after starting the server: The JRE was not found in directory . (JAVA_HOME) Please edit your environment and set the JAVA_HOME variable to point to the root directory of your Java installation.
Please provide details : - is it consequence of changed customizer ? The customizer doesn't allow to change JDK home . AFAIK ( this is true for Win at least ) there is no possibility to set JAVA_HOME for WL start script ( see details on the issue about WL Customizer ). This variable is "hardcoded" in the start script file ( at WL installation process ). So this issue is not customizer issue but installer. For checking this could you please attach two files : - setDomainEnv.sh - startWebLogic.sh in "bin" directory of your weblogic domain ( you can find its path in Customizer ).
> - is it consequence of changed customizer ? Yes, I was able to start up WebLogic before (the Java Home was detected correctly). I have 'installed' WebLogic using the zip archive, not sure if that may make any difference. From what I heard from Petr H (though I haven't looked in the code), NetBeans explicitly passes the JAVA_HOME detected value as an environment variable to the server process when starting up the server, no?
JAVA_HOME is set by "setDomainEnv.sh" script. There is no sense to set JAVA_HOME variable manually because it will be overridden by this script. And I don't see any code in WL plugin which set up this variable. Thanks for the script files. I've got the problem : this is specific Mac OS issue. As result I will need to change UI for Customizer. I was thinking that there could be only two Java vendors : Oracle and Sun. But this is not true. There can be a number of different vendors. For Mac case this is Apple vendor with its own JDK path. This case requires Customizer UI change.
Allowing the JDK change seems to be bit ambitious at this phase. I think parsing the startup script which can change with every minor release and can contain high number of different java vendors. I would suggest to have just not editable text field displaying the used JDK. In such case you have a fallback of displaying "Unable to detect". In future when you get pretty sure about settings you can change such textfield to combobox. I even think the non editable field should be enough as change of JDK for server is pretty rare imo and you just configure it on installation.
Denis just a P4 request - make different public static fields consistent. There are WLPluginProperties.JAVA_OPTS, WLStartTask.JAVA_OPTIONS, WLPluginProperties.VENDOR, WLStartTask.JAVA_VENDOR etc. Thanks.
I think issue 188669 should be closed.
I agree that JDK textfield should be non-editable. This is exactly how it is done now. As I already said WL startup scripts override JAVA_HOME variable so there is no sense to set this env variable. The only way to change JAVA_HOME is edit startup script files manually. But it can be impossible due lack of permissions . Considering these facts RO textfield is only bulletproof solution here.
>I think issue 188669 should be closed. OK. Done. >Denis just a P4 request - make different public static fields consistent. There >are WLPluginProperties.JAVA_OPTS, WLStartTask.JAVA_OPTIONS, >WLPluginProperties.VENDOR, WLStartTask.JAVA_VENDOR etc. Thanks. Sure. There should not be duplicated constants. I will review them and make them consistent.
(In reply to comment #7) > I agree that JDK textfield should be non-editable. > This is exactly how it is done now. I'm sorry I was inaccurate. What I meant was to remove the Java vendor configuration and to keep just JDK text field. If it would be manageable *and* useful we can change the text field to combo later (that would change vendor in background not java_home). I would not allow to change vendor and/or java_home now. > > As I already said WL startup scripts override JAVA_HOME variable > so there is no sense to set this env variable. > > The only way to change JAVA_HOME is edit startup script files manually. > But it can be impossible due lack of permissions . > Considering these facts RO textfield is only bulletproof solution here.
Hm. Actually access to JDK home requires parsing of startup script. I don't see the other way how to know JDK . JAVA_HOME is set to preconfigured default value in case when no vendor is set. Finding this case is a most difficult task . Having known vendor variable is set is very easy case. So I don't see a reason to remove configurable vendor property. Actually it seems this property will be not configurable in most cases because installer write only one non-empty JDK path in the startup script. So it is mostly informative property than configurable. But there is still an option (rare) to modify script file manually and write there several jdk's with different vendor. Anyway : I need to parse startup script to find JDK home. Vendor will be found just as an additional information. If you have other proposition how to find JDK path please let me know. Thanks.
(In reply to comment #10) > Hm. > Actually access to JDK home requires parsing of startup script. > I don't see the other way how to know JDK . I'm ok with that. > > JAVA_HOME is set to preconfigured default value in case when no > vendor is set. Finding this case is a most difficult task . > Having known vendor variable is set is very easy case. > So I don't see a reason to remove configurable vendor property. Ok might be useful. I would definitely give up on radioboxes, combo is better I think. > Actually it seems this property will be not configurable in most cases > because installer write only one non-empty JDK path in the startup script. > So it is mostly informative property than configurable. > But there is still an option (rare) to modify script file manually and write > there several jdk's with different vendor. I was just worried that the thing similar to what Petr observed could happen anyway in some special vendor/home configuration - that would be bad and that's the reason why I suggested to remove the config and just display the info and do not pass any vendor or java_home on server startup. If you think you can prevent such state I have no objections. > Anyway : I need to parse startup script to find JDK home. Vendor will be > found just as an additional information. > If you have other proposition how to find JDK path please let me know. > Thanks.
>Ok might be useful. I would definitely give up on radioboxes, combo is better I >think. Radio cannot be used with current information definitely . Combobox is bettt
>Ok might be useful. I would definitely give up on radioboxes, combo is better I >think. Radio cannot be used with current information definitely . Combobox is better absolutely. >I was just worried that the thing similar to what Petr observed could happen >anyway in some special vendor/home configuration - that would be bad and that's >the reason why I suggested to remove the config and just display the info and >do not pass any vendor or java_home on server startup. If you think you can >prevent such state I have no objections. You are right. I will handle such possible situation . This issue appears because of some vendor is suggested to be used. In case when no vendor was found : Sun is used. But there is no JDK for Sun vendor. So JAVA_HOME was set to empty value. I will care about such case and no vendor will be set if it is not found. startup script will set JAVA_HOME based on empty vendor.
It seems that parsing the script is too much work just to fix this simple regression. Previously, server startup worked fine without parsing the script... I agree that just displaying the info and not passing vendor to the script sounds like the most safe fix. If we decide to put in the combo box, it may be a good idea to have an option called Default, which will not pass any vendor to the script, and then just hardcode the list of vendors we know about (and which are available on your platform).
changeset: 174880:f1bffd927fd1 user: Denis Anisimov <ads@netbeans.org> date: Wed Jul 28 21:49:00 2010 +0400 summary: Fixes for
Integrated into 'main-golden', will be available in build *201007290001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/f1bffd927fd1 User: Denis Anisimov <ads@netbeans.org> Log: Fixes for BZ#188903 - New: Java home not detected correctly on Mac, WebLogic does not start BZ#188904 - New: Field for server port in the customizer is too narrow BZ#188907 - New: NumberFormatException in line convertor
Hi Denis, thanks - I now see the combo with one option "Default" on my Mac, but starting the server still does not work. When I start the server, the progress bar saying "Starting Oracle WebLogic Server" appears, but the output window does not open, and nothing new appears in the server log. There is one related thread in the thread dump: "Default RequestProcessor" daemon prio=1 tid=101aa9800 nid=0x152c75000 waiting on condition [152c74000] java.lang.Thread.State: TIMED_WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <1066c0118> (a java.util.concurrent.CountDownLatch$Sync) at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:198) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:947) at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1239) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:253) at org.netbeans.modules.j2ee.deployment.impl.ProgressObjectUtil.trackProgressObject(ProgressObjectUtil.java:110) at org.netbeans.modules.j2ee.deployment.impl.ServerInstance._start(ServerInstance.java:1453) at org.netbeans.modules.j2ee.deployment.impl.ServerInstance.startTarget(ServerInstance.java:1402) at org.netbeans.modules.j2ee.deployment.impl.ServerInstance.startTarget(ServerInstance.java:1207) at org.netbeans.modules.j2ee.deployment.impl.ServerInstance.start(ServerInstance.java:1084) at org.netbeans.modules.j2ee.deployment.impl.ui.actions.StartAction$1.run(StartAction.java:110) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1426) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1968) I was thinking whether this was caused by missing VM options, so I added '-Xmx1024m -XX:PermSize=256m' to the VM options textfield, but that did not help. Can you please investigate? Thanks.
Could you please provide full text from output window of WL start.
As I wrote, the output window does not even appear. Also looking at the process manager, the server process does not exist. I also verified that from the command line, it starts fine.
Through debugging I found out that vendor was null, and the process start task was throwing NPE. Fixed here: http://hg.netbeans.org/web-main/rev/b79a01103026. Is that the right fix, Denis?
Right, just some improvement . changeset: 175004:be958bbca1dc tag: tip parent: 175003:365f6c81684a parent: 174947:59e84ec4d0e7 user: Denis Anisimov <ads@netbeans.org> date: Thu Jul 29 16:19:12 2010 +0400 summary: Fix for BZ#188903 - Java home not detected correctly on Mac, WebLogic does not start
Integrated into 'main-golden', will be available in build *201007300001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/b79a01103026 User: pjiricka@netbeans.org Log: #188903 - making sure the process is started correctly if vendor is null.