Pages

Saturday, November 24, 2012

Deployed Web App version 0.000001


Since completing coding (several posts ago), my big adventure has been ramping up on the linux system administration skils needed to configure and deploy apps and services into (Amazon AWS/Cloud) Infrastructure. Along the way, I discovered that the AWS Free Usage Tier "Micro" instance server  is not enough to run my application stack on a single server so I had to upgrade to a "Medium" (aka "not-free") server instance. I'm also increasingly under the impression that this piddly app could have been executed (much more effectively) with a direct AJAX (Asynchronous JavaScript and XML) implementation like javascript+php rather than the heavy Google GWT AJAX framework plus the Java Enterprise Edition (J2EE) and SOAP Web Services platfoms that I've employed...but that's another project, possibly the next one, for Adventures in Webdevland. 

Finally, a fully deployed (but very basic & buggy) web application...

WEATHER SCOUT Version 0.000001 
Features:

Front-end/UI:
Display's real time weather for almost any city in the world.
And because it's hosted in the cloud, in the real-live-world-wide-web, its accessible from anywhere in the world!
Also, it has a cross-platform user interface so it works on phones, pc, mac, and ipads ! 
And it maintains consistent look & feel across all devices.


Back-end:
"Administrator" console for configuring application features (available cities can be configured...currently set to USA)
3 Tier Architecture: Web Browser UI, Web Server (Apache Tomcat), Enterprise Server(Oracle Glassfish)
SQL Database for data persistence. Users' available cities' are read from DB (Apache Derby) which is configurable by Application Administrator (via custom Web UI also hosted in the cloud)
Service Oriented Architecture (consumes/exposes SOAP Standard Web Services) to receive and display "live" weather data.
...and more bonus features constantly being discovered (aka bugs)

Release Notes
Corporate firewalls tend to block some amazon services. 
So, if this does not work from your work pc, please try your phone, or try from different network.
Performance is sloooow. Please be patient
Weather Scout is currently configured to work for US cities

Amazon Cloud Infrastructure (Continued)

Signing up and instantiating my first ever server in the cloud was impressively easy. Below is what the server instances look like in the admin console. The background window shows my Amazon hosted Virtual Machines or VMs. While the super imposed window is for connecting to the server instances. To get this form, right click on a server instance and select "connect". You have two options to connect SSH standalone client or SSH browser client which requires Java plug-in....and that's where I ran into my first issue (or educational opportunity).

The issue was not with AWS itself. The issue was that I did not have a Java Runtime Environment (JRE) installed nor a Java browser plug-in. The AWS popup screen was even helpful enough the detect and display this fact with links on how to get the JRE and plugin. And that's where it went awry for while. Considering how much GWT Java and J2EE development I've been doing, I was certain that "Of course, I had Java installed". I recall getting/installing both Oracle Java and Open Java dev kits. And after quite a bit of poking around, I realized that what I had were the Java development kits...aka JDKs, used by IDEs and OSs to compile/run Java programs which are quite something different from  the Java run-time environment, JRE which comes in the form of browser plug-ins for  running browser based java....doh. This is the kind of basic stuff that get's you stumbling and drains time but sigh...its how you learn. Remember, when you are not in the world of commercial Windows or Mac OS, this stuff is not automatically, taken care of for you.  So, the next challenge was getting/installing the JDK. Canonical, the makers or Ubuntu linux, have a software repository where they and any linux software supplier can register software so that download/install can be straightforward. Unfortunately, the Java JDK which used to be in this repository is no more. It would have been OK if the JDK was never in Canonical's repository but because it once was, there was all this conflicting information on the web about how to get it from Canonical. Which delayed me from simply getting it from Oracle which I was reluctant to do because my linux/ubuntu skills are still fuzzy, at best. So, I really appreciate a nice script based install which puts things in all the right directories, makes all needed symbolic links and handles shell environment variables etc. I finally stumbled on a credible  looking software repository which hosts the Oracle JDK for easy install. But first, I needed to add the repository to my Ubuntu configuration. Fortunately, I found instructions for that too. Thanks Web Upd8 for the JDK and Instructions.


