This effort started with the creation of a simple KML file using http://www.geodistance.com. By using the map on the site, a bike route near my home could be traced out and saved as a KML file to my local hard drive. The goal was to create a local HTML file that had an OpenLayers base map layer and the KML file as a second layer on the map.
There were 2 different live examples on the Open Layers site of how to display a KML layer. One of them used an OpenLayers.Layer.Vector object and the other used an OpenLayers.Layer.GML object. Both examples referenced the KML file to a kml subdirectory that exists on whatever web application OpenLayers uses to run the live examples.
Rather than download the library to my local server I chose to include the library with the single script element. I did not have a kml subdirectory under the directory with the HTML file that I was creating—I simply copied the KML file into the same directory as the HTML.
By the time that I got finished with this experiment I ended up with 4 different HTML files. Internet Explorer (Version 7) and Firefox (Version 3.5.3) were the 2 browsers I was using and they both acted differently, depending on whether the KML file was on my local drive or whether I put it on a server reachable over the Internet. Using the 2 different methods of creating the layer caused different behavior, as well.
If the KML file was on my local drive then IE could not find the file at all. It was not obvious that IE was having trouble with the fact that the file was on the local drive. The error message was “Access is denied: Line 1078”, which in the debugger pointed to a place in the OpenLayers.js that did not provide much of a clue as to what kind of access was being denied. It was only by finally uploading the KML to a remote server and providing the full URL, rather than just the local file name, that I got it to work in IE.
Using the local KML file and the two IE failure cases, one being the OpenLayers.Layer.Vector and the other the OpenLayers.Layer.GML, produced 2 different behaviors. When the Vector example failed it would fail to display the map, as well as failing to display the KML. The GML example would at least display the map and just fail to display the KML.
Firefox did not display any error messages when I used the local KML file. But it did not display the KML layer when I used OpenLayers.Layer.Vector. Using Firebug did not provide any information as to why it couldn’t display the Vector layer. But it did display the GML layer. And, unfortunately, if I used the HTML files with the full URL to the KML on the remote server Firefox could not display the KML for either the Vector or the GML. Firebug showed no errors for the Vector method; for the GML method it showed a “no element found” error in the Console Response tab.
All of this leaves me with 4 different HTML files where the only thing different amongst the four is the single “var bikeroute = “ statement where I create a KML layer for the map. None of the 4 files provides a satisfactory solution to what I’m trying to do. I have a local KML file that I want to display on an OpenLayers map in a consistent manner whether I use IE 7 or Firefox 3.5.3. Everything I’ve discussed can be reproduced with no special software and only the 4 HTML files and the KML file. If anyone could decipher for me what is going on with OpenLayers when I try to display a KML file I would greatly appreciate it.
Thursday, September 24, 2009
Monday, August 31, 2009
More Open Layers Frustrations
Since the "SOAPServiceClients" portlets have gained some acceptance I decided that I would work on enhancing the portlet that calculates distance and bearing. To make it easier for the user to enter a pair of coordinates I had an HTML div in the portlet that displayed an OpenLayers map. One of the coordinate pairs was selected with a mouse click on the map and the other was selected with a double-click. That populated the coordinate text boxes and then by selecting the OK button the web service would be called that returned the distance and bearing between the 2 points. What was missing was the ability to see the points and line between them on the map display.
Another developer who had done this successfully in a web application told me that it was simple to implement this functionality and referred me to the API explanation at http://dev.openlayers.org/docs/files/OpenLayers/Control/DrawFeature-js.html. I remembered that I had looked at this once before and ran into trouble before I figured out how to use it. I dug up the earlier HTML file and started to investigate.
The DrawFeature control works with an OpenLayers.Layer.Vector layer. The first step would be a constructor that created a vector layer object. Nothing difficult here, right?
var vectors = new OpenLayers.Layer.Vector("Vector Layer");
Because I was looking at an example from http://openlayers.org/dev/examples/ there were a number of other lines of code I had added to try to get the functionality in the web page that I was creating. The example would work in Firefox, but IE7 refused to display the map and the only clue was an error message "Unspecified error Line 599 character 208". I tracked this down to the constructor line by eliminating all the other DrawFeature code that I had added. So what was wrong with the constructor line? If I commented out that line the map would load in IE7, but when I uncommented the line I would get the "unspecified error" message.
After much frustration I found a different example and noticed that the vector constructor and most of the other OpenLayers initialization was being done within the head tags of the HTML, instead of within the body tags where I had it. With portlets you are not allowed to use the head tag so I had learned that all JavaScript I needed had to be done within the body tag. I temporarily moved the one statement for the Vector layer constructor out of the body and into the head. Lo and behold, IE7 quit complaining about an unspecified error and went ahead and displayed the map.
Now I had occasion to thank Javier who posted a comment to one of my earlier blogs, letting me know that I could get around the portlet restrictions of not using the head tag, by creating an init() function and then calling it from within the map div tag. Sure enough, that worked. I have no idea what it is with OpenLayers and IE7 that runs into a problem with the location on the page of the Vector Layer constructor. All I know is that it has taken up most of my time today and I still haven't even gotten to the part of creating the DrawFeature control.
Another developer who had done this successfully in a web application told me that it was simple to implement this functionality and referred me to the API explanation at http://dev.openlayers.org/docs/files/OpenLayers/Control/DrawFeature-js.html. I remembered that I had looked at this once before and ran into trouble before I figured out how to use it. I dug up the earlier HTML file and started to investigate.
The DrawFeature control works with an OpenLayers.Layer.Vector layer. The first step would be a constructor that created a vector layer object. Nothing difficult here, right?
var vectors = new OpenLayers.Layer.Vector("Vector Layer");
Because I was looking at an example from http://openlayers.org/dev/examples/ there were a number of other lines of code I had added to try to get the functionality in the web page that I was creating. The example would work in Firefox, but IE7 refused to display the map and the only clue was an error message "Unspecified error Line 599 character 208". I tracked this down to the constructor line by eliminating all the other DrawFeature code that I had added. So what was wrong with the constructor line? If I commented out that line the map would load in IE7, but when I uncommented the line I would get the "unspecified error" message.
After much frustration I found a different example and noticed that the vector constructor and most of the other OpenLayers initialization was being done within the head tags of the HTML, instead of within the body tags where I had it. With portlets you are not allowed to use the head tag so I had learned that all JavaScript I needed had to be done within the body tag. I temporarily moved the one statement for the Vector layer constructor out of the body and into the head. Lo and behold, IE7 quit complaining about an unspecified error and went ahead and displayed the map.
Now I had occasion to thank Javier who posted a comment to one of my earlier blogs, letting me know that I could get around the portlet restrictions of not using the head tag, by creating an init() function and then calling it from within the map div tag. Sure enough, that worked. I have no idea what it is with OpenLayers and IE7 that runs into a problem with the location on the page of the Vector Layer constructor. All I know is that it has taken up most of my time today and I still haven't even gotten to the part of creating the DrawFeature control.
Are portlets "Dead" Technology?
I was tempted a couple of weeks ago to post here and say goodbye to working with portlets. Some of the portlets I'd been working on were beginning to get attention from management and we were asked to develop test plans for portlets that would demonstrate compliance with the JSR168/286 and WSRP 1.0/2.0 specifications.
Hoping to build off what others had done in this arena I began researching what was available on the Internet. One of the first articles I came across, http://today.java.net/pub/a/today/2009/01/20/jsr-286-portlet-irrelevance.html, expressed many of the frustrations I'd encountered this past year. I did some forum postings myself and got answers like this:
https://wsrp.dev.java.net/servlets/ReadMsg?list=users&msgNo=494
The test script tool on SourceForge was once maintained by IBM (NetUnity Software) but a representative I contacted from NetUnity said "There has not been much activity for quite some time". Others told me similar things about the failure of the JSR168/286 and WSRP technologies to gain industry acceptance. That explains a lot of the difficulty this past year in finding help from other developers.
But, life goes on, and management doesn't necessarily want to hear that what you've spent all this time and money on is something that you think should be thrown out the window. Plus we had a major success with the group of portlets I had developed called "SOAPServiceClients". We deployed them on a virtual server loaded with GlassFish v2 and Portlet Container with the WSRP Open Portal plug-in. I exposed them as WSRP Producer portlets and a SharePoint portal was able to consume them.
For various political reasons that I won't go into here, the client that our team supports had been very anxious to see if this is something that could be accomplished. In theory, a Java shop can develop portlets that expose Web Services written in Java and then a Microsoft shop can display those Web Services in a presentation layer that is a WSRP Consumer web part in SharePoint. Theory and practice are often two different things and it's hard to find examples where this has actually been done. The client was very happy with the results, but I'm not sure what the real benefit is in the long run. It was a lot of work to just have a simple window on a web page where you can enter coordinates and calculate distance and bearing.
Hoping to build off what others had done in this arena I began researching what was available on the Internet. One of the first articles I came across, http://today.java.net/pub/a/today/2009/01/20/jsr-286-portlet-irrelevance.html, expressed many of the frustrations I'd encountered this past year. I did some forum postings myself and got answers like this:
https://wsrp.dev.java.net/servlets/ReadMsg?list=users&msgNo=494
The test script tool on SourceForge was once maintained by IBM (NetUnity Software) but a representative I contacted from NetUnity said "There has not been much activity for quite some time". Others told me similar things about the failure of the JSR168/286 and WSRP technologies to gain industry acceptance. That explains a lot of the difficulty this past year in finding help from other developers.
But, life goes on, and management doesn't necessarily want to hear that what you've spent all this time and money on is something that you think should be thrown out the window. Plus we had a major success with the group of portlets I had developed called "SOAPServiceClients". We deployed them on a virtual server loaded with GlassFish v2 and Portlet Container with the WSRP Open Portal plug-in. I exposed them as WSRP Producer portlets and a SharePoint portal was able to consume them.
For various political reasons that I won't go into here, the client that our team supports had been very anxious to see if this is something that could be accomplished. In theory, a Java shop can develop portlets that expose Web Services written in Java and then a Microsoft shop can display those Web Services in a presentation layer that is a WSRP Consumer web part in SharePoint. Theory and practice are often two different things and it's hard to find examples where this has actually been done. The client was very happy with the results, but I'm not sure what the real benefit is in the long run. It was a lot of work to just have a simple window on a web page where you can enter coordinates and calculate distance and bearing.
Tuesday, July 7, 2009
File Upload Component in NetBeans 6.5
My next portlet has a requirement to provide the ability for a user to browse their local filesystem and select a file to be uploaded to the server. Support for this in HTML forms has been around for awhile by using a form attribute enctype="multipart/form-data" and attribute type="file" in the form input element. The HTML form is the easy part to understand. The hard part is knowing what to do on the server-side when the form is submitted.
Since I have been using NetBeans 6.5, I decided to try to find an example of how to do this in a NetBeans project. Searches led me to a NetBeans tutorial "Uploading Files in NetBeans Visual Web JSF Application." I'm not familiar with Visual Web JSF but a step-by-step tutorial looked like something I could follow. And if I had the code in a NetBeans Web Application project then it should be easy enough to take the pieces I needed and put them in a portlet project.
I made sure that I had all the software and resources that were listed as requirements. I looked through the NetBeans plugins and installed those related to JSF and Visual Web JSF. Even though the tutorial didn't say anything about plugins it seemed logical that those would be needed. A couple of missing references went away when I installed the plugins after an initial attempt to make a project with the Visual Web JavaServer Faces framework. Unfortunately, I never got any further.
I fiddled around for a day trying different plugins and looking on the web and posting to the NetBeans forums. But I'm stuck with a Reference problem--"jsf12-support library could not be found". I also noticed that all of the default source files that get created are unable to import anything from com.sun.rave.web.ui.appbase. This is in spite of the fact that the IDE shows that the libraries are there in the appbase.jar.
Enough of messing around with the NetBeans framework. Back to the web to look around for other examples. Surely there has to be a way to do this that doesn't require JSF. After all, it looks to me like the JSF is only a convenience for creating buttons and form fields on the HTML part of the application. It doesn't seem tied to the back-end server processing.
Finally, at http://www.scribd.com/doc/220346/How-to-upload-files-using-JavaServer-Pages I found something that looked simple enough. I needed a few tweaks to get it to work within the portlet environment but, lo and behold, I can now upload files. And with only about 30 lines of code in the processAction method of the portlet class. Thanks so much to whomever posted the Scribd document.
Since I have been using NetBeans 6.5, I decided to try to find an example of how to do this in a NetBeans project. Searches led me to a NetBeans tutorial "Uploading Files in NetBeans Visual Web JSF Application." I'm not familiar with Visual Web JSF but a step-by-step tutorial looked like something I could follow. And if I had the code in a NetBeans Web Application project then it should be easy enough to take the pieces I needed and put them in a portlet project.
I made sure that I had all the software and resources that were listed as requirements. I looked through the NetBeans plugins and installed those related to JSF and Visual Web JSF. Even though the tutorial didn't say anything about plugins it seemed logical that those would be needed. A couple of missing references went away when I installed the plugins after an initial attempt to make a project with the Visual Web JavaServer Faces framework. Unfortunately, I never got any further.
I fiddled around for a day trying different plugins and looking on the web and posting to the NetBeans forums. But I'm stuck with a Reference problem--"jsf12-support library could not be found". I also noticed that all of the default source files that get created are unable to import anything from com.sun.rave.web.ui.appbase. This is in spite of the fact that the IDE shows that the libraries are there in the appbase.jar.
Enough of messing around with the NetBeans framework. Back to the web to look around for other examples. Surely there has to be a way to do this that doesn't require JSF. After all, it looks to me like the JSF is only a convenience for creating buttons and form fields on the HTML part of the application. It doesn't seem tied to the back-end server processing.
Finally, at http://www.scribd.com/doc/220346/How-to-upload-files-using-JavaServer-Pages I found something that looked simple enough. I needed a few tweaks to get it to work within the portlet environment but, lo and behold, I can now upload files. And with only about 30 lines of code in the processAction method of the portlet class. Thanks so much to whomever posted the Scribd document.
Wednesday, June 24, 2009
OpenLayers Minutiae
At least in my mind this is "minutiae." How in the world one is supposed to know what makes an OpenLayers map application display properly for the various scenarios that arise is still beyond me. To get the answer I needed today I had to send an email to a colleague who is much more experienced than I am. Thanks, Chad, for helping me with this.
Scenario was as follows: A certain server exposed a number of WMS base layers that represented data coverages over the world. They could be displayed with a custom-built "tileserver" OpenLayers class that inherited from OpenLayers.Layer.Grid. I wanted to use the standard Metacarta world vector layer as a base layer and then have 5 of the tileserver layers as user-selectable overlays.
The Scott Davis, "GIS for Web Developers" book was a great help in walking me through the process of how you add the LayerSwitcher control and pass in the correct parameters for each layer to make them visible over the base layer. Part of what slows me down in this experimentation is that the data I am trying to access is behind a PKI-enabled firewall. You can only get to it if you have a CAC card reader on your PC and a CAC card with the proper credentials. Then it seems that Internet Explorer tends to get picky about timing of the sessions or something because for a while it will do the proper thing of reading and authenticating the CAC but then all of a sudden it quits working. It pretends that it doesn't know it needs to ask you to authenticate and just won't display the data or tells you the page is "not found."
In any case, getting around those hurdles and finally getting a consistent display of the data (or a workaround when it wouldn't display) was a great triumph. But then I saw that the tileserver layers weren't lining up properly with the WMS base overlay. These things were supposed to be in the same projection. What was I doing wrong?
Here's the answer I got back from Chad:
I was using this statement (copied from who knows where) to construct the map object:
var map = new OpenLayers.Map('map', {'maxResolution':'auto'});
Chad suggested using this constructor:
var map = new OpenLayers.Map('map', {
maxResolution: 146543.0339,
projection: "EPSG:4326",
maxExtent: new OpenLayers.Bounds(-180, -90, 180, 90),
scales: [442943842.5, 221471921.25, 110735960.625, 55367980.3125, 27683990.15625, 13841995.078125, 6920997.5390625, 3460498.76953125, 1730249.384765625, 865124.6923828125, 432562.34619140625, 216281.17309570312, 108140.58654785156, 54070.29327392578]
});
Yikes! Now you tell me where do all those numbers come from? I don't think I could ever have discovered this on my own. But I tried it and, sure enough, the layers now line up perfectly with the overlays.
Scenario was as follows: A certain server exposed a number of WMS base layers that represented data coverages over the world. They could be displayed with a custom-built "tileserver" OpenLayers class that inherited from OpenLayers.Layer.Grid. I wanted to use the standard Metacarta world vector layer as a base layer and then have 5 of the tileserver layers as user-selectable overlays.
The Scott Davis, "GIS for Web Developers" book was a great help in walking me through the process of how you add the LayerSwitcher control and pass in the correct parameters for each layer to make them visible over the base layer. Part of what slows me down in this experimentation is that the data I am trying to access is behind a PKI-enabled firewall. You can only get to it if you have a CAC card reader on your PC and a CAC card with the proper credentials. Then it seems that Internet Explorer tends to get picky about timing of the sessions or something because for a while it will do the proper thing of reading and authenticating the CAC but then all of a sudden it quits working. It pretends that it doesn't know it needs to ask you to authenticate and just won't display the data or tells you the page is "not found."
In any case, getting around those hurdles and finally getting a consistent display of the data (or a workaround when it wouldn't display) was a great triumph. But then I saw that the tileserver layers weren't lining up properly with the WMS base overlay. These things were supposed to be in the same projection. What was I doing wrong?
Here's the answer I got back from Chad:
I was using this statement (copied from who knows where) to construct the map object:
var map = new OpenLayers.Map('map', {'maxResolution':'auto'});
Chad suggested using this constructor:
var map = new OpenLayers.Map('map', {
maxResolution: 146543.0339,
projection: "EPSG:4326",
maxExtent: new OpenLayers.Bounds(-180, -90, 180, 90),
scales: [442943842.5, 221471921.25, 110735960.625, 55367980.3125, 27683990.15625, 13841995.078125, 6920997.5390625, 3460498.76953125, 1730249.384765625, 865124.6923828125, 432562.34619140625, 216281.17309570312, 108140.58654785156, 54070.29327392578]
});
Yikes! Now you tell me where do all those numbers come from? I don't think I could ever have discovered this on my own. But I tried it and, sure enough, the layers now line up perfectly with the overlays.
Friday, June 19, 2009
MBeans Server
Now that we have a virtual server back on the Internet and the SOAPServiceClient portlets are ready for testing, it's time to dig out the notes on creating a WSRP Producer from the portlets. Certain individuals have expressed an interest in demonstrating the capability to consume a WSRP producer from the enviroment we have on the virtual server.
Spent some time finding the notes and refreshing my memory. I know that I successfully did this once before when we had the other virtual server on line. Unfortunately, I didn't get too far along before I hit a brick wall.
On the second screen of the configuration process I noticed that the hostname was localhost and not the IP address of the server. I vaguely remembered that this could be changed by selecting the Edit mode for the WSRP Producer portlet. I selected the Edit mode, typed in the necessary information for hostname and port(wasn't real sure about what to use for port, but guessed at 80--it used to be port 8080) and then did the Submit. After a long delay the View mode displayed a red error message:
"The MBean Server has not been started for the following host. Please start the MBean Server and retry."
I spent all day researching, sending emails and trying to understand what was going on. Meanwhile, the portlet continued to display the error message and it was taking a very long time for the portal page to render whenever it was viewed in the browser. Finally, this morning there was a response from the forum at users@wsrp.dev.java.net I tried the suggestion and it worked!
The answer was simple enough. All I had to do was check the box that said isLocal--that means there is no remote MBean server to look up and everything is deployed locally on the same machine. I think the box was checked by default but I may have unchecked it, thinking that changing the hostname from localhost to the IP address meant it was no longer deployed locally.
I was able to get rid of the error message and the rendering time went back to normal. The WSRP producer is created and I can consume it from the PC I have on my local machine. The problem now is that neither SharePoint nor WebLogic can consume it. I think it's related to the fact that I had to put in a port number during the configuration or it would default to 8080. The way GlassFish was installed on the server, it is set up so that it can't be reached from 8080, only from 80. But that doesn't seem to work for the WSRP URL. Time now to see what I can find out about how the server was configured.
Spent some time finding the notes and refreshing my memory. I know that I successfully did this once before when we had the other virtual server on line. Unfortunately, I didn't get too far along before I hit a brick wall.
On the second screen of the configuration process I noticed that the hostname was localhost and not the IP address of the server. I vaguely remembered that this could be changed by selecting the Edit mode for the WSRP Producer portlet. I selected the Edit mode, typed in the necessary information for hostname and port(wasn't real sure about what to use for port, but guessed at 80--it used to be port 8080) and then did the Submit. After a long delay the View mode displayed a red error message:
"The MBean Server has not been started for the following host. Please start the MBean Server and retry."
I spent all day researching, sending emails and trying to understand what was going on. Meanwhile, the portlet continued to display the error message and it was taking a very long time for the portal page to render whenever it was viewed in the browser. Finally, this morning there was a response from the forum at users@wsrp.dev.java.net I tried the suggestion and it worked!
The answer was simple enough. All I had to do was check the box that said isLocal--that means there is no remote MBean server to look up and everything is deployed locally on the same machine. I think the box was checked by default but I may have unchecked it, thinking that changing the hostname from localhost to the IP address meant it was no longer deployed locally.
I was able to get rid of the error message and the rendering time went back to normal. The WSRP producer is created and I can consume it from the PC I have on my local machine. The problem now is that neither SharePoint nor WebLogic can consume it. I think it's related to the fact that I had to put in a port number during the configuration or it would default to 8080. The way GlassFish was installed on the server, it is set up so that it can't be reached from 8080, only from 80. But that doesn't seem to work for the WSRP URL. Time now to see what I can find out about how the server was configured.
Wednesday, June 10, 2009
NetBeans or Glassfish problem?
When your working environment is NetBeans and it is set up to automatically deploy to an instance of Glassfish it is sometimes difficult to sort out if a problem you encounter is a problem with NetBeans or a problem with Glassfish.
I had been hard at work enhancing/updating portlets that I had written several months ago when one afternoon my progress suddenly hit a major bump in the road. Every time I made a change to the NetBeans project and then selected either "Run" or "Debug" I found myself staring for an average of 7 minutes at the NetBeans output window that showed the progress of the build and deployment.
I narrowed it down to the step where the printed output is "Deployment Started". A lot of progress information related to the build would scroll by quickly prior to that statement. But then 7 minutes would pass before the "Deployed Successfully" statement appeared, followed quickly again by the remainder of the printed output, culminating in the statement that showed "BUILD SUCCESSFUL" and the total amount of elapsed time. I couldn't imagine what was causing the hang-up between the start and completion of the deployment process.
A couple of days went by as I began to collect more data, look in logs, reboot processes and the workstation, try building with different projects, etc. I could come up with nothing. Every project I tried to run or deploy would require 7 minutes to do the deployment. I began to plan my code changes carefully to not have to recompile any more than necessary. And I also made a point of leaving myself other tasks like reading email that I could look at while the deployment was grinding along.
Since the slowdown was occurring during the deployment process did that mean the problem was with NetBeans or with Glassfish? Would I need to reinstall one or the other or both? I sure hoped that it wouldn't come to that because I'd have to do some digging to find the notes I accumulated from the many installs of multiple versions of those 2 applications.
One troubleshooting tip that's commonly given whenever the problem is related to a Windows workstation suddenly acting up is to trace back through anything that you might have installed immediately before the problem started to occur. I vaguely remembered that the day I started to notice the problem was also the day I was asked to set up my workstation with a Virtual Private Network (VPN) client that would allow me to access a CM tool my team members were going to start using that was located on a remote network.
The executable I was asked to install was the Contivity VPN client and no one had yet used it on the type of laptop I have. There were warnings about the version not being up-to-date and, sure enough, when I started to install it there were a number of warnings and failure messages that appeared. One warning said that by continuing the installation there was a possibility of my system becoming unstable. At that point I decided to cancel the installation. It took a couple of tries and more error messages to finally get the installation stopped. I sent the text of the error messages to the person who had provided the installation instructions and went back to portlet development.
After exhausting all the other troubleshooting tips I could think of and hearing of someone who successfully installed the VPN client on a laptop like mine I decided I would try again to install the application. Who knows what it might have left behind when I cancelled out of the installation?
By ignoring a couple of warnings that did appear, this time I managed to successfully install the VPN Client. And, lo and behold, after going back to NetBeans and doing a "Run" of the project the results were almost instantaneous. The problem with the 7 minute delay had vanished. I have no idea how the 2 things were related, but I'm just thankful that I can now once again make better progress with the deployments working as they should.
I had been hard at work enhancing/updating portlets that I had written several months ago when one afternoon my progress suddenly hit a major bump in the road. Every time I made a change to the NetBeans project and then selected either "Run" or "Debug" I found myself staring for an average of 7 minutes at the NetBeans output window that showed the progress of the build and deployment.
I narrowed it down to the step where the printed output is "Deployment Started". A lot of progress information related to the build would scroll by quickly prior to that statement. But then 7 minutes would pass before the "Deployed Successfully" statement appeared, followed quickly again by the remainder of the printed output, culminating in the statement that showed "BUILD SUCCESSFUL" and the total amount of elapsed time. I couldn't imagine what was causing the hang-up between the start and completion of the deployment process.
A couple of days went by as I began to collect more data, look in logs, reboot processes and the workstation, try building with different projects, etc. I could come up with nothing. Every project I tried to run or deploy would require 7 minutes to do the deployment. I began to plan my code changes carefully to not have to recompile any more than necessary. And I also made a point of leaving myself other tasks like reading email that I could look at while the deployment was grinding along.
Since the slowdown was occurring during the deployment process did that mean the problem was with NetBeans or with Glassfish? Would I need to reinstall one or the other or both? I sure hoped that it wouldn't come to that because I'd have to do some digging to find the notes I accumulated from the many installs of multiple versions of those 2 applications.
One troubleshooting tip that's commonly given whenever the problem is related to a Windows workstation suddenly acting up is to trace back through anything that you might have installed immediately before the problem started to occur. I vaguely remembered that the day I started to notice the problem was also the day I was asked to set up my workstation with a Virtual Private Network (VPN) client that would allow me to access a CM tool my team members were going to start using that was located on a remote network.
The executable I was asked to install was the Contivity VPN client and no one had yet used it on the type of laptop I have. There were warnings about the version not being up-to-date and, sure enough, when I started to install it there were a number of warnings and failure messages that appeared. One warning said that by continuing the installation there was a possibility of my system becoming unstable. At that point I decided to cancel the installation. It took a couple of tries and more error messages to finally get the installation stopped. I sent the text of the error messages to the person who had provided the installation instructions and went back to portlet development.
After exhausting all the other troubleshooting tips I could think of and hearing of someone who successfully installed the VPN client on a laptop like mine I decided I would try again to install the application. Who knows what it might have left behind when I cancelled out of the installation?
By ignoring a couple of warnings that did appear, this time I managed to successfully install the VPN Client. And, lo and behold, after going back to NetBeans and doing a "Run" of the project the results were almost instantaneous. The problem with the 7 minute delay had vanished. I have no idea how the 2 things were related, but I'm just thankful that I can now once again make better progress with the deployments working as they should.
Subscribe to:
Posts (Atom)