Monday, April 4, 2016

Spring Boot with JSPs using Undertow

This is a follow-up to my previous post Spring Boot with JSPs in Executable Jars.

Undertow is another alternative for using an embedded container with Spring Boot. You can find general information in the Spring Boot reference guide chapter Use Undertow instead of Tomcat. While I was working on updating the Spring Boot documentation regarding the JSP support for Tomcat, I noticed the following line in the reference guide for Spring Boot 1.3.3:

"Undertow does not support JSPs."

Being a good citizen, I dug a little deeper and discovered the Undertow JSP sample application by Chris Grieger. It turns out that Undertow has indeed JSP support by using jastow, which is a Jasper fork for Undertow. The key was to adapt the Undertow JSP sample application for Spring Boot. Doing so was actually fairly straightforward. The actual Undertow configuration uses Spring Boot`s EmbeddedServletContainerCustomizer:

final UndertowDeploymentInfoCustomizer customizer = new UndertowDeploymentInfoCustomizer() {

  public void customize(DeploymentInfo deploymentInfo) {
    .setResourceManager(new DefaultResourceLoader(JspDemoApplication.class))
    .addServlet(JspServletBuilder.createServlet("Default Jsp Servlet", "*.jsp"));

    final HashMap<String, TagLibraryInfo> tagLibraryInfo = TldLocator.createTldInfos();

    JspServletBuilder.setupDeployment(deploymentInfo, new HashMap<String, JspPropertyGroup>(), tagLibraryInfo, new HackInstanceManager());


The full source is available in the JspDemoApplication class. The main issue is more or less the retrieval and configuration of the used Taglibraries. The Undertow JSP sample provides the TldLocator class, which does the heavy lifting. For our example, I am adapting that class so that it works in the context of Spring Boot. In Spring Boot we are dealing with ├╝ber-Jars, meaning the resulting executable jar file will contain other jar files representing its dependencies.

Spring provides some nifty helpers to retrieve the needed Tag Library Descriptors (TLD) files. In TldLocator#createTldInfos I use a ResourcePatternResolver, specifically a PathMatchingResourcePatternResolver with a location pattern of classpath*:**/*.tld.

final URLClassLoader loader = (URLClassLoader) Thread.currentThread().getContextClassLoader();

final ResourcePatternResolver resolver = new PathMatchingResourcePatternResolver(loader);
final Resource[] resources;
final String locationPattern = "classpath*:**/*.tld";

try {
 resources = resolver.getResources(locationPattern);
catch (IOException e) {
 throw new IllegalStateException(String.format("Error while retrieving resources"
   + "for location pattern '%s'.", locationPattern, e));


Don’t forget the asterix right after classpath. The classpath*: allows you to retrieve multiple class path resources with the same name. It will also retrieve resources across multiple jar files. This is an extremely useful feature. For more information please see the relevant JavaDocs for PathMatchingResourcePatternResolver.

Once we have the TLD resources, they will be parsed and ultimately used to create a collection of org.apache.jasper.deploy.TagLibraryInfo. With those at hand, we create a JSP deployment for Undertow using the DeploymentInfo and the TagLibraryInfo collection.

final HashMap<String, TagLibraryInfo> tagLibraryInfo = TldLocator.createTldInfos();
JspServletBuilder.setupDeployment(deploymentInfo, new HashMap<String, JspPropertyGroup>(), tagLibraryInfo, new HackInstanceManager());

And that’s it. Simply build and run the application and you should have a working JSP-based application.

$ mvn clean package
$ java -jar jsp-demo-undertow/target/jsp-demo-undertow-1.0.0-BUILD-SNAPSHOT.jar

In your console you should start seeing how the application starts up.

Once started, open your browser and go to the following Url http://localhost:8080/.

You can find the full source-code for this sample at

Friday, February 12, 2016

Starter Project - Angular 2.0 + TypeScript + WebPack + Bootstrap

As Angular 2.0 is finally in Beta (¡Yeah!), it is playtime now. In my opinion, the best starter project to use (Feb 2016 ;-) is Angular2 Webpack Starter by AngularClass. Unfortunately, it does not come with Bootstrap support out of the box. This is typically not a major issue but many front-end developers will be faced with 2 major changes:

  • Grunt, Gulp and Bower are dead, long live NPM and Webpack
  • TypeScript rules but how do I "require" my CSS dependencies?
Therefore, I created fork of the aforementioned starter project adding Bootstrap support. Also, in order to customize your Bootstrap theme, I believe it is advisable to use either Less or Sass. As I am more familiar with Less, I added it to my setup as well.

Monday, October 12, 2015

AngularJS + Karma - Loading JSON Files for Mocking HTTP Responses

In order to kick-off AngularJS projects, I have been looking at generator-gulp-angular lately, which you can find at:

When doing your unit tests, it is quite convenient to mock HTTP responses using JSON files. However, having your unit tests load additional (JSON) files may not be super obvious using the Karma test runner.


For the task at hand, I am using jasmine-jquery which provides “jQuery matchers and fixture loader for Jasmine framework”. Add that dependency to your bower.json file:

"devDependencies": {
  "jasmine-jquery": "2.1.1"


Now we need to do some additional configuration for Karma. By default, generator-gulp-angular wires the needed files up with:

return wiredep(wiredepOptions).js
    path.join(conf.paths.tmp, '/serve/app/index.module.js'),
    path.join(conf.paths.src, '/**/*.spec.js'),
    path.join(conf.paths.src, '/**/*.mock.js'),
    path.join(conf.paths.src, '/**/*.html'),
    {pattern: path.join(conf.paths.src, '../mocks/**/*.json'), watched: false, included: false, served: true}

In order to make your JSON file available, add

  pattern: path.join(conf.paths.src, '../mocks/**/*.json'),
  watched: false,
  included: false,
  served: true

So that it becomes:

return wiredep(wiredepOptions).js
    path.join(conf.paths.tmp, '/serve/app/index.module.js'),
    path.join(conf.paths.src, '/**/*.spec.js'),
    path.join(conf.paths.src, '/**/*.mock.js'),
    path.join(conf.paths.src, '/**/*.html'),
    {pattern: path.join(conf.paths.src, '../mocks/**/*.json'), watched: false, included: false, served: true}]);

Mocks is a directory in my project’s root folder. Customize as needed. For further details see:

Now, you're ready for testing. In your spec aka unit test file, in the beforeEach:

beforeEach(inject(function (_$httpBackend_, _$rootScope_, $controller) {

you can now mock up the $httpBackend:



Saturday, October 3, 2015

AngularJS Best Practices - Style Guide

Looks like the place du-jour for THE AngularJS style guide is here:

The author, John Papa, also provides the HotTowel Yeoman generator, that implements this style-guide:

If you're a TypeScript aficionado, you may want to keep an eye on the following GitHub issue:

In the meantime - checkout:

And all this came up, as I was looking, for some good explanation for the advice to use AngularJS’
“Controller as” syntax and to avoid $scope as much as possible.

A really good explanation is also here:

Friday, October 2, 2015

TypeScript versus ES6

A good question is: Why would you want to use TypeScript versus ES6?

A few reasons for me:

  • I have to use a transpiler anyway in order to support older browsers such as Babel
  • TypeScript gives me types
  • You can still use JavaScript as valid TypeScript (TS being a superset of JS)
  • It seems to be a more natural fit for Java developers
  • Tooling support seems pretty good
  • AngularJS 2.0 will use it natively - as such you have Google and Microsoft supporting it


Will ES6 make Typescript irrelevant?

TypeScript vs ECMAScript 2015/2016

TypeScript and ES6 Dan Wahlin & Andrew Connell

Angular Air Episode 25: TypeScript or ES6 with Babel?

Thursday, October 1, 2015

AngularJS 1.x and TypeScript

I did a bit of research today on TypeScript. As it is favored (but not required) for the upcoming AngularJS 2.0 release, I wanted to dig a bit deeper. Keep in mind that as of Oct 2015, AngularJS 2.0 is still a pure alpha version and even new projects shall continue using AngularJS 1.4.

Nonetheless, it looks like TypeScript is a viable option even for the latest 1.4 version. In fact, Yeoman now provides an Angular starter (generator-gulp-angular) that gives you the option to use TypeScript as your language of choice.

Here are some resources that I thought were helpful:

I believe, that particularly for Java Developers, TypeScript could be quite interesting - as you have much better type-safety compared to using plain JavaScript. See the following blog entry by Veit Weber:

Why Java Developers might love TypeScript

There is a good presentation by Sander Mak from JavaOne: "TypeScript for Java Developers: Coding JavaScript Without the Pain" on that subject as well:

A longer version:

As you can have a much better OO experience with TypeScript, I think it will be also quite interesting to use rich domain objects with AngularJS rather than using JSON structures directly when retrieving data from your REST endpoints.

There is a great presentation by Gert Hengeveld from NG-NL 2015.


Blog Post:

Convert JSON Structure to TypeScript Classes

If you create TypeScript classes that need to handle JSON, the follow online tool to generate TypeScript interfaces from JSON might be of interest:

TypeScript type definitions

I still need to wrap my head around TypeScript type definitions. They basically bolt on type definition for libraries that are not inherently based on TypeScript. There is a repository for them:

Monday, March 2, 2015

Still want to go to DevNexus 2015 (for free)? Room Volunteers Needed!

We are still looking for a few more room volunteers to help us with the monitoring and basic quality control of the breakout session rooms at DevNexus 2015 next week.

In total we need 24 volunteers (12 tracks x 2 days) for the 2 main conference days (March 11 and 12)  It will be first come, first serve - So please apply ASAP. We will be accepting room monitors from now and up until Thursday, March 5th.

The room monitor will be responsible for:

  • Getting a copy of the presentation slides from speakers right after each session
  • Making sure speakers don't go over their allotted time
  • Communication of any room related issues (power, sound , temp... etc).
  • Count the attendees in each session
  • Provide some feedback in regards to the observed sessions

A volunteer will be in charge of a single track room for one full day. Then s(he) will be free all day on the alternate conference day. For example, you monitor the Agile session room on Wednesday, then you are free to attend any session on Thursday.

Please contact info at ajug dot org if you are interested with the following info:

  • Day and Track
  • Alternative Day and Track 
  • Name
  • Email
  • Phone

Also, let us know if you have any further questions.


Saturday, January 10, 2015

DevNexus 2015 at BMW's Car Hackathon

Thanks to my colleague Sabby Anandan, DevNexus 2015 is getting some mentioning at BMW's Car Hackathon - Hack The Drive in San Francisco. The event takes place this weekend January 11-12.

Details at:

Here are some photos:

Thursday, January 8, 2015

DevNexus 2015 - Early Bird pricing ends Jan 9

The countdown for DEVNEXUS 2015 (Workshop day March 10, main conference March 11-12) is on! The AJUG team has been working hard to secure speakers, build the new event site and make this year's event the best one ever:

  • 3 days (1 workshop day and 2 conference days) 
  • 12 tracks 
  • 120 sessions 
  • expected attendance of 1500 

You can see the accepted list of speakers and sessions at

Please note that the Early Bird pricing ends this Friday Jan 9th!! So if you want to take advantage of the super low event price of $250 (other developer conferences of this scale cost $1000-$1800 to attend) then register this week.

Also don’t forget that we have a whole day of workshops on March 10th. This conference has sold out every year for the last 6 years so be sure to register now at:

A big THANK YOU to all of our sponsors that help make this event possible:






See you all in March!!!

Tuesday, December 2, 2014

Npm, Bower, CI and the Network

Ok, I accepted the reality that building single-page applications (SPA) is better done using the tooling options embraced by the JavaScript community, rather than building those apps using purely Gradle or Maven (and respective plugins). The reason being that building a complete web-UI is rather involved and tools like Yeoman, Grunt (Gulp) and Bower provide quite a bit of useful tooling while also having a much larger user-base than the (less complete) options in the Java world.

So life was good. Everything builds. Of course we still need to integrate the app with our backend that provides the REST endpoints. Personally, I prefer it that developers can build the entire stack at once. Also, can we assume that every (Java) developer has Node/Npm intalled?

Luckily, there are some plugins available for Maven and Gradle that provide useful wrappers around Npm and Node:
Thus, with some trial and error you get a fairly portable build (Linux, Mac and Windows) that not only executes the Grunt build but also downloads and installs Node and its dependencies, Grunt, Bower etc.

You think you finally arrived...Things run mostly okay on the continuous integration (CI) server...mmh, wait... "Mostly" is causing some headaches. This is actually an area where I have some frustrations lately. Looks like the Maven Central in the node world is a tad more volatile than Maven central itself.

In the Java world you have 2 layers of protection that ensure that the CI server build process is fairly resilient to internet hick-ups. Heck, it would even build off-line (assuming no library dependency changes were done). First, you have your local repository of course, which in the case of Maven is typically ${user.home}/.m2/

Second, any serious CI environment would also use a dedicated repository manager that serves as a proxy to the outside world, so that for already retrieved dependencies you would not need to hit Maven Central or other 3rd party repositories.

With NPM you all of a sudden realize you are a tad back into the wild west. Not only do you have to consider NPM (Managing tooling dependencies) but Bower (managing JS/CSS dependencies) as well.

NPM actually provides npm-cache - and you see dependencies being cached in your home directory under ~/.npm/. But try to disable your network card...the eternal spinner is yours. It does not even seem to timeout.

You can go offline - kind of - using “npm install --cache-min 9999999 --no-registry” but it does not seem to support things the way Maven/Gradle does: Check the cache first, and only if the dependency does not exist fetch it remotely. See also:

Another issue I encountered is with using Protractor for the E2E testing of my AngularJS application. You will usually use webdriver-manager to retrieve the necessary Selenium files/driver for your targeted Browser, e.g. Chrome. Since, I like to make the build as portable as possible, I do a post-install of the web-driver manager, which requires direct network access in package.json:

"scripts": {
  "postinstall": "node_modules/protractor/bin/webdriver-manager update"

Bower unfortunately, does its own caching approach which is configured in .bowerrc, e.g.:

"storage": {
"packages": ".bower_cache"

So what about using dedicated repository managers as proxy for NPM and Bower?

Artifactory provides support for NPM but not Bower. There is a feature request to support Bower in Artifactory, though. Nexus also has support for NPM. For Bower an open ticket exists.

Maybe people should start rallying behind web-jars more broadly ;-(