sudo add-apt-repository ppa:webupd8team/java
sudo apt-get update
sudo apt-get install oracle-java7-installer


Just a little bit more tinkering and I was ble to get the plug-in installed in my browser(s)....phew. Now, I could use the in-browser SSH client from Amazon Admin console to log into my brand new Amazon (Free Usage Tier) Micro Instance. I did all this, so that I would not have to figure out how to set-up SSH using the native command line application on my system. It turns out that this other approach with native SSH command line was not so hard but also much better experience. Anyway, with the plug-in Installed, everything worked like a charm, following the Amazon documentation. But it did not take long before I figured out how to use direct command line SSH. One more think I had to learn was how to transfer files from my local machine using SCP command and from this point on, accessing my Amazon VM was almost exactly same as accessing my local Ubuntu VM via command line....pretty darn cool.

Getting started with Amazon Cloud Infrastructure



Though slightly intimidated by all the (impressive) infrastructure and software-as-a-service (SAAS) offerings available from Amazon and other IT suppliers hosted on Amazon, I found the intros and documentation quite accessible. I was especially thrilled to discover Amazon's Free Usage Tier.


AWS Free Usage Tier (Per Month):
Elastic Compute Cloud (EC2)
750 hours of Amazon EC2 Linux† Micro Instance usage (613 MB of memory and 32-bit and 64-bit platform support) – enough hours to run continuously each month*
750 hours of Amazon EC2 Microsoft Windows Server‡ Micro Instance usage (613 MB of memory and 32-bit and 64-bit platform support) – enough hours to run continuously each month*
750 hours of an Elastic Load Balancer plus 15 GB data processing*
30 GB of Amazon Elastic Block Storage, plus 2 million I/Os and 1 GB of snapshot storage*
Simple Storage Service (S3)
5 GB of Amazon S3 standard storage, 20,000 Get Requests, and 2,000 Put Requests*
DynamoDB
100 MB of storage, 5 units of write capacity, and 10 units of read capacity for Amazon DynamoDB.**
Relational Database Service (RDS)
750 hours of Amazon RDS Single-AZ Micro DB Instances, for running MySQL, Oracle BYOL or SQL Server (running SQL Server Express Edition)‡‡ – enough hours to run a DB Instance continuously each month*
20 GB of database storage
10 million I/Os
20 GB of backup storage for your automated database backups and any user-initiated DB Snapshots
SimpleDB
25 Amazon SimpleDB Machine Hours and 1 GB of Storage**
Simple Workflow (SWF)
1,000 Amazon SWF workflow executions can be initiated for free. A total of 10,000 activity tasks, signals, timers and markers, and 30,000 workflow-days can also be used for free**
Simple Queue Service (SQS) and Simple Notification Service (SNS)

100,000 Requests of Amazon Simple Queue Service**
100,000 Requests, 100,000 HTTP notifications and 1,000 email notifications for Amazon Simple Notification Service**
more...

The Free Usage Tier was especially welcome after I tried the Simply Monthly Calculator with the reference web application topology selected. With the default load/configurations, the estimated monthly cost came up to the stunningly-out-of-my-budget amount of: $1,660 per month.

Even though this 3-tier web application is the topology I'm going for, I should be able to fit my web app (Weather Scout) into the Free Usage Tier offering (based on expected utillization being close to zero, no load loadbalancing, scaling group, or high availablity clusters).


Sunday, November 11, 2012

Finally...a full Web Application Stack!



Yes. Its rudimentary but...boy, did it take a while!

I have been working at this for about 10 hrs per week since my last blog post 9 weeks ago.

APPLICATION DESCRIPTION
The application use case scenario is pretty basic. An administrator uses the "Admin Console" screen on the left to select cities to make available to users. On the right, users select cities to view weather status. As the user types a city that they would like to add, the app helpfully provides suggestions. The suggestions are limited to just the cities permitted by the administrator in the Admin Console.

WHY DID IT TAKE SO LONG
Its hard to remember all the challenges but I'll try to list some. I'll probably add more to this list and get into more details on these in future posts.

