I’ve been using JavaScript for years in various varieties. Every time, I end up having too many issues or end up in complexity to believe JavaScript is the answer. In contrast to many JavaScript advocates, I’m primarily a JVM-based developer and have seen the power of modern day languages on the JVM, notably Groovy. People often blame my JavaScript ignorance on lack of knowledge and understanding. There may be some truth there (I’m a backend engineer on the JVM, so JavaScript is not my day job), but it’s not the entire truth. JavaScript has pitfalls regardless if people want to admit it or not. Personally I think that die hard JavaScript developers just “deal” with it, ignore it, or have not seen the advancements of other modern day languages to realize the pitfalls.

My biggest issue with JavaScript as of late is the lack of threading. Many developers, including myself, develop libraries on both Node.js for the server and the browser as the client. This means you develop for the lesser of the two: browsers. This means you are bound by a single thread in the browser. Why is that an issue you say? Isn’t event driven programming far superior? Aren’t threading and multi-threading concurrent applications problematic and complex? The answer to all those questions is yes, as a developer (key part is “as a developer”). The browser and Node.js are not developers; they are libraries and systems that abstract away the complexity of development from the developer. This is especially true in request/response systems such as the web. Think about Java servlets or Apache’s http server or even Node.js/Vert.x clustering. As a developer you design code in a single thread of work, but the underlying system uses multiple threads (or processes in the case of Node.js). The system enforces, rightfully so, that single thread of work. Behind the scenes they concurrently process hundreds of requests. That means, as a developer, you have simplicity in your code and any pauses (ie: remote calls, database invocations, etc) do not block the world. In JavaScript, this is very much not true. If you block anything, you block everything, including the browser application, leading to poor application performance. The answer in JavaScript is event driven programming or callbacks. Fundamentally, there is nothing wrong with that. They are often times very strong design patterns for performance and simplicity in design. In fact, almost every modern day language (even Java), use them where they make sense. For example, many of the utility classes in Groovy heavily use the concept of closures or listeners. The problem is that JavaScript enforces it so heavily (because any minor pause is a stop the world pause), that you quickly end up in callback hell. I realize that there are improved ways of dealing with that such as deferrals and promises. Realistically, though, those are not solutions. Instead, they are bandaids to a broken problem in the first place: lack of threading. Callback hell in JavaScript only exists because every pause blocks everything. If that were not true and the browser still processed while the JavaScript application thread was paused, you would make far less callbacks. The truth is that whether you end up in callback hell or utilize some library such as promises, the result is always the same: far more complexity than is needed. Remember the notion of KISS? Any real world JavaScript application on the browser fails to meet that criteria due to having to ensure every operation is non-blocking.

I heavily realized this recently. I needed to write a generic iteration method that could accept a callback for writing data:

Utils.forEach(array, function(item, writer) { /* write stuff */ });

If you think about this, the solution is fairly straightforward:

Utils.forEach = function(array, callback) {
    var i;
    for (i = 0; i < array.length; i++) {
        callback(array[i], Context.writer);
    }
};

What’s the problem, you ask? Well, what if I told you that the callback was allowed to do anything, including make remote invocations:

var callback = function(item, writer) {
    $.get('/api/' + item.id, function(json) {
        writer.write(json.result);
    });
};

If you use this callback to the Utils.forEach method, it will fail to work as expected because the AJAX invocations will happen at some point in the future. The solution to this and keeping to simplicity, is to use a synchronous AJAX request. However, that means blocking everything, which is obviously not an option. That is where JavaScript fails. It requires you to take simplicity and over-complicate it. This is not just for AJAX, it goes for anything that could block, including I/O. For example, to fix our 6-line Utils.forEach implementation to support asynchronous callbacks leads to the following hard to read code:

Utils.forEach = function(array, callback) {
    var i, iterator;
    i = 0;
    iterator = function() {
        if (i < array.length) {
            i++;
            callback(array[i], Context.writer, iterator);
        }
    };
    iterator();
};

That’s now an 11-line hard to follow function doing weird workarounds like creating a temporary callback iterator and recursively invoking itself. If you did not catch it yet, this is not complete. We have to then modify our user callback to accept that third callback parameter and make sure it invokes the iterator callback. This requires a dependence on both sides, which is another no-no in computer science (loose coupling anyone?)

var callback = function(item, writer, iterator) {
    $.get('/api/' + item.id, function(json) {
        writer.write(json.result);
        iterator();
    });
};

In any other language that has multi-threads and application pauses do not block everything, the original method works just fine. This is very unfortunate in JavaScript. Although, I have plenty of other issues for the language, but that’s for another time and many of those are being solved by languages such as CoffeeScript, Dart and TypeScript or even by the upcoming EcmaScript 6 standard. Unfortunately, the latter won’t happen in browsers for a few years out. The threading issue will continue to be a hinderance for application simplicity and scalability (development-wise).

Will JavaScript be the next VM or the future of development? Time will certainly tell. Until JavaScript allows some form of true behind the scenes threading where the application does not entirely block, I do not buy into it even though I’m sure I’ll continue working in it. By the way, yes I know web workers exist, but again that’s another bandaid to the original problem and web workers have too many other issues and inherent complexity. Personally, I know other systems such as Groovy and Grails offer so many more advantages and I choose the language that offers the best advantages for a given use case.

As a last aside, one of the things I love about Grails (or Spring on Java) is AOP (aspect oriented programming). AOP allows loose coupling in a high degree by moving cross cutting concerns (logging, debugging, performance metrics, etc) away from the application. This is easy in Grails because you wrap the method in a proxy and detect the start and end of the function. With JavaScript, the end of the function is often times not the end of the function, because it has to invoke a callback. Take the AJAX example callback above. If I wanted to inject timing statements around that, it would be very fast because the AJAX call happens in the background. It would have to magically know that a callback was invoked and wrap that as well. That is near impossible which is why AOP libraries do not effectively work in JavaScript. This is yet another reason why I choose Grails over JavaScript. As applications become more complex, these options do not exist in JavaScript, because of the nature of the language. Hopefully this changes over time so JavaScript can become a better framework for real world applications while still maintaining their simplicity.

