I see in line 116 of org.netbeans.modules.compapp.jbiserver.JbiManager
   public static boolean isRunningAppServer(String serverInstance) {
       if (serverInstance == null) {
           return false;
       }

       J2eePlatform platform =
Deployment.getDefault().getJ2eePlatform(serverInstance);
             if (!isAppServer(platform)) {
           return false;
       }
             // Can't get the ServerInstance directly from the platform! Get the
info from layer.
             Properties properties = getServerInstanceProperties(serverInstance);
             String url = properties.getProperty(URL_ATTR);
       String userName = properties.getProperty(USERNAME_ATTR);
       String password = properties.getProperty(PASSWORD_ATTR);
             String plugin = Deployment.getDefault().getServerID(serverInstance);
             if (url != null && userName != null && password != null && plugin
!= null) {
           StartServer startServer = getStartServer(plugin, url, userName,
password);
           if (startServer != null) {
               return startServer.isRunning();
           }
       }
       return false;
   }


First of all, there is no guarantee that the password get from
properties.getProperty(PASSWORD_ATTR); is correct.
It can be emtpy is the user decides NOT to store it for security reasons.

Only our plugin caches it in memory when prompted.
Then, this code is not handling the runtime exception.

There is some difficulty to really know if a server is running if we do  not
know the password. It could be another instance of a different server there
(7.0, 8.1, 9,x etc).


Line 197 of this file also uses private APIS to search and construct a
Deployment manager and you'll pass the WRONG password there again (not the one
cache).
This was never meant to be used this way...

See:
   private static StartServer getStartServer(String plugin,
           String url, String userName, String password) {
       try {
           FileSystem defaultFileSystem =
Repository.getDefault().getDefaultFileSystem();
           FileObject file = defaultFileSystem.findResource(
                   "/J2EE/DeploymentPlugins/" + plugin + "/Factory.instance");
// NOI18N
                     DataObject dob = DataObject.find(file);
                     InstanceCookie cookie = (InstanceCookie)
dob.getCookie(InstanceCookie.class);
                     DeploymentFactory deploymentFactory =
                   (DeploymentFactory) cookie.instanceCreate();
           DeploymentManager deploymentManager =
                   deploymentFactory.getDeploymentManager(url, userName,
password);                                 file = defaultFileSystem.findResource(
                   "J2EE/DeploymentPlugins/" + plugin +
"/OptionalFactory.instance");  // NOI18N                     dob =
DataObject.find(file);                     cookie = (InstanceCookie)
dob.getCookie(InstanceCookie.class);                    
OptionalDeploymentManagerFactory deploymentManagerFactory =
                   (OptionalDeploymentManagerFactory) cookie.instanceCreate();
                     StartServer startServer =
deploymentManagerFactory.getStartServer(deploymentManager);
                     return startServer;
       } catch (Exception e) {
           e.printStackTrace();
       }
             return null;
   }


Who owns org.netbeans.modules.compapp.jbiserver.JbiManager ? 

I also see a println left over in our StartServer line 648. We should remove it.

Mike: Please attach your NBUSERDIR/config/J2EE/InstalledServers/.nbattr file

I need to know if the password there is empty, or if not if it is the correct one .

I am the owner of this piece of code in CompApp Project. After fixing the
println in StartServer, you can assign this issue to me.

Are you saying that I should ask the user for the password if the password is empty?

What's the corrected way to check the server status here?

Or maybe our DMFactory could return a cached DM that already has the correct
password. This way, you would get a correct DM, without changing your code.
I would not want to ask 2 times the password to the user.

The point is more at the ARC/DEVREV level: I am not sure such lookup was
supposed to be used this way..
Maybe Pavel can add his view on that. I am glad we detected this dependancy now :-)

adding venkat from JBI Manager team

*** Issue 85147 has been marked as a duplicate of this issue. ***

Test scenarios include
a/
1/ start the ide, server not running
2/ enter wrong u/p in the serve props (p not empty)
3/ deploy an app or start the server 
4/ enter wrong u/p in popup dialog more than once, then 
test the cancel effect, or test the correct u/p entry effect
Cancel state should be known by the IDE. In case of cancel, it is ok to return
not ruuning if there is some user action that would trigger again the popup for u/p

b/ same as a/ but with an empty password. See the effect when entering the
correct u/p in the popup: nothing should be saved.

From a/ or b/ (ie. server and IDE running), we also need to test the effect of a
u/p change: either from the IDE via the server props or externally if let say
the amdin person decides to change its password while the IDE and the server is
running: what is the impact there.


Maybe the thing to do is to trap the exception in isrunning and do nothing but
returning false. I think this was the effect we had before. This RT exception is
not currently well handled by people calling use, so we could remove it, and
maybe only enter an entry in the server log in the IDE (we can do that now)

Also, the change you did in a previous p2 fix is good there for this bug as
well: now the DM factory has a cache of DMs, so that it returns DMs that have
correct status initialized (local, secured, etc).