Java/POJO (Plain Old Java)
Applied new (to me) concepts to handle Exceptions, Collections, XML parsing, and even variable declarations and scope (a missing use of "final" declaration was the source of 10hrs - 20hrs of tedious debugging)
Java/EJB (Enterprise Java Beans)
Challenges with consuming SOAP Web Service from J2EE/EJB which I was able to do just fine using regular Java
Java/JPA (Java Persistence API)
Challenges with Java Persistence API syntax and usage
Google GWT
Spent many hours learning the idioms of GWT framework particularly around user interactions and Client/Server Remote Procedure calls.
Apache Derby
Challenges with starting, configuring Apache Derby database as standalone server outside of Eclipse
IDE.

NEXT STEP...
Heavy sigh and deep breadth...deploy servers and services to the cloud!

Tuesday, September 4, 2012

It's kinda like baking a cake...




For this post, I put together a diagram of all the components (aka blood, sweat and tears) that went into the very humble Temperature converter web app in preceding posts. Ok,"blood, sweat and tears" may be a tad bit dramatic but not by much. Certainly, long long long hours went into first learning what constitues an E2E web application stack, then of the many, many, many options out there, selecting a suitable stack. Theeeeen, I had to get them, install them, learn them and use them. An experience which, so far, feels like learning to bake a cake, while learning how to make everything that goes into cake baking. And I mean "everything". The cake and all it's ingredients can be compared to the program itself. The java language abstractions and logical constructs that go into making the program are the ingredients. These are the typical, perhaps obvious, things you think of when approaching the task of cake baking or application development. However, for a complete web application (or almost any non-trivial useful application), you also need tools, appliances, and infrastructure. Even for the "simple" task of cake baking these tools, appliances and infrastructure are quite extensive when you think about it. There are uncountable variations of hand tools, electro-mechanical appliances and fairly expensive infrastructure like furniture, cool/hot storage and of course....an oven!  In cake baking, you also need foundation skills that are easy to take for granted. Skills like reading, writing, vocabulary, math, measuring). Then their are craft skills like kneading, decorating, ingredient sourcing & preparation and others. Sourcing & prep, are not as trivial as one might think. For example, where do you get creme fraiche from and how is it best to stored & prepped for different uses? Finally, and just as importantly, in addition to all these these pre-requisites, you need to have some (good) ideas of satisfactory end results. That is, what does a cake look like, taste like, smell like, how is it served, who uses it, for what (if anything else besides eating), when, how often, what should it cost etc. It begins to be clear that baking the most simple of cakes is far from trivial. 

Ok, so maybe I've succeeded in reminding you about the hidden complexities of cake-baking. Big deal, You are probably thinking "Well, cake baking is one thing. Yes, maybe it is surprisingly more complex than anyone would initially think but software development is totally something else. Of course, that's a complicated thing!." No big surprise there, genius. People, and not just "people", the biggest brained of our kind, spend their lives studying software development aka computer science aka information technology. Clearly, if this is surprising to me, I'm on the other end of the spectrum from exactly those big brained ilk. However, hear me out for a few more seconds. Yes, the best and the brighest spend lifetimes studying software development. But so do the best and the brightest cake makers. Yet, just because the highest forms of software development, like cake baking, takes lifelong dedication and training, this does not mean that regular, modern, affluent, intelligent, capable people should not be able to make delicious cakes or software programs!

Hopefully, prior chronicles provide enough context for the components, tools, appliances and infrastructure outlined in the diagram above. I'll be diving into these more in future adventures which, most immediately, will include adding database/persistence to the humble app. This will also include beefing up the functionality to include features affectly known as user CRUD or record Creation, Reading, Updating, Deletion through the user interface. Also, I'll need to actually deploy the application in to the wild world web...yes, I said "wild" world web...and I meant it.

Monday, August 27, 2012

First E2E Web App Stack (Almost)

Finally E2E Web Application using Google GWT, Apache Tomcat, Glassfish, J2EE and Web services!



