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.
versions: weblogic 9.1 jre: bundled jrocket description: after adding the wl server to NB50RC1, and invoking "Projects->Servers->BEA Weblogic Application Server 9.0", weblogic startup, seemingly correctly. The final entry in the server output window is "<Jan 18, 2006 11:14:08 AM CST> <Notice> <WebLogicServer> <BEA-000360> <Server started in RUNNING mode> ". However, NB doesn't apparently detect the successful startup. The progess indicator continues to remain active for a very long time (approx 5 minutes). Eventually, an error dialog comes up that states "BEA Weblogic Application Server 9.0 start failed. At this point, if you exist NB, the windows Task Manager will show two running java processes. These have to be killed manually. Seems like pretty much a show stopper for using the integrated weblogic functionality, so have indicated P1 severity.
Update (1/18/06): I created my own domain, specifying jdk1.5.0_6 as the default jdk, and created a new NB weblogic server. This times the results were slightly different. This time after the server successfully started up, I didn't get an error dialog. However, NB still didn't seem to detect the successful start up. This was indicated by the fact that the start icons for the server were active and the "stop the server" icon button was inactive. Once I was able to get the servet to register the correct status by clicking on the "refresh the server status" button. On all other occasions, pressing the refresh buttom resulted in a pause, and then resumption of the incorrect status.
Could you please check the issue 67170? It is about a similar problem - wrong server state detection - we saw some locks in the thread dump. We try to obtain weblogic's deployment manager, but after several tries the call is blocked inside of weblogic. We are waiting for some time (it would explain thos 5 minutes) and if if there is no answer we simply return and expect the server is stopped. Are you able to reproduce it always or randomly? What could help us is a thred dump created in time when NB is detecting the state. It can say whether it is the same problem or not.
We are also supporting WebLogic 9.0 only. I personally tried it to run and it worked but version 9.1 was not tested by our QA team, thus we cannot guarantee no problems. Please try it with version 9.0.
btw, refreshing node in the Runtime tab invokes the same mechanism as the one in the startup time. There are some differences when running on Sun JDK or WL JRockit but both cases are a little bit unpredictable. I spent quite a lot of time of stabilize it a little but only good way seems to be changing the detection mechanism. It was too late to change it, thus we agreed to postpone it to the next release. My personal estimate is that your problem is the same as in (or close to) the issue I mentioned earlier. Please help us to evaluate this issue as soon as possible. Thank you.
For thread dump follow: http://qa.netbeans.org/bugzilla/generating-thread-dumps.html I remember some issue on tomcat where server state detection was done via creating a Socket. It very rarely did not work on Windows because of some bug in the Sun JDK. In WL plugin we also first try to check whether the port is not bound. It can also be the problem, unless it is already fixed in JDK.
The reporter wrote following: "Today, I'm trying this with both WL9.0 and WL9.1 and it's working. The only issue is that occasionally I'll have to press the refresh button, but this workaround works reliably now whereas yesterday it didn't. One difference is that today I'm running RC2 and yesterday I was running RC1 (I accidentally deleted by RC1 installation). There is another difference as well. Instead of using the out-of-the-box WL examples domain, I created and used one of my own. But, anyway now this problem does look very much like the other that you referred me to in your earlier email. You can mark mine as a duplicate, and now that the refresh button works reliably as a workaround, P3 seems to be a suitable priority setting." (The issue mentioned in the quotation is the issue 67170). Decresing the priority to P2, marking as duplicate. *** This issue has been marked as a duplicate of 67170 ***