Posts tagged with 'jbosscentral'

One of the most useful (and by the way, also one of the coolest) features of JBoss SwitchYard (http://switchyard.jboss.org/) is its graphical process editor. The editor enables you to create composite service definitions through a graphical interface, instead of having to directly edit cumbersome raw XML. For example:

The big blue box in the center window is called the canvas. Here’s where you can see the graphical representation of the service definition. With SwitchYard, it’s all about the services. With the SwitchYard editor, you can create the services, and not just edit Java source code.

What’s always been missing has been a corresponding tool for debugging SwitchYard Services. This gap is now being filled by the SwitchYard Debugger.

A debugger such as GDB provides you with the ability to interrupt a program’s execution through breakpoints so that you can examine code and data. In SwitchYard, however, you’re not just dealing with Java classes, you 're creating (and debugging) services. The SwitchYard debugger lets you add a breakpoint to any service or reference to a service. The debugger supports these actions:

In contrast to a Java debugger, the SwitchYard debugger enables you to invoke breakpoints during steps (such as transformation) during the execution of the service, right in the service bus:

The best way to understand the new debugger is to see it in action. We’ll do this by using the debugger with SwichYard "quickStart" example programs. Let’s get started!

Before we can see the debugger in action, we have to install the SwitchYard runtime and its corresponding Eclipse tooling. Luckily, downloading and installing JBoss software* is quick and painless (and free!)

The steps to install the SwitchYard runtime are:

The steps to install SwitchYard’s Eclipse tooling are:

(We’re using the latest versions of the software available when this post is being written.)

One of the helpful features included with JBoss projects are example programs referred to as “quickstarts.” As the name implies, the goal of these examples is to help users get started quickly in learning technologies provided by JBoss projects. As we mentioned earlier in this post, the approach that we’ll take is to introduce a bugs into quickstarts, and then use the debugger to locate these bugs.

To introduce SwitchYard applications to new users, we’ll examine the first quickstart that we’ll use in some detail. If you are already familiar with SwitchYard applications, you can skip over this section of the post.

Let’s start by using the debugger to interrupt a running service in a quickStart and enable us to examine the data in a message being processed by the service. After this, we’ll take things one step further and introduce a bug into a service and then use the debugger to find the cause of the bug and work around it.

Before we examine how the debugger can be used with a quickStart we’ll take a look at how quickstarts are implemented and how to use the SwitchYard editor.

The first quickstart that we’ll run makes use of Apache Camel to implement content based routing to route messages to selected services. This quickstart is aptly named: rules-camel-cbr. Before we run the quickstart, let’s take a quick look at how it works.

To understand how the quickstart is constructed and how it works, we’ll examine it by looking at these 3 elements:

Let’s start by looking at the design of the quickstart application and its services.

To import the quickstart into our JBDS workspace, navigate to File→Import→Maven→Existing Maven Projects:

Browse to the quickstarts directory under the directory into which you installed SwitchYard, select the quickstart and it is imported.

The SwitchYard graphical application editor enables you to create services and references to services, configure gateway bindings for all the protocols that SwitchYard supports, configure message transformers (to convert messages from one format to another), create skeletons of the classes, interfaces, and unit tests for your services.

The service definitions that you create in the editor are stored in a file named switchyard.xml. In the quickstart, this file is located in the src/main/resources/META-INF directory. All the quickstarts that we’ll use in this post follow this same pattern. Let’s open this file in the editor and take a look around.

To open the file in the editor, simple double-click on the switchyard.xml file’s icon. When the editor opens, here’s what we see:

The big blue box in the center window is called the canvas. Here’s where you can see the graphical representation of the service definitions:

At this point, we should take a moment to understand the graphical symbols that are used in the service definitions.

The visual elements defined in switchyard.xml conform to the OASIS Service Component Architecture Assembly Model Specification (http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-spec-v1.1.html). The Service Component Architecture (SCA) model provides standards for building SOA applications.

A green chevron represents a service definition. The corresponding purple chevron represents a reference to a service. The blue rectangles are service components. These are containers that can hold implementations or one or more services through references.

Why was this standard selected as the lingua franca of SwitchYard configuration? What advantages does using this standard give us? There are multiple levels of advantages:

The set of fundamental service definition symbols is defined in the OASIS Service Component Architecture Assembly Model Specification here: http://docs.oasis-open.org/opencsa/sca-assembly/sca-assembly-1.1-spec-CD-01.html#_Toc193601722

The other symbols relate to the SwitchYard-specific service implementations and bindings. For example, the RoutingService is implemented as a Camel XML service, the DestinationService is implemented as a JBoss Drools service, and the Red, Blue, and Green services are implemented as Java Bean services.

The full range of options supported by SwitchYard is displayed in the Palette view:

(Yes, it’s a long list. You have to scroll to see all the options.)

One thing to keep is that while this service definitions are persisted in an .xml file, and while you are able to view the contents of that file, you should not attempt to edit the raw XML in that file. The editor has built in protections to ensure that you do not create an invalid configuration. These protections are not in effect if you edit the raw XML directly. Accordingly, while we’ll examine both the information available to you in the graphical editor and the switchyard.xml file, we’ll focus on using the editor.

Let’s start by examining the application service design as presented by the editor, in the context of the application logic flow, then we’ll look a bit deeper into how you can create and manage the application design through the editor.

What happens in the quickstart is a three step process:

How is this all accomplished? Let’s look at the RoutingService definition. Select the RoutingService in the diagram, open the Properties view and you’ll see this:

Remember that this service is a Camel XML service. The implementation of that route is defined in the route.xml file. The route definitions take the form of a Spring DSL. (See http://camel.apache.org/spring-xml-extensions.html for more details.)

The contents of this file are pretty self-explanatory as the destination color determines the ultimate destination. For example:

What happens when the quickstart processes a message is:

First, the incoming message is routed, by the RoutingService to the DestinationService.

As seen in route.xml:

Let’s look at the DestinationService definition. Select the DestinationService in the diagram, open the Properties view and you’ll see this:

Then, the DestinationService service uses an MVEL statement to find the Widget class’s ID, and rules defined in JBoss Drools (remember that this service is implemented as a JBoss Drools service) to set the Destination value:

As seen in DestinationServiceRules.drl:

Then, the route logic continues in a structure to route the message to the correct destination:

OK. We have the Destination value set in each widget. But, how does the widget get routed to the correct destination?

Camel provides a Java DSL (Domain Specific Language) to implement routes. In the DSL, a camel route contains a source ("from") and a destination ("to). These reference the RoutingService and DestinationService interfaces that we just saw in the SwitchYard editor.

In the case of the quickstart, the route definitions take the form of a Spring DSL. The route is self-explanatory, even if you do not have experience with Camel. The destination service is selected based on the content; Red, Green, or Blue.

There’s just one more thing we have to look at before we run the quickstart - how to start the chain reaction of tasks that the quickstart will perform.

Testing server-side applications such as those built with SwitchYard can be difficult. Since this is server-side software, you have to install and run a server, the application has to be deployed to that server, and then you have to construct a client to access the application on the server. You can end up in a situation where you have to build either a throwaway test client, or a reusable test framework. Either way, you have to invest time and effort into building something other than your application.

Luckily, JBoss SwitchYard provides a built in framework that makes testing your applications fast and easy. This QuickStart makes use of the SwitchYardRunner class. SwitchYardRunner is a JUnit Runner class, but more than that, it starts up an embedded SwitchYard runtime. When this embedded runtime starts, your application is packaged up as a SwitchYard application that is deployed to the test instance.

To make use of SwitchYard’s test support, all you have to do is to annotate the test with the SwitchYardRunner JUnit test Runner class. This class will startup an embedded SwitchYard runtime, one for each test method, and then package up the test into a SwitchYard application and deploy that application to the runtime.

In addition to the SwitchYardRunner class, SwitchYard also makes testing easy by providing the TestMixIn feature. TestMixIns enable to turn on additional test support, based on the specific needs of your application. This quickstart makes use of the CDIMixIn to register its bean services. Some of the other TestMixIns support testing http services, JBoss Smooks transformations, and JMS services.

OK, enough talk. Let’s run the quickstart.

First, deploy the quickstart to a SwitchYard server. In JBDS, this is a simple task. It can be done with the server either started or stopped, but let’s start the server first so that you more easily spot the server logging messages when the quickstart is deployed.

To start the server, select it in the “servers” view, and press the start button.

The server console window will open, and you should see something like this:

Then, to deploy the quickstart, select the server in the “servers” view again, right-click, select “Add/Remove Applications” and select the quickstart.

Switch back to the console view and you should see something like this:

INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "switchyard-quickstart-rules-camel-cbr.jar" (runtime-name : "switchyard-quickstart-rules-camel-cbr.jar")

To run the client test program, select the rules-camel-cbr/src/test/java/org/switchyard/quickstarts/rules/camel/cbr/RulesCamelCBRTest.java Java source file, and run it as a JUnit test.

Switch back to the server console, and you’ll see the quick start’s output!

And the green bar appears!

Now, we’ll use the debugger to interrupt a running service in a QuickStart and enable us to examine the data in a message being processed by the service. After this, we’ll take things one step further and introduce a bug into a service and then use the debugger to find that bug.

Let’s start by setting a breakpoint on the Blue service. We’ll use this breakpoint to enable us to view the contents of the message received by the service. For the purposes of our first example, we’ll use the Blue service.

To set a breakpoint in the SwitchYard editor, first position the cursor over the service’s green chevron icon. A small palette of icons is displayed:

To set a breakpoint on the service, select the eyeglasses icon. The presence of this icon on a service definition as seen in the SwitchYard editor indicates that a breakpoint is set:

Notes that as we are adding a breakpoint on the service, the breakpoint will trigger for any reference or composite service invoking that service. In contrast, if you add a breakpoint on a service reference, it will only break when that reference is invoked.

To view and modify the breakpoint’s properties, open the Debug perspective and look in the breakpoints view:

And then right-click on the breakpoint, to view and edit the breakpoint’s properties:

For our example, we’ll use the default properties. We’re mainly concerned with the breakpoint being triggered at service entry.

Now that our breakpoint has been defined, let’s run the RulesCamelCBRTest program again.

To run the test with the debugger, right-click on RulesCamelCBRTest, select Debug As→JUnit Test:

When the breakpoint is reached, the program is suspended. If we look in the Variables view in the Debug perspective, we can see the incoming message and the values that controlled the content-based routing of a message to the Blue service:

Now that we’ve seen the quickstart run correctly, it’s time to introduce a bug, and then use the debugger to find it. For this illustration, we’ll use a different quickstart.

Remember the scene in the movie “Independence Day,” when Will Smith uploads a software virus into the evil aliens’ spaceship? Let’s do something similar and add a bug into a quickstart, and then use the debugger to find the bug and even fix it.

Some of the types of bugs that you have to deal with in a services and message based system involve when there are problems in the content in the messages, and how the services are (or are not) able to handle those problems. What sorts of bad things can happen to good messages? Missing a field, wrong namespace, malformed XML, errors in the headers, etc. The debugger makes it possible to tweak a message to debug a problem, without having to redeploy the service.

The quickstart that we’ll look at is “validate-xml.” This quickstart demonstrates the SwitchYard XML validator. The quickstart deploys a service that accepts a message and returns an object that is transformed with XLST. The incoming message is checked for XML validity, so that malformed messages are caught. Before we can run the quickstart, it must be deployed in the same manner as the rules-camel-cbr quickstart that we looked at earlier in this article.

The quickstart’s application diagram is very simple as only one service (“OrderService”) is implemented. This service only accepts a message and returns an object that is processed by the XLST transformer, but it’s adequate for our purposes. The diagram looks like this:

The test application that we want to run is: validate-xml/src/test/java/org/switchyard/quickstarts/validate/xml/WebServiceTest.java

This application executes separate two Junit tests. First, it verifies that a properly formatted SOAP message can be transformed and validated, and then it verifies that an intentionally malformed SOAP message (that is, a message that contains invalid XML) is caught.

Before we look at causing and catching a bug, let’s examine the message tansformation that is performed by this quickstart. The transformation is performed with the order.xslt file in the quickstart. It’s a simple transformation in that it transforms incoming messages that look like this:

Into objects that look like this:

The change simply indicates whether the incoming order was accepted.

If we set our breakpoint on the “OrderService” service:

And then run/debug the WebServiceTest, we can view the message, before and after its transformation, in the debugger. Here’s the message before transformation:

And here’s the message after its transformation:

The second test in the WebServiceTest intentionally sends a message that includes an invalid XML element.

The invalid SOAP message looks like this:

Yes, it’s easy to spot the invalid XML. ;-)

Let’s expand on this test application a bit and alter it to not gracefully trap the error resulting from the invalid XML. To do this, we’ll edit the invokeOrderWebServiceValidationFail() method and change this:

To this:

So that when we run the test, we see this JUnit error:

Before we can debug the OrderService, we must set our breakpoint:

Then we edit the breakpoint’s properties. For our example, we want the trigger to be set for the validation of incoming messages:

When we run/debug the WebServiceTest program, the breakpoint is reached and we can examine the message contents:

And, there’s the invalid XML element. What makes the debugger especially useful is that we can now edit the message and remove the invalid XML:

And then allow the program to resume its operation. In this way, we can determine if the program has any other bugs before we correct the cause of the invalid XML, redeploy, etc.

We’ve taken an introductory look at the new SwitchYard debugger in this article. The debugger enables you to debug not just a class or method, but a Switchyard service. The debugger is configured through the SwitchYard graphical service/application editor and enables you to both monitor and control the operation of a service to make it easier for you to find those pesky bugs and is a great addition to the SwitchYard developer toolkit.

The author would like to thank Rob Cernich for his input and reviews of the article as it was being written, Keith Babo for his background on the SwitchYard editor, and Jiri Sedlacek for his painstaking review of my sometimes suspect grammar. (Many thanks!)

All of these components have been verified to work with the same dependencies as JBoss Tools 4.2 and Developer Studio 8.

To install the Integration Stack tools, first install JBoss Developer Studio from the all-in-one installer, bundled and configured out of the box with everything you need to get started. Alternatively, if you already have eclipse-jee-luna installed, you can install JBoss Developer Studio or JBoss Tools from the Eclipse Marketplace via Help > Eclipse Marketplace…​

Once Developer Studio is installed, restart Eclipse and select the Software/Update tab in the JBoss Central view. The current 8.0.0.Beta1 integration stack is available as "Early Access" so you must check the "Enable Early Access" checkbox in the installer window. Select the items you’d like to install:

The standard p2 installer is available for JBDSIS. Simply start jbdevstudio or eclipse-with-jbds, then:

The community JBoss Tools Integration Stack (JBTIS) installation is easy as well. If you already have eclipse-jee-luna installed, install JBoss Tools from the Eclipse Marketplace via Help > Eclipse Marketplace…​

Once JBoss Tools is installed, restart Eclipse and select the Software/Update tab in the JBoss Central view. The current 4.2.0.Beta1 integration stack is available as "Early Access" so you must check the "Enable Early Access" checkbox in the installer window. Select the items you’d like to install:

The standard p2 installer is available for JBTIS. Simply start eclipse-with-jbt, then:

Note: If you installed into your own Eclipse you should bump up the launch resource parameters:

This is a Beta1 release so some things are in flux but virtually every component has something new or updated. Here’s a small list of what’s new:

Don’t miss the Features tab for up to date information on your favorite Integration Stack component!

JBoss Developer Studio comes with everything pre-bundled in its installer. Simply download it and install it like this:

JBoss Tools or JBoss Developer Studio Bring-Your-Own-Eclipse (BYOE) requires a bit more:

This release requires at least Eclipse 4.4 (Luna) but we recommend using the Eclipse Luna SR1 Java EE Bundle since then you get most of the dependencies preinstalled.

Once you have installed Eclipse, you can either find us on Eclipse Marketplace under "JBoss Tools (Luna)" or "JBoss Developer Studio (Luna)".

For JBoss Tools you can also use our update site directly if you are up for it.

There have been many feature additions and a lot of bugfixing polish going into this main release and these have been documented/described in details at What’s New.

The main headlines are:

This release would not have been possible without feedback and contributions from our community and the team(s) around Developer Studio. For that I’m truly grateful. Any contribution counts!

The following people have participated in this release with either code, ideas, feedback and testing:

Alexander Silgidjian, Alexey Pakseykin, Andrei Ivanov, Andy Goldstein, Antonio Goncalves, Asif Kilwani, Axel Wathne, Chris West, Chunyun Chen, Clovis Seragiotto, Cody Lerum, Cojan van Ballegooijen, Daniel Castro, Daniel Cunha, Daniel Dekany, Darren hartford, Darryl Miles, Eduardo de souza, Emily Brand, Ender Wiggin, Eric Barber, Filippo rossoni, Guillaume Jouvelot, Harald Wellmann, Henk de boer, Hermes Waldemarin, Hernán Chanfreau, Igor Jacy Lino Campista, Jeffrey Simpson, Jesper Skov, Jim Boettcher, Joe Guzzardo, Jorge Yagüe París, Josh B, Juergen Zimmermann, Karl Pietrzak, Labdoui labdoui, Luke Maurer, Marcel Neuwohner, Martin Lippert, Masao Kunii, Mikhail Kalkov, Nan wei, Nero M, Nicolas duminil, Oliver Pfau, Palmer Eldritch, Patrick Decat, Paul Richardson, Pei-Tang Huang, Radosław Józwik, Rainer Schön, Randall Smith, Rich DiCroce, Robert Baty, Robert Munteanu, Roman Ilin, Ron Ratovsky, Sebastien Deleuze, Stephen Neal, Suz Dorfield, Sébastien Pinel, Tagir Valeev, Thiago andrade, Thomas Maslen, Weiweijiang jiang, Wolfgang Knauf, Zerr Angelo, Alexander Kurtakov, Alexey Kazakov, Aliaksey Nis, Andre Dietisheim, Andrea Vibelli, Andrej Podhradsky, Arun Gupta, Aslak Knutsen, Barry LaFond, Boleslaw Dawidowicz, Brenton Leanhardt, Brian Fitzpatrick, Burr Sutter, Catherine Robson, Corey Daley, Daniel Azarov, David Chia, David Hladky, David Stephan, Denis Golovin, Denis Maliarevich, Duncan Doyle, Emil Cervenan, Emmanuel Bernard, Eric Rich, Fred Bricon, Gavin King, George Gastaldi, Gorkem Ercan, Ilya Buziuk, Isaac Rooskov, Jakub Niedermertl, James Cobb, Jane Murphey, Jaroslav Jankovič, Jeff Cantrill, Jim Tyrrell, Jiri Pallich, Jiri Peterka, Joshua Wilson, Juraci Paixão Kröhling, Juraj Húska, Karel Piwko, Koen Aers, Konstantin Marmalyukov, Krzysztof Daniel, Lars Heinemann, Len DiMaggio, Lincoln Baxter III, Lucia Jelinkova, Lukáš Fryč, Marek Novotny, Marek Schmidt, Marius Bogoevici, Marián Labuda, Martin Malina, Matthias Wessendorf, Max Rydahl Andersen, Maxim Areshkau, Michelle Murray, Mickael Istria, Mustafa Musaji, Nick Boldt, Paul Leacu, Pavol Srna, Pete Muir, Peter Palaga, Petr Stribny, Petr Suchý, Radim Hopp, Radoslav Rábara, Rafael Benevides, Rastislav Wagner, Rick Wagner, Rob Cernich, Rob Stryker, Robb Greathouse, Ron Šmeral, Sande Gilda, Sebastien Blanc, Snjezana Peco, Stefan Bunciak, Ståle Pedersen, Tadeas Kriz, Takayuki Konishi, Tomas Repel, Tomáš Sedmík, Travis Rogers, Van Halbert, Viacheslav Kabanovich, Victor Rubezhny, Vineet Reynolds, Vitali Yemialyanchyk, Vladimir Vasilev, Vlado Pakan, Vojtech Juranek, Xavier Coulon and Yahor Radtsevich.

Thank you!

If you like to be part of shaping the next update and major release please take a look at JBoss Tools Community Acceptance program! It will start up soon!

Hope you enjoy this release and remember…​

Have fun!

Max Rydahl Andersen+ @maxandersen

To install the Integration Stack tools, first install JBoss Developer Studio from the all-in-one installer, bundled and configured out of the box with everything you need to get started. Alternatively, if you already have eclipse-jee-kepler installed, you can install JBoss Developer Studio or JBoss Tools from the Eclipse Marketplace via Help > Eclipse Marketplace…​

Once Developer Studio is installed, restart Eclipse and select the Software/Update tab in the JBoss Central view and look for the JBoss Developer Studio Integration Stack installation section. Select the items you’d like to install:

The community JBoss Tools Integration Stack URL is:

http://download.jboss.org/jbosstools/updates/stable/kepler/integration-stack

Note: If you installed into your own Eclipse you should bump up the launch resource parameters:

Fix release versions of Fuse Tooling 7.2.2, jBPM/Drools 6.1.0 and Teiid Designer 8.3.4. Also - there are updated ESB 1.5.310.Final project examples. Look for specific bug fixes in the Release Notes.

Don’t miss the new Features tab for up to date information on your favorite Integration Stack component !

JBoss Developer Studio comes with everything pre-bundled in its installer. Simply download it and install it like this:

JBoss Tools or JBoss Developer Studio Bring-Your-Own-Eclipse (BYOE) requires a bit more:

This release requires at least Eclipse 4.4 (Luna) but we recommend using the Eclipse 4.4 JEE Bundle since then you get most of the dependencies preinstalled.

Once you have installed Eclipse, you either find us on Eclipse Marketplace under "JBoss Tools (Luna)" or "JBoss Developer Studio (Luna)".

For JBoss Tools you can also use our update site directly if you are up for it.

Note: Integration Stack tooling will become available from JBoss Central at a later date.

This release is mainly a big set of bug fixes but we managed to slip in a bunch of new features too.

There are more improvements covered in the more details: What’s New.

The next release is set to be the last candidate release, so please, do try this one out and give feedback to make sure you’ll have a good experience with JBoss Tools on Eclipse Luna!

Let us know what you think in the comments below!

Hope you enjoy it and remember…​

Have fun!

Max Rydahl Andersen & Fred Bricon
@maxandersen @fbricon

To understand why we are changing it its good to try understand how our builds for JBoss Tools is setup to have commits in builds be picked up by Jenkins which then publishes the result to our nightly build update sites.

The following picture is a simplification of the process and how the bits moves through the various sites and gets community tested.

We have ~40 repositories with more or less independent plugin sets in our Github jbosstools organization. When these change we build an update site for each of them and when one is built the content gets aggregated into an "uber" jbosstools update site.

In the beginning this was not a big problem but over the years with more traffic and more frequent builds users risk having update errors because during their update the build from which they were updating could be overwritten with a newer one.

To remedy this we now offer a composite of the latest nightly builds instead. This means that parsing the site’s metadata will be slightly slower but after that the download speed will be the same, and you should now rarely encounter the above issue.

Another advantage is that with this site you can now revert to an earlier nightly build, in case that works better.

Thus, in short - if you are willing to test our JBoss Tools nightly builds - please use this as your update site:

http://download.jboss.org/jbosstools/updates/nightly/luna/

If you are trying out latest nightly builds why not signup as part of JBoss Tools CAT member and help by giving us feedback to know if we are going in the right direction ?

To do this start here.

Have fun!

Max Rydahl Andersen
@maxandersen

JBoss Developer Studio comes with everything pre-bundled in its installer. Simply download it and install it like this:

JBoss Tools or JBoss Developer Studio Bring-Your-Own-Eclipse (BYOE) requires a bit more:

This release requires at least Eclipse 4.4 (Luna) but we recommend using the Eclipse 4.4 JEE Bundle since then you get most of the dependencies preinstalled.

Once you have installed Eclipse, you either find us on Eclipse Marketplace under "JBoss Tools (Luna)" or "JBoss Developer Studio (Luna)".

For JBoss Tools you can also use our update site directly if you are up for it.

Note: Integration Stack tooling will become available from JBoss Central at a later date.

This release is mainly a bunch of bug fixes but also a few new features and a very important regression fix.

We’ve added support for Ionic framework. Ionic is a AngularJS based framework that provides nice mobile components that works especially well with Cordova based application.

There are more improvements covered in the more detailed: What’s New.

This Beta is the last planned Beta for JBoss Tools 4.2 and Developer Studio 8. The next release is set to be the candidate release thus please do try this release out and give feedback to make sure you’ll have a good experience with JBoss Tools on Eclipse Luna!

Let us know what you think in the comments below!

Hope you enjoy it and remember…​

Have fun!

Max Rydahl Andersen
@maxandersen

One of the data points are which JBoss servers users create.

Mind you we don’t collect the exact version of the server installed, just which server adapter users are using - i.e. EAP 6.1 also covers EAP 6.2 and 6.3, WildFly 8 covers 8.0 and 8.1 etc.

The numbers above shows the last two weeks of server creation by our beta users. Not surprisingly majority of users are using the community version of the latest JBoss servers (AS 7.1 and WildFly 8), and it’s great to see the third most used server is the free for development/enterprise supported EAP 6.1/6.2/6.3.

What I find funny is that there are still users using the latest/greatest development tools, but who runs JBoss AS 3.2 - this was last released back in 2006! Talk about dedication :)

What the list shows to me is the importance of development tools need to support multiple versions because even though most are using latest/greatest runtime there are still a great bunch of users that will be using older versions of runtimes. Many developers tend to forget or blissfully ignore this.

I’m convinced as users move to our release that gathers these data we will start see even higher numbers of "older" runtime usage.

What is a bit disconcerting is how few seem to know about our Deploy only server (in this list noted as systemCopyServer ). This server allows you to use Eclipse’s support for incremental deployments to any directory locally or remotely available. Really useful for deploying to a non-JBoss server, a remote PHP or just a plain html app.

You should try it out!

File  New  Server  Basic  Deploy Only

Combine this with our LiveReload support and you get a great and fast workflow!

Another data item we have insight to is the uptake of Eclipse versions.

The graph above is our recorded startups of Eclipse Java EE installs since January pr. week. Be aware the versions listed are the EPP versions, not Eclipse release train versions - I’ll do the mapping for you below.

Two things to note: the "Drop" at the end is just the effect of the numbers ending middle of the month, the "Dip" in mid April I’m not sure what is but we see it across all our Google analytics thus I expect it was an Google Analytics anomoly. The numbers have since stabilized, that said…​lets interpret!

This graph shows how Eclipse Kepler SR1 release (2.0.1) usage is dropping as users upgrade to Kepler SR2 release (2.0.2) - this are most likely the effect of users using Eclipse built-in update mechanism to upgrade.

What also can be seen is that the latest stable release (4.4.0) uptake is gaining faster than total Eclipse version usage (the faint lines are even older eclipse versions). Meaning total usage of JBoss Tools is up/stable. Eclipse isn’t dead yet :)

