A JBoss Project
Red Hat

Latest posts

JBoss Tools 4.3.1 and Red Hat JBoss Developer Studio 9.1 for Eclipse Mars.2 are now generally available!

jbds9
Java 8 is required for installing and using JBoss Tools. We still support developing and running applications using older Java runtimes. See more in Beta1 blog.

Installation

JBoss Developer Studio comes with everything pre-bundled in its installer. Simply download it from our JBoss Products page and run it like this:

java -jar jboss-devstudio-<installername>.jar

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

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

Once you have installed Eclipse, you can either find us on the Eclipse Marketplace under "JBoss Tools" or "Red Hat JBoss Developer Studio".

For JBoss Tools, you can also use our update site directly.

http://download.jboss.org/jbosstools/mars/stable/updates/

There is also a new installer available for 64-bit Windows. See details in New Developer Studio Platform Installer for Container Based Development section.

What is new?

This release is based on Eclipse Mars.2 and our focus was mainly on OpenShift and Red Hat Container Development Kit tools improvements. Besides that there is a bunch of new features and a lot of fixed bugs. The full list of what is new you can find on this page.

New Developer Studio Platform Installer for Container Based Development

A new installer for 64-bit Windows is now available. This installer is quite different from the good old Developer Studio universal installer. This will help you install Developer Studio with a full development environment for container based development using Red Hat Enterprise Linux and OpenShift.

Developer Studio Platform Installer Beta currently works on 64-bit Windows only and is available as a Technology Preview.

It helps to install and configure the following components to work together on your machine:

  • Red Hat JBoss Developer Studio

  • Red Hat Container Development Kit

  • Vagrant

  • VirtualBox

  • OpenJDK

  • Cygwin

  • OpenShift Client (OC) Tools

Red Hat JBoss Developer Studio Platform

You can see how this installer works in this short screen cast:

OpenShift 3 and Red Hat Container Development Kit

OpenShift 3 was introduced as a technology preview feature in JBDS 9.0.0.GA. We’re happy to see it graduate to the level of supported feature in this release.

new explorer

New OpenShift Server Adapter for easier and faster deployment, debug mode, integration with Red Hat Container Development Kit and more notable features were added. More than 300 issues and enhancements were also tackled in this version. See the full list of the new OpenShift tooling stuff on New and Noteworthy page.

Docker

Tooling for Docker is available in Eclipse Mars under the Linux tools umbrella. Despite this name, this works on all major developer platforms. It is mirrored on JBoss Tools update site.

docker explorer view

The Docker tools was introduced in Developer Studio 9.0 and has been improved in Developer Studio 9.1:

  • New Docker Machine Support

  • Improved Run Image Launch Configuration

  • TM Terminal Support for Interactive Shells

  • Build Docker Images improvements

More details in New and Noteworthy.

Hibernate 5

Hibernate 5 is now supported. Two new runtime providers for Hibernate were added in this release. Both these new versions can be selected in the relevant wizards.

cfg xml
Figure 1. Hibernate Configuration File Wizard

Forge 3

The included Forge runtime is now 3.0.1.Final. Read the official announcement here.

startup

Automated Error Reporting

With your permission, Eclipse and Red Hat JBoss Developer Studio can now inspect errors logged inside the IDE and inform project committers about the issues you’ve experienced. This optional service, called Automated Error Reporting Initiative (AERI), can report issues to both the Eclipse Bugzilla and the JBoss JIRA.

When the first error is logged, you’ll be asked if you’d like to participate in error reporting, which is by default completely anonymous and only happens if an error occurs.

Should you want to configure how the service operates, or provide your email address so that you could be contacted regarding any reports you submit, open Preferences > General > Error Reporting. You can then click Configure Projects…​ to enable or disable reporting to Eclipse or JBoss.

AERI Reporting Enabled

As always, neither Eclipse nor JBoss will use any information unless a user has opted in, nor is there ever any personal information sent unless it is provided on the Preferences page.

What is Next

Our next stop is a major update for Developer Studio which will be based on Eclipse Neon.

Enjoy!

Alexey Kazakov

Recently, I was working on a problem with WildFly and Java hot code replacement. When the JVM refuses to update a class (for example, because you added a method), JBoss Server tooling tries to be helpful and offers to restart the web apps in the WildFly server. Unfortunately, this doesn’t work 100%: even though the class in question is deployed and used, further changes in the class will be refused. While debugging a potential fix for this (it’s a garbage collection problem, but that’s not the point of this story), I installed a new version of OpenJDK and bam! everything just stopped working. Ok, "everything" is overstating the problem a bit, but I couldn’t deploy to the server anymore, which for a web app is pretty bad. So forget about hot code replacement…​this is MUCH worse. Seems I was hitting a known problem.

So what’s the problem?

The tooling complained that it couldn’t move some file to its final location, in the deployment directory of the server. Often the root directory, but not always. Hmh…​the directory being locked maybe? This was on Windows, so I fired up cmd.exe and looked at the directory in question (dir /Q is helpful). This is where it gets weird. The directory was there, but it had no owner. Deleting it was impossible. Wat?!

Wat

I started procmon.exe to see what was happening. The move to the directory failed with DELETE_PENDING. Looking at the source, this directory had been deleted (successfully) as part of the deployment, and recreated. All of a sudden, my spidey sense tingled…​there was something weird about deleting stuff on Windows (I used to be a real hacker, you know…​). On Unix-like OS’s, deleting a file just removes it from the directory. Once the last link to the file is gone it is deleted as soon as the last handle to the file is closed. Windows almost does the same thing, but the file is not immediately removed from the directory. Instead, it is in a zombie state, where you can still see the file, but you can’t do anything with it. That would explain the problem, so like a good little scientist, I then had a hypothesis: the WildFly server was somehow keeping a handle to the deleted directory open and thus, kept it alive. Since WildFly is using the Java WatchService to find out about changes in the deployment directory, the WatchService was my designated bad guy for the time being.

Let’s verify

It’s quite hard to test this against the WildFly server (it being a, let’s say, "non-trivial" program), so what was needed was a simple program that reproduces the problem…​clickety click…​here we go: two processes, one is watching a directory, the other tries to delete, recreate and modify the directory. Looks good, except it did NOT reproduce the problem.. This could be timing-dependent, so I applied a time tested strategy called "poking at the problem". Just added some sleep(500)'s in random places and hoped for the best. Indeed, after a couple of tries, I was able to reproduce the problem maybe 20% of the time. Even better: I could reproduce it with the debugger attached. Good thing this was on OpenJDK: it meant I could just download the sources and debug through the WatchService class. And indeed, the WatchService was stuck trying to clean up the handle to our directory. It had dutifully cancelled any pending "overlapped" I/O requests (that’s just asynchronous I/O for the non-Windows folk) and now was waiting for the I/O to be indeed cancelled. But the last operation on the directory had failed (it was deleted, remember?), so there was no pending I/O, which means the thread would wait forever.

The takeaway…​

We now have a bug report and a patched build of OpenJDK that allows me to get back to solving the original problem. That’s pretty cool, eh? This is a good example of what you can do when a system is open to inspection. It helps that I can look at the OpenJDK sources; debugging bytecodes is definitely no fun. But the coding style used in the WatchService class is also very important. They mirror the Windows native calls in a Java class. This (and MSDN) makes it possible to debug the windows specific implementation of the watch service.

Thanks to Rob Stryker and Alex Kashchenko who helped me debug this problem.

Looking for older posts ? See the Archived entries.
back to top