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.
For some reason I can't connect to remote Sun application servers anymore. At first I suspected the web proxy settings to be faulty (I usually specify the webproxy and override it through the use of No Proxy Hosts) but nothing. Then I tried running the IDE with "no proxy" and also making sure that the local environment variable "http_proxy" wasn't set; that too didn't help. Then I took a closer peek at the server I setup and noticed that even though I specified a type of "Sun Java System Application Server" it automaticly changed back to "Glassfish V2". The remote server I'm trying to connect to is the Sun System Application Server Platform Edition 9.0_1 (build b02-p01) which is the same version I have installed locally. Considering that this setup simply works as it should on NetBeans 5.5.1 I can't help suspect this to be a bug in 6.0 beta1. With kind regards, Peter
Which Linux are you running? What was the value of the Platform Location field when you registered the remote instance? If you installed GF V2 when you installed 6.0 beta 1, you may have registered the remote domain with the platform set to the GF V2 installation directory. I do not know if the installer will prevent you from overwriting the 9.0_1 bits with GF V2 bits, also....
My Linux version is Ubuntu 6.06 LTS (the "long term support" version). So not the latest & greatest but simply a working environment. The value of the platform location field was /opt/SDK. This is the directory in which I've installed the Sun AS PE 9.0. The Glassfish server which I installed together with NB6 is located in /home/peter/java/glassfishv2. I made very sure to leave these two seperated (the PE 9 server is the one which I also use for production). I noticed this behaviour because all servers got the "fishhead" icon while I was used to the Sun logo.
I tried to reproduce the problem with the environment below: Glassfish V2 FCS build (b58g) Linux Machine: Ubuntu 7.04 version Netbean nightly 09/25/2007 build installed on a WinXP machine I found no problem to add the remote Ubuntu domain1 to the netbean Services Servers List Machine: ubuntu.sfbay.sun.com Admin Port: 4848 Admin Username/password: admin/adminadmin
I will do some investigation with 9.0 and recent 6.0 bit tomorrow.
has the admin port on the remote AS domain been secured?
which JDKs are you using? For NB on your local machine and GF on the remote machine....
I don't have an Ubuntu box any more. tested: nb 6.0 recently updated bits, no personal changes that overlap remote registration. built with jdk 1.5 update 12, running under jdk1.5 update 12. Platform set to recently "installed" v1 update 1 patch 1 bits downloaded from GF.d.j.n. Clean userdir. I did not import my settings when the IDE started. Solaris. Remote server recently downloaded and installed v1 update 1 patch 1 bits. Running under JDK 6 update 2. Windows Vista I was able to register the instance in NetBeans and "explore it" in the Services explorer.
I did another test: I cleared my old 5.5.1 userdir. I started up 5.5.1 and registered the remote instance. I was able to explore it... I exited out of 5.5.1. I started up my nb 6 bits, with a new userdir specified AND the com.sun.aas.installRoot property set to my V2 b58g bits. When the IDE asked if I wanted to import my settings, clicked Yes. When the IDE finished opening... I switched to the services tab and saw that there were TWO domains registered. The remote instance was running and I was able to 'explore it", the local v2 domain (which was automatically registered when the IDE started) was not connected (since it wasn't running)... I have not been able to reproduce this issue so far. If you could provide more details of what you are seeing and doing (especially when you start up the IDE the first time and register the remote domain), I would appreciate it.
waiting for detail from filer.
status: I have tried to reproduce the issue and failed. I have requested that another member of the team reproduce the issue and they have failed. I have requested more info from the original filer and have waited for about a week. Please reopen this issue with details when they become available.