XRebel for standalone apps with embedded Jetty

XRebel was designed to work specifically with Java web applications. Currently, it relies on Servlet API to serve its UI. It has been tested with a range of application servers (Apache Tomcat, WildFly, WebSphere, and others) and some full stack frameworks as well, including Spring Boot and JavaSpark.

Sometimes however, you might want to use XRebel with a standalone Java process that is not using Servlet API. Hence, XRebel cannot display its embedded UI to render the data it collected from the application. What can we do about this? Well, XRebel is tested on Jetty and it works quite well there. Jetty is also often used as an embedded HTTP server. So why don’t we use this trick and embed Jetty into our standalone app to serve XRebel UI.

Here’s our example application:



Just for the demonstration purposes, it executes an HTTP request every 3 seconds and reads the response. Quick and dirty.

To embed Jetty server we need is to add a dependency to Jetty container and initialize the server when the application starts. The required dependencies are jetty-server and jetty-servlet:



Then we can start Jetty by adding the following code snippet into the static initializer of the class:



To enable XRebel agent, you need to start the application with -javaagent VM argument pointing to the location of xrebel.jar. For instance:

-javaagent:/Users/anton/tools/xrebel/xrebel.jar -Dxrebel.traces.all=true

I also added -Dxrebel.traces.all=true VM property to enable tracing of non-HTTP activities by XRebel. Tracing of non-HTTP activities in XRebel is disabled by default, hence I need to add this parameter in order to see profiling data for the periodic tasks (if I wish).

Once I launch the application, it will boot up the embedded Jetty instance on port 8080. The standalone XRebel UI is deployed by the agent to /xrebel context. Hence, if we open http://localhost:8080/xrebel in the browser we will see the following:

As you can see, it is quite easy to use XRebel with the standalone apps with this little trick. Just start an embedded Jetty instance on some port and you will be able to see what is your application doing. Perhaps, you can spot a sneaky bug with it before it gets to production! :)

If you want to play with the example application, I have it at GitHub. Download XRebel and start the application with the appropriate VM arguments to enable the agent. It will be fun! :)

XRebel 2.0 with Application Profiling

From the very start, our users requested profiler capabilities in XRebel. As of 2.0, it is possible to get the performance overview for every request and identify the slowest methods.

The profiler view shows the time distribution in the call tree by assigning the percentages to the individual nodes that represent method invocations. The slowest methods are also accompanied with an extra percentage figure that indicates the method own contribution time.

JSP tag mapping is one neat little feature, new in XRebel 2.0. Instead of a cryptic runtime name XRebel displays the real JSP tag.

In 2.0, there are some more notable improvements to the existing features. The session component is now able to handle very large HTTP session snapshots. And of course, there's a ton of little UI improvements -- all to make the profiler more pleasant to use.

Links for XRebel:

• Download
• Features
• Documentation

XRebel 2.0 Beta is available

XRebel 2.0 Beta is available for download! The new version includes profiling capabilities and it is now possible to get an overview of performance breakdown in a single HTTP request. The cool part is that XRebel shows only the minimal relevant information by filtering out a lot of irrelevant stuff. I have tested the new version with a lot of different enterprise-grade applications, including Atlassian Jira, Magnolia CMS, Liferay Portal, eXo Platform... and it works just great!

The greatest feedback so far was that the tool provided the ability to monitor JPA queries and the subsequent JDBC invocations in one go. With the new version, XRebel is turning into a real profiler, yet simple and powerful.

XRebel 1.2

Just released XRebel 1.2. It is amazing, astonishing, splendid, beautiful, awesome, beautiful, beautiful, beautiful! :) I'm most pleased with its ability to show the relation between ORM-level events/queries and the generated SQL queries that are executed via JDBC. Like this:

Or even like this:

The cool part is that even with no special requirements to filtering, the call tree scales very well - the user could see the compact call stack with relevant branching points starting from the incoming HTTP request towards the JDBC calls, or NoSQL... or outgoing HTTP invocations.. even RMI!

/me happy! :)

Deploying Spring Petclinic demo application to JBoss/WildFly

Spring Petclinic is a very good demo application to experiment with - it is simple enough, yet demonstrates quite a good number of features. Usually I deploy it to Tomcat and obviously don't have any issues with it - it just deploys, runs, and works as expected.

Recently, however, for demonstration purposes, I needed to deploy this application to JBoss (or WildFly). And this is not as straightforward as one might expect.

First I tried with JBossAS 7.1.1.Final. The deployment fails with the following exception:

11:42:38,247 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/petclinic]] (MSC service thread 1-3) Exception sending context initialized event to listener instance of class org.springframework.web.context.ContextLoaderListener: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'entityManagerFactory' defined in class path resource [spring/business-config.xml]: Invocation of init method failed; nested exception is java.lang.NoSuchMethodError: javax.persistence.JoinColumn.foreignKey()Ljavax/persistence/ForeignKey;

  at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1568) [spring-beans-4.1.1.RELEASE.jar:4.1.1.RELEASE]

  at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:540) [spring-beans-4.1.1.RELEASE.jar:4.1.1.RELEASE]
...

The latest Petclinic application (as of October 2014) uses JPA 2.1 and JBoss 7.1.1 bundles JPA 2.0 APIs. So I decided that it should probably work out of the box on WildFly since it comes with JPA 2.1 jars. And it did - the application deployed just fine, but then there's another library that prevents the application from operating properly - Dandelion:

Exception starting filter dandelionFilter: com.github.dandelion.core.DandelionException: The protocol vfs is not supported. 
        at com.github.dandelion.core.utils.ResourceScanner.scanForResourcePaths(ResourceScanner.java:204) [classes:] 
        at com.github.dandelion.core.utils.ResourceScanner.findResourcePaths(ResourceScanner.java:138) [classes:] 
        at com.github.dandelion.core.bundle.loader.spi.AbstractBundleLoader.loadBundles(AbstractBundleLoader.java:89) [dandelion-core-0.10.0.jar:] 

The issue was reported but at the time of writing this post the fix wasn't published yet. So hopefully Dandelion v0.11.0 will be capable to be deployed on WildFly.

So to overcome this and deploy Spring Petclinic (at the state of October 2014) to WildFly 8.1 one would have to get rid of the dependency on Dandelion, and rewrite some of the JSPs not to use Dandelion taglibs. Then the application deploys and works just fine.

So after making all the fixes I got Spring Petclinic running deployed to WildFly and could monitor it with XRebel:

XRebel 1.0

XRebel 1.0 is out! Looking forward for the new versions of this nice tool!