In my last attempt, I tried rejiggering the GWT Designer Log-in Manager tutorial to implement my own functionality. Specifically, I planned to keep the UI elements (panels, textboxes, buttons etc) but change the labels and functions to implement a Temperature Converter web application which accepted temperature values and made calls to converter service which actually resided in the server back-end. My desire was for the service to be SOAP/HTTP service which was called by GWT server which in turned serviced the GWT client. My implementation approach was to just deal with GWT client/server aspect first before introducing the SOAP service. This is the Log-in Manager tutorial, I started with:


And this was the GWT Remote Procedure Call tutorial which I was leveraging in order to rejigger above tutorial to add RPC functionality:


I had written about completing the RPC tutorial in earlier post (Begining Web/SOA/J2EE Dev). However, this was were I as getting stuck. This RPC tutorial has a rather confusing/clumsy syntax for linnking the web service interface, its implementation, the client proxy and the async callback function. It was not helping that I was trying to learn how to apply the RPC at the same time as I was rejiggering UI tutorial which was also my first exposure to the GWT Designer (Window Builder project). So, I took different approact of first completing start-to-finnish GWT Desinger project and then returing to the RPC aspects. For a fresh start I turned to a different GWT Designer project from the Log-in Manager application. It's another StockWatcher app similar to the one I did in Begining Web/SOA/J2EE Dev but this one is done using GWT Designer/Window Builder:


I completed this tutorial painlessly and it gave me even more appreciation for GWT for web application UI over straight-up HTML/Javascript which, again, is what GWT ultimately generates/deploys. It just makes the coding/development seemingly easier/better because it allows you to develop in good old Java and uses familiar UI development constructs. So, I'm now a GWT client app developer Wizard (not exactly) but the problem still was that I had no server side implementation or link from client to server. Fortunately, I found a different tutorial which had much more straight forward approach to dealing with this GWT RPC:


First, I used the GWT RemoteService Wizard to redo the StockWatcher GWT Designer web application to remotely call the stock watcher service (rather than use client side implementation). Worked like a charm. Then I proceeded to create my very own GWT Designer web application from scratch to implement a temperature conversion application. First, I created the client side using same steps as Stock Watcher tutorial with the temperature conversion logic located in the client, then I followed the GWT Remote Service Wizard steps to transfer the conversion logic to the GWT service, finally I used eclipse webservice client generator to create client class from my web service which was a J2EE application (EAR) I had previous created deployed on Glassfish server. that experience will be covered in future blog entry. The GWT pieces are covered in the Google tutorials but the Eclipse web service client generator is not. From the GWT Window Project in Eclipse, navigate to the following:

File -> New -> Other -> Web Services - Web Service Client

Then enter the WSDL location for you web-service. Turn the dial on the client-o-creator to "Develop Client"...you can turn it all the way up to assemble, deploy, or test but then you'd need to add/configure a suitable Web Application Server to your workspace (which can be a very useful thing to test or get a feel for the Web Service operations but not something needed right this second...especially since I develeloped/deployed this particular service).


Hit Finnish...and presto !

Now, you'll see a new package with a bunch Plain Old Java Objects (pojos) in your project explorer new. Below, this new package is appopriately named com.ola.pojo (named by me when I originally created the webservice). The package contains an Interface class called TempConverter.java which shows the methods that the class provides aka as the operations provided by the service. Additionally, the package includes a bunch of supporting classes TempConverterProxy.java, TempConverterPrixy,TempConverterServiceLocator.java,TempConverterSoapBindingStub.java, all created by the Eclipse tooling from the WSDL which I had specified. All you now need to do use this service is to instantiate an obect of TempConverterProxy and you can call any of its methods/properties just like its a pojo object...pretty neat, I think.




And after all that - creating web service using J2EE, deploying that services as a EAR package into Glassfish J2EE container, Creating GWT RPC server to call/consume that web service, and then finally creating GWT client to provide UI and use the web service methods via RPC calls to GWT server - what you have is...

So, at the top of the post, I declared success of full E2E implentation of a web application stack...well,  almost the full stack. This humble app is still missing the database/persistence functionality. Next, I'll try to get a diagram together illustrating the full stack. And I'll continue work on another app to also implement persistence.




Sunday, August 19, 2012

Google Web Toolkit Expedition (Cntd.)













