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 84242 - Error deploying to AppServer if AS was started outside NetBeans
Summary: Error deploying to AppServer if AS was started outside NetBeans
Status: RESOLVED FIXED
Alias: None
Product: serverplugins
Classification: Unclassified
Component: Sun Appserver 9 (show other bugs)
Version: 5.x
Hardware: PC Windows XP
: P2 blocker (vote)
Assignee: Vince Kraemer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-09-05 18:27 UTC by chaase3
Modified: 2006-09-12 20:21 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description chaase3 2006-09-05 18:27:55 UTC
With the current Q build
(netbeans-5_5-qbuild-bin-200608181330-windows-18_Aug_2006_1330.exe) I am having
a problem not seen in NB 5.5 beta 1. 

If I use the Sun Java System Application Server's own commands to start the
AppServer from outside NetBeans, then when I try to deploy an application in
NetBeans, I get an error: 

Another process is using the administrative port: 4,848

NB is trying to stop and restart the AppServer before deploying the app. It used
to perform this task, and it always succeeded in doing so. Now it gets this
error and fails. Now I can only deploy an app to the AppServer if I don't start
the AppServer outside of NB. NB only recognizes the AppServer if NB started it.

This is a significant regression from previous builds. The Tutorial has always
provided instructions on how to start and stop the AppServer. If this problem is
not fixed, we will have to explicitly state that users MUST NOT start the
AppServer if they will be using NetBeans, only if they will be using Ant. This
seems to expose a bug in NetBeans, which seems undesirable.
Comment 1 _ ludo 2006-09-05 21:15:39 UTC
regression  from a fix related to profiler bug.
Vince, take a look.
Comment 2 Vince Kraemer 2006-09-06 19:45:04 UTC
I just did a clean check-out and build of release55 on WinXP and ran it against
jdk1.5.0_06.

I am using GF v1 u1 b5, which I started outside the IDE.

I created an ent app that has a simple web app in it.

I used Debug Main Project to force a stop/start and could not replicate the
issue described by the filer.

Need more info to duplicate. 

Server build?
JDK in use by NB and server?
output window content for the deploy command?
relevant server log content?
Project that demonstrates this issue?

Please reopen with more detailed information, if this issue persists in recent
daily builds...
Comment 3 chaase3 2006-09-06 20:30:38 UTC
Cannot reproduce using latest daily build
(netbeans-5_5-daily-bin-200609050000-windows-5_Sep_2006_0000.exe).

Was using server build sjsas_pe-9_0-fcs-bin-b48-windows-04_may_2006.exe with JDK
1.5.0_06.

Project that demonstrated issue was the Java EE tutorial example
examples/web/hello1 (the first application in the Tutorial, in Chapter 2).
Comment 4 _ ludo 2006-09-06 20:48:45 UTC
Vince: the user was able to see this behaviour.
The check was added recently, and I am not sure why. We have extensive uimpl for
isRunning() which is much more than a socket lookup.
Not reproducible yet does not mean we can ignore this bug.
Reopening, to see how we can avoid this check to that it will never happen...
Comment 5 Vince Kraemer 2006-09-06 21:53:55 UTC
portInUse check was added to fail fast, if the server would not be able to start
due to some other process running on port the admin port.  The most common case
is when the user has multiple servers registered on the same admin port....

If you have a registered instance A with admin port Z running and then try to
start registered instance B, that also uses port Z, the start operation for
registered instance B takes a long time to fail and the message about the
failure is full of false positives for the root cause...

This change is actually related to issue 81422
Comment 6 Vince Kraemer 2006-09-12 20:21:35 UTC
it looks like ludo fixed this, by commenting out the message