JS Ext

Friday, February 8, 2013

Feature Request: Serving JSPs from Jar files

JSPs need to be in a war file.  This is part of the J2EE spec.  For simple web applications, this make sense.  Your dynamic web project contains the JSPs that are part of the project.  When you get into larger, more module projects, it would be nice if the servlet engine could read a JSP from a jar file.  I am going to give a concrete example where this would have been useful.

I wrote a regression test library for REST applications at my company.  The idea is that you can write a regression test in JavaScript that fires off a fake REST call that returns JSON.  You parse the JSON request and call assert functions to make sure the data came back is sane.  These tests execute on JVM startup.  What good is a test if you can't see the result?  I wanted to write a very simple user interface that allows you to see the results of the regression tests.  This user interface does a few things.  It lists the results of the tests.  It also allows you to download the log for the individual unit test, in the event that one fails.  This feature makes it easier to debug a failed regression test.  It also allows you to re-run the regression tests (maybe the database was down).  You can also use your HTTP monitoring software to ping the user interface to make sure all of your REST services are healthy.  Sounds simple enough, right?

The J2EE spec actually encouraged me to write the user interface in raw Java as a Servlet instead of writing it as a JSP.  Remember, this was a library for other webapps to use.  This was not a webapp in and of itself.  This means it is a jar file.  Any user interface that I write would have to be contained inside of the jar file.  JSPs can't be rendered from jar files, though.  I toyed with various ideas.  I thought, maybe I can unpack my JSPs into a subfolder inside of the unpacked war on JVM startup.  I decided this would be a bad idea.  I thought about symlinking in the JSPs from a common location.  This meant the user interface wouldn't run on the developers' desktops, however.  I thought about putting the JSPs in a separate jar file and having the dynamic web projects use the Maven shade plugin to shade in the user interface JSPs.  I didn't want to put the Java and JSP code for the library into different projects, though.  I finally settled on writing the user interface in Java.  The developers would just add the Servlet to their web.xml.

For a library like this, the user interface didn't need to be elaborate.  The target audience was Java developers.  There were other scenarios that did require a more elaborate user interface, but describing that scenario requires a lot of background information that I can't get into.  This would be a great addition to the J2EE spec that would make it a lot easier to write modular code without having to deal with the Maven shade plugin.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.