TRYING TO USE GWT CLIENT TO CALL SOAP SERVICE (CONTINUED)

The unfortunate thing for me about the process of trying to get GWT client to call SOAP service was that as I tried to execute my "brilliant" idea, neither Eclipse or GWT, where giving me any warning/error signs as I blissfully created/compiled/tested/deployed my modules. It also did not help that I spied a Google article which seemed to indicate that this was possible.

https://developers.google.com/appengine/articles/soap

I was not the only one drawn into this tempting (but fruitless) prospect. Excitingly, there was even a lenghty/current bug thread in which the Google developer who authored the GWT-RPC/SOAP article was actively defending his article and why it should be possible for GWT client to call SOAP service.

https://groups.google.com/forum/?fromgroups#!topic/google-web-toolkit/6AI19vFN6go%5B1-25%5D

After hours of research/trial&error, I've concluded that it's not possible.  My reasoning (which I only vaguely understood and I only half heartedly put it forward here) is that the web service client proxy generated by eclipse, and all its related Java plumbing, can not be run by the browser which has only limited Java Runtime Environment (JRE). And, for the browser to make a call to a Web Service that is not provided by the GWT Service (servicing the GWT client), there is some kind of violation of the  browser's Single Origin Policy (SOP) which I only vagurely read about. Anyway, all this was more than enough to get me back to more standard approach to use Client GWT to call Server GWT (which in turns call SOAP service)....

USING SERVER-SIDE GWT TO CALL SOAP