This particular post will focus on the client side rendering via jQuery Mobile. jQuery Mobile is a great framework that allows the application to focus on semantics and clean HTML design while the actual rendering is performed client side via CSS and JS. Further, the framework supports responsive design that automatically scales to the desired form factor including phones, tablets, and desktops. All this combined allows the application developer to define the semantic HTML that scales to all platforms rather than having to create separate interfaces and designs for each form factor.

To utilize jQuery Mobile you need to include the relevant CSS and JS files which also includes the jQuery core library. The simplest way is using the jQuery CDN via:

<link rel="stylesheet" href="http://code.jquery.com/mobile/1.3.0-beta.1/jquery.mobile-1.3.0-beta.1.min.css" />
<script src="http://code.jquery.com/jquery-1.8.3.min.js"></script>
<script src="http://code.jquery.com/mobile/1.3.0-beta.1/jquery.mobile-1.3.0-beta.1.min.js"></script>

jQuery Mobile uses the HTML5 data attributes to identify the options for various components. The main component in jQuery Mobile is the page. A page identifies a particular unique page or screen in the application. A single HTML page may include multiple pages for optimizations, but jQuery Mobile will only show a single page at a time. Per my main layout, an examlpe page layout is (notice the data attributes):

<div id="page" data-role="page">
    <div data-role="header" data-id="header" data-position="fixed">
        <h1>Title</h1>
    </div>
    <div data-role="content">
        page content goes here
    </div>
    <div data-role="footer" data-id="nav" data-position="fixed">
        <div data-role="navbar">
            <ul>
                <li><a href="#">Overview</a></li>
                <li><a href="#">Navigation</a></li>
            </ul>
        </div>
    </div>
</div>

The page section contains three main div sections: the header, the content, and the footer. jQuery Mobile supports fixed positioning across form factors for headers and footers. The fixed positioning allows the elements to remain in their respective locations regardless of user scrolling or page transitions. This symbolizes a typical native mobile application (ie: iOS). The footer may also include a navigation bar that also resembles a navigation bar in a native iOS application, especially if icons are included (they are not in my case). The biggest takeaway from this simple example is that the HTML is simple and straightforward, yet it works in almost every form factor imaginable.

The next great part about jQuery Mobile is its automatic navigation and linking support. By default, all links in your application are standard links that would work regardless of JavaScript being enabled. This also means they are easily traversal by search engines for SEO purposes. jQuery Mobile automatically translates links into AJAX links and does automatic page transitions. It also manages the history through HTML5 history linking as well as through old school methods such as hashtag references. The server-side developer purely defines standard HTTP request modeling of pages while jQuery Mobile automatically downloads content through AJAX behind the scenes. The best part of the navigation is the automatic transitions. Using data attributes within links, you can customize the transition without any JavaScript code such as slideup, slidedown, flip, etc. For example, the transaction page in my application defines a button that loads the create transaction view through a slideup transition via data-transition="slideup". This makes the form look like it comes from the bottom. Transitions, especially in client-side applications, are great at informing the user an action is taking place and a new view is being displayed.

Next up is button support. jQuery Mobile supports automatic button styling for standard links as well as custom form inputs and buttons. An application selects the proper semantics (links for traversing, buttons for form handling, etc), but they all appear the same. Buttons may also include icons in addition to text. For example, within Grails I define a custom link using Grails linking support.

The first example right aligns a button in a header section. Note that the data role is not required in headers, but the CSS class is needed to properly align the button on the right or left.

<g:link action="create" params="[type:type]" class="ui-btn-right"
        data-icon="plus" data-transition="slideup">
    Add
</g:link>

The second example is used within a form. One button is a standard link while the other is a form submit button. jQuery Mobile properly handles both links and frames through AJAX navigation.

Note that the data-role="button" causes the to display as an actual button. Also, the data-theme may be used to customize the styling of the button. Finally, when using transitions, you can reverse the animation with the data-direction="reverse" attribute. In this application, the create form slides up to display. Upon submission or cancel, the form should slide back down in reverse.

<g:link action="list" params="[type:type]" 
           data-role="button" data-icon="delete" data-theme="a"
           data-transition="slideup" data-direction="reverse">
    Cancel
</g:link>
<button type="submit" data-theme="b" data-icon="check"
           data-transition="slideup" data-direction="reverse">
    Submit
</button>

The whole form aspect is also fully supported by jQuery Mobile. Certain form elements are custom styled and laid out to support various form factors. The basic form element is defined as the following. The key is using the fieldcontain role along with a label and associated input field.

<div id="name-container" data-role="fieldcontain">
    <label for="name">Name:</label>
    <g:textField name="name" value="${fieldValue(bean: transaction, field: 'name')}" />
</div>

The final thing to note in the application is the custom listview support. jQuery Mobile, inline with native client applications, supports a variety of listviews to show lists and tables of data. The listview support is amazing and provides all sorts of options through data attributes. It also allows customization which is what I used to gain the proper look and feel. The end result is a great looking interface without having to design or create crazy CSS rules. The HTML is purely semantic as list items.

<ul id="overview-list" data-role="listview" data-dividertheme="b">
    <li data-theme="e">
        <h4 class="listview-content">Today's Balance</h4>
        <h4 class="listview-note ui-li-aside">
	       $100.00
	</h4>
    </li>
    <li data-role="list-divider">January 2013</li>
    <li>
        <a href="#" class="ui-btn-right" data-transition="slide">
            <h4 class="listview-info bill">25</h4>
		  <h4 class="listview-content">My Bill</h4>
		  <h4 class="listview-note ui-li-aside amount">$23.00</h4>
	   </a>
    </li>
</ul>

The interesting portions are the dividerthemes that provide different styling for the dividing sections. I use one style for the main divider at the top for the overview balance and then a different style for each month dividing the items. The actual content is controlled by the h4 references and associated style classes that align the content to the left, right, or as general textual content. Finally, I use a custom class (ie: bill, budget, etc) to customize the left-aligned date to a particular color to identify each transaction type.

There is so much more to jQuery Mobile and the documentation is pretty good. For example, you can use jQuery syntax to add further hooks into the framework such as handling a long tap on a given list view item:

