Escalante 0.3.0 out now with Play Framework 2.1 support!

We're pleased to announce the next official release of Escalante - version 0.3.0. We consider this release to be beta quality, and lacks some of the features and API stability that will end up in the 1.0.0 release.

What is Escalante?

If this is the first time you've ever heard of Escalante, check out our FAQ section to find out more about Escalante.

What's in this release?

The main focus of this release has been adding support for Play Framework 2.1 scala web applications to Escalante. This means that Play 2.1 applications can be built, deployed and run on top of Escalante just like a normal Play application but with some limitations. To help Play users deploy applications on top of Escalante, quickstart applications have been developed and these are the best starting point.

Here's a summary of other highlights of this release:

  • Lift integration has been enhanced in order to support Lift 2.5 applications. The "Hello World" Lift quickstart has been upgraded to use Lift 2.5, but the other Lift quickstarts remain using Lift 2.4. This has been done on purpouse so that different Lift quickstarts can demonstrate not only different functionality, but they can also demonstrate that Lift applications can be deployed on top of Escalante, side by side, even if they use different Lift and/or Scala versions!

  • Support for Lift applications needing Scala 2.10 has been added. In fact, Escalante is now based on Scala 2.10 and resolves other Scala version as needed depending on the deployment.

  • Escalante SBT plugin version 0.2.0 has been released with added support for Play applications to be built, deployed and run on top of Escalante. In order to avoid issues with Escalante SBT plugin, please follow the methods shown in the quickstarts on how to define the Escalante SBT plugin version to use.

  • Escalante Quickstarts have now been tagged for version 0.3.0 and the great news is two new Escalante Play Quickstarts have been added with SBT build files. Also, the SBT based quickstarts now define the Escalante SBT plugin dependency via Git URI in order to avoid the dependency resolution issue on SBT/Ivy mentioned earlier.

What's next?

In next release, Escalante will be moving to being based on top of Widlfly and both Lift and Play integrations will be further enhanced. If there's anything in particular you'd like to see done with regards to Lift or Play integration, let us know!

Get It

The simplest way to install 0.3.0 is downloading our binary distribution.

Get In Touch

If you have any questions, issues, or other feedback about Escalante, you can find us on #escalante on freenode or our public forums.

Twitter

If you're interested in anything Escalante related, make sure you follow @escalanteio to find out first :). If you want to make any comments on Twitter, make sure you use the #escalante hash tag.

Why JBoss AS should use Scala... ;)

I bet the title got the attention of a few JBoss Application Server developers, but let me clarify something before I go on: My intention is not to rewrite JBoss AS in Scala. However, I think Scala makes it easier to build and test JBoss AS extensions/subsystems compared to Java. Let me explain:

JBoss Application Server 7+ is formed out of a MSC core and a bunch of subsystems built on top of it. To test these subsystems, a mix of steps are required including: compile the code, build the module(s) for this subsystem, change application server configuration, start the server and run your tests.

If you look at the JBoss Application Server code base, you'll find that all these steps are achieved with a mix of operations involving: Java compilation, Maven, Ant scripts...etc, which is a bit of pain.

When I started developing Escalante, one of my aims was to be able to test my Escalante subsystems with minimal need from a build tool and in the fastest possible way. The end result is that today I can just right click one of the Escalante Arquillian tests (i.e. Lift HelloWorldTest) , and it will run all the steps above without the need of a build tool! How is that possible? Let me explain:

Building an Escalante subsystem

Escalante code is layered in such way that subsystems can be built purely using Scala code. For this post, let's take the Lift subsystem as example (For those unaware, Lift is a web application development framework for Scala, more info in the FAQ). So for Lift, we have a class called LiftModule which builds the JBoss module supporting the subsystem from scratch. For that it uses:

  • ShrinkWrap to build the JBoss module jar which includes classes in a number of packages and definition of the corresponding the JBoss AS Extension service provider:
  • Scala XML integration to define XML directly in the code (without annoying Java formatting required to write an XML programmatically). XML is a requirement of the JBoss Application Server, and the Lift module uses XML to define itself and its dependencies. XML is also required in order to configure the extension and subsystem in the main app server configuration file:
Warning: I'm fully aware that XML is one of Scala's most controversial features, but it's actually very handy in this particular case because it allows for seamless XML coding within Scala code. This promotes encapsulation allowing both metadata information and logic to build a JBoss module to reside in the same place, without the need of separate XML files.

Running Escalante Arquillian tests

With the subsystem built, it's time to figure out how to make sure the JBoss Application Server instance is ready to serve our applications. For this, Escalante has implemented some nifty Arquillian callbacks in a class called ArquillianListener , which allow us to execute some code at different stages. This listener class uses an AppServer class that encanpsulates logic to do with setting up the application server correctly.

Unzip JBoss AS before test set up

Using @Observes with BeforeSetup, we can force the base JBoss Application Server to be unzipped so that Arquillian has a JBoss Home to use:

The testUnzipAppServer() method just unzips the server and changes file permissions if necessary:

Prayer to the JBoss AS Gods: I hope at some point there will be an easier way to kick off a JBoss Application Server from Arquillian without the need of this unzipping... I'd love to have a way to say: my application needs subsystems X, Y and Z, go fetch them and start a server with those subsystems.

Set up modules before container start

Using @Observes with BeforeStart, we can force Arquillian to install the modules into the JBoss Application Server using the code mentioned above. This way, by the time the server starts, all the extensions we want to install are ready with their modules built and the configuration ready:

Tear down modules after container stop

This is a very important step because it's here where the app server is restored to its initial state in order for other tests to run cleanly. This involves restoring the original configuration:

Note: In order to minimise changes to the application server and simplify cleanup phase, the modules that we're testing are stored under a different module path to the one the server uses. Arquillian allows us for these extra modules paths to be passed to the server through the `modulePath` property. See arquillian.xml used by Escalante for more details.

Plug Arquillian with the listener

Once the code is written, we just need to write the corresponding service provider definition so that Arquillian picks it up:

Run the tests from the IDE

With this in place, you can now run your JBoss Application Server subsystem in-container tests directly from the IDE (of course, if you run it from Maven it will also work)!!

Reuse, reuse, reuse...

A very cool thing things about Scala is that it can work both as an standard programming language to build applications, but also as a scripting language, so this means that whatever code I've used to build the subsystems and set up the app server for the unit tests, it can be perfectly used when building an Escalante distribution.

With minimal changes, and the help of the Maven Scala plugin, I was able to create a simple Scala script that would build the entire Escalante distribution, which effectively builds the modules alongside their configurations, and installs the subsystems and extensions in the main configuration:

Configuring Maven Scala plugin to run this script is dead easy:

Summary

Pretty much everything I explained in this blog post could have been achieved using just Java (i.e. Maven has a Java exec plugin that could execute a Java class to build the distribution).

However, I think Scala makes it a lot more concise and cleaner to write all this up, particularly when it comes to embedding XML.

So, next time you're building a JBoss Application Server extension, give Scala a go! Using the code in this blog post you should be able to build JBoss Module jar archives required to test and run application server extension/subsystems programmatically, as well as adding their own configuration to the main app server configuration in a nice, reusable, way.

There are other benefits JBoss Application Server could get from using Scala as opposed to Java, but I'll leave those for future blog posts ;).

Finally, all the code I mentioned above is located in the Escalante Git repository, so you can clone it, open it in your favourite IDE and see all of this in action :)

Escalante 0.2.0 out now with SBT plugin!

We're pleased to announce the second official release of Escalante - version 0.2.0. We consider this release to be beta quality, and lacks some of the features and API stability that will end up in the 1.0.0 release.

What is Escalante?