I was hoping to avoid this so that I did not have to create new/additional GWT client and GWT server components in order consume SOAP Web Service (which I'm also largely planning/expecting to author for my applications). It's probably a fair time to ask/answer the question: Why not create all server side components in GWT (and avoid SOAP/HTTP service altogether)? This is just a pedagogical decision to allow me to get broad perspective of Web/SOA/J2EE architerctures. For now, I'm committed to implementing generic/universal SOAP/HTTP web service using J2EE components deployed in J2EE Application Containers like Websphere, Glassfish, JBOSS, Weblogic (actual implementation is Glassfish) which could be consumed by any SOAP/HTTP client (anywhere on the internet...or connected network). 

Back to trialing GWT Client/Server to consume SOAP/HTTP. The GWT Stock Watcher tutorial, uses %100 code to generate its UI elements. Panels, buttons, labels were all added/formatted using Java code (onjects were instantiated from classes that represented UI elements, then the objects' methods where called and attributes set). Also, formatting was done using CSS which was described in XML docs that where referenced by the UI Java code. This seemed a whole heck of a lot better than the JSP/Servlet syntax but still this all-code approach is tedious. I knew there had to be a better way.This GWT business was supposed to be EASY after all. So, I dug into "GWT Designer" but Guess what, that's another toolkit with its own plug-in module and its own project type called "Window Builder" project (as opposed to standard GWT which is "Google Web Application" project)...sigh. Somehting else to download/learn. 

GWT DESIGNER CHALLENGES OR "OPPORTUNITIES"
The Google developer site seems to have conflicting information as to whether GWT designer is loaded in the GPE "GWT Plugin for Eclipse" which I already had. Furthermore, The Ecliplise "installed software" screen shows "GWT Editor/Designer" installed. However, I did not seem to have the option to create "Window Builder" project which was called for in one of the tutorials. Google showed that others seemed to have this frustration too. I tried installing the GWT Designer plug-in separately anyway however the kicker was that it was not available for the latest Eclipse release Juno. Which made me believe (or "want to believe") that is must already be included in the GPE which I had installed. But after much fretting and hours of frustration, I concluded that the full GWT Designer (with Window Builder and other neccessary dependencies) where not available for Juno. So, I had to download Eclipse yet again. This time I had to back-rev to release Eclipse Helios reliease 3.7....and get all my Glassfish, GWT plug-ins all over again.



FINALLY RUNNING WITH GWT DESIGNER 

True to the promise, it seems the UI development is much "easier" with this tool. So, I bravely started yet another march up yet another learning curve starting with the Login Manager Tutorial.

https://developers.google.com/web-toolkit/tools/gwtdesigner/tutorials/loginmanager

However, instead of doing a clean word-for-word sweep of the tutorial, I opted to directly replace the tutorial functionality with mine. The Login manager took user data 'Name' and 'Password', and did some rudimentary client-side validation once a submit button was clicked. It did not actually communicate with any backend service. My version was going to accept user entered numeric value 'Temperature in Celsius'. Then on button click, it was going to update a label on the screen to show Temperature converted to Fahrenheit which was to be calculated by calling SOA/HTTP web service which I had already implemented and deployed to my local Glassfish J2EE application server. I'm getting stuck at the syntax/implementation/integration of GWT's asynchrounous client RPC call, the GWT's RPC service wrapper and the SOAP/HTTP service itself....

Stumbling with (JSP/Servlet/GWT/SOAP)


Finally, I felt like I had all the components (Tomcat, GWT, J2EE Classfish, Eclipse) installed with a modicum level of understanding gleaned from creating/deploying working code from tutorials to piece together E2E web app. So, I boldly proceeded. However, I was met with new series of challenges or should I say, "learning opportunities"...

FIRST STUMBLING BLOCK
Figuring out how to import Web Service WSDLs for use by View or Controller (JSP/Servlet or GWT framework overaly). After much time, I pieced together that I need to create, in my project, a "web service client proxy" using the WSDL (Eclipse ->Dynamic Web Project -> New -> Web Services -> Web Service Client -> Pop-up Wizard to specify/import WSDL). This creates the plumbing including a class called MyxxxServiceProxy.Java. This class then needs to be instantiated, and its methods called, in my View or Controller…at least this is my working theory 

SECOND STUMBLING BLOCK
My Eclipse IDE would not let me import the WSDL using aforementioned wizard. I tried external internet published web services (thinking something may be wrong with my locally authored services). I tried my services running locally on both Glassfish and Tomcat. I tried pasting the WSDL file as resource direct into my Eclipse project…nothing. Google search on error - "IWAB0014E Unexpected exception occurred." - showed this was a known bug that was addressed in previous versions of Eclipse, so should be fixed in my current version (Juno 4.2) but no dice. Suggested workarounds included - restarting/changing workspaces and starting/restarting development mode web server - but none worked. Finally, I tried importing WSDL from my eclipse IDE on my Mac (as opposed to my Ubuntu VM)…success…but now I had to shift development to my Mac but I accepted this for now.

THIRD STUMBLING BLOCK

Now I could, in theory, create views and controllers to consume my web service resource. In practice, I had never actually done this step. In all my disparate tutorials, none had made this crucial connection between either JSP/Servlet or GWT(Client/Server) and Soap/HTML service. So, making this step work, demanded more stumbling, but that itself was not the actual third stumbling block. That, came with my Apple Eclipse IDE being unable to load my local Tomcat Server in it's dev mode. 

"Could not load the Tomcat server configuration at /usr/local/apache-tomcat-7.0.29/conf. The configuration may be corrupt or incomplete.

Reason:
Could not load the Tomcat server configuration at /usr/local/apache-tomcat-7.0.29/conf. The configuration may be corrupt or incomplete."

Clearly, the "Reason", which was just a repeat of the error, was very helpful…not. I tried changing, in config/server.xml, apache tomcat port#s from 8080 currently used by my Glassfish server running in my Ubuntu vm which is networked with Mac via Virtualbox (though did not think that was source of error as previous port conflict errors in Eclipse have been more explicit). I also tried tomcat-users.xml configuration. Thinking that the users/roles that I added to manage tomcat from browser, where causing problems for IDE…nothing. Then, as I was typing this journal entry it just hit me "try google !" (dooooh)and I did. This time, unlike with STUMBLE#2, I met with success. Results indicated that there was an OS (not Tomcat) permissions issue with Eclipse being able to read/write configuration files in tomcat config directory. So, taking the blunt mallet solution approach, I promptly chmod rwx * in /config…even though, something (i.e., common sense) tells me that universal rwx on any folder…especially your web server folder…is generally not a good thing. But I'll come back to it later. For now, glad to be back in business…sorta. 

RESOLUTION TO STUMBLE#2 
Downloaded/installed new instance of eclipse. That means, also had to reinstall Glassfish plugins and GWT plugins. But tests show WSDL import/client proxy generation is working. Notably, there's no diffence in "Build" version between new/old eclipse versions. One just works. The other doesn't…..aaargh!

Version: Juno Release
Build id: 20120614-1722

TRYING TO CREATE JSP/SERVLET THAT CONSUME WEB SERVICES

After, getting new Eclipse JUNO installed and web service client proxy generation working, I fooled around trying to figure out if/how standard JSP/Servlet framework and Eclipse JSP editor could be used to provide basic/rudimentary web app UI used to call SOAP/HTTP web service. Meeehhn, I know that somehow this "should be possible" but JSP as an "easier" method to deliver client side UI from servlet (as opposed to using servlet to create/format HTML using standard printout) is whack. Maybe there are neat tools out there, besides Eclipse, to do this kind of direct Servlet/JSP formating or maybe I just have not properly wrapped my head arond JSP/Servlets. Eitherway, I was convinced direct coding of Servlet/JSP is not the answer...so, back to Google GWT. 

BACK TO GOOGLE GWT
As I journaled on 8/16, I had successfully completed the GWT Stock Watcher sample tutorial which included creating GWT Service and calling from GWT client via GWT RPC. However, available documentation stated that GWT RPC was not same as SOAP/HTTP and that SOAP/HTTP was not directly supported, instead generic HTTP calls could be used. However, since "Eclipse" and its Axis/WebToolkit modules where doing the actual generation of client proxy from WSDL which were then exposed as regular Java classes to components within project, I figured.....eeeah, why not give it a try...

Begining Web/SOA/J2EE Dev


8/16/2012 - Thursday

     

By now, its been 3 weeks ~ maybe 100 hours ~ of dog headed attempt to get broad hand's-on perspective of Web/SOA/J2EE development. So far, I've tackled:












Apache Tomcat - for Front-end/View (HTML/JSP) and Controller (Servlets) web framework













J2EE Glassfish - for "Model" or business logic served up via Soap/HTML


Eclipse IDE - with all the plugins to make "stuff" for all of the above
Plus all the Operating System and Browser specific quirks of developing with each of above platforms

Now I was attacking Google Web Toolkit (as an alternate Front-end and Controller web-framework)


I actually started with GWT few days back on Sunday (8/12/2012). And  I had triumphantly completed the first section of Google Web Toolkit Tutorial:

BUILDING A SAMPLE GWT APPLICATION


And I had moved on to the next section

COMMUNICATING WITH SERVER


And that's were I got stuck (again) .

I had completed the server side implementation and the client side updates to call the server method (using GWT RPC) to get the (fake) stock quotes being used to populate the browser view.

Everything worked EXCEPT for a bit of code functionality designed to mimic catching and reacting to a GWT RPC exception. Code was functional but the simulated exception throwing/catching was not happening. That Sunday, after working through the tutorials ALL WEEKEND, all I could manage was to review my code, staring and comparing with tutorial for easy mistakes...Nothing. At this point, I was too brain-dead to go into discipliened/debug mode. 

Today, I finally picked it back up and I started setting breaking points to step through the code but bewilderingly, breakpoints where not working. The Eclipse IDE was just not doing anything with them. Google search on "eclipse breakpoints not working gwt" showed me that others had the problem but there was no clear RCA. I tried restarting browser, IDE, VM, server, application, and changed my eclipse Properties -> Java Build Path -> library -> JRE System Library from "java-6-openjdk-i386" (base Ubuntu JRE install) to "jdk1.6.0_33" (which I had recently downloaded from Sun to try to solve some other issue on some other project at some other point), also fixed my $JAVA_HOME environement variable to point to the "jdk1.6.0_33" folder (export JAVA_HOME = usr/lib/jdk1.6.0_33)....I'm not sure exactly which combination of advice/actions cured the problem but something worked. Actually it worked two fold...the breakpoint debugging functionality worked and so did the apparent bug with the non-functioning exception trying/catching....phew