One of the successful portlets I had built when I had been using NetBeans 6.1 made a WFS call and displayed the returned features on an OpenLayers map. I knew that I would be wanting to make some enhancements to that portlet and opened the project in my newly installed 6.5 version of Netbeans. The clean and build was successful but the Run and Deploy wouldn't work.
The Run/Deploy tab of the IDE showed these errors:
Deployment Started
Deployment Failed
C:\Documents and Settings\536116\My Documents\NetBeansProjects\TestWFS\nbproject\build-impl.xml:550: The module has not been deployed.BUILD FAILED (total time: 2 seconds)
Opening up the build-imp.xml file didn't provide any clues as to what might be causing the deployment failure.
The IDE log had a lot of incomprehensible messages related to the portlet. Many of them appeared before the message about the failed deployment of the portlet and were "java.lang.IllegalStateException" messages about trying to access a file from the "default package." There was a recommendation to
Please see http://www.netbeans.org/download/dev/javadoc/org-openide-modules/org/openide/modules/doc-files/classpath.html#default_package
Looking at that web page didn't help. It was obviously outdated, not even having a "default_package" section.
The only thing I could think of was that maybe I hadn't installed everything that was needed for portlet development. Did I need to do some additional plugins or update plugins after going from 6.1 to 6.5? I had installed Portal Pack 2.0 when I was using the earlier NetBeans version. Was I now supposed to install the latest Portal Pack 3.0 M2? I thought I had read somewhere that those plugins were included with the IDE download. I thought I remembered that right after the installation I had gone to the Plugin Manager and enabled 5 plugins related to portlets that were already in the "to be installed" section. I spent a lot of time trying to find the right documentation for portal pack and NetBeans and Portlet Container wondering what I had overlooked. Surely if a portlet was built with NetBeans 6.1 there shouldn't be additional changes needed to import the project into NetBeans 6.5.
Finally I decided that I would do a simple test and build a HelloWorld portlet in NetBeans 6.5. I discovered that the same failure to deploy was occurring. But this time I noticed these errors in the Portlet Container tab:
CLI171 Command deploy failed : Deployment of application failed - Invalid user or password java.lang.Exception: Deployment on Glassfish failed at org.netbeans.modules.portalpack.servers.jnpc.impl.SunAppServerDeployHandler.deployOnGlassFish(SunAppServerDeployHandler.java:103) at org.netbeans.modules.portalpack.servers.jnpc.impl.SunAppServerDeployHandler.deploy(SunAppServerDeployHandler.java:175) at org.netbeans.modules.portalpack.servers.jnpc.impl.JNPCTaskHandler.deploy(JNPCTaskHandler.java:89) at org.netbeans.modules.portalpack.servers.core.PSDeployerImpl.run(PSDeployerImpl.java:148) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:572) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:997)PortalPack Message : Deployment Failed : Deployment on Glassfish failed
I went into the properties for Portlet Container and in the Server Config tab found fields for User Name and password. Admin was the User Name that was filled in but password field was blank. Apparently, that was the step that I missed. When I typed in the admin password and applied the change I was then able to deploy the portlet. Back in business for building GIS portlets, but, once again, wondering what documentation I had overlooked that would have explained about the extra configuration step for the Portlet Container.
Friday, December 26, 2008
Saturday, December 13, 2008
NetBeans 6.5 and GlassFish v2ur2
Having finally gotten NetBeans 6.5 successfully installed my next goal was to build and deploy an application developed by a member on my team that looked up geospatially-enabled information from geonames.org and created a KML file of the output. I had already successfully done this with the code and NetBeans project files provided by the team on a previous version of NetBeans using the instance of GlassFish v2ur2 that was configured within NetBeans. It compiled and deployed with no problems. It was a service that when it was running I could access and display the returned KML file on an OpenLayers map within a portlet that was on the same instance of GlassFish.
But, for a true test, rather than doing it all within NetBeans, I wanted to take the WAR file that NetBeans created and deploy it remotely to a different instance of GlassFish. That proved to not be as easy. The instance of GlassFish I wanted to deploy to was running on a laptop with Windows Vista. I zipped up the WAR file on the Windows XP laptop, emailed it to myself, and downloaded it to the Windows Vista laptop. Windows Vista, in all its wisdom, kept insisting that the WAR file was a file type of "Directory", which really it is, but to move it into the .autodeploy folder of GlassFish I didn't want it expanded like Vista kept insisting. I finally resorted to the DOS command line to get done what I needed to do.
Once the WAR file was in the autodeploy folder the war_deployed file appeared, indicating the deployment was successful. But when I tried to display the index.jsp of the servlet in the browser, it displayed a "service is not available" page. Now it was time to look in the logs.
First I tried looking in the logs through the admin console. The log was filling up faster than I could scroll through in the window with messages that said:
WARNING *********** NetBeans HTTP Monitor ************ The request cannot be recorded most likely because the NetBeans
HTTP Server is not running. Go to the IDE and start the HTTP Server from within the Runtime window to fix this problem.
Now isn't that an aggravation. I didn't have NetBeans running and I didn't want NetBeans to be running so why should the server be complaining about a NetBeans feature not working? That's one of the problems with downloading and installing server and IDE packaged as one. They get dependent in a way that you may not necessarily want.
Doing a Google query of the error message I found this very helpful solution:
http://javahowto.blogspot.com/2008/12/disable-netbeans-httpmonitor-in.html
Rather than take the time to implement that fix, I looked at the log in NotePad. This is the NPE that was there:
[#2008-12-11T12:20:21.484-0500SEVEREsun-appserver9.1javax.enterprise.system.container.web_ThreadID=18;_ThreadName=Timer-15;_RequestID=bc574187-48c7-45d6-8456-6042df2f372f;WebModule[/GeonamesDotOrgLookupService]PWC1275: Exception sending context initialized event to listener instance of class mil.nga.to6.GeonamesDotOrg.ServiceListenerjava.lang.NullPointerException at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:433) at org.apache.log4j.PropertyConfigurator.configure(PropertyConfigurator.java:336) at mil.nga.to6.GeonamesDotOrg.ServiceListener.contextInitialized(ServiceListener.java:40) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4523) at org.apache.catalina.core.StandardContext.start(StandardContext.java:5184) at com.sun.enterprise.web.WebModule.start(WebModule.java:326) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:973) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:957) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:688) at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1584) at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1222) at com.sun.enterprise.server.WebModuleDeployEventListener.moduleDeployed(WebModuleDeployEventListener.java:182) at com.sun.enterprise.server.WebModuleDeployEventListener.moduleDeployed(WebModuleDeployEventListener.java:278) at com.sun.enterprise.admin.event.AdminEventMulticaster.invokeModuleDeployEventListener(AdminEventMulticaster.java:974) at com.sun.enterprise.admin.event.AdminEventMulticaster.handleModuleDeployEvent(AdminEventMulticaster.java:961) at com.sun.enterprise.admin.event.AdminEventMulticaster.processEvent(AdminEventMulticaster.java:464) at com.sun.enterprise.admin.event.AdminEventMulticaster.multicastEvent(AdminEventMulticaster.java:176) at com.sun.enterprise.admin.server.core.DeploymentNotificationHelper.multicastEvent(DeploymentNotificationHelper.java:308) at com.sun.enterprise.deployment.phasing.DeploymentServiceUtils.multicastEvent(DeploymentServiceUtils.java:226) at com.sun.enterprise.deployment.phasing.ServerDeploymentTarget.sendStartEvent(ServerDeploymentTarget.java:298) at com.sun.enterprise.deployment.phasing.ApplicationStartPhase.runPhase(ApplicationStartPhase.java:132) at com.sun.enterprise.deployment.phasing.DeploymentPhase.executePhase(DeploymentPhase.java:108) at com.sun.enterprise.deployment.phasing.PEDeploymentService.executePhases(PEDeploymentService.java:919) at com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:276) at com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:294) at com.sun.enterprise.admin.mbeans.ApplicationsConfigMBean.deploy(ApplicationsConfigMBean.java:555) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.sun.enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java:375) at com.sun.enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java:358) at com.sun.enterprise.admin.config.BaseConfigMBean.invoke(BaseConfigMBean.java:464) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784) at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.sun.enterprise.admin.util.proxy.ProxyClass.invoke(ProxyClass.java:90) at $Proxy1.invoke(Unknown Source) at com.sun.enterprise.admin.server.core.jmx.SunoneInterceptor.invoke(SunoneInterceptor.java:304) at com.sun.enterprise.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:174) at com.sun.enterprise.deployment.autodeploy.AutoDeployer.invokeDeploymentService(AutoDeployer.java:564) at com.sun.enterprise.deployment.autodeploy.AutoDeployer.deployJavaEEArchive(AutoDeployer.java:545) at com.sun.enterprise.deployment.autodeploy.AutoDeployer.deploy(AutoDeployer.java:492) at com.sun.enterprise.deployment.autodeploy.AutoDeployer.deployAll(AutoDeployer.java:267) at com.sun.enterprise.deployment.autodeploy.AutoDeployControllerImpl$AutoDeployTask.run(AutoDeployControllerImpl.java:374) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462)
Here is the rest of the log file related messages that appear after the NPE, interesting that startup failed yet it was considered successfully auto-deployed.
[#2008-12-11T12:20:21.484-0500SEVEREsun-appserver9.1org.apache.catalina.core.StandardContext_ThreadID=18;_ThreadName=Timer-15;_RequestID=bc574187-48c7-45d6-8456-6042df2f372f;PWC1306: Startup of context /GeonamesDotOrgLookupService failed due to previous errors#] [#2008-12-11T12:20:21.593-0500INFOsun-appserver9.1javax.enterprise.system.tools.deployment_ThreadID=18;_ThreadName=Timer-15;[AutoDeploy] Successfully autodeployed : C:\servers\glassfish\domains\domain1\autodeploy\GeonamesDotOrgLookupService.war.#]
I had gotten the code from my team member so wasn't that familiar with what it was doing. He gave me several pointers on what to look for and we finally determined that there were 9 files in the WEB-INF/classes folder that were in the NetBeans project, but did not get copied over in to the NetBeans WAR file. That meant we had a build issue. I had just taken the project files "as-is" and assumed all was well since it built, ran and deployed from within NetBeans. Makes you wonder why NetBeans can't detect such a situation as this.
Not being that knowledgeable with how to tweak the build within NetBeans, I did the workaround of manually copying the missing files into the WAR. I redeployed the new WAR file and this time it worked. Whew, another learning experience. Thanks to all who helped.
But, for a true test, rather than doing it all within NetBeans, I wanted to take the WAR file that NetBeans created and deploy it remotely to a different instance of GlassFish. That proved to not be as easy. The instance of GlassFish I wanted to deploy to was running on a laptop with Windows Vista. I zipped up the WAR file on the Windows XP laptop, emailed it to myself, and downloaded it to the Windows Vista laptop. Windows Vista, in all its wisdom, kept insisting that the WAR file was a file type of "Directory", which really it is, but to move it into the .autodeploy folder of GlassFish I didn't want it expanded like Vista kept insisting. I finally resorted to the DOS command line to get done what I needed to do.
Once the WAR file was in the autodeploy folder the war_deployed file appeared, indicating the deployment was successful. But when I tried to display the index.jsp of the servlet in the browser, it displayed a "service is not available" page. Now it was time to look in the logs.
First I tried looking in the logs through the admin console. The log was filling up faster than I could scroll through in the window with messages that said:
WARNING *********** NetBeans HTTP Monitor ************ The request cannot be recorded most likely because the NetBeans
HTTP Server is not running. Go to the IDE and start the HTTP Server from within the Runtime window to fix this problem.
Now isn't that an aggravation. I didn't have NetBeans running and I didn't want NetBeans to be running so why should the server be complaining about a NetBeans feature not working? That's one of the problems with downloading and installing server and IDE packaged as one. They get dependent in a way that you may not necessarily want.
Doing a Google query of the error message I found this very helpful solution:
http://javahowto.blogspot.com/2008/12/disable-netbeans-httpmonitor-in.html
Rather than take the time to implement that fix, I looked at the log in NotePad. This is the NPE that was there:
[#2008-12-11T12:20:21.484-0500SEVEREsun-appserver9.1javax.enterprise.system.container.web_ThreadID=18;_ThreadName=Timer-15;_RequestID=bc574187-48c7-45d6-8456-6042df2f372f;WebModule[/GeonamesDotOrgLookupService]PWC1275: Exception sending context initialized event to listener instance of class mil.nga.to6.GeonamesDotOrg.ServiceListenerjava.lang.NullPointerException at org.apache.log4j.PropertyConfigurator.doConfigure(PropertyConfigurator.java:433) at org.apache.log4j.PropertyConfigurator.configure(PropertyConfigurator.java:336) at mil.nga.to6.GeonamesDotOrg.ServiceListener.contextInitialized(ServiceListener.java:40) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4523) at org.apache.catalina.core.StandardContext.start(StandardContext.java:5184) at com.sun.enterprise.web.WebModule.start(WebModule.java:326) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:973) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:957) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:688) at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1584) at com.sun.enterprise.web.WebContainer.loadWebModule(WebContainer.java:1222) at com.sun.enterprise.server.WebModuleDeployEventListener.moduleDeployed(WebModuleDeployEventListener.java:182) at com.sun.enterprise.server.WebModuleDeployEventListener.moduleDeployed(WebModuleDeployEventListener.java:278) at com.sun.enterprise.admin.event.AdminEventMulticaster.invokeModuleDeployEventListener(AdminEventMulticaster.java:974) at com.sun.enterprise.admin.event.AdminEventMulticaster.handleModuleDeployEvent(AdminEventMulticaster.java:961) at com.sun.enterprise.admin.event.AdminEventMulticaster.processEvent(AdminEventMulticaster.java:464) at com.sun.enterprise.admin.event.AdminEventMulticaster.multicastEvent(AdminEventMulticaster.java:176) at com.sun.enterprise.admin.server.core.DeploymentNotificationHelper.multicastEvent(DeploymentNotificationHelper.java:308) at com.sun.enterprise.deployment.phasing.DeploymentServiceUtils.multicastEvent(DeploymentServiceUtils.java:226) at com.sun.enterprise.deployment.phasing.ServerDeploymentTarget.sendStartEvent(ServerDeploymentTarget.java:298) at com.sun.enterprise.deployment.phasing.ApplicationStartPhase.runPhase(ApplicationStartPhase.java:132) at com.sun.enterprise.deployment.phasing.DeploymentPhase.executePhase(DeploymentPhase.java:108) at com.sun.enterprise.deployment.phasing.PEDeploymentService.executePhases(PEDeploymentService.java:919) at com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:276) at com.sun.enterprise.deployment.phasing.PEDeploymentService.deploy(PEDeploymentService.java:294) at com.sun.enterprise.admin.mbeans.ApplicationsConfigMBean.deploy(ApplicationsConfigMBean.java:555) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.sun.enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java:375) at com.sun.enterprise.admin.MBeanHelper.invokeOperationInBean(MBeanHelper.java:358) at com.sun.enterprise.admin.config.BaseConfigMBean.invoke(BaseConfigMBean.java:464) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImpl.java:213) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784) at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at com.sun.enterprise.admin.util.proxy.ProxyClass.invoke(ProxyClass.java:90) at $Proxy1.invoke(Unknown Source) at com.sun.enterprise.admin.server.core.jmx.SunoneInterceptor.invoke(SunoneInterceptor.java:304) at com.sun.enterprise.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:174) at com.sun.enterprise.deployment.autodeploy.AutoDeployer.invokeDeploymentService(AutoDeployer.java:564) at com.sun.enterprise.deployment.autodeploy.AutoDeployer.deployJavaEEArchive(AutoDeployer.java:545) at com.sun.enterprise.deployment.autodeploy.AutoDeployer.deploy(AutoDeployer.java:492) at com.sun.enterprise.deployment.autodeploy.AutoDeployer.deployAll(AutoDeployer.java:267) at com.sun.enterprise.deployment.autodeploy.AutoDeployControllerImpl$AutoDeployTask.run(AutoDeployControllerImpl.java:374) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462)
Here is the rest of the log file related messages that appear after the NPE, interesting that startup failed yet it was considered successfully auto-deployed.
[#2008-12-11T12:20:21.484-0500SEVEREsun-appserver9.1org.apache.catalina.core.StandardContext_ThreadID=18;_ThreadName=Timer-15;_RequestID=bc574187-48c7-45d6-8456-6042df2f372f;PWC1306: Startup of context /GeonamesDotOrgLookupService failed due to previous errors#] [#2008-12-11T12:20:21.593-0500INFOsun-appserver9.1javax.enterprise.system.tools.deployment_ThreadID=18;_ThreadName=Timer-15;[AutoDeploy] Successfully autodeployed : C:\servers\glassfish\domains\domain1\autodeploy\GeonamesDotOrgLookupService.war.#]
I had gotten the code from my team member so wasn't that familiar with what it was doing. He gave me several pointers on what to look for and we finally determined that there were 9 files in the WEB-INF/classes folder that were in the NetBeans project, but did not get copied over in to the NetBeans WAR file. That meant we had a build issue. I had just taken the project files "as-is" and assumed all was well since it built, ran and deployed from within NetBeans. Makes you wonder why NetBeans can't detect such a situation as this.
Not being that knowledgeable with how to tweak the build within NetBeans, I did the workaround of manually copying the missing files into the WAR. I redeployed the new WAR file and this time it worked. Whew, another learning experience. Thanks to all who helped.
Thursday, December 4, 2008
Nuts with NetBeans
My first attempts at developing applications in the NetBeans environment were back in February when I first loaded version 6.0 on my laptop. I was trying to understand the Web Services projects that my team members had been developing using NetBeans. The first project I was given to play with had been built using NetBeans 5.5. I was forewarned that I would see an error message associated with libraries and that "all" I needed to do was get rid of the reference to JAXWS20 because the JAX-WS libraries were included with JDK6. To this day, I don't understand all the implications of what happened when Sun started including those libraries with JDK6. Getting my coworker's project to compile wasn't as easy as his email implied. At one point I posted to a forum http://forums.sun.com/thread.jspa?messageID=10116236 which was never satisfactorily answered and now I can't remember anymore what workaround I finally came up with.
From those initial installs of 6.0, to get needed features that kept coming up, I've gone through 6.0.1, 6.1, 6.5 Beta, and now 6.5. I dread it every time that I have to install a new version. To get around some of the problems I have had to delete the .nbi and .netbean directories, which, I think, causes problems later on when you try to uninstall. A week or so ago I wanted to install 6.5 on a laptop where I had both 6.0.1 and 6.1 installed. I'd been using the 6.1 for quite awhile and wasn't ready to get rid of it. On the other hand, things on the laptop were getting a bit cluttered. I decided I would uninstall the 6.0.1, leave the 6.1 and install 6.5.
After selecting Remove in the Windows Add/Remove Programs GUI, a popup message appeared: "Missing target component. The specified target component - nb-base/6.0.1.1.200801291616 was not found in the registry. The installer can continue as if the target component was not specified." The options for the popup were Yes to continue, No to exit. Regardless of which option I chose the installer exited without uninstalling NetBeans 6.0.1. After trying with the Windows Add/Remove Programs, I used the uninstall.exe in the NetBeans 6.0.1 folder, but the behavior was the same.
I've had some success finding answers through Sun user forums for problems with Portlet Container, Glassfish, WSRP, etc., and decided to send an email to nbusers@netbeans.org. After several days of getting no response I decided to experiment and see what I could learn. But you know how it is when you think the answer is just around the corner. I was sure that if I copied and renamed the right combination of .netbeans folders and tweaked the registry.xml I could get the 6.0.1 version back into a state where the uninstaller would be able to cleanly get rid of it. I think I was worrying too much about uninstalling the correct way.
I finally gave up and went back to looking at the forum. It was then that I realized this forum did not work like the others. I had been expecting that when someone responded to my question an email would get sent to the address I had used to send the question. Instead, I saw that someone had responded to my question shortly after it was posted. Basically, the response recommended just deleting the appropriate folders as the way to uninstall. And all this time I had believed what the documentation said "Use the Add/Remove Programs utility. Do not manually delete the directories and files."
But you do what you have to do to keep going. So I deleted all (hopefully) the appropriate folders. I tried to use the registry cleaning utility recommended by the forum post but it didn't do much that I could see. I'm sure there are bits and pieces of NetBeans 6.0.1 hanging around yet on my laptop.
From those initial installs of 6.0, to get needed features that kept coming up, I've gone through 6.0.1, 6.1, 6.5 Beta, and now 6.5. I dread it every time that I have to install a new version. To get around some of the problems I have had to delete the .nbi and .netbean directories, which, I think, causes problems later on when you try to uninstall. A week or so ago I wanted to install 6.5 on a laptop where I had both 6.0.1 and 6.1 installed. I'd been using the 6.1 for quite awhile and wasn't ready to get rid of it. On the other hand, things on the laptop were getting a bit cluttered. I decided I would uninstall the 6.0.1, leave the 6.1 and install 6.5.
After selecting Remove in the Windows Add/Remove Programs GUI, a popup message appeared: "Missing target component. The specified target component - nb-base/6.0.1.1.200801291616 was not found in the registry. The installer can continue as if the target component was not specified." The options for the popup were Yes to continue, No to exit. Regardless of which option I chose the installer exited without uninstalling NetBeans 6.0.1. After trying with the Windows Add/Remove Programs, I used the uninstall.exe in the NetBeans 6.0.1 folder, but the behavior was the same.
I've had some success finding answers through Sun user forums for problems with Portlet Container, Glassfish, WSRP, etc., and decided to send an email to nbusers@netbeans.org. After several days of getting no response I decided to experiment and see what I could learn. But you know how it is when you think the answer is just around the corner. I was sure that if I copied and renamed the right combination of .netbeans folders and tweaked the registry.xml I could get the 6.0.1 version back into a state where the uninstaller would be able to cleanly get rid of it. I think I was worrying too much about uninstalling the correct way.
I finally gave up and went back to looking at the forum. It was then that I realized this forum did not work like the others. I had been expecting that when someone responded to my question an email would get sent to the address I had used to send the question. Instead, I saw that someone had responded to my question shortly after it was posted. Basically, the response recommended just deleting the appropriate folders as the way to uninstall. And all this time I had believed what the documentation said "Use the Add/Remove Programs utility. Do not manually delete the directories and files."
But you do what you have to do to keep going. So I deleted all (hopefully) the appropriate folders. I tried to use the registry cleaning utility recommended by the forum post but it didn't do much that I could see. I'm sure there are bits and pieces of NetBeans 6.0.1 hanging around yet on my laptop.
Subscribe to:
Posts (Atom)