If this is the first time you've ever heard of Escalante, check out our FAQ section to find out more about Escalante.

What's in this release?

This second release focuses on improving support for Lift web applications within Escalante. These are the highlights:

  • Escalante-optimised Lift applications are now supported in any Lift version (as long as Maven resolution succeeds, see documentation for more info), including latest milestone Lift 2.5-M4 release.

  • The way Lift applications define metadata so that Escalante can resolve Scala/Lift dependencies has changed. Instead of the old WEB-INF/lift.xml archive, Escalante now searches for META-INF/escalante.yml file, which is a much more human readable archive thanks to the use of YAML, and a lot easier to work with from a parsing perspective. For more info, check the documentation.

  • Escalante optimised Lift applications can now select which extra Lift modules to use (i.e. mapper, jpa, record...etc) by defining them in META-INF/escalante.yml, hence reducing burden on permanent space to only those modules needed. To find out more, check the documentation.

  • A SBT plugin fully dedicated to Escalante is now available!! Version 0.1.0 is now available from JBoss Nexus repository. This plugin allows several for Escalante-optimised Lift WAR applications to be created (including generation of META-INF/escalante.yml), and it can deploy these applications to an Escalante instance (embedded, no separate process!) from the SBT console thanks to the escalante-run command. I'd like to personally thank Josh Suereth for the chat we had at Devoxx 2012 that kicked off the development of the SBT plugin, and David Pollak, Lift founder and lead, for motivating me to enable Escalante instances to be started from SBT. Thanks guys!! Check the Escalante SBT Git repo to find out out more about the Escalante SBT plugin.

  • Escalante Quickstarts have now been tagged for version 0.2.0 and the great news is Escalante Quickstarts now have SBT build files as well as the existing Maven files. So, regardless of whether you use SBT or Maven, Escalante's got you covered :). The SBT files are configured with the Escalante SBT plugin, so you can get started with the newly created Escalant SBT plugin right away!

  • A new Escalante Quickstart has been added showcasing interaction of Lift applications with JPA 2.0. Although injection of @PersistenceContext or @PersistenceUnit instances is not yet available, Lift developers wanting to run their JPA applications in Escalante are recommended that they bind the EntityManagerFactory instance to JNDI.

What's next?

This new Escalante version uses a newer base JBoss EAP version than the one you can currently access via OpenShift, so the previous instructions provided to run Escalante in OpenShift might not work as expected. Over the next few weeks we'll be working on getting Escalante 0.2.0 working on OpenShift, hopefully with a dedicated cartdridge.

On top of that, now that Escalante SBT integration is in place, we'll start looking into how to get Play applications run on top of Escalante, as well as carry on developing Escalante Lift integration adding more quickstarts...etc.

Get It

The simplest way to install 0.2.0 is downloading our binary distribution.

Get In Touch

If you have any questions, issues, or other feedback about Escalante, you can find us on #escalante on freenode or our public forums.

Twitter

If you're interested in anything Escalante related, make sure you follow @escalanteio to find out first :). If you want to make any comments on Twitter, make sure you use the #escalante hash tag.

Deploying Lift applications on OpenShift

Having released the first milestone of Lift's integration into Escalante a short while back, we turned our heads to getting more people to deploying Lift applications on top of Escalante.

What is Lift? If you've never heard of Lift, or you don't know what Lift-based web applications can offer you, please check Lift's FAQ section.

So, I'm very proud to announce that you can now run Lift applications on Red Hat's OpenShift cloud. OpenShift is Red Hat's free, auto-scaling Platform as a Service (PaaS) for applications. As an application platform in the cloud, OpenShift manages the stack so you can focus on your code.

For Lift users this means that you can now deploy your Lift applications on OpenShift, and let it manage the stack for you which behind the scenes will run on top of Escalante.

