Last June I was contacted by an acquisitions editor with Manning Publications and asked if I would be interested in reviewing an outline for a book proposal on portlets. Books on portlets are few and far between and I was more than happy to take a look at the proposal. Not only did I get a complimentary ebook of my choice from Manning, but I was asked again last week to do a review, this time of the initial chapters of the book.
Feeling as I do, that the portlet technology is far from reaching the level of acceptance that was hoped for, I remain skeptical that this book will be a best seller. I am grateful to the author, though, for all the work he has obviously had to do to create these first four chapters. If the book makes it to press, it will already be outdated, but I would not hesitate to pay the $50+ price that will probably be charged. I got lost on the 3rd and 4th chapters because I've not been exposed to the Spring Portlet MVC framework. I'm not sure I will ever be using Spring and didn't want to spend the time downloading yet another new tool. But I got enough good stuff out of the first 2 chapters that the book would be well worth the price.
Anything that I can find in printed form about portlets is valuable in building up my knowledge and understanding. I found the first 2 chapters to be a good summary and review of the portlet architecture. In several areas there were sections that lit up the proverbial light bulb. For example, I could certainly relate my experiences to the section on "Choosing a Portal Server." It helped me realize part of the reason why learning to develop portlets has been such a struggle. There is no one who understands why a portal is needed in our environment. Without knowing the requirements it's been hard to have a direction and purpose for struggling down this path.
What I will be most grateful to the author (Ashish Sarin) for is the instructions and explanations he provided for downloading and installing the Liferay portal and the Eclipse IDE. Because I had just finished a two-week effort to install WebLogic Server 10.3, WebLogic Portal 10.3 and WebLogic Workshop on a Linux virtual machine I had the basis for contrasting something lightweight and simple with something that was an installation and configuration nightmare. If I had been able to have Sarin's manuscript in hand a year and a half ago when I started this whole portlet thing, I might have been a much happier developer.
Why did I want to fight with WebLogic in the first place? Well, we have needed some way to verify that when we develop portlets they are JSR 168 compliant. We use the NetBeans IDE with portlet plug-ins to develop the portlets and Sun's Open Portal Portlet Container to deploy them. Early on I had tried using WebSynergy (which became Web Space Server) but gave up in frustration. I know that it is built on top of Liferay and some would say that it is the same thing as Liferay, now that the 2 Open Source projects were combined. But I did not find it at all easy to understand, maybe because I didn't realize at the time how closely tied it was to Liferay. I was always trying to find documentation by going to the Sun forums and wikis. I hadn't gotten involved with the Liferay community.
Sarin's book, complete with illustrations and step-by-step instructions, gave me the courage to give Liferay and Eclipse another try. I was blown away at how easy it was to get up and running and to deploy the first JSR-168 test portlet. After the hours spent with WebLogic I still did not know how to do the simple task of deploying a JSR-168 portlet. That was the reason in the first place that I went to the trouble of installing it. Although I finally did get a JSR-168 portlet installed on WebLogic, I dread ever having to do it again. To give you an idea of the nightmare look at the forum thread.
We should be able to use Liferay as our JSR-168 portlet testbed. It's quite simple to upload and install a portlet application. And there's so much more out-of-the-box functionality that can be added. Asking management to take a look at the portlets we deployed on Portlet Container was a bit embarrassing because of the barebones interface. I hope to have time to build up some nice looking pages and capabilities on Liferay.
Tuesday, November 17, 2009
Friday, October 2, 2009
Mystery solved
I guess I had expected something more in the way of documentation for OpenLayers that would explain the behavior of the different cases I had created for trying to display my KML file on an OpenLayers map. But thanks to Scott Davis, who does a marvelous job of teaching "GIS for Web Developers", I now have an OpenLayers map that displays the KML in Firefox and in IE. Both browsers are consistent in handling the display for both the OpenLayers.Layer.Vector class and the OpenLayers.Layer.GML class. I can't say that I understand everything that's happening behind the scenes or which of the two classes is the preferred one to use. But I do understand a whole lot more about JavaScript and OpenLayers and troubleshooting than I did before.
"Due to security restrictions in Javascript, it is not possible to retrieve information from remote domains via an XMLHttpRequest. Classes like Layer.WFS and Layer.GeoRSS use XMLHTTPRequest to get their data." Those two statements from the OpenLayers FAQ page were the key to solving the problem. I think I had suspected that before taking Scott's class, but I suffer from a need to know exactly why things work the way they do, even in the most obscure details that most people don't care about. I wanted to see something in black and white that said if you are using the Layer.Vector and Layer.GML you need to have a proxy. The OpenLayers examples for KML don't show the proxy host variable being set like they do for the Layer.WFS examples. I guess I was being a bit laxy, too, and not wanting to create a servlet to make the call if I didn't have to.
But without getting into the gory details, Scott assured me that if I just accepted the rule that the HTML with the JavaScript must be in the same domain as the server from which the data is being retrieved my problems would go away. I bit the bullet and created a servlet to intercept the OpenLayers call, grab the data from the remote domain and push it back to OpenLayers. Now I know to always use a proxy. And I have a better proxy servlet than the first attempt at a servlet I made months ago when I was using the Layer.WFS class.
For anyone who is doing web development that involves GIS and has struggled with the learning curve, I highly recommend purchasing the book "GIS for Web Developers" by Scott Davis. And to really get a good foundation check out his class.
"Due to security restrictions in Javascript, it is not possible to retrieve information from remote domains via an XMLHttpRequest. Classes like Layer.WFS and Layer.GeoRSS use XMLHTTPRequest to get their data." Those two statements from the OpenLayers FAQ page were the key to solving the problem. I think I had suspected that before taking Scott's class, but I suffer from a need to know exactly why things work the way they do, even in the most obscure details that most people don't care about. I wanted to see something in black and white that said if you are using the Layer.Vector and Layer.GML you need to have a proxy. The OpenLayers examples for KML don't show the proxy host variable being set like they do for the Layer.WFS examples. I guess I was being a bit laxy, too, and not wanting to create a servlet to make the call if I didn't have to.
But without getting into the gory details, Scott assured me that if I just accepted the rule that the HTML with the JavaScript must be in the same domain as the server from which the data is being retrieved my problems would go away. I bit the bullet and created a servlet to intercept the OpenLayers call, grab the data from the remote domain and push it back to OpenLayers. Now I know to always use a proxy. And I have a better proxy servlet than the first attempt at a servlet I made months ago when I was using the Layer.WFS class.
For anyone who is doing web development that involves GIS and has struggled with the learning curve, I highly recommend purchasing the book "GIS for Web Developers" by Scott Davis. And to really get a good foundation check out his class.
Thursday, September 24, 2009
KML file on OpenLayers Map
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.
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.
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.
Friday, May 29, 2009
Back to Portlet Puzzles
The learning curve for OpenLayers and WCS was temporarily set aside again as I found that I needed to spend more time negotiating the curves in the portlet learning road.
I had the basics down well enough a few months ago when I had managed to develop the application with the SOAP Service Client Portlets. But I had been learning as I went along and I knew that the way I did things in the earlier portlets was different from what I later decided was the right way to do it. And there had been no real in-depth testing done on any of the portlets.
I set out to document a series of test cases that would make it possible for another person to do the testing. It was difficult enough to start something from scratch and decide what format to use and how detailed to make the instructions. Then as I came up with explanations and procedures I realized that there were things that I myself didn't understand very well on how they worked. Some test cases that I hadn't thought of before showed errors in my original logic. And there were cases where I had chosen to use shortcuts and display less than what was actually available as data from the service. I knew I had to spend some time refactoring the code.
Of course, whenever you start to make changes in your code it always turns out to take longer than what you planned. And when it comes to portlets there are many parts of development that I still don't understand. But after this week's efforts I can say that I finally have a better understanding of the portlet lifecycle and how to properly use the various classes and objects that are needed for portlets like the SOAP Service Client Portlets, which are primarily used to gather form data from the user and return data results for display.
I had used a lot of examples over the past year to further my learning. Some examples came from sources that were being used to illustrate the new features of JSR 286. I probably shouldn't have started with those before I had a really good understanding of JSR 168. That caused confusion by making things more complicated than the simple cases I was trying to solve.
Not until this week did I understand when I should be using getParameter/setParameter as opposed to getAttribute/setAttribute. It was a real revelation to realize that setting render parameters was all that I needed to do in order for the values obtained from the service calls in the processAction method to be available to the doView method. And that what was available in the doView would also be available in the view jsp--there wasn't a need to get the parameters in both places. "getPortletContext().getRequestDispatcher.include(request,response)" had never dawned on me that "include" meant everything was shared between the two.
It took a lot of trial and error and null pointer exceptions but where I ended up getting a lot of extra mileage was once I figured out how to use the setRenderParameters and getParameterMap to pass a whole series of data values. This made possible a total revamping of the Multi-Point GeoidHeight portlet. Whereas before I only displayed a comma-separated list of the answers, I can now display all the information in a nice table form, including original inputs, inputs converted to decimal degrees, the heights and any error messages that are returned. I vaguely remember one of the other portlets I did where I knew this was a feature I needed to incorporate but didn't want to take the time then to figure it out. There's a still a bit of cleanup on Multi-Point GeoidHeight and then I'll be continuing with the other SOAP Service Client Portlets to see what needs fixing/enhancing.
I had the basics down well enough a few months ago when I had managed to develop the application with the SOAP Service Client Portlets. But I had been learning as I went along and I knew that the way I did things in the earlier portlets was different from what I later decided was the right way to do it. And there had been no real in-depth testing done on any of the portlets.
I set out to document a series of test cases that would make it possible for another person to do the testing. It was difficult enough to start something from scratch and decide what format to use and how detailed to make the instructions. Then as I came up with explanations and procedures I realized that there were things that I myself didn't understand very well on how they worked. Some test cases that I hadn't thought of before showed errors in my original logic. And there were cases where I had chosen to use shortcuts and display less than what was actually available as data from the service. I knew I had to spend some time refactoring the code.
Of course, whenever you start to make changes in your code it always turns out to take longer than what you planned. And when it comes to portlets there are many parts of development that I still don't understand. But after this week's efforts I can say that I finally have a better understanding of the portlet lifecycle and how to properly use the various classes and objects that are needed for portlets like the SOAP Service Client Portlets, which are primarily used to gather form data from the user and return data results for display.
I had used a lot of examples over the past year to further my learning. Some examples came from sources that were being used to illustrate the new features of JSR 286. I probably shouldn't have started with those before I had a really good understanding of JSR 168. That caused confusion by making things more complicated than the simple cases I was trying to solve.
Not until this week did I understand when I should be using getParameter/setParameter as opposed to getAttribute/setAttribute. It was a real revelation to realize that setting render parameters was all that I needed to do in order for the values obtained from the service calls in the processAction method to be available to the doView method. And that what was available in the doView would also be available in the view jsp--there wasn't a need to get the parameters in both places. "getPortletContext().getRequestDispatcher.include(request,response)" had never dawned on me that "include" meant everything was shared between the two.
It took a lot of trial and error and null pointer exceptions but where I ended up getting a lot of extra mileage was once I figured out how to use the setRenderParameters and getParameterMap to pass a whole series of data values. This made possible a total revamping of the Multi-Point GeoidHeight portlet. Whereas before I only displayed a comma-separated list of the answers, I can now display all the information in a nice table form, including original inputs, inputs converted to decimal degrees, the heights and any error messages that are returned. I vaguely remember one of the other portlets I did where I knew this was a feature I needed to incorporate but didn't want to take the time then to figure it out. There's a still a bit of cleanup on Multi-Point GeoidHeight and then I'll be continuing with the other SOAP Service Client Portlets to see what needs fixing/enhancing.
Thursday, May 14, 2009
OpenLayers again
Leaving aside all that I still need to learn about how to download data from a WCS call, I thought that a good place to start would be to make sure I knew how to use an OpenLayers map that would allow a user to draw a bounding box rectangle and then have the javascript capture the BBOX coordinates. I could see such functionality in action on a couple of sites and thought it would be fairly straightforward.
It was almost a full day's work to find an example. I get frustrated paging through all the http://www.openlayers.org/dev/examples/. A lot of them don't work or, if they do work, it's not clear what you have to do to get them to work and what it is that you are supposed to see when you use them. The list changes rapidly and when I'm looking for something in particular I start at the top of the list and work my way down and usually run out of time or patience before I get to the bottom. This time I decided to start at the bottom of the list.
As well as looking at the examples on the OpenLayers site, I thought I would try some Google queries, too. That turned up some interesting information, but nothing that was what I was specifically looking for. In this particular instance those searches, combined with the decision to start at the bottom of the OpenLayers list, caused me to lose a lot of time. I finally found what I was looking for near the top of the list of OpenLayers examples. I shouldn't look at it as lost time, I suppose, because I learned new things along the way.
In any case, using a combination of ideas from custom-control.html and custom-control-point.html (that one doesn't even display the map when you look at it on the OpenLayers site) I created a BBOX1.html with the basic functionality that I wanted. The user can use the shift-click (and where is this documented in OpenLayers?) to draw a bounding box. When the mouse is released the BBOX coordinates display in the area below the map. Not very useful, in and of itself, but it's a big step because now I can capture those coordinates and use them when I'm to the point of building the URL to make the WCS call.
But today we have a new problem. A common approach in the OpenLayers examples, and the one being used in BBOX1.html, is to create an init() function that does the work of creating the map object with the base layers and controls and events that then gets called from onload() in the body tag. That's all well and good for a normal web page, but it doesn't work in the portlet world, which is where I'm playing.
Since portlets are fragments of HTML markup you cannot use the head, title, or body tags. Those tags are under the control of the portlet container. Whenever I use javascript in a portlet I have to make sure that the code is all within the body tag, because that is the only place you can put HTML in a portlet. When I get an OpenLayers example to work I take the code in the init() function and put it all within the body tag, instead of a separate function. I've always wondered if there'd be a situation where that would mess things up.
I made a BBOX2.html file with the init() function removed and all the code put inside the body tag. Unless I'm overlooking an obvious mistake, there are no other differences between the two HTML files. But now when I load the BBOX2.html file in Firefox I get a script error that points me to a line of code that's within the OpenLayers.js file. The code is referring to an element.style object and the error states that "element has no properties." It's next to impossible to follow any flow of code within OpenLayers.js because there's no formatting in the file. And I certainly wouldn't want to make changes to that file. So why does Firefox complain that the element has no properties just because the code is taken out of the head tag and put in the body tag? It makes no sense. Welcome to my OpenLayers world.
It was almost a full day's work to find an example. I get frustrated paging through all the http://www.openlayers.org/dev/examples/. A lot of them don't work or, if they do work, it's not clear what you have to do to get them to work and what it is that you are supposed to see when you use them. The list changes rapidly and when I'm looking for something in particular I start at the top of the list and work my way down and usually run out of time or patience before I get to the bottom. This time I decided to start at the bottom of the list.
As well as looking at the examples on the OpenLayers site, I thought I would try some Google queries, too. That turned up some interesting information, but nothing that was what I was specifically looking for. In this particular instance those searches, combined with the decision to start at the bottom of the OpenLayers list, caused me to lose a lot of time. I finally found what I was looking for near the top of the list of OpenLayers examples. I shouldn't look at it as lost time, I suppose, because I learned new things along the way.
In any case, using a combination of ideas from custom-control.html and custom-control-point.html (that one doesn't even display the map when you look at it on the OpenLayers site) I created a BBOX1.html with the basic functionality that I wanted. The user can use the shift-click (and where is this documented in OpenLayers?) to draw a bounding box. When the mouse is released the BBOX coordinates display in the area below the map. Not very useful, in and of itself, but it's a big step because now I can capture those coordinates and use them when I'm to the point of building the URL to make the WCS call.
But today we have a new problem. A common approach in the OpenLayers examples, and the one being used in BBOX1.html, is to create an init() function that does the work of creating the map object with the base layers and controls and events that then gets called from onload() in the body tag. That's all well and good for a normal web page, but it doesn't work in the portlet world, which is where I'm playing.
Since portlets are fragments of HTML markup you cannot use the head, title, or body tags. Those tags are under the control of the portlet container. Whenever I use javascript in a portlet I have to make sure that the code is all within the body tag, because that is the only place you can put HTML in a portlet. When I get an OpenLayers example to work I take the code in the init() function and put it all within the body tag, instead of a separate function. I've always wondered if there'd be a situation where that would mess things up.
I made a BBOX2.html file with the init() function removed and all the code put inside the body tag. Unless I'm overlooking an obvious mistake, there are no other differences between the two HTML files. But now when I load the BBOX2.html file in Firefox I get a script error that points me to a line of code that's within the OpenLayers.js file. The code is referring to an element.style object and the error states that "element has no properties." It's next to impossible to follow any flow of code within OpenLayers.js because there's no formatting in the file. And I certainly wouldn't want to make changes to that file. So why does Firefox complain that the element has no properties just because the code is taken out of the head tag and put in the body tag? It makes no sense. Welcome to my OpenLayers world.
Monday, May 11, 2009
From SOAP Service Client Portlets to WCS Map Portlet
I've set aside the SOAP Service Client Portlets for now in favor of investigating the next task on the list. The goal is to build a map portlet that allows a user to select map layers from a WMS, draw a bounding box on the map, and download data from a WCS call. WMS and WCS are Open Geospatial Consortium (OGC) specs for Web Map Service and Web Coverage Service, respectively. And "map portlet" in this project that I'm a part of means having to struggle with my old friend, the OpenLayers JavaScript library.
Months past I struggled with OpenLayers when I was trying to build a Web Feature Service (WFS) client. I got the minimal test case working before I got dragged into other things. Wouldn't you know it, though, there's a whole new set of things to understand about WCS. I'd worked some with WMS and had the basic idea of that one, but I hadn't really paid any attention to WCS. I tried to get back into the mode of those two things by starting with some sample data sets. Surely there had to be some WMS and WCS sample data somewhere out on the Web.
What a tangled mess it is in the world of GIS data. Some things, including the Scott Davis "GIS for Web Developers", are excellent resources to a certain level but just when you need the key thing of "where is some data I can use in an OpenLayers call" you find out that the information is no longer current. Or the supposed map server is down. Or there is some layer that GAIA actually finds, but then it won't show anything because the zoom is wrong or some other inexplicable error.
I've learned way more in three days at this than I think my head can handle. I went back to playing around some more with GeoServer 1.7.0 that I had installed once before. That was explained well in the Scott Davis' book and provided a lot of insight. But it was an older version and talked about the Mapbuilder client, which is now replaced by an OpenLayers client. I hope I don't have to go to the extent of having my own functional OGC server just to get some sample WCS data to play with.
Some developers on my team have done work in this area and I was pointed to a couple of sample OpenLayers calls. But the only way to get the calls to actually return the data is to have a CAC-enabled workstation, which my laptop is not. Going back and forth between my laptop and a machine on another network where I can use the CAC helped me to make some headway. I hope to get either a CAC reader on my laptop or to find some WWW WCS data that I can use.
And, of course, there's a hassle everytime I have to add something to my basic OpenLayers map. I wasn't able to find the syntax error in the WCS call until a developer on my team said he used Firebug and it returned an exception saying the a map.setCenter call was needed. I never saw that when I was using Firebug--don't know why it didn't show up for me.
Unfortunately, when I go back and forth with the 2 systems I run into the problem that the CAC-enabled system does not have Firefox installed and security restraints prevent the installation of any software on that machine. Hence, using Firebug for debugging on my laptop is helpful but then IE7 on the other machine doesn't always agree with Firefox as to what is allowable JavaScript code. I was pointed to Visual Web Developer to debug IE issues. Something else I'll need to learn. Good thing I'm not opposed to learning new stuff. It never ends in this job.
Months past I struggled with OpenLayers when I was trying to build a Web Feature Service (WFS) client. I got the minimal test case working before I got dragged into other things. Wouldn't you know it, though, there's a whole new set of things to understand about WCS. I'd worked some with WMS and had the basic idea of that one, but I hadn't really paid any attention to WCS. I tried to get back into the mode of those two things by starting with some sample data sets. Surely there had to be some WMS and WCS sample data somewhere out on the Web.
What a tangled mess it is in the world of GIS data. Some things, including the Scott Davis "GIS for Web Developers", are excellent resources to a certain level but just when you need the key thing of "where is some data I can use in an OpenLayers call" you find out that the information is no longer current. Or the supposed map server is down. Or there is some layer that GAIA actually finds, but then it won't show anything because the zoom is wrong or some other inexplicable error.
I've learned way more in three days at this than I think my head can handle. I went back to playing around some more with GeoServer 1.7.0 that I had installed once before. That was explained well in the Scott Davis' book and provided a lot of insight. But it was an older version and talked about the Mapbuilder client, which is now replaced by an OpenLayers client. I hope I don't have to go to the extent of having my own functional OGC server just to get some sample WCS data to play with.
Some developers on my team have done work in this area and I was pointed to a couple of sample OpenLayers calls. But the only way to get the calls to actually return the data is to have a CAC-enabled workstation, which my laptop is not. Going back and forth between my laptop and a machine on another network where I can use the CAC helped me to make some headway. I hope to get either a CAC reader on my laptop or to find some WWW WCS data that I can use.
And, of course, there's a hassle everytime I have to add something to my basic OpenLayers map. I wasn't able to find the syntax error in the WCS call until a developer on my team said he used Firebug and it returned an exception saying the a map.setCenter call was needed. I never saw that when I was using Firebug--don't know why it didn't show up for me.
Unfortunately, when I go back and forth with the 2 systems I run into the problem that the CAC-enabled system does not have Firefox installed and security restraints prevent the installation of any software on that machine. Hence, using Firebug for debugging on my laptop is helpful but then IE7 on the other machine doesn't always agree with Firefox as to what is allowable JavaScript code. I was pointed to Visual Web Developer to debug IE issues. Something else I'll need to learn. Good thing I'm not opposed to learning new stuff. It never ends in this job.
Wednesday, May 6, 2009
Scaled Back Geographic Translator Service
I had to scale back quite a bit from what the sample web client offers for Geographic Translator Service but I think I finally got it all working as a portlet. At least the concept is there now and someone could expand the 5 possible coordinate systems the portlet offers back to the 36 offered by the service if it proves to be a useful portlet.
I had to learn some things about CSS in order to get a dynamic display of the proper input fields needed for whichever coordinate system the user selects from the pulldown. I ended up going back to the method of using separate divs for each group of form fields AND putting a form in each div. That last part is the key concept I missed when I tried doing it that way the first time.
Copying sample code from the Internet when you don't really understand something has its own hazards. In this case, I was copying the example that gave me the clue about the form within the div but it had a lot of extra CSS attributes that the other example didn't have. And my knowledge of CSS is very limited. I can say, though, that after the struggles to get it to work I know more now about CSS than when I started. In particular, the difference between "display" and "visibility" and why to use one rather than the other.
The really amusing CSS goof resulted because the example I started with used absolute positioning, which I didn't know enough about to change. When I thought everything was ready to test out I was about to give up in despair again when I used the pulldown with the onClick and I still didn't see the divs get changed to display the fields of the form. I tried pulling all the code out of the JSP and putting it into a separate HTML file. When I did it that way it would work.
So what was preventing the divs from displaying when the code was part of the portlet?
Suddenly, during one of the display attempts my eyes were drawn to the top of the portal page. I haven't been seeing the top of the portal page for awhile because as the list of finished portlets grows the one I'm currently working on gets pushed to the bottom of the page. But there up at the top, overlaid on the Geoid Height portlet, was the missing div! I thought at first it was an issue with not having used portlet namespace tags and was ready to go back and add all that nonsense like I had to do for the OpenLayers map portlet. But it turned out the problem was with the absolute positioning within the style attribute. Once I removed all of that and let it use the default (position within the normal flow of the page) the problem went away.
There were still other problems to solve, including how to get the correct default values to display for each of the div sets. I think it was during these struggles that I finally had to cut back on all the parameters and quit trying to reuse the same names within each set. I know it's not very efficient to have different variable names for each of the coordinate value fields. There's probably some way to make use of arrays and if this portlet is to grow back up to the scale of offering 36 different coordinate systems that could probably be solved. But for now I think it's OK and it gives the basic sense of what the portlet is doing.
As usual, I've run out of steam when I think of what's left to do for giving it a thorough testing. The challenge I will deal with next is to remove from the project the extra portlet that I had created when I first started Geographic Translator and thought I was going to need a portlet that would allow the user to look up the meaning of the RESTful interface cryptic parameter strings. A couple of weeks ago I had made the mistake of creating a test portlet in the project that I later wanted to delete. Trying to delete and clean up completely what gets created when a portlet is added to the project turned out to be a non-trivial task. I learned from that experience to create a test portlet within a separate test project where I could delete the whole project when the test was done. But now that there's an unneeded portlet in this project I get to go through the "delete and clean" exercise again. There should be an easier way.
I had to learn some things about CSS in order to get a dynamic display of the proper input fields needed for whichever coordinate system the user selects from the pulldown. I ended up going back to the method of using separate divs for each group of form fields AND putting a form in each div. That last part is the key concept I missed when I tried doing it that way the first time.
Copying sample code from the Internet when you don't really understand something has its own hazards. In this case, I was copying the example that gave me the clue about the form within the div but it had a lot of extra CSS attributes that the other example didn't have. And my knowledge of CSS is very limited. I can say, though, that after the struggles to get it to work I know more now about CSS than when I started. In particular, the difference between "display" and "visibility" and why to use one rather than the other.
The really amusing CSS goof resulted because the example I started with used absolute positioning, which I didn't know enough about to change. When I thought everything was ready to test out I was about to give up in despair again when I used the pulldown with the onClick and I still didn't see the divs get changed to display the fields of the form. I tried pulling all the code out of the JSP and putting it into a separate HTML file. When I did it that way it would work.
So what was preventing the divs from displaying when the code was part of the portlet?
Suddenly, during one of the display attempts my eyes were drawn to the top of the portal page. I haven't been seeing the top of the portal page for awhile because as the list of finished portlets grows the one I'm currently working on gets pushed to the bottom of the page. But there up at the top, overlaid on the Geoid Height portlet, was the missing div! I thought at first it was an issue with not having used portlet namespace tags and was ready to go back and add all that nonsense like I had to do for the OpenLayers map portlet. But it turned out the problem was with the absolute positioning within the style attribute. Once I removed all of that and let it use the default (position within the normal flow of the page) the problem went away.
There were still other problems to solve, including how to get the correct default values to display for each of the div sets. I think it was during these struggles that I finally had to cut back on all the parameters and quit trying to reuse the same names within each set. I know it's not very efficient to have different variable names for each of the coordinate value fields. There's probably some way to make use of arrays and if this portlet is to grow back up to the scale of offering 36 different coordinate systems that could probably be solved. But for now I think it's OK and it gives the basic sense of what the portlet is doing.
As usual, I've run out of steam when I think of what's left to do for giving it a thorough testing. The challenge I will deal with next is to remove from the project the extra portlet that I had created when I first started Geographic Translator and thought I was going to need a portlet that would allow the user to look up the meaning of the RESTful interface cryptic parameter strings. A couple of weeks ago I had made the mistake of creating a test portlet in the project that I later wanted to delete. Trying to delete and clean up completely what gets created when a portlet is added to the project turned out to be a non-trivial task. I learned from that experience to create a test portlet within a separate test project where I could delete the whole project when the test was done. But now that there's an unneeded portlet in this project I get to go through the "delete and clean" exercise again. There should be an easier way.
Saturday, May 2, 2009
Getting Nowhere Fast
I seem to be getting nowhere fast with the Geographic Translator Web Service client. Once everything was fixed to account for the fact that the services WSDL URL had changed, I realized that the confusing instructions on how to pass parameters to the translator service that I had spent days trying to understand was not meant to be the way to call the service. The posted client and instructions I had been looking at were created to provide a method of testing the RESTful interface to the web service.
As part of the new server that went online to host the SOAP services, the developer posted a sample client for the Geographic Translator Service that was a more familiar way to collect input from the user. Each piece of the input was its own textbox or pulldown menu, instead of several cryptic strings of coded letters and numbers separated by an exclamation point. I had wondered why the data would be input that way only to then have to be parsed apart in order to set up the individual parameter fields in the web service call. Being able to see this version of a web client in action really helped clarify what was going on with the service.
But changing that horse in midstream led to a new difficulty. When a user selects which one of the 36 coordinate systems that will be used as the input system for the transformation, that changes the number and type of parameters that must be entered to represent the coordinate. The HTML page needs to change dynamically to present the user with the correct entry fields after the coordinate system selection is made.
I thought that I had come up with a solution by making use of div tags and some Javascript that would display or not display the appropriate div after the user selected the coordinate system from a pulldown. To get a feel for how it would work I started small by limiting the possible coordinate systems to just 5 of the 36. It took awhile to get the divs set up the way that looked best and, even then, I was stumped on how to get any of them, except the first, to change style when displayed to align the input parameters to the right.
Getting the alignment to look nice turned out to be the least of my problems. It was when I decided they looked good enough and went to the next step of actually submitting the data that I could see it wouldn't work. I had wanted to use the same names for the input fields in each of the divs and only have one form. But after several fruitless attempts to try to get the right data to be passed in to the right fields after the coordinate system was changed I decided that it could not be done that way. After the submission of the form it appears that the server does not make a distinction between parameters that are named the same thing but are in different divs within the same form.
The only way I could think to do it next, was to start all over with a redesign where I would have a separate JSP page for each of the different coordinate systems. It was tedious work starting over and copying and pasting to make the set of JSP pages. And not the best solution because I could see there was a lot of duplicate code. But at least I was getting the right data in when I ran through the first test. It was when I selected the pulldown to choose a different coordinate system that I realized the fallacy of my thinking. I had a JSP page ready and waiting to display for that next coordinate system but what was going to trigger the display of that page? A Javascript function that was called by an onClick in the select tag had enabled the display of the div in the method I had used before. But now without the Javascript there was nothing to dynamically change the HTML and nothing to rerender the portlet so that the doView would get called to display the proper JSP page.
What to try next? I wonder if I could make use of what's there and just figure out a way to fit in a renderURL call because that would call the doView method. Would I put a link somewhere for the user to click, sort of like when I had the "Back" functionality in one of the portlets? Or should I start over and make a beginning page where the user first selects the coordinate system as a link that loads the correct JSP page?
While looking for some more ideas on the Internet I stumbled on an example that has dynamic HTML to hide and show a div like what I had earlier. I wish I had seen this example instead of the one I followed. This one has a form within each of the divs. I bet mine would have worked if I had done it that way instead of trying to just have a single form and use the divs to separate out the parameter fields. Usually when I try something and it doesn't work I make a copy of it, just in case. But, wouldn't you know, this time I did not save any of what I had when I was trying to use the Javascript with the div tags. Enough for one day. Maybe my thoughts will fall into place and give me the proper solution the next time that I look at it.
As part of the new server that went online to host the SOAP services, the developer posted a sample client for the Geographic Translator Service that was a more familiar way to collect input from the user. Each piece of the input was its own textbox or pulldown menu, instead of several cryptic strings of coded letters and numbers separated by an exclamation point. I had wondered why the data would be input that way only to then have to be parsed apart in order to set up the individual parameter fields in the web service call. Being able to see this version of a web client in action really helped clarify what was going on with the service.
But changing that horse in midstream led to a new difficulty. When a user selects which one of the 36 coordinate systems that will be used as the input system for the transformation, that changes the number and type of parameters that must be entered to represent the coordinate. The HTML page needs to change dynamically to present the user with the correct entry fields after the coordinate system selection is made.
I thought that I had come up with a solution by making use of div tags and some Javascript that would display or not display the appropriate div after the user selected the coordinate system from a pulldown. To get a feel for how it would work I started small by limiting the possible coordinate systems to just 5 of the 36. It took awhile to get the divs set up the way that looked best and, even then, I was stumped on how to get any of them, except the first, to change style when displayed to align the input parameters to the right.
Getting the alignment to look nice turned out to be the least of my problems. It was when I decided they looked good enough and went to the next step of actually submitting the data that I could see it wouldn't work. I had wanted to use the same names for the input fields in each of the divs and only have one form. But after several fruitless attempts to try to get the right data to be passed in to the right fields after the coordinate system was changed I decided that it could not be done that way. After the submission of the form it appears that the server does not make a distinction between parameters that are named the same thing but are in different divs within the same form.
The only way I could think to do it next, was to start all over with a redesign where I would have a separate JSP page for each of the different coordinate systems. It was tedious work starting over and copying and pasting to make the set of JSP pages. And not the best solution because I could see there was a lot of duplicate code. But at least I was getting the right data in when I ran through the first test. It was when I selected the pulldown to choose a different coordinate system that I realized the fallacy of my thinking. I had a JSP page ready and waiting to display for that next coordinate system but what was going to trigger the display of that page? A Javascript function that was called by an onClick in the select tag had enabled the display of the div in the method I had used before. But now without the Javascript there was nothing to dynamically change the HTML and nothing to rerender the portlet so that the doView would get called to display the proper JSP page.
What to try next? I wonder if I could make use of what's there and just figure out a way to fit in a renderURL call because that would call the doView method. Would I put a link somewhere for the user to click, sort of like when I had the "Back" functionality in one of the portlets? Or should I start over and make a beginning page where the user first selects the coordinate system as a link that loads the correct JSP page?
While looking for some more ideas on the Internet I stumbled on an example that has dynamic HTML to hide and show a div like what I had earlier. I wish I had seen this example instead of the one I followed. This one has a form within each of the divs. I bet mine would have worked if I had done it that way instead of trying to just have a single form and use the divs to separate out the parameter fields. Usually when I try something and it doesn't work I make a copy of it, just in case. But, wouldn't you know, this time I did not save any of what I had when I was trying to use the Javascript with the div tags. Enough for one day. Maybe my thoughts will fall into place and give me the proper solution the next time that I look at it.
Tuesday, April 28, 2009
Geographic Translator
The interesting challenge with Geographic Translator has nothing to do with portlet technologies. This application is in dire need of someone with Graphical User Interface skills.
There are very cryptic parameter strings that have to be composed and passed in to the service to produce the desired transformation. Wanting to provide a capability to support transformations between 36 different coordinate systems and 230 different datums, while leaving the SOAP parameters as close as possible to the parameters of the underlying legacy application, has led to a very confusing set of instructions.
It was much easier to use the code completion feature of NetBeans after building the web service client to figure out exactly what data was needed by each of the service options. But then, not being very adept at designing web page forms, I was left to struggle with figuring out the best way to present the instructions to users for the many different use cases.
I was starting to get the hang of using the HTML div tag and the onClick javascript function to dynamically present the user with the form fields needed for input based on which type of transformation was being performed. Then suddenly the WSDL was no longer accessible over the network. So what was going on this time?
After a number of email exchanges (what exactly does "they changed something on the external firewall to prevent me natting" mean?) I found out that the IP address of the 6 WSDLs I was using in the NetBeans project that has the 6 SOAP Web Service clients had been changed. So now, how difficult is it to get the code working again?
I remembered the little trick of doing a "Refresh Client" to point the services to the new WSDL location. I also did a clean and build. The build was now working but if I tried to run the project and access one of the services I would continue to get an exception stating that the WSDL could not be found because it was looking at the old IP address. The solution was to delete each of the web service clients and then recreate them with the new WSDL. Not really that time consuming once I knew what had to be done, but, of course, the whole day was wasted trying to figure out what was going on.
The developer of the SOAP Web Services was kind enough to provide me with his code solution that uses a configuration file to make a Web Service client configurable after deployment. That will definitely bear looking into since this environment is proving to be somewhat less than stable.
There are very cryptic parameter strings that have to be composed and passed in to the service to produce the desired transformation. Wanting to provide a capability to support transformations between 36 different coordinate systems and 230 different datums, while leaving the SOAP parameters as close as possible to the parameters of the underlying legacy application, has led to a very confusing set of instructions.
It was much easier to use the code completion feature of NetBeans after building the web service client to figure out exactly what data was needed by each of the service options. But then, not being very adept at designing web page forms, I was left to struggle with figuring out the best way to present the instructions to users for the many different use cases.
I was starting to get the hang of using the HTML div tag and the onClick javascript function to dynamically present the user with the form fields needed for input based on which type of transformation was being performed. Then suddenly the WSDL was no longer accessible over the network. So what was going on this time?
After a number of email exchanges (what exactly does "they changed something on the external firewall to prevent me natting" mean?) I found out that the IP address of the 6 WSDLs I was using in the NetBeans project that has the 6 SOAP Web Service clients had been changed. So now, how difficult is it to get the code working again?
I remembered the little trick of doing a "Refresh Client" to point the services to the new WSDL location. I also did a clean and build. The build was now working but if I tried to run the project and access one of the services I would continue to get an exception stating that the WSDL could not be found because it was looking at the old IP address. The solution was to delete each of the web service clients and then recreate them with the new WSDL. Not really that time consuming once I knew what had to be done, but, of course, the whole day was wasted trying to figure out what was going on.
The developer of the SOAP Web Services was kind enough to provide me with his code solution that uses a configuration file to make a Web Service client configurable after deployment. That will definitely bear looking into since this environment is proving to be somewhat less than stable.
Wednesday, April 22, 2009
Geonames Service Portlet is done
I contacted the developer of the Web Service to see if he could help troubleshoot the com.sun.xml.internal.ws.server.UnsupportedMediaException that I was getting. At first he said he wasn't getting the exception but when I sent him the code of the simple Java client I had built he reproduced the error.
It appeared that my code was sending a blank string for one of the query parameters and rather than sending XML the service was generating an HTML error page--something a SOAP service is not supposed to do. The developer determined that the problem was with the Saxon9 library file built into the Web service projects. The Saxon library is needed for XSLT 2.0 transformations but, apparently, there are problems using Saxon9 with Glassfish. Once the library was moved out of the projects and into the system lib for Glassfish, the service began returning the correct error messages. From there, it was up to me to do my usual fumbling around with trial and error and using the NetBeans debugger to get the portlet working.
Meanwhile, I had the opportunity to do some reading in the book "JBoss Portal Server Development" by Ramanujam Rao. The sample code accompanying the book gave me an idea on how to restructure the geonames portlet. Instead of having one form on the view page with a pulldown to select the four different service options I created 5 different view pages. The initial page is a table with links and descriptions of the 4 services. Behind the links I use the renderURL to load the view page for the selected service. This made it much easier to break out the slight differences in input parameters for each of the 4. It took me awhile to grasp the correct logic flow to make sure the right page is displayed at the right time and that the data is there for dispaly when it's supposed to be.
That exercise gave me a better understanding of when to use renderURL versus actionURL and the difference between parameters and attributes. Since the Portlet Specification is modeled after the Servlet Specification I would probably have an easier time grasping the concepts if I were more familiar with the Servlet spec.
On to the next one--Geographic Translator service. Looks complicated.
It appeared that my code was sending a blank string for one of the query parameters and rather than sending XML the service was generating an HTML error page--something a SOAP service is not supposed to do. The developer determined that the problem was with the Saxon9 library file built into the Web service projects. The Saxon library is needed for XSLT 2.0 transformations but, apparently, there are problems using Saxon9 with Glassfish. Once the library was moved out of the projects and into the system lib for Glassfish, the service began returning the correct error messages. From there, it was up to me to do my usual fumbling around with trial and error and using the NetBeans debugger to get the portlet working.
Meanwhile, I had the opportunity to do some reading in the book "JBoss Portal Server Development" by Ramanujam Rao. The sample code accompanying the book gave me an idea on how to restructure the geonames portlet. Instead of having one form on the view page with a pulldown to select the four different service options I created 5 different view pages. The initial page is a table with links and descriptions of the 4 services. Behind the links I use the renderURL to load the view page for the selected service. This made it much easier to break out the slight differences in input parameters for each of the 4. It took me awhile to grasp the correct logic flow to make sure the right page is displayed at the right time and that the data is there for dispaly when it's supposed to be.
That exercise gave me a better understanding of when to use renderURL versus actionURL and the difference between parameters and attributes. Since the Portlet Specification is modeled after the Servlet Specification I would probably have an easier time grasping the concepts if I were more familiar with the Servlet spec.
On to the next one--Geographic Translator service. Looks complicated.
Wednesday, April 15, 2009
Geonames Service Portlet
I thought I had settled on a good process for building the SOAP Service client portlets. Development was just getting to the point of being routine--dump the WSDL URL into the NetBeans Web Service Client wizard, adjust the sample HTML query form to make it a dynamic JSP page for the portlet view mode, and then use NetBeans code completion to figure out what parameters the web service calls required. Coordinate Parse, Country Names and Geoid Height (single and multiple) were finished and posted to the virtual server to be viewable over the Internet. That brought me approximately to the place I had been when the services were hosted on a different server and I had first built the portlets.
But then I tackled Geonames Service, which had not been available the first time I was on this task. It appeared to be straighforward like the others. There was a WSDL and a sample HTML query form. The query form had 4 different submit buttons for 4 different cases so I had to make a decision on whether or not to break out the 4 into separate portlets like I had done with the 2 different Geoid Height input forms. I opted instead to use one portlet with one form, but added to the form a pulldown for the 4 different options. There are a couple of extra fields required for 2 of the 4 queries so at some point I will need to figure out how to dynamically change the HTML so that it displays the extra fields when the user selects one of the pulldown options where those fields are required.
To get something up and running quickly I decided to use the defaults for entry parameters and just make sure I could return and display the same thing as the sample query form. I then realized that even the sample was not returning data in a couple of the cases. Contacting the developor gave the explanation that the backend database of the web service had only a small sampling of data loaded. He gave some guidance on which query parameters would be most likely to yield data. Unfortunately, when I finally got to the point of being ready to do the initial basic query through the portlet I ran into a new snag.
The client was returning an exception:
com.sun.xml.internal.ws.server.UnsupportedMediaException: Unsupported Content-Type: text/html;charset=utf-8 Supported ones are: [text/xml]
Putting the client in Debug mode showed that the service and port calls were successful and the input parameter was being loaded with all the necessary data. But then the call to the actual operation itself caused the exception. And it was the same exception regardless of which of the 4 operations were used.
I googled the text of the exception but it didn't help me figure out the source of the problem or how to solve it. Some suggestions were to examine the server log, but that isn't an option since I have no access to the server that's hosting the service. Someone suggested using SOAPUI to see what is being returned by the server, but I'm not sure how to do that. I don't understand enough about the flow of the messages between the browser and the service to know where to look into what's going on. I even tried to simplify things by leaving the portlet, portlet container, servlet container, etc out of the picture and just building a basic Java application client to make the query. But the same thing happens--the service returns the exception as soon as the call to the operation is made. And I don't know how to use the debugger to dig any further into what happens during the call.
But then I tackled Geonames Service, which had not been available the first time I was on this task. It appeared to be straighforward like the others. There was a WSDL and a sample HTML query form. The query form had 4 different submit buttons for 4 different cases so I had to make a decision on whether or not to break out the 4 into separate portlets like I had done with the 2 different Geoid Height input forms. I opted instead to use one portlet with one form, but added to the form a pulldown for the 4 different options. There are a couple of extra fields required for 2 of the 4 queries so at some point I will need to figure out how to dynamically change the HTML so that it displays the extra fields when the user selects one of the pulldown options where those fields are required.
To get something up and running quickly I decided to use the defaults for entry parameters and just make sure I could return and display the same thing as the sample query form. I then realized that even the sample was not returning data in a couple of the cases. Contacting the developor gave the explanation that the backend database of the web service had only a small sampling of data loaded. He gave some guidance on which query parameters would be most likely to yield data. Unfortunately, when I finally got to the point of being ready to do the initial basic query through the portlet I ran into a new snag.
The client was returning an exception:
com.sun.xml.internal.ws.server.UnsupportedMediaException: Unsupported Content-Type: text/html;charset=utf-8 Supported ones are: [text/xml]
Putting the client in Debug mode showed that the service and port calls were successful and the input parameter was being loaded with all the necessary data. But then the call to the actual operation itself caused the exception. And it was the same exception regardless of which of the 4 operations were used.
I googled the text of the exception but it didn't help me figure out the source of the problem or how to solve it. Some suggestions were to examine the server log, but that isn't an option since I have no access to the server that's hosting the service. Someone suggested using SOAPUI to see what is being returned by the server, but I'm not sure how to do that. I don't understand enough about the flow of the messages between the browser and the service to know where to look into what's going on. I even tried to simplify things by leaving the portlet, portlet container, servlet container, etc out of the picture and just building a basic Java application client to make the query. But the same thing happens--the service returns the exception as soon as the call to the operation is made. And I don't know how to use the debugger to dig any further into what happens during the call.
Thursday, April 9, 2009
Geoid Height Calculator Portlet
Taking the portlets that were built originally to make SOAP Web Service calls and modifying them so that they would directly call the servlets that use the RESTful interface turned out not to be worth the effort. I decided to stick with just making the changes that would be needed to match the changes in the Web Services.
The first one that I started with was the geoid height calculator. It took awhile to figure out the new service calls and parameters and how to correctly set them up to get the results back from the server. The code completion feature of NetBeans was a big help with that.
Then I decided that I had not really designed the original portlet correctly in how it was interacting with the user to get the input data and display the output data. Plus I had not figured out in the first go-round how I should give the portlets a default input setting. I looked at more sample portlets, reread some of the documentation on the Portlet API and learned more about render parameters, RenderRequest, ActionRequest, ActionResponse, and how the portal, the portlet container, and the portlets all interact with each other and with the user.
I'm still not where I need to be. I can't decide the best approach for presenting the data input form to the user and then presenting the results from the Web Service call. Currently, I have not made use of the EDIT mode. I'm doing everything in the VIEW mode, checking in doView() to see if there's a calculated result to display. If not, the doView displays a JSP page that has the input form. If there are results to display, a different JSP page is displayed. On that page I have a "Back" link that takes the user back to the JSP page with the form after the results data has been viewed.
The problem I'm seeing is that when I'm in the same browser and I rerun the portlet after making some change to the code the view that comes up is the view that I had previously. I'm setting the ActionResponse render parameters in the processAction so they are available when the results are rendered. I would have expected that when the portal makes the first render request to the portlet that it would have no attribute data yet because the user has not yet entered anything in the form. But whatever information was in the render parameters from the previous use of the form, including the calculated result, is still available when doView() is first called. This causes the JSP page with the results from the last calculation to be displayed, instead of the JSP page with the form, as I would have expected. My thinking now is that instead of using two different pages in the VIEW mode to accomplish the gathering of data and displaying of results, what I may want to do is use the EDIT mode to display the page with the form and the VIEW mode to display the results and/or the blank starting page. But, again, I may run into the difficulty of not knowing the difference between the state of when there is data to display and when it's the starting state where the user has not yet submitted a request.
The Geoid Height Web Service offers two separate service queries. The one that the current portlet uses is the case where the user can input a single coordinate pair from which to calculate Geoid Height. I have the correct (I think) code inside the processAction method to handle the other case where the user can input a list of coordinate pairs and get the Geoid Height for each pair. But I couldn't decide the best way to display a second option in the form for that case. I decided to make these two cases into 2 separate portlets. As I begin to build the portlet for the case of multiple pairs I think I will use that one as the test case to see if it works better if I use the EDIT mode as the place to gather the user input.
The first one that I started with was the geoid height calculator. It took awhile to figure out the new service calls and parameters and how to correctly set them up to get the results back from the server. The code completion feature of NetBeans was a big help with that.
Then I decided that I had not really designed the original portlet correctly in how it was interacting with the user to get the input data and display the output data. Plus I had not figured out in the first go-round how I should give the portlets a default input setting. I looked at more sample portlets, reread some of the documentation on the Portlet API and learned more about render parameters, RenderRequest, ActionRequest, ActionResponse, and how the portal, the portlet container, and the portlets all interact with each other and with the user.
I'm still not where I need to be. I can't decide the best approach for presenting the data input form to the user and then presenting the results from the Web Service call. Currently, I have not made use of the EDIT mode. I'm doing everything in the VIEW mode, checking in doView() to see if there's a calculated result to display. If not, the doView displays a JSP page that has the input form. If there are results to display, a different JSP page is displayed. On that page I have a "Back" link that takes the user back to the JSP page with the form after the results data has been viewed.
The problem I'm seeing is that when I'm in the same browser and I rerun the portlet after making some change to the code the view that comes up is the view that I had previously. I'm setting the ActionResponse render parameters in the processAction so they are available when the results are rendered. I would have expected that when the portal makes the first render request to the portlet that it would have no attribute data yet because the user has not yet entered anything in the form. But whatever information was in the render parameters from the previous use of the form, including the calculated result, is still available when doView() is first called. This causes the JSP page with the results from the last calculation to be displayed, instead of the JSP page with the form, as I would have expected. My thinking now is that instead of using two different pages in the VIEW mode to accomplish the gathering of data and displaying of results, what I may want to do is use the EDIT mode to display the page with the form and the VIEW mode to display the results and/or the blank starting page. But, again, I may run into the difficulty of not knowing the difference between the state of when there is data to display and when it's the starting state where the user has not yet submitted a request.
The Geoid Height Web Service offers two separate service queries. The one that the current portlet uses is the case where the user can input a single coordinate pair from which to calculate Geoid Height. I have the correct (I think) code inside the processAction method to handle the other case where the user can input a list of coordinate pairs and get the Geoid Height for each pair. But I couldn't decide the best way to display a second option in the form for that case. I decided to make these two cases into 2 separate portlets. As I begin to build the portlet for the case of multiple pairs I think I will use that one as the test case to see if it works better if I use the EDIT mode as the place to gather the user input.
Monday, April 6, 2009
New Direction
For now, the portlets with the Open Layers map and the problems with deploying portlets to the Web Space Server instance on our virtual server are going to be put on the back burner. Our new direction is to more fully develop the half-dozen Geospatial SOAP Service Client portlets we prototyped several months ago. These portlets provide a user interface to the Geospatial SOAP Web Services that are running on one of our team's virtual services.
Sample services include a geoid height calculator, a map-based distance and bearing calculator, country names service and coordinate parse service.
As I investigated the changes made to the services on the virtual server I noticed that each of the services now has a RESTFul interface. Looking at the example Query Form and RESTful calls that are provided it appears that it should be much easier to create portlet clients that make RESTful calls. That is something I've not done before.
Apparently, when I build the NetBeans project I leave off the part where the wizard is used with the WDSL to create the code that looks up the web service. I can just mimic the sample Query Form in the view.jsp of the portlet and directly make a call to the servlet that is providing the RESTful interface.
Let's go create a new NetBeans project and see what happens.
Sample services include a geoid height calculator, a map-based distance and bearing calculator, country names service and coordinate parse service.
As I investigated the changes made to the services on the virtual server I noticed that each of the services now has a RESTFul interface. Looking at the example Query Form and RESTful calls that are provided it appears that it should be much easier to create portlet clients that make RESTful calls. That is something I've not done before.
Apparently, when I build the NetBeans project I leave off the part where the wizard is used with the WDSL to create the code that looks up the web service. I can just mimic the sample Query Form in the view.jsp of the portlet and directly make a call to the servlet that is providing the RESTful interface.
Let's go create a new NetBeans project and see what happens.
Wednesday, April 1, 2009
Didn't pass
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.
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.
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.
Subscribe to:
Posts (Atom)