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.
Wednesday, June 24, 2009
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)