Deploying your first Lift app on OpenShift

  1. First of all, sign up for OpenShift and follow the instructions in the Getting Started guide to set up SSH keys, command line tools...etc.

  2. Once you've signed up, log in, go to My Applications and create a brand new JBoss Enterprise Application Platform 6.0 application.

  3. Give the application a name, for example escalante, and click on Create Application button.

  4. Once you've installed Git locally, clone the application following the instructions on OpenShift, i.e:

      $ git clone \
         ssh://[USER_ID]@escalante-[YOUR_DOMAIN].rhcloud.com/~/git/escalante.git/
      $ cd escalante/
    
  5. Get rid of the default sample application and commit it:

      $ git rm -r pom.xml src
      $ git commit -m "Remove default app"
    
  6. From the root of the local copy of the application, merge in the modules and server configuration needed to run Escalante on top of JBoss EAP. The merged files will be stored under the .openshift folder:

      $ git remote add escalante -m master \
          git://github.com/escalante/escalante-openshift.git
      $ git pull -s recursive -X theirs escalante master
    
  7. To help users get started with Escalante, we've developed some quickstarts out of which we'll be demostrating how Hello World Lift application runs on OpenShift. So, merge in the Escalante quickstarts:

      $ git remote add quickstart -m master \
          git://github.com/escalante/escalante-quickstart.git
      $ git pull -s recursive -X theirs quickstart master
    
  8. You now have all you need to run the Hello World Lift Escalante quickstart on OpenShift. To run it, you need to push the changes in your local repository. By pushing the changes, OpenShift will build the application and deploy it, so might take a little while. Execute:

      $ git push
    
  9. Once the push finishes access the application via: http://escalante-[YOUR_DOMAIN].rhcloud.com/ and you should see something like this:

Run alternative quickstarts: The quickstarts repository you merged in contains several applications that can run on top of Escalante. Check the Escalante Quickstarts documentation for detailed information on these examples. You can alternatively enable other applications, such as the `persistence-lift` quickstart. To do so, modify the root `pom.xml` file and select which quickstart to build:

Future Work

Deploying Lift applications to OpenShift this way is a bit arduous, which is why we're also working on producing an OpenShift cartdridge designed specifically for Lift applications that can run on top of Escalante, which would simplify the process significantly. Watch this space!

Get in touch!

If you have any questions, issues, or other feedback about Escalante, you can find us on #escalante on freenode or our public forums.

Escalante 0.1.0 Released

We're pleased to announce the first official release of Escalante - version 0.1.0. We consider this release to be beta quality, and lacks some of the features and API stability that will end up in the 1.0.0 release.

What is Escalante?

Escalante is an application server for Scala. It's an integrated platform built on JBoss AS7 that aims to provide an environment for deploying and running Scala applications that is easier to use and more efficient to run than other existing solutions.

What's in this release?

For this first release, we've focused on Lift web applications, trying to make them easier and leaner to deploy compared to other plattforms. With just a little bit of information, Escalante can vastly reduce the size of your deployments and can make it more efficient to run multipl Lift applications in paralell within the same Escalante server. You can find out more by checking Escalante's documentation.

What's next?

Now that we have 0.1.0 out the door, we'll be focusing on:

  • OpenShift cartdridge for Lift applications
  • Providing more Lift quickstarts
  • Investigate other Scala frameworks
  • SBT build files for Escalante quickstarts

Get It

The simplest way to install 0.1.0 is downloading our binary distribution.

Get In Touch

If you have any questions, issues, or other feedback about Escalante, you can find us on #escalante on freenode or our public forums.

Twitter

If you're interested in anything Escalante related, make sure you follow @escalanteio to find out first :). If you want to make any comments on Twitter, make sure you use the #escalanteio hash tag.

Thank you

From here I'd like to thank everyone who's been encouraging and helping me get this first Escalante release out. From Mark, who a less than a year ago inspired me to get Escalante started, to the Project:odd team who have been helping me with all the pain points of doing your first ever release, setting up the site, put up with my questions...etc ;). Thanks you all.