Monday, July 25, 2011

iOS support in Oracle Maps API

With the latest patch release (version11.1.1.5.1 found here ), MapViewer's Oracle Maps JavaScript API now fully supports iPhone/iPad map interaction using touch events such as pinch to zoom out, double tap to zoom in and other general touch events. Your existing application will automatically get these support once you upgrade to the 11.1.1.5.1 version of MapViewer's oraclemaps.js lib.

In addition to the iOS support, we are also looking into Android support in the future.

Monday, July 18, 2011

Deploying MapViewer on IBM WebSphere 7

I just finished deploying MapViewer (the 11.1.1.5.1 patch release found here ) on IBM WebSphere 7, using the main steps outlined below. Overall I would say it is just a typical process of deploying any J2EE enterprise applications on WebSphere.

1. Log into WebSphere console, and pick the server instance to deploy MapViewer.

2. Start deploying MapViewer by creating a new enterprise application.

3. Download and save the mapviewer.ear file to your local file system if not already done so. Then select this EAR file when prompted. You do not need to unpack this .ear file.

4. Go through the necessary steps by accepting all the defaults as instructed, but note the following special instructions.

At step 7 "Map context roots for web modules", make sure the context root is set to "/mapviewer".

Then at Step 8 "Map security roles to users or groups", make sure the admin user (virtuser in my case) is mapped to the map_admin_role defined by MapViewer. You can ignore the secure_maps_role which is for demo purpose only. Alternatively, you can also map other WebSphere users/groups to this map_admin_role. Later you will use the mapped user or group to log into MapViewer's Admin page.

5. You should get a summery page like below at the end of the deployment steps.



Now save the configuration and finish the deployment process. You should see MapViewer in the applications list, as illustrated below.



6. Next, you need to find where WebSphere stores the mapviewer.ear's unpacked contents. The easiest way to do so, is to start MapViewer and log in to its admin page (by clicking on the Admin button from the home page at /mapviewer). Click the Management tab, then Configuration. Near the top of the page, you will see a line indicating where the mapViewerConfig.xml file was loaded from. In my case, it is:

/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/AppSrv01_Cell01/OracleAS MapViewer.ear/web.war/WEB-INF/conf/mapViewerConfig.xml

This tells us that WebSphere has expanded the mapviewer.ear file into the directory:

/opt/IBM/WebSphere/AppServer/profiles/AppSrv01/installedApps/AppSrv01_Cell01/OracleAS MapViewer.ear/.

7. Now, we need to modify MapViewer's libraries in order for it to work properly in WebSphere 7.

8. Go to MapViewer's web.war/WEB-INF/lib folder, and physically remove the two jars: jsf-api.jar and jsf-impl.jar. This ensures all MapViewer web pages (which are written in JSF 1.0) work properly in WebSphere, since WebSphere already comes with a set of JSF 1.2 jars, and we don't want our (older) JSF jar files to conflict with these.

9. From your Oracle 11g database install, copy the two JDBC driver related jars, ojdbc5.jar and orai18n.jar, and put them in MapViewer's web.war/WEB-INF/lib folder. Alternatively, you can download these two jars from Oracle's JDBC OTN web page. I used version 11.2.0.2 jars, but earlier versions of these jars should work too.

10. Now, go to WebSphere console and restart the MapViewer application.

From this point on, you will just need to perform typical MapViewer configuration tasks such as adding a new data source et al.

Final note, if before performing step 8 above (where you removed the two jsf jars), you already tried visiting some of the MapViwer pages, then it is likely you will have seen errors related to JSP exceptions. What you need to do (after performing step 8), is go to MapViewer's web.war folder, and touch every .jspx file so that their last modified timestamp gets changed. Do the same for the .jspx files under web.war/admin folder too. This will force WebSphere to re-compile all the .jspx files (using the JSF 1.2 jars that came with WebSphere).