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.
I think that GlassFish should be fully available if downloaded and installed with the IDE distribution. This was so before 7.0.1. Now there is only Tomcat and one has to register GlassFish manually. This is not a problem for myself, but for people who I advise, for example to run a maven testcase, "just download NetBeans EE, run it and select GlassFish". How to reproduce: Start NetBeans the first time, or with an empty userdir. Open any web project, e.g. Maven web project and try to run it. NetBeans doesn't know how to run the project because it doesn't know that the installer has installed GlassFish. Prompts with: "Select deployment server" The dialog has an entry for the Tomcat server that the installer installed but no GlassFish.
did the user import their settings? Did the installer actually install glassfish? It seems like this is an installation issue... but the steps to reproduce do not include info on how the IDE was installed.
- Did the user import their settings? No - Did the installer actually install glassfish? Yes - the steps to reproduce do not include info on how the IDE was installed? I download the full version (everything) and run the installer. To me it appears trivial how to get this issue but I might be missing something. I download NetBeans full version (everything) and install it. When I start it the first time then it asks me to import user settings. I don't let it import user settings. My aim is to get a 100% fresh start as to not complicate things. I use a new userdir to emulate the same fresh scenario. I can reproduce this with an empty userdir always with any project that requires a server. Have you tried it?
I have not been able to reproduce this... though I am on 7, not Vista. Do you have a project that exhibits this behavior that you can share? If yes... please attach it to this issue.
This is not related to any project. Any web example project will do. I use ServletStateless. My observations: 1) On IDE installation, GlassFish is installed, but no registered while Tomcat is. 2) When starting with fresh userdir, each time I am asked again to register GlassFish. These are two distinct problems. If GlassFish registration was in fact on global IDE level (not userdir level), then the registration should stick, and the IDE should not ask me again with every new userdir. So where on my computer should I check where GlassFish should be registered for the case where I start with a new userdir? Somehow there must be a logic that checks this - the proof is that it works for Tomcat. In my case it appears that the GlassFish registration sticks only with the userdir. If I start 6.9 with a new userdir then it also activates Java Web and EE and it complains that no server is registered. So I register the server. Then I empty the userdir and start again with the same userdir then again complains. The issue with 7.01 is that Tomcat is always registered but GlassFish isn't, and I think that is not in the interest of Oracle/NetBeans and BTW I don't want to mention Tomcat anymore because I use EJB3 not Spring.
please attach the IDE log associated with a 'first start' of a new userdir where/when you see this problem. I haven't been able to replicate it... so there may be something like install location that are contributing to this problem. The log is likely to have enough details to make progress on this issue. closing as incomplete for now. please reopen when the log is attached.
- Empty userdir - Start NetBeans with "C:\Program Files\NetBeans 7.0.1\bin\netbeans.exe" --userdir C:\tmp\userdir - Decline Confirm Import Settings with [No] - Menu|File|New Project|Samples|Java Web|Servlet Stateless (Java EE6) Finding Feature, Activating Java Web and EE - Dialog "Enter Master Password" [OK] Dialog "Open Project", "Resolve Missing Server Problem" [Close] - Projects window, ServletStateless is red, Right click "Resolve Missing Server Problem" [Cancel]
Created attachment 110550 [details] log file
Created attachment 110551 [details] screen shot
Hmmm. I followed your steps and am not able to replicate the behavior. I installed 7.0.1 onto a Win 7. I started it using the command-line and a fresh userdir... I created a copy of the ServletStateless sample... I ran the sample successfully. Where did you install glassfish 3.1.1 when you installed 7.0.1? what is the content of C:\Program Files\NetBeans 7.0.1\nb\config? Do you have the following files... GlassFishEE6WC\Instances\.nbattrs GlassFishEE6WC\Instances\glassfish_autoregistered_instance J2EE\InstalledServers\.nbattrs J2EE\InstalledServers\tomcat_autoregistered_instance JavaDB\.nbattrs JavaDB\registration_instance
need more info... see https://netbeans.org/bugzilla/show_bug.cgi?id=201506#c9 NOTE: if there is a C:\Program Files\NetBeans 7.0.1\nb\config\GlassFishEE6WC\Instances\.nbattrs, please attach it. If there is a C:\Program Files\NetBeans 7.0.1\nb\config\J2EE\InstalledServers\.nbattrs, please attach it. If there isn't a C:\Program Files\NetBeans 7.0.1\nb\config\GlassFishEE6WC\Instances\.nbattrs, then the issue is likely to be in the installer code.
Re: Do you have the following files... GlassFishEE6WC\Instances\.nbattrs no, only up to folder GlassFishEE6WC\Instances\ GlassFishEE6WC\Instances\glassfish_autoregistered_instance no, only up to folder GlassFishEE6WC\Instances\ J2EE\InstalledServers\.nbattrs yes J2EE\InstalledServers\tomcat_autoregistered_instance yes JavaDB\.nbattrs yes JavaDB\registration_instance yes
attachments? see https://netbeans.org/bugzilla/show_bug.cgi?id=201506#c10
Do you have answers for the other questions in https://netbeans.org/bugzilla/show_bug.cgi?id=201506#c9
Created attachment 110906 [details] C:\Program Files\NetBeans 7.0.1\nb\config\J2EE\InstalledServers\.nbattrs Re Comment https://netbeans.org/bugzilla/show_bug.cgi?id=201506#c10, there isn't a C:\Program Files\NetBeans 7.0.1\nb\config\GlassFishEE6WC\Instances\.nbattrs The directory is empty.
Created attachment 110907 [details] C:\Program Files\NetBeans 7.0.1\nb\config in zip file
Created attachment 110913 [details] the nbattrs file from J2EE\InstalledServers replaces the octet steam with test/plain mime type..
Based on the description and evidence, it seem like the installer did not write the files necessary to associate the GF install with the NB install. A plugin code change is not going to be able to address this. Reassigning the issue to the folks responsible for the installer.
Please attach installer log that corresponds to the latest NetBeans 7.0.1 installation. %USERDIR%\.nbi\log\*.log
Created attachment 110935 [details] latest 3 installer log files in zip file
According to the logs you attached the registration of GlassFish Server Open Source Edition 3.1.1 with Base IDE installed at C:\Program Files\NetBeans 7.0.1 completed successfully (see log [1]). So there are two possible reasons of the issue: 1) org.netbeans.modules.glassfish.common.registration.AutomaticRegistration didn't create registration files. I'll try find Windows Vista and install NB 7.0.1 + GF 3.1.1 to see if that is the case. 2) registration files were somehow manually deleted after the installation. bht, could you please try to reproduce the issue to be sure this is a really P2 bug. Thanks in advance. [1]: [2011-08-05 11:13:02.828]: ... integrate GlassFish Server Open Source Edition 3.1.1 with Base IDE installed at C:\Program Files\NetBeans 7.0.1 [2011-08-05 11:13:02.828]: executing command: C:\Program Files\Java\jdk1.6.0_25\jre\bin\java.exe -cp platform/core/core.jar;platform/lib/boot.jar;platform/lib/org-openide-modules.jar;platform/core/org-openide-filesystems.jar;platform/lib/org-openide-util.jar;platform/lib/org-openide-util-lookup.jar;ide/modules/org-netbeans-modules-glassfish-common.jar org.netbeans.modules.glassfish.common.registration.AutomaticRegistration C:\Program Files\NetBeans 7.0.1\nb C:\Program Files\glassfish-3.1.1\glassfish, in directory: C:\Program Files\NetBeans 7.0.1 [2011-08-05 11:13:04.687]: [return]: 0 [2011-08-05 11:13:04.687]: ... command execution finished
The problem disappeared.