I didn't pass the exam for the Sun Certified Programmer for Java 6 Platform SE6. The training class taught me a lot and gave me the motivation to continue my studies.. There's another class that I can take in September at no cost. I've already signed up for that class and will continue my studies.
It would be nice to have a job where the basics of Java programming would be put to use and that would help fill in the missing pieces in my knowledge of the basics. Instead, I get to go back to seeing what kind of GIS portlets I can dream up.
I was successful this week in getting the portlet to work that makes a WFS call for World Port Index data that's loaded on one of our team's virtual servers. The feature data is displayed on an Open Layers map. I resurrected another portlet that queried a local instance of a Geonames.org lookup service compiled from code written by a developer on the team. That query returns KML data and displays it on an OpenLayers map.
The KML portlet could only work on my local machine because the service was running locally. I thought I would make an attempt to get the same service running on the virtual server. Not a trivial task, given the lapse in time from when I had been working on this before. I needed some way to get the WAR file to the remote server. At first I thought I could just use the GlassFish admin console through a browser and upload the file. But then I realized the virtual server was not letting that port be accessed remotely. I recalled that when this issue came up months ago the process was to use VNC to get to the server, bring up a browser locally on the server and get to the Admin console from there.
When I tried VNC it wouldn't let me in. I figured out that since this office had recently changed their network setup it was likely that I was now getting out of here with a different IP address. Sure enough, that was the case. It took several email exchanges with the admin person on the other end but we finally managed to get VNC working again from here to there.
Next problem--When you upload a WAR file from the GlassFish Admin console the browse option only lets you look for something on the local machine. Now I was back to square one. How to get the WAR file from here to the remote server? The solution that I finally came up with was to use GEOINT Online. Who would ever have imagined that the GEOINT Online SharePoint site would be useful for anything technical? Turns out the Document Sharing feature in one of my communities allows me to upload a file. So I upload the file from here to the community, go to the browser on the remote server, log in to GEOINT Online, find the Shared Document on my community and download it. Pretty cool.
After all of that, the GeonamesDotOrgLookupService actually does work on the virtual server. Now I can retrieve the KML file across the network and not just from my local machine. Next step is to think about what wonderful things that will allow me to demonstrate in my GIS portlets.
Wednesday, April 1, 2009
Sunday, March 22, 2009
Going Back and Going Forward
I've given up on getting an answer on the forum to my problem with not being able to deploy portlets to the Web Space Server instance running on the Solaris VM. I went back to working with a portlet I had created several months ago that used an Open Layers map and had a call to a Web Feature Service (WFS) that displayed some National Inventory of Dams (NID) data. There is a lot more that I need to learn about working with WFS clients.
After finally digging up the portlet that was the most current and displaying it on GlassFish, the first problem I encountered was that the point features were not displaying on the map. Investigation revealed that my team had removed the feature data from the virtual server I had been accessing for the NID data. Since that link was somewhat hardcoded in the proxy servlet code my first task would be to rethink the way I created the URL to make it easier to modify for different data sources.
Several email exchanges with the team gave me a URL for a WFS data set similar to the NID that I could fairly easily replace in the portlet code. This data is a feature set representing World Port Index (WPI) location points. During the course of making the code changes I encountered a problem that I had managed to avoid dealing with earlier when I was doing portlets with Open Layers maps. I knew that I would eventually have to start using the portlet namespace taglib because most of the Open Layers examples used the same variable names. And that doesn't work well when you have more than one of the Open Layers portlets displayed on the page. The data was showing up in the wrong divs.
I started the task of adding all the portlet namespace tags but I will now be setting that task aside for at least the next week. I'm attending a 7-day Training Camp class that is designed to prepare me for passing Sun's Certified Java Programmer 6 class. My Java knowledge is definitely not what it needs to be to pass that exam. NetBeans is a great tool for doing the behind-the-scenes Java code that's needed for portlets, but it means that I haven't had much experience or practice with the basics of Java.
I'm going to need to concentrate every brain cell this week on the basics of the Java language. I've started looking at a book with examples of the test questions and I'm dismayed at how deliberately tricky the questions are. I never knew it was possible to make such an intense multiple choice exam--so many "choose all that apply" or "fails to compile" or "exception at runtime" or "prints this" or "prints that." It doesn't test just factual knowledge, you have to understand and think about and trace through the code before you can begin to pick an answer.
The worst that could happen when the end of next week comes and I attempt the test is that I don't pass. But that won't be the end. There's still a year (I think) in which I will be able to continue to study on my own and retake the test again. It's going to be a lot of work but I look forward to having a concrete goal ahead of me, for once, instead of the vagaries of deciding what I should try to make work next with portlets.
After finally digging up the portlet that was the most current and displaying it on GlassFish, the first problem I encountered was that the point features were not displaying on the map. Investigation revealed that my team had removed the feature data from the virtual server I had been accessing for the NID data. Since that link was somewhat hardcoded in the proxy servlet code my first task would be to rethink the way I created the URL to make it easier to modify for different data sources.
Several email exchanges with the team gave me a URL for a WFS data set similar to the NID that I could fairly easily replace in the portlet code. This data is a feature set representing World Port Index (WPI) location points. During the course of making the code changes I encountered a problem that I had managed to avoid dealing with earlier when I was doing portlets with Open Layers maps. I knew that I would eventually have to start using the portlet namespace taglib because most of the Open Layers examples used the same variable names. And that doesn't work well when you have more than one of the Open Layers portlets displayed on the page. The data was showing up in the wrong divs.
I started the task of adding all the portlet namespace tags but I will now be setting that task aside for at least the next week. I'm attending a 7-day Training Camp class that is designed to prepare me for passing Sun's Certified Java Programmer 6 class. My Java knowledge is definitely not what it needs to be to pass that exam. NetBeans is a great tool for doing the behind-the-scenes Java code that's needed for portlets, but it means that I haven't had much experience or practice with the basics of Java.
I'm going to need to concentrate every brain cell this week on the basics of the Java language. I've started looking at a book with examples of the test questions and I'm dismayed at how deliberately tricky the questions are. I never knew it was possible to make such an intense multiple choice exam--so many "choose all that apply" or "fails to compile" or "exception at runtime" or "prints this" or "prints that." It doesn't test just factual knowledge, you have to understand and think about and trace through the code before you can begin to pick an answer.
The worst that could happen when the end of next week comes and I attempt the test is that I don't pass. But that won't be the end. There's still a year (I think) in which I will be able to continue to study on my own and retake the test again. It's going to be a lot of work but I look forward to having a concrete goal ahead of me, for once, instead of the vagaries of deciding what I should try to make work next with portlets.
Tuesday, March 10, 2009
SharePoint versus Web Space Server
I've had some time now to kick the tires on Sun's GlassFish Web Space Server 10.0 that was released last month. One of the things that strikes me is how much it seems to want to imitate the features of Microsoft Office SharePoint Server. But maybe that's because of the time I had been spending working with MOSS. Web Space Server came out of Project WebSynergy. When I played around with WebSynergy last fall I was concentrating on portlets and WSRP and if it had MOSS-like features, I wasn't paying much attention to that part of it. It was difficult enough just to get it to work.
I appreciate that Web Space Server has better documentation. I think it has finally fully incorporated Liferay and can take advantage of the community knowledge from that product. There is a lot of documentation about the social networking, content management and workflow features, which is interesting from the standpoint of a comparision to SharePoint. But the focus of my project is supposed to be building portlets that will work on any portal. Once again, as I try to actually build and deploy portlets with GIS usability I continue to encounter problems.
We have 2 instances of Web Space Server 10.0 that are being evaluated. I installed webspace-10-fcs-gfv2-windows.zip on Windows Vista on my laptop. For an evaluation copy visible to the group we installed webspace-gfv2-sunos-x86.zip on Sun Solaris 10 on a virtual machine. On the Windows Vista Web Space Server I was able to deploy the WAR file containing the 4 GIS portlets that I had developed earlier in the year with NetBeans 6.5. But I can't seem to get the WAR file to deploy on the Sun Solaris instance. Still waiting for a response from the users@webspace.dev.java.net mailgroup.
There must be some part of the Solaris installation that we've done incorrectly--I'm thinking maybe something to do with file/folder permissions. That's the instance where I have an outstanding question from a week ago when we first installed it and the User Sample Login portlet that's supposed to be on the Welcome screen was not working. It wasn't working when I first installed the Windows Vista instance but I got a response right away from the mailgroup on that one. It was just a matter of rebooting the server. But that didn't work on the Sun Solaris instance. There were error messages, too, when the Windows Vista one didn't work but there have been no error messages when the Solaris version fails to deploy the portlets. It's like the deployment process is just not finishing.
If we can get no response from the forum about why we can't deploy to the Solaris version I'm not sure what the next step will be--maybe talk again to the sys admin who installed it and see if we need to reinstall. Meanwhile, what I now need to do is set up NetBeans to use the Web Space Server on my laptop and beef up a couple of portlets I built awhile ago that use Open Layers. Portlets sure do look a lot better on Web Space Server than they do on Portlet Container.
I appreciate that Web Space Server has better documentation. I think it has finally fully incorporated Liferay and can take advantage of the community knowledge from that product. There is a lot of documentation about the social networking, content management and workflow features, which is interesting from the standpoint of a comparision to SharePoint. But the focus of my project is supposed to be building portlets that will work on any portal. Once again, as I try to actually build and deploy portlets with GIS usability I continue to encounter problems.
We have 2 instances of Web Space Server 10.0 that are being evaluated. I installed webspace-10-fcs-gfv2-windows.zip on Windows Vista on my laptop. For an evaluation copy visible to the group we installed webspace-gfv2-sunos-x86.zip on Sun Solaris 10 on a virtual machine. On the Windows Vista Web Space Server I was able to deploy the WAR file containing the 4 GIS portlets that I had developed earlier in the year with NetBeans 6.5. But I can't seem to get the WAR file to deploy on the Sun Solaris instance. Still waiting for a response from the users@webspace.dev.java.net mailgroup.
There must be some part of the Solaris installation that we've done incorrectly--I'm thinking maybe something to do with file/folder permissions. That's the instance where I have an outstanding question from a week ago when we first installed it and the User Sample Login portlet that's supposed to be on the Welcome screen was not working. It wasn't working when I first installed the Windows Vista instance but I got a response right away from the mailgroup on that one. It was just a matter of rebooting the server. But that didn't work on the Sun Solaris instance. There were error messages, too, when the Windows Vista one didn't work but there have been no error messages when the Solaris version fails to deploy the portlets. It's like the deployment process is just not finishing.
If we can get no response from the forum about why we can't deploy to the Solaris version I'm not sure what the next step will be--maybe talk again to the sys admin who installed it and see if we need to reinstall. Meanwhile, what I now need to do is set up NetBeans to use the Web Space Server on my laptop and beef up a couple of portlets I built awhile ago that use Open Layers. Portlets sure do look a lot better on Web Space Server than they do on Portlet Container.
Thursday, February 26, 2009
Still here building portlets
Yes, I know, it's been awhile, but I'm still here building portlets. I got sidetracked by other work assignments. The side trip involved working with Microsoft Office SharePoint Server, MOSS, for short. It was an interesting comparision to the world of Sun and Open Source. I did get to attend a very good training class (http://www.tedpattison.net/Courses/SPT401.aspx). But my project has no funds for an MSDN license. You can't do any development work with the application unless you purchase the MSDN license. So the company foots the bill for my training but the project has no funds for development resources--go figure.
Back to the world of open source. Thank goodness, development platforms are free, but, of course, you pay the price by not having access to support when you need it. I guess where I left off here with my last post I had been struggling with the NetBeans IDE. Awhile after that, I remember I had another issue with NetBeans. That one got posted Jan 28 (http://www.nabble.com/NetBeans-6.5-JavaScript-Debugger-Firefox-2.0.0.x-to21713322.html#a21713322) but still isn't answered. I vaguely remember someone helped me find out what I needed to know by using Firebug.
Over the last couple of months I did deploy some GIS portlets to our VM server (http://12.187.20.146:8080/portletdriver/dt). Not very pretty, but they do prove the concept. And from my laptop I am able to consume the portlet that is a WSRP producer on the VM. What I need to do next is get back to experimenting with the next generation WebSynergy, now called Web Space Server. I'd like to get it installed on my laptop. I remember the problems I encountered with port conflicts because I had 2 versions of GlassFish plus the WebSynergy GlassFish installed on the laptop.
I opened 3 console windows this morning on my laptop and did an asadmin start-domain command for each of the 3 servers--wanted to see if all 3 were still functional and what ports they were listening on. The GlassFish v2ur1 and v2ur2 both give a nice output in the console window that tells you where the server log is being written to and what 7 ports the server listens on. When I started WebSynergy I immediately remembered one of the many frustrations I had with it--it gives absolutely no output in the console window except the cryptic "Command start-domain executed successfully." I'll have to go digging again for the server log and if I remember correctly even the server log doesn't provide much information about port numbers. I can see from accessing it in the browser that I used 8585 for the http, but I know there are others in there somewhere that conflict with what the 2 GlassFish servers use. Should hopefully be in my notes.
Once I get that figured out I think the next step will be to remove/delete (it's never clear on these open source things how you undo the installation) the WebSynergy. Then I can use whatever ports I had been using for that and try to install Web Space Server to use those ports. Let the fun begin.
Back to the world of open source. Thank goodness, development platforms are free, but, of course, you pay the price by not having access to support when you need it. I guess where I left off here with my last post I had been struggling with the NetBeans IDE. Awhile after that, I remember I had another issue with NetBeans. That one got posted Jan 28 (http://www.nabble.com/NetBeans-6.5-JavaScript-Debugger-Firefox-2.0.0.x-to21713322.html#a21713322) but still isn't answered. I vaguely remember someone helped me find out what I needed to know by using Firebug.
Over the last couple of months I did deploy some GIS portlets to our VM server (http://12.187.20.146:8080/portletdriver/dt). Not very pretty, but they do prove the concept. And from my laptop I am able to consume the portlet that is a WSRP producer on the VM. What I need to do next is get back to experimenting with the next generation WebSynergy, now called Web Space Server. I'd like to get it installed on my laptop. I remember the problems I encountered with port conflicts because I had 2 versions of GlassFish plus the WebSynergy GlassFish installed on the laptop.
I opened 3 console windows this morning on my laptop and did an asadmin start-domain command for each of the 3 servers--wanted to see if all 3 were still functional and what ports they were listening on. The GlassFish v2ur1 and v2ur2 both give a nice output in the console window that tells you where the server log is being written to and what 7 ports the server listens on. When I started WebSynergy I immediately remembered one of the many frustrations I had with it--it gives absolutely no output in the console window except the cryptic "Command start-domain executed successfully." I'll have to go digging again for the server log and if I remember correctly even the server log doesn't provide much information about port numbers. I can see from accessing it in the browser that I used 8585 for the http, but I know there are others in there somewhere that conflict with what the 2 GlassFish servers use. Should hopefully be in my notes.
Once I get that figured out I think the next step will be to remove/delete (it's never clear on these open source things how you undo the installation) the WebSynergy. Then I can use whatever ports I had been using for that and try to install Web Space Server to use those ports. Let the fun begin.
Friday, December 26, 2008
NetBeans 6.5 and OpenPortal Portlet Container 2.0
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.
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.
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)