// process once the page has actually been initialized
$('#page').live('pageinit', function(event) {
    // process long holds
    $('#overview-list li').bind('taphold', function() { /* do something */ }
});

If you have yet to try jQuery Mobile I strongly encourage it. It fits perfectly with Grails as well. If you use Grails, you may also want to consider using the Grails resource plugin with the Grails jQuery Mobile plugin. The two automate the inclusion of the necessary dependencies and libraries. However, the jQuery Mobile plugin in Grails tends to be behind a few releases in the fast evolving framework, which is why I opted to just use the CDN directly.

Read the previous article on Server Side via Grails.

The application I am presenting here is a Budget Analyzer application. The problem with most of the financial applications and budget aware applications such as Mint.com is that they do not provide a forward looking statement. One of the things I like to know when dealing with accounts is how much money would be in my account in two weeks based on upcoming bills and budgets. This is very handy when making a payment and knowing whether you have a certain amount in your account so you do not hit any thresholds. Although forward looking balances are mere estimates, it gives you an easy way to see what bills are approaching and their approximate impact to the bottom line.

The first part of this application is the server-side stack composing of Grails. I used the latest Grails 2.2 build for this application. If you do not have Grails installed, the easiest way to install and manage the various instances of Grails on your system is the excellent GVM (Groovy enVironment Manager) Tool. I would show how to install it, but it is so simple that just visiting the site and following the couple steps is all you need.

The backend of the application is built using standard Domain objects in Grails. Domain objects in Grails are so simple its ridiculous. If you have ever built a persistence layer in Java using something like JPA or Hibernate, you know how much crud there is in defining properties, annotations (or XML files), getters/setters, proper equals/hashCode implementations, etc, not to mention trying to recall the countless annotations you need for mapping the tables, columns, joins, cascading, caching, etc. Grails provides suitable defaults in most cases following its convention over configuration principle. Combined with Groovy’s automatic getter/setter provisioning, you can create a simple Transaction class in a few lines.

class Transaction {
    String name
    int recurrence
    double amount
    Date startDate
}

That class is a valid Grails domain object that you could easily invoke Transaction.list() to fetch all saved transactions. As I said, ridiculously easy.

Domain objects may also contain helper methods to add domain-specific business logic. Note that the business logic should be independent of any other beans or objects and should be self contained of any dependencies. One thing to keep in mind is that Grails may confuse helper methods as domain properties so you may have to add the fields to the transient declarations (ie: static transients = ['expired']. See my domain classes for an example of how I use domain objects.

Since I was using domain objects, I needed a place to persist them. Grails provides various persistence capabilities on its GORM platform including Hibernate and NoSQL approaches. My domain model is very simple, so a traditional Hibernate SQL database worked fine. For development I used the in-memory H2 database. This works great especially when domain models are iterated upon so you don’t have to worry about merge conflicts, database destruction, etc. I used the BootStrap.groovy startup file in Grails to initialize the database with a set of transactions. For production, I used a standard MySQL installation. See DataSource.groovy for more information.

The next layer of the server-side architecture is the Grails service layer. Grails services are simplified Spring managed bean built on autowiring. They provide the business logic of the platform above the UI layer and controllers as well as shared code between controllers. Services may exist per domain class to provide functions to query the domain class or they may contain more generalized business logic that utilizes several domain classes. The organization of the services depends on your particular use cases. I prefer services to contain the queries and persists rather than within controllers so that the services act as the in-between layer. Further, services may be easily injected into any bean (controllers, other services, jobs, etc). As such, they are great at abstracting the queries from each of those components. The TransactionService.groovy is an excellent example of this. It provides business logic to rollup transactions into specific transaction items. It also provides a few different queries. However, in order to simplify the query cache and persistence, I use Transaction.list() in both queries and then perform the query in Groovy code. Transactions in my system are only composed of a 10-30 instances, so performing a list each time is no problem.

Above the service tier is the standard controller tier used to interact with the views. Controllers provide automatic routing by a convention over configuration rule. In this application, there are multiple types of transactions: bills, budgets, deposits, etc. They are each transactions with their own impact to the underlying balance. As they are each transactions, they all share the same semantics for the views. The easiest way to do this with controllers is by passing a type query parameter as part of the path. However, in order to be more RESTful, I put the type parameter as part of the path and injected it as a query param into the controller via UrlMappings.groovy. The rule /transaction/$type?/$action?/$id? accomplishes this by associating the type as a query path parameter along with the id. URL mappings in Grails are simple and effective at creating generic controllers with RESTful linking. Further, all link creation in Grails (g:link, createLink, etc) properly recreate the links based on the given controller, action, and parameters. This allows the URL mapping to be changed in a single location without having to update all other links in the application. Other than that, the controllers are fairly straightforward and perform UI logic to setup the UI model that gets passed into the views. One other minor note is the usage of the static allowedMethods fields to ensure the actions are handled in only certain HTTP transactions. This is especially helpful when dealing with the RESTful style linking.

The controllers utilize the views for actual rendering. The views are fairly straightforward. In this application, there are two layouts that provide the frame around the page content: main and dialog. The main layout is the application frame around the pages. The dialog layout is used to provide a jQuery Mobile dialog frame. Both layouts provide the associated header sections that provide the meta data, including iOS headers for supporting a home screen web application, icon, and splash screen. They also provide the assets for javascript and CSS. Note that I could have used the new Grails resource plugin to inject the CSS automatically. However, as I only have a few assets most of which are on a CDN via jQuery, it was simpler to just inject in the page directly. I highly recommend the resources plugin for anything more complex.

The main layout uses two features to allow the page to pass data to the layout. The first is content sections. The main layout contains two distinct content sections that page can implement: buttons and content. The buttons provide the buttons that appear in the page header (think iOS). The content is the actual page content between the header and footer. This is achieved in the layout via the <g:pageProperty name="page.content" /> tag. In the actual page, such as the main overview page, you simply include a <content tag="content"> tag. The layout can then choose where to place each content section within its frame.

The second feature is page properties. For example, the main layout defines the common footer, but in some templates, the footer is not desired. The page can use standard HTML5 data attributes to notify the layout accordingly. For example, the create transaction template disables the footer by specifying <body data-nofooter="true"> on the main body tag. The layout can retrieve that property as an expression such as <g:if test="${pageProperty(name:'body.data-nofooter') != 'true'}">. Note that the values are expressed as strings. Both of these features make layouts much more powerful as well as more effective at being generic.

The only other interesting aspect of the views is using sub-templates to share code between page templates. The create and edit transaction templates do this as they each provide the same form elements.

The next part of the stack is jobs. Jobs are Grails components that run periodically (either through a timeout or cron definition) that allow the application to perform background processing. Jobs are provided by the Grails Quartz plugin. Note that while 1.0-RC5 is currently out as of this post, I had issues in getting it properly running. As such, I am using compile "org.grails.plugins:quartz:0.4.2" as my dependency. The Quartz plugin provides a Grails job component that allows the full Spring managed bean autowiring injection (similar to controllers and services). To create a new job, invoke the grails create-job command. The jobs appear in the jobs folder. The easiest sample is a simple timeout and execution block:

class MyJob {
    def timeout = 60000L; // 1 minute
 
    def execute() { println "Invoke me every minute!" }
}

In this application, the BalanceRetrieveJob is used to retrieve the latest balance every hour. The job injects a balance loader automatically. The loader is just an interface that a specific implementation can be provided as defined in the Spring resources.groovy file.

Another aspect of the job is sending emails whenever a threshold is exceeded. The mail plugin (compile "org.grails.plugins:mail:1.0.1" along with a custom repository mavenRepo "http://download.java.net/maven/2/") provides a very simple method for sending emails using a custom Groovy DSL. Just setup the appropriate configuration in Config.groovy to get started.

The server side aspect was extremely simple to build and the fact that it only takes a few days to construct is a testimony of the power you can build in an application leveraging Grails.

But one more thing…

I needed a place to host my newly created application so that I could load it on my iPhone and iPad as a home screen web application. After first trying to use Google AppEngine and its annoying restrictions followed by my own LAMP domain which did not have sufficient resources to run Java, I decided to use VMWare’s Cloud Foundry. I already had an account and since it is still in beta it was free to use. If you have not tried Cloud Foundry yet and are writing Grails applications, I highly recommend it! You are probably thinking I had to spend a bunch of time setting things up, changing around code, changing the domain model, etc. If so, you are heavily mistaken. All I needed to do was include the Cloud Foundry plugin (compile "org.grails.plugins:cloud-foundry:1.2.3" and associated Maven repositories) and then run grails prod cf-push. The plugin took care of the rest including configuring a MySQL instance in the cloud and re-configuring the data source configuration accordingly. Grails took care of auto-creating the schema, the bootstrap took care of initializing the transactions, and the job took care of downloading the initial balance on startup. Once I was ready to re-deploy, I simply had to run grails prod cf-update. It was so extremely easy I am actually annoyed I started with my other options first. For more information including other minor setup steps, see the One-Step Deployment Guide.

The biggest aspect that impressed me with Cloud Foundry was speed and performance. When I ran on App Engine (which required all sorts of other annoying changes and setup and was no where near as simple), it took forever to load at times. When I ran in my domain, it was horrific. When I run in Cloud Foundry, it renders pages in milliseconds making the experience awesome.

Stay tuned for the next series on using jQuery Mobile and Phantom JS.

Read the next article on Client Side via jQuery Mobile.

if (getX() <= 5 and getX() >= 9) { }

Although that makes sense, the following is much more readable:

if (getX() between 5 and 9) { }

It is also faster because getX() is only invoked once rather than twice as in the previous example. You could avoid that in the previous example, but using a local variable, but often times that is overkill for a simple check.

The in operator is even more convenient:

if (getX() == 5 || getX() == 7 || getX() == 9 || getX() == 11) { }
// vs
if (getX() in (5, 7, 9, 11)) { }

With the range operator in Groovy, this is possible to simulate the between operator but it does not perform as fast as it has to do a list creation and then a list lookup rather than two conditional checks which is heavily optimized in VMs.

if (getX() in 5..10) { }

Hopefully future languages (Groovy, Javascript, Python, Ruby, etc) can all add the between and in operators in future releases to further empower developers.

Server sent events are actually quite easy to implement, much more so than websockets (talking pure protocol of course as frameworks exist for both that make it easy). In fact, event source at the server side is basically a standard HTTP request/response with a specific format over a long-held request. On the client-side, the browser has a built-in JavaScript API that knows how to handle that format to receive asynchronous callbacks. This allows applications to easily support server-sent events for certain use cases. My specific use case I built into a standard Servlet on Tomcat with the native JavaScript API.

So what is my use case? My use case is basically providing progress for long running tasks. Imagine a user clicks on a submit button or a link that results in a long running request. How do you notify the user of that progress? The old way was just putting a spinner on the page to notify the user that “something” was happening. However, what if the “something” actually failed or is stuck? The user would never know. The next method was the application would spin off a second AJAX request to constantly ping the server for progress. I have never been a big support of this method as it results in two connections per user as well as constantly pinging the server wasting bandwidth. Long polling came around to help alleviate the bandwidth issues, but you would still need 2 connections not to mention the expense of tearing down and bringing up the long polling connections. My answer to this is server-sent events. This could also be done with web-sockets, but it’d be much more complex and have no added benefit. Remember the principle rule of development: KISS (keep it simple). In other words, do not use complicated technology unless you get a better bang for your buck. In this scenario we already have to invoke an HTTP request to handle the submission and since SSE is essentially an HTTP request, it works nicely.

Let’s get to the code. The first portion is the server side. This example is a pure Java Servlet but you could use any technology. You could also use other servlet-based frameworks rather than dealing specifically with the servlet. This is only meant to demonstrate what you could do.

Basically, once the doGet method is called, it sets the content type and encoding so that the client knows that a EventSource connection is being established. Failure to set these settings will cause the client to error. Next, it creates a long running task to do whatever it needs to do which also has a progress state. The task is used to send another SSE whenever the progress updates. This allows the task to immediately notify the client whenever its progress updates. The actual data is sent down as JSON so that the client can parse it for information.

The client code is just as simple.

Basically, whenever the link is invoked, it sends an EventSource connection to the above servlet. Every time a message is sent it updates the progress bar accordingly. Once the complete message is received it properly closes the connection so that it is not re-established by the browser. At this point, the script would update the page notifying the user of completion.

Note that the CSS3 progress bar in this example is based off the great work at http://www.catswhocode.com/blog/how-to-create-a-kick-ass-css3-progress-bar.

The full example is at this Gist: https://gist.github.com/3604120

From the rest of the community who is fully confused by the latest announcement from AT&T concerning Facetime over 3G and the requirement for the new shared data plans, we would like to have some questions answered that would help to further solidify your position and rationale for this announcement.

1. Why is it a requirement to only support the new shared data plans rather than the tiered data plans? I know of several people currently with an unlimited plan who would willingly move to a tiered data plan, including myself, in order to gain Facetime over 3G. However, we do not want to be forced to pay an additional $20-40 on average from our current plans. For example, as a user who does not talk often and who never uses texting, why would I need to have unlimited quantities? In that scenario, I only need 400-500 minutes and no texting, which averages around $50-60 a month. Add 4 GB of data and that is only $80-90 a month versus the $70 + $40 for shared data plans. If the biggest issue is truly data usage, why does it matter if I am on a tiered data plan or a shared data plan (data is data and caps are caps). The use=age of texting and voice should not impact the usage of data and applications. The end result is the same for both the consumer and your bottom line.

2. Why is this restriction only in place for Facetime? There are several other popular video communication applications for smartphones, the most popular being Skype. Skype currently works over 3G without issue and without restriction. One could argue that Skype has more market penetration than Facetime and is potentially more threatening to your network. For one, Skype has a much larger market share and supports many more devices due to its support for Android and iOS (not to mention tablets, computers, and other smartphones). From the latest Google Play market statistics, the Android-based Skype application has been downloaded 50M-100M times. Compare that to the fact that only the iPhone 4 and iPhone 4S support Facetime and only iOS to iOS calls are supported. I’m willing to guess the market share is drastically in favor of Skype. For example, last quarter, only 7M iPhones were activated on the AT&T network. The nationwide split is around 50% Android and 32% iOS. That being said, why should Facetime be disallowed but Skype allowed. That seems to give an unfair competitive advantage to Skype without justifiable means. This is further compounded when you add other video-chat applications such as Qik, Fring, Tango, Google+, etc. If the answer is that Facetime is “theoretically” easier and more penetratable as market share, can you please share that data with us? However, why should one companies’ success force an unfair advantage? Either all video applications should be disallowed or none should be.

3. If the selling point is you need to have a specific shared data plan, then why should the data used by Facetime count against that data usage? If you are requiring a specific data plan, there has to be an incentive to selecting that plan versus another plan such as the tiered data plans. Otherwise, this just seems like a ruthless attempt to coerce users into unwanted plans and extra cost.

4. Why not make Facetime only available over certain network capabilities (HSPA+ or LTE)?. In theory LTE, and even HSPA+ to a lesser extent, should provide better bandwidth than today’s older generation 3G networks. It would not be unreasonable to only support Facetime over these high speed networks for both bandwidth conservation and sheer performance and quality. The community, although still disappointed, would be able to better understand these types of restrictions (other than the fact that Skype and other applications run over 3G still). This would also allow a smaller rollout over time in order to better gauge the true network impact.

These answers would help the community better understand where you are coming from as an organization. We are all fully aware of the data bandwidth issues plaguing wireless carriers today, but in the end the decisions being made in this issue do not make sense: competitor networks are not making such concessions, other applications work without restriction, market share analysis (at least what the public has access to) provides no known concrete evidence that Facetime over 3G will substantially impact wireless networks adversely. These types of issues only worsen the credibility of AT&T, decrease customer satisfication, and ultimately confuse your user base.

We hope to hear back from you regarding these questions,

Sincerely,

The AT&T iPhone Community
on behalf of Nicholas Hagen

Servlets

The first piece of configuration we will talk about is servlets. Typically, you will not change servlet paths from one environment to another, but there are certain occasions where you will need to. The problem is that there is no way to do substitution parameters in web.xml. One way I found to do this is by using the new servlet-based methods to dynamically add servlets. The Servlet 3.0 specification allows you to add servlets dynamically during startup, typically as part of a Servlet Context Listener.

@WebServletContextListener 
public class MyServletContextListener implements ServletContextListener { 
    public void contextInitialized(ServletContextEvent event) { 
        // create servlet instance
        MyServlet servlet = new MyServlet();
 
        // get current environment
        String env = System.getProperty("env.name");
 
        // configure servlet per environment (dev, test, prod, etc)
 
        // register and configure the servlet
        ServletRegistration.Dynamic reg =
            event.getServletContext().addServlet("MyServlet", servlet);
        reg.setLoadOnStartup(1);
 
        // configure mapping based on environment
        String mapping = null;
        if ("dev".equals(env)) { mapping = "devctx"; }
        if ("test".equals(env)) { mapping = "testctx"; }
        else { mapping = "prodctx"; }
        reg.addMapping(mapping);
    } 
 
    public void contextDestroyed(ServletContextEvent event) { 
        // ...
    } 
}

Servlets must only be added dynamically during startup through a servlet context listener. For more information, see the JavaDocs. Another idea would be to use a custom servlet that acts as a delegate but allows parameter substitution. In this situation, you could use variables such as ${property} within init-param values. The delegating servlet could then load those parameters and substitute system properties for the variables before passing onto the corresponding servlet.

Persistence Units (JPA)

There are two was to use JPA in a Java EE application. The first is using @PersistenceContext to inject an EntityManager into a bean. The second is to directly use Persistence.createEntityManagerFactory. In either scenario, JPA loads a matching META-INF/persistence.xml. Within the persistence unit there are two ways to configure the associated database data source. The first is using JNDI sources. In this case, the container manages the actual configuration which is the best option as you would configure each container differently per environment. However, if that is not a possibility for your scenario (such as using a standard SE application or simple web application), then you can use substitution values to override the persistence unit properties. For example, when using Hibernate as the implementation to JPA, you must configure the hibernate.connection.url which would be different per environment. The Persistence.createEntityManagerFactory method has a form that takes two arguments: the unit name and a set of override properties. The second argument can be used to override or add properties to the persistence unit properties. For example, you could pass the system properties as the second argument and then define the overrides as system properties.

EntityManagerFactory emf = Persistence.createEntityManagerFactory("DataSource", System.getProperties());
EntityManager em = emf.createEntityManager();

On the actual command line, you could define the property such as: -Dhibernate.connection.url=jdbc:..... That will then override the URL setting in the persistence unit. Each environment would pass a different option.

MDB Queues

MDBs and their resource adapter counterparts often times require a configuration for the actual JMS environment (hostname, port, etc). These settings would once again be environment specific. The problem is that the configuration is usually part of an EJB configuration file or using annotations. The nice thing is that some containers allow some of these options to use substitution expressions using system properties. For more information and specific examples for Glassfish, see the blog article on The power of System properties substitution in Glassfish. Other containers such as JBoss, Websphere, etc offer similar support. Consult your individual container for more information.

The first step is to create the directory structure and the plugins and applications for the Grails project. Use the following commands to setup the structure:


#> mkdir sample
#> cd sample
#> grails create-plugin plugin-a
#> grails create-plugin plugin-b
#> grails create-app test


If we look at our directory structure, we now have three directories, two representing plugins and one representing the application that will make use of the plugins. To enable this as a Maven multi module project, run the following command to generate all of the required POMs.


grails create-multi-project-build com.mycompany.grails:sample:1.0.0-SNAPSHOT


This will now create a POM in the main directory and each of the sub-directories. The command will also properly process the plugins as plugin projects and the applications as application projects. The root POM will be the parent POM containing each directory as a module. Note that this script will not generate or overwrite a given app or plugin if a POM already exists. In those cases, you will need to make sure you set the parent properly.

Let’s start in the parent POM in the main directory. After opening this POM you will notice it is pretty simple. The groupId, artifactId and version are all set to the values passed on the command line. The packaging is set to pom which associates this project as a parent POM. The last portion of the POM is the list of modules that should be executed with this project. This should contain all of the children modules.

Note that you can also include standard Maven and Java projects that are in the same directory structure by simply adding them as a module as well. This main project will resultingly build all children projects, regardless of type (grails-plugin, grails-app, jar, etc) and automatically build in the proper order based on the dependency management.

Now let’s look at the individual POMs. Let’s start with one of the plugins, such as plugin-a. If you recall from my previous article, this closely resembles the standard POM from a Grails plugin. The only real difference is that this POM contains a parent section that references the parent POM in the main directory. The rest is the same. You should follow the instructions in that article to ensure the POM and *GrailsPlugin.groovy file are in sync in terms of versioning. One last thing to note is that for plugins, Grails sets the groupId to org.grails.plugins to follow its conventional practice for 3rd party plugins. For internal sites, you may want to change this to your own company such as com.mycompany.grails. Make sure that if you change the groupId in the plugin POM, you also change it in any dependencies of any other plugins or applications.

Similarly, if we look at the POM from the test application directory, it too is the same per my previous article. Again, the only difference is the inclusion of the parent section. You should follow the instructions in that article to ensure the POM and application.properties file are in sync in terms of versioning. While we are here, let’s also add the two plugins as dependencies. The dependencies may already be listed if Grails automatically added them to the POM. If you wanted to be even more interesting, though, you could have plugin-a be a dependency of plugin-b and then add just plugin-a as a dependency of the application. Maven will correctly determine the order and build accordingly.

<dependency>
    <groupId>org.grails.plugins</groupId>
    <artifactId>plugin-a</artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <type>zip</type>
    <scope>compile</scope>
</dependency>
 
<dependency>
    <groupId>org.grails.plugins</groupId>
    <artifactId>plugin-b</artifactId>
    <version>1.0.0-SNAPSHOT</version>
    <type>zip</type>
    <scope>compile</scope>
</dependency>

At this point, you should be able to go back to the main directory and run mvn clean package. That should build both plugins first followed by the application. The application will install both plugins into it and then build itself. In the end you will wind up with two ZIP archives that are installed in the Maven repository and one WAR archive that is installed.

We could stop here, but that’d be too easy. Maven has much more powerful constructs to simplify maintenance and configuration of the POMs.

The first thing I would change is the versions. Within multi-module projects, if all versions are the same and match the parent POM, then you do not need to include the version. The same applies for the groupId (although remember that the groupId of plugins may be different by convention). This will, then, remove the duplication of version in each POM (once in the parent and once in the children). To update the version, simply use the Maven release plugin or the mvn versions:set -DnewVersion=1.0.1-SNAPSHOT command. These will both cycle through the parent POM and all child modules to update the versions accordingly. As an example, my application POM now looks like this:

<parent>
    <groupId>com.znet.grails</groupId>
    <artifactId>sample</artifactId>
    <version>1.0.0-SNAPSHOT</version>
</parent>
 
<artifactId>test</artifactId>
<packaging>grails-app</packaging>

The next thing I noticed is that each POM includes the Grails version via the grails.version property. In theory, within a multi-module project setup, all modules would be built using the same Grails version. As a result, we can place this in our parent POM and automatically inherit in our children POMs. So, remove the properties block from each child POM and copy it into the parent POM.

Up next? Dependencies. Maven has a neat construct called dependencyManagement that is particularly useful within parent POMs. Dependencies within the dependencyManagement section are not actually dependencies of any given project. Instead they are mere templates. In this way, you can define the groupId, artifactId, version, type, and scope for any or all dependencies. Then, within the dependencies section of any other child POM, you only reference the groupId and version. If all three plugins all made use of the same dependency, you would only need to change the version once rather than three times. Let’s add a couple dependencies to the parent POM (note that this works because we just added the grails.version property definition to the parent POM). You may also choose to add all the dependencies in the application POM as needed.

<dependencyManagement>
    <dependency>
        <groupId>org.grails</groupId>
        <artifactId>grails-dependencies</artifactId>
        <version>${grails.version}</version>
        <type>pom</type>
    </dependency>
 
    <dependency>
        <groupId>org.grails</groupId>
        <artifactId>grails-plugin-testing</artifactId>
        <version>${grails.version}</version>
        <scope>test</scope>
    </dependency>
</dependencyManagement>

We can now update each plugin and the main application POMs to change these two core dependencies to just the following. Now, we have a single place of configuration and maintenance.

<dependencies>
    <dependency>
        <groupId>org.grails</groupId>
        <artifactId>grails-dependencies</artifactId>
        <type>pom</type>
    </dependency>
 
    <dependency>
        <groupId>org.grails</groupId>
        <artifactId>grails-plugin-testing</artifactId>
    </dependency>
 
    ...
 
</dependencies>

You will notice that we just updated those two dependencies in all three children. Being every Grails app and/or plugin will include those dependencies, we can just add them to the dependencies (NOT dependencyManagement) block of the parent POM and remove from the children POMs. In this manner, all children projects that inherit from the parent will get those dependencies. Once again, we have a single place of maintenance. The Grails application child POM will still include several other dependencies, but those dependencies are not shared by ALL children dependencies. Only the dependencies that exist in all children should be placed in the parent POM dependencies block. One other potential issue is that if your multi module project also includes non-Grails projects such as Java/JAR projects, then this will also not work. One solution for that is to have a top level multi module project for all projects, including Java, and a single Grails project which itself is a multi-module project. For example:

sample/
    java-library-jar/
    grails-modules/
        plugin-a/
        plugin-b
        test-app/

Any of the Grails app can still reference the Java library but the grails-module will also be a multi-module project that will only contain Grails modules, thus allowing us the conventions in this article.

The next piece in comparing the POMs to simplify is the plugin section. Once again, the same configuration has been included in every POM. Rather than include in every POM, we can remove from each child POM and include in the main POM instead. Again, take note that if non-Grails projects exist, this will not work (consider using pluginManagement instead). Another workaround there other than the one above is to use Maven profiles and use a file existence activator based on the presence of the grails-app directory. In other words, if a grails-app directory exists in a given module, then activate it as a Grails build and invoke a set of plugins. Non-Grails projects will not have those plugins activated then.

If you remember from the previous articles we had to include some modifications to the Grails plugins, add custom plugins for doing search and replace for versioning artifacts, and update the Maven release process for it. As we now have a single location for our plugin management, we can make those changes to the parent POM rather than each individual POM. This dramatically improves maintainability.

One issue to be aware of is with the search and replace plugin. That plugin had a hard-coded file name. To avoid that issue, use the filesToInclude property instead to use GLOB-style matches.

<plugin>
    <groupId>com.google.code.maven-replacer-plugin</groupId>
    <artifactId>replacer</artifactId>
    <version>1.5.0</version>
    <executions>
        <execution>
            <phase>validate</phase>
            <goals>
                <goal>replace</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <filesToInclude>*GrailsPlugin.groovy</filesToInclude>
        <replacements>
            <replacement>
                <token>/\*\s*@@VERSION@@\s*\*/\s*".*"\s*/\*\s*@@VERSION@@\s*\*/</token>
                <value>/* @@VERSION@@ */ "${project.version}" /* @@VERSION@@ */</value>
            </replacement>
        </replacements>
    </configuration>
</plugin>

This will only match those files in the main directories ending with GrailsPlugin.groovy, which, by convention, all Grails plugins do.

Another issue to be aware of is that for the plugins, we changed the validate-plugin goal to run in a different phase so that the search and replace would work properly. If you keep this configuration in the parent POM, it will attempt to run the validate-plugin task on every project, which will fail in the application project as that is a Grails application, not a plugin. This unfortunately is difficult to solve. The best way to solve, without having to add duplicated plugin configuration to the POMs, is through Maven profiles. Maven profiles can have custom builds and plugins. Unfortunately, because plugins and apps look so similar, it is not easy out of the box to configure this. The best way I found is to use the existence of a file. For example, you could drop a grails.plugin file in each plugin directory and key off of that.

<profiles>
    <profile>
        <id>grails-plugin</id>
        <activation>
            <file>
                <exists>grails.plugin</exists>
            </file>
        </activation>
        <build>
            <plugins>
                 <plugin>
                    <groupId>org.grails</groupId>
                    <artifactId>grails-maven-plugin</artifactId>
                    <version>${grails.version}</version>
                    <configuration>
                        <fork>true</fork>
                    </configuration>
                    <extensions>true</extensions>
                    <executions>
                        <execution>
                            <id>default-validate-plugin</id>
                            <phase>initialize</phase>
                            <goals>
                                <goal>validate-plugin</goal>
                            </goals>
                        </execution>
                    </executions>
                </plugin>
            </plugins>
        </build>
    </profile>
</profiles>

This is not the cleanest approach and requires having an extra file in each plugin directory, but it works properly. The good news is that the configuration and maintenance is only in one place. You could even pull this configuration out to a super POM that all Grails projects (single module or multi-module) depend on.

If we now look at our child POMs, the plugins are almost empty, with the only piece being the repository and tools profile. As those are once again shared by the plugins and applications, pull this out into the parent POM. With that in place, the plugins and applications are now very simple only providing their metadata and dependencies. The Grails configuration and build process is all centralized to the parent or super POM.

For a complete example of this setup that includes the search and replace plugin and Maven release plugin support for local checkins, see my examples on GitHub.

Hopefully all three of these articles will help you to configure your Grails projects as a Maven build.

Other Articles in this Series:

1. Grails 2.1 and Maven Integration: Simple Project
2. Grails 2.1 and Maven Integration: Plugins
3. Grails 2.1 and Maven Integration: Multi-Module Projects

The first step is to create a plugin. Instead of using grails create-app, we will use the plugin-variant grails create-plugin. At that point, we can once again use the create-pom command to create the resulting POM.


#> grails create-plugin my-plugin
#> cd my-plugin
#> grails create-pom com.mycompany.groupid


Before looking at the POM, we should update the plugin descriptor first. Grails automatically creates a plugin descriptor based on the name of the plugin. In this case, the descriptor is named MyPluginGrailsPlugin.groovy. One of the first few lines is the defined version. In order to be more Maven-compliant by using SNAPSHOT in the version while in development mode, change the version to 0.1-SNAPSHOT.

Now, let’s crack open the POM. You will notice that the generated POM for the plugin closely resembles the generated POM for a Grails application. The only major difference is the number of required dependencies. Per my previous article, Grails automatically generates the dependencies based on the dependencies block in the BuildConfig.groovy file.

The first step that is required is to change the packaging type. Grails applications use the packaging type of grails-app; however, plugins need to use grails-plugin. As a result, make sure to update the packaging type to grails-plugin. This configures Maven for the proper plugins and commands when building and deploying the plugin. Whereas the Grails application creates WAR artifacts, the Grails plugins creates ZIP artifacts.

The next step is to change the version. The version in the POM must match precisely with what was configured in the plugin descriptor. In fact, the validation plugin in the Grails Maven plugin ensures they match before deployment. As a result, set the version to match what is in the plugin descriptor file (ie: 0.1-SNAPSHOT).

At this point, you may also choose to set the name, description, include other dependencies, etc. Now we are ready to build and deploy.


#> mvn clean install


This will build and install the plugin as a ZIP archive in your local Maven repository. You could also deploy it to a remote Maven repository by configuring the deployment repository.

With our plugin built and deployed locally, we can now include this plugin in our previous sample application. If you do not have a sample application, simply follow my previous article or run these commands:


#> cd ..
#> grails create-app myapp
#> cd myapp
#> grails create-pom com.mycompany.groupid


Within the application’s base directory, open its POM file so we can add our plugin as a dependency. Adding plugins as dependencies are just like any other dependency in Maven and include the GAV (groupId/artifactId/version) coordinates. The important piece to include is the type. Plugins in Grails are deployed as zip files, so the type should be zip.

<dependency>
    <groupId>com.mycompany.groupid</groupId>
    <artifactId>my-plugin</artifactId>
    <version>0.1-SNAPSHOT</version>
    <type>zip</type>
</dependency>

The groupId and version should obviously match what was deployed/installed for the plugin. You may also set the scope to compile or runtime depending on how the plugin is needed. Otherwise, at this point, you should be able to build the application again.


#> mvn clean package


If that runs successfully, you will notice that the my-plugin plugin is installed in the plugins subdirectory. This means the plugin was properly installed into the application. You now have a working Grails application, plugin included, built completely with Maven.

But not so fast….

If you recall, we had to ensure that the version number was the same in both the POM and the plugin descriptor. This becomes a problem if you are using the Maven release plugin. The Maven release plugin automatically configures the version and re-builds the project to release it accordingly. This will cause a validation error since the plugin descriptor will still be expressed as a SNAPSHOT, but the POM will be a release build without SNAPSHOT. Similar, when the release plugin advances to the next development version, the plugin descriptor will still be off.

The solution to this, or at least my solution unless others have better ones, is to use search and replace in Maven to automatically replace the versions in the plugin descriptor with those in the POM. There are a few different replacement options in Maven, but the one I’m using is the maven-replacer-plugin.

The best way I thought of doing search and replace was doing a prefix and a suffix as comments. This way you could easily match and replace with a simple regex as well as keep the file compilationly valid. For example, here is a portion of my plugin descriptor:


def version = /* @@VERSION@@ */ "0.1-SNAPSHOT" /* @@VERSION@@ */


We can now use our search and replace plugin in Maven to easily replace that. You may also want to consider doing this for other properties such as the title, description, SCM path, etc so that you can control them all from a single location in the POM. Then, using the search and replace plugin, you configure it in this manner:

<plugin>
    <groupId>com.google.code.maven-replacer-plugin</groupId>
    <artifactId>replacer</artifactId>
    <version>1.5.0</version>
    <executions>
        <execution>
            <phase>validate</phase>
            <goals>
                <goal>replace</goal>
            </goals>
        </execution>
    </executions>
    <configuration>
        <file>MyPluginGrailsPlugin.groovy</file>
        <replacements>
            <replacement>
                <token>/\*\s*@@VERSION@@\s*\*/\s*".*"\s*/\*\s*@@VERSION@@\s*\*/</token>
                <value>/* @@VERSION@@ */ "${project.version}" /* @@VERSION@@ */</value>
            </replacement>
        </replacements>
    </configuration>
</plugin>

You will notice that the phase it its bound to is validation. However, that is also the phase that the validation of the plugin for the Grails Maven plugin occurs in. Unfortunately, there is no way (that I’m aware of) to selectively order plugin execution when two goals are in the same phase. My solution is to run the replacement in validate and then change the validation plugin to run in initialize, which occurs right after validate. For example, change the Grails Maven configuration to the following.

<plugin>
    <groupId>org.grails</groupId>
    <artifactId>grails-maven-plugin</artifactId>
    <version>${grails.version}</version>
    <configuration>
        <fork>true</fork>
    </configuration>
    <extensions>true</extensions>
    <!-- RUN VALIDATION IN INITIALIZE PHASE SO REPLACEMENT PLUGIN
         RUNS PROPERLY IN VALIDATE PHASE -->
    <executions>
        <execution>
            <id>default-validate-plugin</id>
            <phase>initialize</phase>
            <goals>
                <goal>validate-plugin</goal>
            </goals>
        </execution>
    </executions>
</plugin>

You should now be able to change the version in the POM and run mvn clean package and have it update the plugin descriptor and successfully build it. The last step, similar to my last article, is to perform an scm:checkin during preparationGoals and completionGoals of the release plugin so that the plugin descriptor is committed to source along with the associated POM.

<plugin>
    <artifactId>maven-release-plugin</artifactId>
    <version>2.3.2</version>
    <configuration>
        <preparationGoals>clean verify scm:checkin -Dmessage="perform release"</preparationGoals>
        <completionGoals>validate scm:checkin -Dmessage="prepare for next release"</completionGoals>
    </configuration>
</plugin>

You need both preparation and completion goals so that you both commit the updates during the release and after the release and upon configuring the next version. Note that this may unfortunately lead to 4 checkins per release (2 for the release plugin, 2 from this configuration).

You can now build, package, release, and deploy the plugin purely using Maven. You will most likely want to include the above configuration in a parent or super-POM so that all Grails projects can inherit from it to reduce the configuration and management of each Grails project.

Being this is the first release of the pure Maven integration into Grails, I do have the following feature requests for future updates:

1. The create-pom script should detect a plugin and set packaging to grails-plugin
2. The create-pom script should consider changing the version to 0.1-SNAPSHOT, but then it would differ from what is in the plugin descriptor by default, so this may not be a good idea
3. The create-pom script should set the description to an empty string rather than null or the version number

My next article will touch on the multi-module support in Maven and Grails and how to build the plugins and applications as a single build.

Other Articles in this Series:

1. Grails 2.1 and Maven Integration: Simple Project
2. Grails 2.1 and Maven Integration: Plugins
3. Grails 2.1 and Maven Integration: Multi-Module Projects