So the mentioned JBI code should be ok (maybe not in terms of API  contract, but
at runtime :-)

*** Issue 85498 has been marked as a duplicate of this issue. ***

*** Issue 85819 has been marked as a duplicate of this issue. ***

I see this behaviour now after reverting 71222 always on my mac duo intel on
this sequence:
start the ide, srat the server from RTT
have a web app: run it: it works
run it again: you see the message and run stops.
But on the simple cpu laptop, I did not this the beahviour.

We spent the afternoon with Vince and Peter W on this, looking at the different
threads involved as well as an astronomous number of DM created. After caching
these DMs in a weak map in the factory so that we have exactely 1 dm per
instance (remember the dm  has a lot of state saved like: secure, local,
started, good U/P, etc etc,) I cannot reproduce this. So this seems to be the
solution.
I tried many times since then both on the mac duo and a single xp laptop, and
the issue is gone with this DM creation optimization.
I think this the correct fix so far. It also has a nice side effect for
performance: testing if a server is secure, or has the correct password is
costly and was done many many times at each DM creation previously.

Will do more testing to make sure we avoid any regression there, but the fix
does not add any synchronized statement and I did not see any locks with it so far.

It is still possible the that root cause of the bug is due to bad multi threaded
behaviour of the server backend APIs (AMX and 88) which is seen in bug 77122
when multiple threads can call apis at DM init that are now done only once for
the only DM per instance. This way, we limit the effect of 77122.

Created attachment 34755 [details]
patched files

Created attachment 34756 [details]
diff patches

Vince and I tested a lot the proposed change during the W.E. 
For me, it is OK to integrate in dev branch.  I would prefer to do that now, so that this can be verified soon 
by QE and the bug filers asap on monday.

commit to release55_dev

http://serverplugins.netbeans.org/source/browse/serverplugins/sun/appsrv81/src/org/netbeans/modules/j2ee/sun/ide/dm/SunDeploymentFactory.java?r1=1.3.8.4.2.3.2.2&r2=1.3.8.4.2.3.2.3
http://serverplugins.netbeans.org/source/browse/serverplugins/sun/appsrv81/src/org/netbeans/modules/j2ee/sun/ide/dm/SunDeploymentManager.java?r1=1.10.4.5.2.16.2.2&r2=1.10.4.5.2.16.2.3
http://serverplugins.netbeans.org/source/browse/serverplugins/sun/appsrv81/src/org/netbeans/modules/j2ee/sun/ide/dm/Bundle.properties?r1=1.4.8.2.2.3&r2=1.4.8.2.2.3.2.1
http://serverplugins.netbeans.org/source/browse/serverplugins/sun/appsrv81/src/org/netbeans/modules/j2ee/sun/ide/j2ee/StartSunServer.java?r1=1.4.4.6.2.19.2.3&r2=1.4.4.6.2.19.2.4

I played with the today's build and I have not seen this problem again. So not
reproducible after the latest changes. 

I used 10/2 release55_dev build to verify this wrong password and user id issue,
I deploy a archived stateless ejb app for 10 times and I did not see this wrong
password error message once, before the fix I was able to see the wrong password
error message at lease once for every 5 redeployment.

I also tried with IDE sample app WebJpa, I redeploy it 5 times and did not see
this wrong password message which I saw the error message before the fix. 
However at the 5th redeploy of this sample app, the IDE hang, I showed the error
to Vince and he collected the thread dump, he thinks it could be the same issue
as bug 77122.

So the fix for this bug "wrong password" is verified. The fix is working for me.  

check into release55

http://serverplugins.netbeans.org/source/browse/serverplugins/sun/appsrv81/src/org/netbeans/modules/j2ee/sun/ide/dm/SunDeploymentManager.java?r1=1.10.4.5.2.16&r2=1.10.4.5.2.17
http://serverplugins.netbeans.org/source/browse/serverplugins/sun/appsrv81/src/org/netbeans/modules/j2ee/sun/ide/dm/SunDeploymentFactory.java?r1=1.3.8.4.2.3&r2=1.3.8.4.2.4
http://serverplugins.netbeans.org/source/browse/serverplugins/sun/appsrv81/src/org/netbeans/modules/j2ee/sun/ide/dm/Bundle.properties?r1=1.4.8.2.2.3&r2=1.4.8.2.2.4
http://serverplugins.netbeans.org/source/browse/serverplugins/sun/appsrv81/src/org/netbeans/modules/j2ee/sun/ide/j2ee/StartSunServer.java?r1=1.4.4.6.2.21&r2=1.4.4.6.2.22

*** Issue 86331 has been marked as a duplicate of this issue. ***

I used 10/5 release55 build to verify the fix, the fix works, the test result I
got is the same as the one I described in above when I was testing with
release55_dev build.

I am marking this bug as verified.