I wish Google Analytics had a way to show this graph cumulative instead of per line…​anyone up for a data extraction and visualization project ? I’ll give you access to the data to play with.

Finally, my personal main interest was to see what the uptake of Eclipse Luna is.

You can see what effect a GA release of Eclipse has. The red line is Eclipse Luna going from a couple of hundreds starts to now 7.000 starts pr. week since its release - but do notice that there is no corresponding drop (yet) in Kepler. Looks like most are installing Luna next to their Kepler installs (my theory at least ;)

This mimicks previous years uptake patterns and once everyone gets back from vacation and Luna SR1 release comes out it should be close to the level of Eclipse Kepler installs. Good to see users continue to picking up latest greatest features and bugfixes!

I’ll go look at the numbers again in a few months to see if the trend continues.

If there is some additonal data you are interested or questions about the above let me know in comments and I’ll try include/answer it!

Have fun!

Max Rydahl Andersen
@maxandersen

OAuth is an open standard for authorization. It specifies a process for resource owners to authorize third-party access to their server resources without sharing their credentials. Designed specifically to work with Hypertext Transfer Protocol (HTTP), OAuth essentially allows access tokens to be issued to third-party clients by an authorization server, with the approval of the resource owner, or end-user. PhoneGap Developers use inAppBrowser’s API to show the OAuth consent page.

CordovaSim supports inAppBrowser plugin and handles OAuth authorization. Here is a short video with OAuth demo and brand-new CordovaSim’s features (source code is also taken from the Michael Dellanoce’s article):

The sample should work with JBoss Tools 4.2.0 Beta3 release and later versions.

A few things to notice here : first, the Hybrid Mobile Tools imports the project into Eclipse and configures the proper plugins without there being any Eclipse specfic setup in the project. This works because the project is following the conventions from Cordova CLI generated projects and the import wizard understands this.

Secondly, when using Java 8, you can connect the Chrome debugger to the CordovaSimulator (Right click → Debug on browser) allowing you to step through the code, introspect variables and so forth.

We are trying our best to make CordovaSim as good as possible. User feedback is what we are seeking for now. We are looking forward to hearing your comments / remarks!
Have fun!

Ilya Buziuk
@ilyabuziuk