text:
tag:blogger.com,1999:blog-305876332020-08-15T11:18:05.684+05:30My WikiJaikiran's technical blog Jaikiranhttp://firstname.lastname@example.com:blogger.com,1999:blog-30587633.post-33129331296623796252019-10-26T10:09:00.000+05:302019-10-26T10:09:36.994+05:30Apache Ivy 2.5.0 released
This week, we released 2.5.0 version of Apache Ivy. Apache Ivy is a build dependency manager that is integrated with the Apache Ant build tool. The download is available as usual at https://ant.apache.org/ivy/download.cgi.

This 2.5.0 version comes after a long gap in releases of Ivy. 2.4.0 was released way back on December 26 2014. After that, the project has seen slowness in development activities. However, with help from the some community members, especially Nicolas Lalevée, back in around 2017, we had some bug fixes and enhancements done. On April 19 2018, we released 2.5.0-rc1. We called it a "rc1" because it was a long time since we had done a project release and wanted users to be aware that there might be some unexpected issues.

2.5.0-rc1 saw some community members using this version and reporting back some bugs that they ran into. We have been able to fix them during this past year and it was now finally time to release it as 2.5.0. We expect the Ivy community to start using this version in favour of older releases and report back any issues that they run into either at https://issues.apache.org/jira/browse/IVY or in our Ivy user mailing list https://ant.apache.org/mail.html

Users migrating from previous versions of Ivy are recommended to use a fresh/clean Ivy local cache to avoid certain issues with cached Ivy metadata that might have been introduced in a previous version (2.5.0-rc1) of Ivy.

The complete list of changes (since 2.4.0) that are part of this release is available at https://ant.apache.org/ivy/history/2.5.0/release-notes.html.

Going forward, the goal is to fix any bugs that are reported and introduce certain enhancements that will help improve the usage of the tool.

Jaikiranhttp://email@example.com:blogger.com,1999:blog-30587633.post-35318268870940712352019-09-06T17:59:00.001+05:302019-09-06T17:59:29.288+05:30Ant 1.10.7 released - Ability to include/exclude JUnit 5 "tags" during test execution
1.10.7 version of Ant has just been released yesterday. This release consists mostly bug fixes and some minor enhancements. The downloads are as usual available at https://ant.apache.org/bindownload.cgi

Notable among these bug fixes is a fix to a regression that happened in our 1.10.6 release. In that 1.10.6 release, we accidentally broke compatibility against Java 8. Ant 1.10.x releases are supposed to support Java runtimes starting from Java 8. However, during our previous release, our use of javac compilation attributes caused us to generate a binary which in some cases would run into issues when run against Java 8. This issue has now been fixed in this 1.10.7 release. More details about the regression are available in the bugzilla issue here https://bz.apache.org/bugzilla/show_bug.cgi?id=63457.

Among the enhancements that have made it into this newer release, includes an enhancement to the junitlauncher task. The junitlauncher task is meant for running JUnit 5 framework based test cases. In this 1.10.7 release of Ant, thanks to a contribution from Matthias Gutheil (https://github.com/MatthiasGutheil), this task now allows you to include or exclude JUnit 5 "tags" from a particular execution of tests. New attributes "includeTags" and "excludeTags" have been introduced to support selecting the relevant tags for execution. The junitlauncher task manual https://ant.apache.org/manual/Tasks/junitlauncher.html has the complete details.

As usual, any suggestions, feedback or questions can be raised in our user mailing list https://ant.apache.org/mail.html.
Jaikiranhttp://firstname.lastname@example.com:blogger.com,1999:blog-30587633.post-32948569697621845522019-05-11T17:14:00.000+05:302019-05-11T17:14:31.147+05:30Apache Ant 1.10.6 released - fork mode for junitlauncher and new jmod and link tasks
Apache Ant 1.10.6 has been released this week. This release contains numerous bug fixes as well as some very exciting new features. The complete release notes is available here and the downloads itself are available here. In this article, I will go over some of the new features that have made it into this release.

Running JUnit5 tests in a forked JVM, using junitlauncher task

A while back, Ant 1.10.x introduced support for JUnit5 tests to be launched using the new "junitlauncher" task. Given the nature of changes between JUnit 4.x and JUnit 5, the amount of support introduced in the new "junitlauncher" task was minimal. Based on user feedback about this task, this task has now been enhanced to support "fork" mode. This was one of the most asked for enhancement, in this task. The "fork" mode support in this task now allows users to configure this task to launch the tests in a forked JVM instead of running these tests within the same JVM as the one, the build is currently running in. Fork mode allows much more control over how these tests execute (things like setting up additional JVM arguments just for these tests or even system properties). The complete details of how to use fork mode in this task, is available in the manual for this task. Here's a very basic minimal example of one such usage:

<target name="test-basic-fork">
 <junitlauncher>

 <classpath refid="test.classpath"/>
 <test name="org.example.myapp.SampleTest" outputdir="${output.dir}">
 <fork dir="${basedir}">
 <sysproperty key="myapp-system-property" value="hello world!"/>
 </fork>
 </test>
 </junitlauncher>
</target>

The example above, sets up "junitlauncher" task to launch a test class named "org.example.myapp.SampleTest" in a forked JVM. The "fork" element in the example above is configured to setup a Java system property named "myapp-system-property" with a value of "hello world!". When the test executes, this Java system property will be made available to this test or any other class being executed in that forked JVM. More advanced ability of the "fork" element is explained in the manual linked previously.

New jmod and link tasks for Java 9+ tools

Java 9 shipped with a new modular ecosystem. This also brought in new tools to create and manage the Java modules. In this release of Ant 1.10.6, we introduce new tasks - "jmod" and "link", which can be used to create Java modules and then assemble them to create custom JVM runtime images. More details about these tasks can be found in their manuals here and here. A big thanks to Craig Pell who contributed these valuable tasks. More Java 9+ enhancements are being worked upon in Ant and we plan to make them available in future releases.

Please do download this new version of Ant and provide us feedback, suggestions in our user mailing list.
Jaikiranhttp://firstname.lastname@example.com:blogger.com,1999:blog-30587633.post-35740398392544995892018-08-27T10:47:00.000+05:302018-08-27T10:47:09.158+05:30Java 11 release candidate now available - time to try it out
The Java language development team has just released a release candidate build for Java 11, last week.

Java 11 release brings in good number of new features as noted at http://openjdk.java.net/projects/jdk/11/#Features. Personally, the TLS 1.3 and the HTTP client API are of special interest to me. Given the nature of changes in this version, it's important to try out this release candidate to make sure that these changes don't cause regressions or introduce change in semantics or features that your application or framework relies on. So this is a good time to try out this build and provide your feedback to the team.

The release can be downloaded from http://jdk.java.net/11/. Any issues, feedback and suggestions can be provided by following the process noted in the "Feedback" section on that downloads page.

Jaikiranhttp://email@example.com:blogger.com,1999:blog-30587633.post-81162631370754234892018-07-16T12:27:00.000+05:302018-07-16T12:27:49.772+05:30Apache Ant 1.9.13 and 1.10.5 released - Supports Java 11 single-file source programs
We just released 1.9.13 and 1.10.5 versions of Apache Ant. As usual, you can download it from the Ant project download page.

Both these versions are mainly bug fix releases. The 1.10.5 version however has a new enhancement to the "java" task. As I blogged previously - Java 11 introduces a new feature where you can execute single-file Java programs without having to explicitly compile them first. Ant 1.10.5 release now supports this feature through a new "sourcefile" attribute in the "java" task. More about it can be found the manual of that task.

A simple usage example of this new feature of the "java" task is as follows:

<project default="launch-java" name="Java 11 - launch single-file source program">

 <target name="launch-java"
 description="Simple example of single-file source program execution,
 introduced in Java 11">

 <condition property="java11">
 <javaversion atleast="11"/>
 </condition>
 <fail unless="java11">Java 11 runtime version is necessary to run this example</fail>

 <mkdir dir="${basedir}/javasource"/>

 <echo file="${basedir}/javasource/HelloWorld.java">
 import java.nio.file.Files;
 import java.nio.file.Paths;
 import java.io.BufferedWriter;
 public class HelloWorld {
 public static void main(String[] args) throws Exception {
 System.out.println("Hello world, " + args[0] + "!");
 }
 }
 </echo>

 <java sourcefile="${basedir}/javasource/HelloWorld.java" fork="true" failonerror="true" logerror="true">
 <arg value="Java 11"/>
 </java>
 </target>
</project>

As you'll notice, the build file uses the "java" task to set the "sourcefile" attribute to point to a Java source file. The rest of the usage details of the "java" task, including passing arguments to the program, continue to remain the same as before.

When you run "ant" on this build file, you should see the following output:

[java] Hello world, Java 11!

Of course, you will need to use a Java 11 binary to run this against. You can get the early accessible Java 11 binary from here.

Jaikiranhttp://email@example.com:blogger.com,1999:blog-30587633.post-68120251699189813642018-07-13T18:30:00.002+05:302018-07-13T19:01:25.661+05:30Java 11 upcoming features - Launch Single-File source programs

Java 11 is nearing completion and it's entered the rampdown phase. It almost feels like a few weeks back that Java 9 was released and here we are, within a few months of Java 11 being released. Given the new release process and timelines for Java, this will become a common thing. Whether that's a good thing or not, we'll keep it aside.

The changes coming in Java 11 are listed here. These are some nice enhancements and features coming in this release. Two of them that I'm really excited about are:

 - HTTP client (standard) http://openjdk.java.net/jeps/321 which will bring in HTTP client APIs as part of the Java language.
 - Launch Single-File Source-Code Programs http://openjdk.java.net/jeps/330

In this article, I will go through the "Launch Single-File Source-Code Programs" feature. What this enhancement proposes to accomplish is to make it easy for running Java code which consists of a single file with the "main()" method in it.

Imagine you have a simple HelloWorld program as follows in a file HelloWorld.java under org/myapp directory:

package org.myapp;

public class HelloWorld {

 public static void main(String[] args) throws Exception {
 System.out.println("Hello World!");
 }
}

Right now, without the proposed feature, in order to run this program, the user has to first compile it using javac command:

javac org/myapp/HelloWorld.java

Once that succesfully compiles, you then run the java command to execute the program:

java org.myapp.HelloWorld

So it's a 2 step process. It looks trivial even for beginners, but it can still be made simpler not just for beginners but even developers who regularly work with Java.

Once Java 11 gets released (or if you want to try it now, you can get the early access builds from http://jdk.java.net/11/) we can run the above program as follows (as a single command):

java org/myapp/HelloWorld.java

Notice the difference here:
 1. one, we no longer use the javac command to explicitly compile the source
 2. The java command is now passed the path to the source file (org/myapp/HelloWorld.java) instead previously where we used to pass it the fully-qualified classname.

This difference is minor but important, since the java command now "understands" that it now has to internally do whatever it's necessary (like compiling the source) when it's passed a file path whose file name ends with the .java extension. Of course, such a file is expected to contain regular/valid Java code with a top level class exposing the "public static void main(String[])" method.

Furthermore, just like your regular Java programs you can continue to pass application specific arguments to the program as before. For example, for a calculator program which looks below, in a org/myapp/Calculator.java file:

package org.myapp;

public class Calculator {

 public static void main(final String[] args) throws Exception {
 final int sum = Integer.parseInt(args[0]) + Integer.parseInt(args[1]);
 System.out.println(args[0] + " + " + args[1] + " = " + sum);
 }
}

you can pass the program arguments as follows:

java org/myapp/Calculator.java 2 4

where 2 and 4 are passed as the program arguments and you would see the output as follows:

2 + 4 = 6

This feature also adds support for "shebang" files, files which are expected to hava valid Java code plus a "shebang". Personally, I'm not too fond of this specific aspect of the feature. However, the good thing is, the JDK team took feedback from the community and made this additional aspect of a feature, non-intrusive (for tools/commands which already deal with Java source files) and something that some of us can ignore if we don't want to use it. The details of when/how to use the "shebang" files for this feature are explained in the linked JEP-330.

So far, although Java 11 hasn't been released, I have been using the early access builds and extensively using this feature for some of my regular work which sometimes involves coming up with short programs that help reproduce an issue. I usually don't use IDEs for things like these, so it's been a welcome enhancement to be able to issue a single command against such files and have them executed.

Jaikiranhttp://email@example.com:blogger.com,1999:blog-30587633.post-73862082640067147892018-05-14T10:50:00.000+05:302018-05-14T12:05:46.673+05:30Apache Ivy 2.5.0-rc1 released - Now allows timeouts on resolvers
A few weeks back, we released the 2.5.0-rc1 version of Apache Ivy. Apache Ivy is a dependency management build tool, which usually is a used in combination with Apache Ant. The download is available on the project download page

This release is significant since the last release of Apache Ivy was way back in December 2014. So it's more than 3 years since the last official years. During these past few years, the project development stalled for a while. I use Apache Ivy in some of our projects and have been pretty happy with the tool. It's never a good sign to see one of your heavily used tools to be no longer under development or even have bug fixes. So a year or so back, I decided to contribute some bug fixes to the project. Over time, the project management committee invited me to be part of the team.

We decided that the first obvious, immediate goal would be to revive the project and do a formal release with bug fixes. This 2.5.0-rc1 is the result of that effort which started almost a year back. A lot of changes have gone into this release and also a good number of enhancements have made it into this release. This release has been a result of contributions from various different members from the community. The complete list of release notes is available here

We intentionally named this release 2.5.0-rc1 (release candidate) since it's been a while we have done an official release and also given the nature of changes. Please give this release a try and let us know how it goes. Depending on the feedback, we will either release 2.5.0 or 2.5.0-rc2. As usual, some of us from the development team keep an active watch in the ivy user mailing list. So if you have any feedback or questions, please do drop a mail to us, there.

Now coming to one of the enhancements in this release - there's been more than one. One of the issues I personally had was if the repository, backing a dependency resolver configured for Ivy, had some connectivity issues, the build would just hang. This was due to the inability to specify proper timeouts for communicating with these repositories through the resolver. As of this release, Ivy now allows you to configure timeouts for resolvers. This is done through the use of (the new) timeout-constraints element in your Ivy settings file. More details about it are here. Imagine you have a url resolver which points to some URL. The URL resolver would typically look something like:

<url name="foo">
 <ivy pattern=.../>
 <artifact pattern=.../>
 <artifact pattern=.../>
</url>

Let's now try and configure a connection timeout for this resolver. The first thing you would do is define a named timeout-constraint, like below:

<timeout-constraints>
 <timeout-constraint name="timeout-1" connectionTimeout="60000" />
</timeout-constraints>

The value for the name attribute can be anything of your choice. The value for connectionTimeout attribute is represented as a timeout in milli seconds. In the above example, we configure the "timeout-1" timeout-constraint to be of 1 minute. You can even specify a readTimeout which too is in milli seconds. More about this element can be found in the documentation.

As you might notice, we have just defined a timeout-constraint here but haven't yet instructed Ivy to use this constraint for some resolver. We do that in the next step, where we set the "timeoutConstraint" attribute on the URL resolver that we had seen before:

<url name="foo" timeoutConstraint="timeout-1">
 <ivy pattern=.../>
 <artifact pattern=.../>
 <artifact pattern=.../>
</url>

Notice that the value of "timeoutConstraint" attribute now points to "timeout-1" which we defined to have a 1 minute connection timeout. With this, when this URL resolver gets chosen by Ivy for dependency resolution, this connection timeout will be enforced and if the connections fails to be established within this timeout, then an exception gets thrown instead of the build hanging forever.

Although the example uses a URL resolver to setup the timeout constraint, this feature is available for all resolvers that are shipped out of the box by Ivy. So you can even use it with the ibiblio resolver (which communicates with Maven central) too.

Like I noted earlier, please do give this release a try and let us know how it goes.

Jaikiranhttp://email@example.com:blogger.com,1999:blog-30587633.post-75924044268686235082018-05-11T20:48:00.002+05:302018-05-11T20:48:49.214+05:30VMWare vijava - The curious case of "incorrect user name or password" exception
In one of the projects I have been involved in, we use yavijava (which is a fork of vijava) library to interact with vCenter which hosts our VMs. vCenter exposes various APIs through their webservice endpoints which are invoked through HTTP(s). The yavijava library has necessary hooks which allows developers to use a HTTP client library of their choice on the client side to handle invocations to the vCenter.

In our integration, we plugged in the Apache HTTP client library, so that the yavijava invocations internally end up using this HTTP library for interaction. Things mostly worked fine and we were able to invoke the vCenter APIs. I say mostly, because every once in a while we kept seeing exceptions like:

InvalidLogin : Cannot complete login due to an incorrect user name or password.

This was puzzling since we were absolutely sure that the user name and password we use to interact with the vCenter was correct. Especially since all of the previous calls were going through fine, before we started seeing these exceptions.

The exception stacktrace didn't include anything more useful and neither did any other logs. So the only option that I was left with was to go look into the vCenter (server side) event logs to see if I can find something. Luckily, I had access to a setup which had a vSphere client, which I then used to connect to the vCenter. The vSphere client allows you to view the event logs that were generated on the vCenter.

Taking a look at the logs, showed something interesting and useful. Every time, we had run into this "incorrect user name or password" exception on the client side, there was a corresponding event log on the vCenter server side at INFO level which stated "user cannot logon since user is already logged on". That event log was a good enough hint to give an idea of what might be happening.

Based on that hint, the theory I could form was, somehow for an incoming (login) request, vCenter server side notices something on the request which gives it an impression that the user is already logged in. Given my background with Java EE technologies, the immediate obvious thing that came to mind was that the request was being attached with a "Cookie" which the server side uses to associate requests against a particular session. Since I had access to the client side code which was issuing this login request, I was absolutely sure that the request did not have any explicitly set Cookie header. So that raised the question, who/where the cookie was being associated with the request. The only place that can happen, if it's not part of the request we issued, is within the HTTP client library. Reading up the documentation of Apache HTTP client library confirmed the theory that the HTTP client was automagically associating a (previously generated) Cookie against the request.

More specifically, the HTTP client library uses pooled connections. When a request is made, one of the pooled connections (if any) gets used. What was happening in this particular case was that, a previous login would pick up connection C1 and the login would succeed. The response returned from vCenter for that login request would include a Cookie set in the response header. The Apache HTTP client library was then keeping track of this Cookie against the connection that was used. Now when a subsequent login request arrived, if the same pooled connection C1 gets used for this request, then the HTTP client library was attaching the Cookie that it kept track against this connection C1, to this new request. As a result, vCenter server side ends up seeing that the incoming login request has a Cookie associated with it, which says that there's already a logged in session for that request. Hence, that INFO message in the event logs of vCenter. Of course, the error returned isn't that informative and in fact a bit misleading since it says the username/password is incorrect.

Now that we know what's going on, the solution was pretty straightforward. Apache HTTP client library allows you to configure Cookie policy management. Since in our case, we wanted to handle setting the Cookie explicitly on the request, we decided to go with the "ignoreCookies" policy which can be configured on the HTTP client. More about this can be found in the HTTP client library documentation (see the "Manual Handling of Cookies" section). Once we did this change, we no longer saw this exception anymore.

There isn't much information about this issue anywhere that I could find. The closest I could find was this forum thread https://sourceforge.net/p/vijava/discussion/826592/thread/91550e2a/. It didn't have a conclusive solution, but it does appear that it's the same issue that the user there was running into (almost 7 years back!)

Jaikiranhttp://firstname.lastname@example.com:blogger.com,1999:blog-30587633.post-6904737586727848572018-03-28T14:51:00.001+05:302018-03-28T14:51:49.920+05:30Ant 1.10.3 released with JUnit 5 support
We just released 1.9.11 and 1.10.3 versions of Ant today. The downloads are available on the Ant project's download page. Both these releases are mainly bug fix releases, especially the 1.9.11 version. The 1.10.3 release is an important one for a couple of reasons. The previous 1.10.2 release, unintentionally introduced a bunch of changes which caused regressions in various places in Ant tasks. These have now been reverted or fixed in this new 1.10.3 version.

In addition to these fixes, this 1.10.3 version of Ant introduces a new junitlauncher task. A while back, the JUnit team has released JUnit 5.x version. This version is a major change from previous JUnit 3.x & 4.x versions, both in terms of how tests are written and how they are executed. JUnit 5 introduces a separation between test launching and test identification and execution. What that means is, for build tools like Ant, there's now a clear API exposed by JUnit 5 which is solely meant to deal with how tests are launched. Imagine something along the lines of "launch test execution for classes within this directory". Although Ant's junit task already supported such construct, the way we used to launch those tests was very specific to Ant's own implementation and was getting more and more complex. With the introduction of this new API within the JUnit 5 library, it's much more easier and consistent now to launch these tests.

JUnit 5, further introduces the concept of test engines. Test engines are responsible for "identifying" which classes are actually tests and what semantics to apply to those tests. JUnit 5 by default comes with a "vintage" engine which identifies and runs JUnit 4.x style tests and a "jupiter" engine which identifies and runs JUnit 5.x API based tests.

The "junitlauncher" task in Ant introduces a way to let the build specify which classes to choose for test launching. The goal of this task is to just launch the test execution and let the JUnit 5 framework identify and run the tests. The current implementation shipped in Ant 1.10.3, is the basic minimal for this task. We plan to add more features as we go along and as we get feedback on it. Especially, this new task doesn't currently support executing these tasks in a separate forked JVM, but we do plan to add that in a subsequent release.

The junit task which has been shipped in Ant since long time back, will continue to exist and can be used for executing JUnit 3.x or JUnit 4.x tests. However, for JUnit 5 support, the junitlauncher task is what will be supported in Ant.

More details about this new task can be found in the junitlauncher's task manual. Please give it a try and report any bugs or feedback to our user mailing list.
Jaikiranhttp://email@example.com:blogger.com,1999:blog-30587633.post-82909085297875685092018-02-20T10:15:00.000+05:302018-02-20T11:03:08.505+05:30WildFly 12.0.0.Beta1 tagged and available
WildFly 12.0.0.Beta1 has been tagged and has been (I think) officially released. The announcement happened a few days back in the dev mailing list and unlike the previous releases, this time the release binaries seem to be only available in Maven repository and can be obtained from here - WildFly 12.0.0.Beta1 distribution (the .tar.gz and .zip are the relevant ones). The list of changes for this release can be found in the JIRA release notes.

As you'll notice in the release notes, there's some initial support for EE 8 specs, including Servlet 4.0 among others. Plus there's also numerous bug fixes in this release from the previous 11.0.0.Final version which was released some months back. As usual, please give this version a try and if there are any issues or feedback that you would like to report, please start a discussion in the WildFly user forum

If you haven't been following the WildFly dev mailing list, there's also a discussion which outlines the release plans for WildFly going forward. You can find that discussion here

Finally, there's been major changes to Java EE processes and committee and even the name, over the past year. If you haven't been following those changes, then you can read through Mark Little's recent blogs including the most recent ones which talk about the new brand name for Java EE and setting up of the working group.

Jaikiranhttp://firstname.lastname@example.com:blogger.com,1999:blog-30587633.post-50082480019953527472018-02-07T17:32:00.000+05:302018-02-07T17:43:53.095+05:30Apache Ant new versions (1.9.10 and 1.10.2) released
This past year has been pretty hectic, so I haven't had a chance to update this blog more often.

In my limited spare time last year, I started contributing to Apache Ant project. Although Ant probably isn't as widely used as some years back, it still is used in many projects, as the build tool. Some of the products I'm involved in, does use Ant and that motivated me to contribute to some bug fixes in Ant. After a period of time, last year, I was invited to be a committer and a few weeks back, to be part of the Ant project management committee (PMC), which I consider a honour.

Just today, we released a couple of new versions of Ant - 1.9.10 and 1.10.2. These are essentially bug fix releases but do contain some new enhancements. The complete release notes, for each of these releases, can be found here and here.

The downloads are available from the project's download page and the full announcement, in the mailing list, can be read here

If you have any issues/suggestions/feedback about the project, feel free to report it in the user mailing list which is listed on this page.

Jaikiranhttp://email@example.com:blogger.com,1999:blog-30587633.post-62493509174900030222017-10-30T13:14:00.000+05:302017-11-11T13:00:05.830+05:30Kafka with OpenSSL

UPDATE: This article has been updated on Nov 11th 2017 with the following details:

Updated to note that the issues linked in this article, related to WildFly OpenSSL, have all been fixed and the WildFly OpenSSL master branch now has the version which contains these fixes. The numbers that you see in this article, include those fixes.

Updated to add a section which lists the producer and consumer numbers when Java 9 runtime is used, for both the SSL engine shipped by JRE as well as the OpenSSL one.

Updated to note that the version of Kafka used is 1.0.0 (which was released recently)

In one of the products I'm involved in, we use Kafka extensively. We have been using Kafka since 0.8.x days. If you follow the Kafka development, you might be aware that they are about to release their 1.0.0 version very soon. Kafka allows you to use SSL for both producing and consuming messages. Both the Kafka broker and the client libraries are configurable to specify the necessary SSL characteristics. Within our own product, we use Java client side libraries for consuming and producing messages. Their Java client side libraries have gone through a phase of API changes a while back in one of their releases. We use their "new" Java client APIs.

We started experimenting with using SSL for producing and consuming messages in Kafka, more than a year back. Our initial experiments showed that switching to SSL instead of using plaintext had a noticeable impact on performance. Given the way we use Kafka within our product, even some consistent (milli seconds) degradation in latency is almost noticeable. It's a acceptable and a known fact that you do incur certain performance impact when you are using SSL. However, the amount of degradation was to a point that we decided not to switch to SSL for a while. There have been discussions and JIRAs like this one where such impact has been tracked. Things have definitely improved since that JIRA (we are on 0.10.x release these days), but we didn't have enough time to get some numbers with SSL enabled within our environment.

A small detour
With that background, let me take a small detour from Kafka discussions. I also follow WildFly and various other projects in its ecosystem. Very recently, WildFly added support for using OpenSSL as a SSL provider instead of the one that's shipped as part of the JRE. As part of that support, they use WildFly OpenSSL project, which provides Java bindings (the implementation of interfaces necessary to use it as a SSLEngine in Java) for OpenSSL. Given that Java has a plugable mechanism for SSL providers and that fact that Kafka allows you to configure such SSL configurations, the WildFly OpenSSL project interested me.

Using Kafka with WildFly OpenSSL
I vaguely remember reading in some discussions that OpenSSL performs better compared to the SSL provider shipped in Java. So I decided to experiment with using WildFly OpenSSL with Kafka and compare it with the SSL provider shipped in Java. My goals of this experiment were pretty much these:

Use SSL for producing and consuming messages in Kafka

Compare OpenSSL against the SSL provider shipped in Java

Use the default settings that's shipped in Kafka for this performance testing. In fact, Kafka developers encourage you to use the defaults in performance testing as much as possible.

Use the tools shipped within Kafka for testing this performance. Kafka ships both producer and consumer performance testing tool, which is good enough for what we are after. Using their own tools, rules out any issues that I might end up with in the tool that I write for these tests (I did in fact write one of my own, just for the sake of it, but decided to stick with the ones shipped in Kafka since it pretty much ended up being similar both in terms of code and the output it produced)

I would like to note that it wasn't ever a goal for me, in these experiments to compare plain text and SSL numbers. This experiment is solely to see how different SSL providers are performing.

Setting up the system for the tests

Kafka installation

I decided to use the latest version of Kafka. The latest released version currently is 1.0.0 and I downloaded it from their downloads page. Kafka installation is straightforward, you just extract the downloaded archive and can straightaway boot it up and start consuming and producing messages. I won't go into any of the installation details of Kafka since that's out of the scope of this installation. I will go into the configurations that I used as we go along.

WildFly OpenSSL installation

I use MacOS for development and will be using this for my tests. In order to use WildFly OpenSSL, I went ahead and cloned the github repo. Ran into a build issue, but it was a straightforward fix for which there's now a pull request with a fix. I then setup Kafka to use WildFly OpenSSL and started experimenting. This set of experiments was just to make sure that it's usable without impacting any functionality. I did run into an issue which turned out to be an issue in WildFly OpenSSL which is now reported here. This issue has now been fixed and pushed to the WildFly OpenSSL upstream repo.

The README of that project already has the necessary instructions to build it, so I won't get into those details.

Java installation

I use the Oracle JRE 1.8 version for these tests:

java version "1.8.0_131"

Java(TM) SE Runtime Environment (build 1.8.0_131-b11)

Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

OpenSSL installation

In this experiments I'm going to use 1.1 version of OpenSSL. I installed it through homebrew and it's available at /email@example.com/bin/openssl. The exact version is:

/email@example.com/bin/openssl

OpenSSL> version

OpenSSL 1.1.0f 25 May 2017

Putting it all together

I built my WildFly OpenSSL libraries and copied over the java/target/wildfly-openssl-java-1.0.3.Final-SNAPSHOT.jar and macosx-x86_64/target/wildfly-openssl-macosx-x86_64-1.0.3.Final-SNAPSHOT.jar into the <kafka-install-dir>/libs/ folder. These are the 2 jars that contain the necessary WildFly OpenSSL support (depending on what OS you are on, you might need a different jar).</kafka-install-dir>

Given that I was going to use WildFly OpenSSL in multiple different tools which have their own different "main" classes, I decided to write a extremely basic Java agent which would just register WildFly OpenSSL as a provider. I then just pass -javaagent:<path-to-my-javaagent-jar> as a JVM option to each of the tools/scripts I use for these tests. The code in my Java agent is pretty straight forward:</path-to-my-javaagent-jar>

public class OpenSSLEnabler {

 public static void premain(final String agentArgs) throws Exception {
 try {
 org.wildfly.openssl.OpenSSLProvider.register();
 } catch(Exception e) {
 System.err.println("Failed to register WildFly OpenSSL provider");
 e.printStackTrace();
 }
 }
}

I setup the following as an environment variable to make sure this Java agent is picked up as well as OpenSSL 1.1 is used for these tests (when I enable OpenSSL as the provider):

 export KAFKA_OPTS="-javaagent:/opt/installations/kafka/1.0.0.RC4/kafka_2.12-1.0.0/libs/wildfly-openssl-javaagent-1.0.0-SNAPSHOT.jar -email@example.com/lib/"

Note: The wildfly-openssl-javaagent-1.0.0-SNAPSHOT.jar is the jar containing the Java agent class that I explained above and the -Dorg.wildfly.openssl.path system property is to ensure that WildFly OpenSSL uses this specific OpenSSL installation (when I enable OpenSSL as the provider).

Performance tests details

The first round of testing will be using the SSL provider shipped in Java. We will use the kafka-producer-perf-test.sh and kafka-consumer-perf-test.sh scripts that are shipped by Kafka itself (they are available in the bin directory of your Kafka installation).

The second round of testing will be using OpenSSL provider backed by WildFly OpenSSL. In these tests too we will use kafka-producer-perf-test.sh and kafka-consumer-perf-test.sh scripts.

Kafka Broker and topics

In my test I'm going to create 3 topics, each with a replication factor of 1 and with partition count 1. The topics will be called kafka-ssl-perf-test-1k, kafka-ssl-perf-test-10k and kafka-ssl-perf-test-500k:

./kafka-topics.sh --create --topic kafka-ssl-perf-test-1k --partitions=1 --replication-factor=1 --zookeeper=localhost:2181

./kafka-topics.sh --create --topic kafka-ssl-perf-test-10k --partitions=1 --replication-factor=1 --zookeeper=localhost:2181

./kafka-topics.sh --create --topic kafka-ssl-perf-test-500k --partitions=1 --replication-factor=1 --zookeeper=localhost:2181

Producer tests

The producer will run with --record-size of 1024, 10240 and 512000 in 3 separate runs. Each run will generate --num-records 10000 with the respective size. Our usage of Kafka typically generates messages of lesser than 10K, so I decided to not stretch the tests for too large messages. In my test, I will use the kafka-ssl-perf-test-1k topic for 1024 sized messages, kafka-ssl-perf-test-10k for 10240 sized messages and kafka-ssl-perf-test-500k for 512000 sized messages.

Consumer tests

The consumer will be consuming (all) 10000 messages of each of these topics, in 3 separate runs. I used `--new-consumer` option for these tests since that's what we use in our application, through the Java client APIs.

Java default SSL run

As noted, by default, Kafka uses the SSL provider shipped in JRE. So it isn't necessary to configure the provider specifically. However, we will configure a few other configurations to enable SSL itself (by default Kafka uses plain text). So the broker configs that I added/changed are these, in $KAFKA_HOME/config/server.properties:

listeners=PLAINTEXT://localhost:9092,SSL://localhost:9093
ssl.keystore.location=/opt/kafka-experiments/ssl-certs/keystore.jks
ssl.keystore.password=password
ssl.key.password=password
ssl.truststore.location=/opt/kafka-experiments/trust-certs.jks
ssl.truststore.password=password
ssl.protocol=TLSv1.2

The rest of the configurations are unchanged and the ones default shipped by Kafka. As you see above, the main configurations are enabling SSL and using 9093 as the port for SSL communication and using TLSv1.2 as the SSL protocol.

Start Zookeeper and Kafka broker

cd <kafka-install-dir>/bin/
nohup ./zookeeper-server-start.sh ../config/zookeeper.properties &
nohup ./kafka-server-start.sh ../config/server.properties &</kafka-install-dir>

Run the producer perf test script

We'll pass the following producer configs (through a kafka-jre-ssl-producer.properties) to these runs:

bootstrap.servers=localhost:9093
security.protocol=SSL
ssl.protocol=TLSv1.2
ssl.truststore.location=/opt/kafka-experiments/trust-certs.jks
ssl.truststore.password=password

These configurations just enable SSL (and by default uses the JRE shipped SSL provider) with TLSv1.2 as the protocol on 9093 port.

1024 sized message

./kafka-producer-perf-test.sh --record-size 1024 --num-records 10000 --topic kafka-ssl-perf-test-1k --producer.config ./kafka-jre-ssl-producer.properties --throughput -1 > producer-jre-ssl-1k.txt

10240 sized message

./kafka-producer-perf-test.sh --record-size 10240 --num-records 10000 --topic kafka-ssl-perf-test-10k --producer.config ./kafka-jre-ssl-producer.properties --throughput -1 > producer-jre-ssl-10k.txt

512000 sized message

./kafka-producer-perf-test.sh --record-size 512000 --num-records 10000 --topic kafka-ssl-perf-test-500k --producer.config ./kafka-jre-ssl-producer.properties --throughput -1 > producer-jre-ssl-500k.txt

Note: I have the performance numbers in a table, later in this blog.

Run the consumer perf test script

We'll pass the following consumer configs (through a kafka-jre-ssl-consumer.properties) to these runs:

bootstrap.servers=localhost:9093
security.protocol=SSL
ssl.protocol=TLSv1.2
ssl.truststore.location=/opt/kafka-experiments/trust-certs.jks
ssl.truststore.password=password

Just like for the producer, these configurations enable SSL and use the default JRE provider with TLSv1.2. We will be consuming of 3 separate topics, each having messages of different sizes that we produced above. Each run uses a different and unique consumer group id.

1024 sized message

./kafka-consumer-perf-test.sh --topic kafka-ssl-perf-test-1k --new-consumer --messages 10000 --broker-list localhost:9093 --consumer.config ./kafka-jre-ssl-consumer.properties --group jre-ssl-1k > consumer-jre-ssl-1k.txt

10240 sized message

./kafka-consumer-perf-test.sh --topic kafka-ssl-perf-test-10k --new-consumer --messages 10000 --broker-list localhost:9093 --consumer.config ./kafka-jre-ssl-consumer.properties --group jre-ssl-10k > consumer-jre-ssl-10k.txt

512000 sized message

./kafka-consumer-perf-test.sh --topic kafka-ssl-perf-test-500k --new-consumer --messages 10000 --broker-list localhost:9093 --consumer.config ./kafka-jre-ssl-consumer.properties --group jre-ssl-500k > consumer-jre-ssl-500k.txt

Just like the producer numbers, I've noted these consumer numbers in a section later in this blog.

WildFly OpenSSL run

Now that we are done with the producer and consumer runs with default JRE SSL, we'll now reconfigure the Kafka broker to use OpenSSL as the provider. We won't be doing any other configuration changes to the broker configs and the producer, consumer configs we use for testing. To give this run the similar characteristics as that of our previous run, I deleted the Kafka and Zookeeper directories that store the Kafka topics. Essentially, this run is going to be from a clean slate. As noted previously, to enable WildFly OpenSSL, I configured the following environment property:

export KAFKA_OPTS="-javaagent:/opt/installations/kafka/1.0.0.RC4/kafka_2.12-1.0.0/libs/wildfly-openssl-javaagent-1.0.0-SNAPSHOT.jar -email@example.com/lib/"

Here's what the relevant broker configs (in server.properties) look like now for OpenSSL:

listeners=PLAINTEXT://localhost:9092,SSL://localhost:9093
ssl.keystore.location=/opt/kafka-experiments/ssl-certs/keystore.jks
ssl.keystore.password=password
ssl.key.password=password
ssl.truststore.location=/opt/kafka-experiments/trust-certs.jks
ssl.truststore.password=password
ssl.provider=openssl
ssl.protocol=TLSv1.2

As you'll notice the only additional configuration here is the ssl.provider=openssl.

We then start zookeeper and the Kafka broker as previously. Remember, we (intentionally) deleted the Kafka directories that held the topics. So we will recreate the necessary topics as we did previously.

Run the producer perf test script

We'll pass the following producer configs (through a kafka-openssl-producer.properties) to these runs:

bootstrap.servers=localhost:9093
security.protocol=SSL
ssl.protocol=TLSv1.2
ssl.provider=openssl
ssl.truststore.location=/opt/kafka-experiments/trust-certs.jks
ssl.truststore.password=password

It's the same as what we used in our previous run, except that we use ssl.provider=openssl.

1024 sized message

./kafka-producer-perf-test.sh --record-size 1024 --num-records 10000 --topic kafka-ssl-perf-test-1k --producer.config ./kafka-openssl-producer.properties --throughput -1 > producer-openssl-1k.txt

Note: You'll see the following log message, which indicates that WildFly OpenSSL is rightly picked up, which then uses the natively installed 1.1.0f version of OpenSSL:

Oct 29, 2017 8:35:25 PM org.wildfly.openssl.SSL init
INFO: WFOPENSSL0002 OpenSSL Version OpenSSL 1.1.0f 25 May 2017

10240 sized message

./kafka-producer-perf-test.sh --record-size 10240 --num-records 10000 --topic kafka-ssl-perf-test-10k --producer.config ./kafka-openssl-producer.properties --throughput -1 > producer-openssl-10k.txt

512000 sized message

./kafka-producer-perf-test.sh --record-size 512000 --num-records 10000 --topic kafka-ssl-perf-test-500k --producer.config ./kafka-openssl-producer.properties --throughput -1 > producer-openssl-500k.txt

Run the consumer perf test script

We'll pass the following consumer configs (through a kafka-openssl-consumer.properties) to these runs:

bootstrap.servers=localhost:9093
security.protocol=SSL
ssl.protocol=TLSv1.2
ssl.provider=openssl
ssl.truststore.location=/opt/kafka-experiments/trust-certs.jks
ssl.truststore.password=password

It's the same as what we used for our consumer run with JRE SSL, except that we set the ssl.provider=openssl in this case.

1024 sized message

./kafka-consumer-perf-test.sh --topic kafka-ssl-perf-test-1k --new-consumer --messages 10000 --broker-list localhost:9093 --consumer.config ./kafka-openssl-consumer.properties --group open-ssl-1k > consumer-openssl-1k.txt

Just like the producer run with OpenSSL, you should see the following log message which confirms that WildFly OpenSSL was picked up for this run:

Oct 29, 2017 8:35:25 PM org.wildfly.openssl.SSL init
INFO: WFOPENSSL0002 OpenSSL Version OpenSSL 1.1.0f 25 May 2017

10240 sized message

./kafka-consumer-perf-test.sh --topic kafka-ssl-perf-test-10k --new-consumer --messages 10000 --broker-list localhost:9093 --consumer.config ./kafka-openssl-consumer.properties --group openssl-10k > consumer-openssl-10k.txt

512000 sized message

./kafka-consumer-perf-test.sh --topic kafka-ssl-perf-test-500k --new-consumer --messages 10000 --broker-list localhost:9093 --consumer.config ./kafka-openssl-consumer.properties --group openssl-500k > consumer-openssl-500k.txt

Final numbers (Java 8)

So let's now jump to the numbers, that we captured, from the above runs. The following is producer and consumer numbers for various message sizes that we tried above with JRE SSL and OpenSSL:

Producer Stats:

 Producer Stats	 Message size 1024	 Message size 10240	 Message size 512000

 	 JRE SSL	 OpenSSL	 JRE SSL	 OpenSSL	 JRE SSL	 OpenSSL

 Records/sec	 10857.76	 14306.15	 2232.64	 2645.50	 181.41	 430.45

 MB/sec	 10.60	 13.97	 21.80	 25.83	 88.58	 210.19

 Avg. Latency (ms)	 337.01	 222.05	 776.62	 659.71	 361.02	 151.50

 Max. Latency (ms)	 568.00	 387.0	 1050.00	 887.00	 618.00	 282.00

 50th % latency (ms)	 351	 236	 814	 690	 356	 146

 95th % latency (ms)	 548	 369	 933	 808	 381	 183

 99th % latency (ms) 	 565	 384	 1016	 870	 522	 235

 99.9th % latency (ms)	 568	 387	 1046	 885	 561	 262

Consumer Stats:

 Consumer Stats	 Message size 1024	 Message size 10240	 Message size 512000

 	 JRE SSL	 OpenSSL	 JRE SSL	 OpenSSL	 JRE SSL	 OpenSSL

 Data consumed MB	 9.7656	 9.7656	 97.6563	 97.6563	 4882.8125	 4882.8125

 MB/sec	 16.5239	 24.5986	 50.4423	 97.2672	 86.8797	 250.4263

 Total consumed messages	 10000	 10000	 10000	 10000	 10000	 10000

 Num messages/sec	 16920.4738	 25188.9169	 5165.2893	 9960.1594	 177.9296	 512.8731

 Rebalance time (ms)	 29	 17	 31	 16	 29	 17

 Fetch time (ms)	 562	 380	 1905	 988	 56173	 19481

 Fetch MB/sec	 17.3766	 25.6990	 51.2631	 98.8424	 86.9245	 250.6449

 Fetch messages/sec	 17793.5943	 26315.7895	 5249.3438	 10121.4575	 178.0215	 513.3207

Summary (Java 8)
The above tables show that OpenSSL (backed by WildFly OpenSSL) out-performs the SSL provider shipped in the JRE, in both producer and consumer metrics recorded by the Kafka performance scripts. This by no means is a fine tuned performance testing or any kind of benchmark. The whole goal of this exercise was to see if it was worth the efforts to try and use OpenSSL (backed by WildFly OpenSSL) with Kafka. If the numbers/differences weren't as prominent as they are here, it wouldn't have been worth it. But as you see, the numbers show drastic improvements with WildFly OpenSSL and are promising enough to let us experiment more with OpenSSL.

Performance when using Java 9

I (and few other folks) were curious what kind of numbers we get when this same test was run with Java 9 as the runtime environment. Java 9 has some known performance improvements around SSL (like this), so I ran the entire set of tests (producer and consumer with both JRE shipped SSLEngine and WildFly OpenSSL) with Java 9 runtime. Just like for Java 8, I used the out-of-the-box settings for Kafka as well as Java 9 itself. The same set of instructions, noted previously in this article, were followed as for Java 8 to run these tests. The exact Java 9 version that was used is:

java version "9.0.1"

Java(TM) SE Runtime Environment (build 9.0.1+11)

Java HotSpot(TM) 64-Bit Server VM (build 9.0.1+11, mixed mode)

Producer Stats (Java 9)

 Producer Stats	 Message size 1024	 Message size 10240	 Message size 512000

 	 JRE-9 SSL	 OpenSSL	 JRE-9 SSL	 OpenSSL	 JRE-9 SSL	 OpenSSL

 Records/sec	 11481.05	 14265.33	 2480.77	 2760.14	 437.34	 494.07

 MB/sec	 11.21	 13.93	 24.23	 26.95	 213.55	 241.25

 Avg. Latency (ms)	 341.45	 227.38	 702.48	 636.20	 148.82	 132.03

 Max. Latency (ms)	 529.00	 403.00	 1009.00	 854.00	 691.00	 269.00

 50th % latency (ms)	 358	 236	 709	 634	 138	 122

 95th % latency (ms)	 513	 389	 885	 775	 198	 193

 99th % latency (ms) 	 526	 401	 987	 834	 310	 228

 99.9th % latency (ms)	 529	 402	 1007	 853	 645	 249

Consumer Stats (Java 9)

 Consumer Stats	 Message size 1024	 Message size 10240	 Message size 512000

 	 JRE-9 SSL	 OpenSSL	 JRE-9 SSL	 OpenSSL	 JRE-9 SSL	 OpenSSL

 Data consumed MB	 9.7656	 9.7656	 97.6563	 97.6563	 4882.8125	 4882.8125

 MB/sec	 13.3593	 24.1723	 66.6141	 89.5108	 233.0253	 247.7076

 Total consumed messages	 10000	 10000	 10000	 10000	 10000	 10000

 Num messages/sec	 13679.8906	 24752.4752	 6821.2824	 9165.9028	 477.2358	 507.3052

 Rebalance time (ms)	 30	 18	 31	 18	 28	 17

 Fetch time (ms)	 701	 386	 1435	 1073	 20926	 19695

 Fetch MB/sec	 13.9310	 25.2995	 68.0531	 91.0123	 233.3371	 247.9214

 Fetch messages/sec	 14265.3352	 25906.7358	 6968.6411	 9319.6645	 477.8744	 507.7431

Summary (Java 9)

In the above numbers you'll notice that:

Both for producer and consumer, there's a drastic improvement in the JRE shipped SSLEngine numbers, in almost all metrics, in Java 9 as compared to its counterpart in Java 8. It's especially prominent in messages with higher sizes.

There's not much difference in the numbers for WildFly OpenSSL, in Java 9, as compared to its Java 8 counterpart. In fact, the consumer performance numbers of WildFly OpenSSL in Java 9 have dropped slightly when compared to Java 8. The producer performance in Java 9 with WildFly OpenSSL have however improved slightly when compared to Java 8.

When the numbers of producer and consumer metrics of WildFly OpenSSL with Java 9 runtime are compared with the JRE shipped SSL engine in Java 9, WildFly OpenSSL still out-performs the one shipped in JRE.

All the configurations, the Java agent code and the output of the runs are available in my github repo here

Jaikiranhttp://email@example.com:blogger.com,1999:blog-30587633.post-14406564098915726472014-12-27T11:16:00.001+05:302014-12-27T11:52:14.881+05:30Remote JMX access to WildFly (or JBoss AS7) using JConsole

One of the goals of JBoss AS7 was to make it much more secure by default, when compared to previous versions. One of the areas which was directly impacted by this goal was that you could no longer expect the server to expose some service on a port and get access to it without any authentication/authorization. Remember that in previous versions of JBoss AS you could access the JNDI port, the JMX port without any authentication/authorization, as long as those ports were opened for communication remotely. Finer grained authorizations on such ports for communications, in JBoss AS7, allows the server to control who gets to invoke operations over that port.

Of course, this is not just limited to JBoss AS7 but continues to be the goal in WildFly (which is the rename of JBoss Application Server). In fact, WildFly has gone one step further and now has the feature of "one single port" for all communication.

JMX communication in JBoss AS7 and WildFly

With that background, we'll now focus on JMX communication in JBoss AS7 and WildFly. I'll use WildFly (8.2.0 Final) as a reference for the rest of this article, but the same details apply (with minor changes) to other major versions of JBoss AS7 and WildFly, that have been released till date.

WildFly server is composed of "subsystems", each of which expose a particular set of functionality. For example, there's the EE subsystem which supports the Java EE feature set. Then there's the Undertow subsystem which supports web/HTTP server functionality. Similarly, there's a JMX subsystem which exposes the JMX feature set on the server. As you all are aware, I'm sure, JMX service is standardly used for monitoring and even managing Java servers and this includes managing the servers remotely. The JMX subsystem in WildFly allows remote access to the JMX service and port 9990 is what is used for that remote JMX communication.

JConsole for remote JMX access against JBoss AS7 and WildFly

Java (JDK) comes bundled with the JConsole tool which allows connecting to local or remote Java runtimes which expose the JMX service. The tool is easy to use, all you have to do is run the jconsole command it will show up a graphical menu listing any local Java processes and also an option to specify a remote URL to connect to a remote process:

# Start the JConsole
$JAVA_HOME/bin/jconsole

Let's assume that you have started WildFly standalone server, locally. Now when you start the jconsole, you'll notice that the WildFly Java process is listed in the local running processes to which you can connect to. When you select the WildFly Java instance, you'll be auto connected to it and you'll notice MBeans that are exposed by the server. However, in the context of this article, this "local process" mode in JConsole isn't what we are interested in.

Let's use the "Remote process" option in that JConsole menu which allows you to specify the remote URL to connect to the Java runtime and username and password to use to connect to that instance. Even though our WildFly server is running locally, we can use this "Remote process" option to try and connect to it. So let's try it out. Before that though, let's consider a the following few points:

Remember that the JMX subsystem in WildFly allows remote access on port 9990

For remote access to JMX, the URL is of the format - service:jmx:[vendor-specific-protocol]://[host]:[port]. The vendor specific protocol is the interesting bit here. In the case of WildFly that vendor-specific-protocol is http-remoting-jmx.

<vendor-specific-protocol><host><port>Remember that WildFly is secure by default which means that just because the JMX subsystem exposes 9990 port for remote communication, it doesn't mean it's open for communication to anyone. In order to be allowed to communicate over this port, the caller client is expected to be authenticated and authorized. This is backed by the "ManagementRealm" in WildFly. Users authenticated and authorized against this realm are allowed access to that port.</port></host></vendor-specific-protocol>

<vendor-specific-protocol><host><port>
Keeping those points in mind, let's first create a user in the Management Realm. This can be done using the add-user command line script (which is present in JBOSS_HOME/bin folder). I won't go into the details of that since there's enough documentation for that. Let's just assume that I created a user named "wflyadmin" with an appropriate password in the Management Realm. To verify that the user has been properly created, in the right realm, let's access the WildFly admin console at the URL http://localhost:9990/console. You'll be asked for username and password for access. Use the same username and password of the newly created user. If the login works, then you are good. If not, then make sure you have done things right while adding the new user (as I said I won't go into the details of adding a new user since it's going to just stretch this article unnecessarily long).

So at this point we have created a user named "wflyadmin" belonging to ManagementRealm. We'll be using this same user account for accessing the JMX service on WildFly, through JConsole. So let's now bring up the jconsole as usual:</port></host></vendor-specific-protocol>
<vendor-specific-protocol><host><port>
</port></host></vendor-specific-protocol>

$JAVA_HOME/bin/jconsole

On the JConsole menu let's again select the "Remote process" option and use the following URL in the URL text box:

service:jmx:http-remoting-jmx://localhost:9990

Note: For JBoss AS 7.x and JBoss EAP 6.x, the vendor specific protocol is remoting-jmx and the port for communication is 9999. So the URL will be service:jmx:remoting-jmx://localhost:9999

In the username and password textboxes, use the same user/pass that you newly created. Finally, click on Connect. What do you see? It doesn't work! The connection fails. So what went wrong?

<vendor-specific-protocol><host><port>Why isn't the JConsole remote access to WildFly not working?</port></host></vendor-specific-protocol>

<vendor-specific-protocol><host><port></port></host></vendor-specific-protocol>
<vendor-specific-protocol><host><port>
You did all the obvious things necessary to access the WildFly JMX service remotely but you keep seeing that JConsole can't connect to it. What could be the reason? Remember, in one of those points earlier, I noted that the "vendor specific protocol" is an interesting bit? We use http-remoting-jmx and that protocol internally relies on certain WildFly/JBoss specific libraries, primarily for remote communication and authentication and authorization. These libraries are WildFly server specific and hence aren't part of the standard Java runtime environment. When you start jconsole, it uses a standard classpath which just has the relevant libraries that are part of the JDK/JRE.

To solve this problem, what you need to do is bring in the WildFly server specific libraries into the classpath of JConsole. Before looking into how to do that, let's see which are the WildFly specific libraries that are needed. All the necessary classes for this to work are part of the jboss-cli-client.jar which is present in JBOSS_HOME/bin/client/ folder. So all we need to do in include this jar in the classpath of the jconsole tool. To do that we use the -J option of jconsole tool which allows passing parameters to the Java runtime of jconsole. The command to do that is:</port></host></vendor-specific-protocol>

$JAVA_HOME/bin/jconsole -J-Djava.class.path=$JAVA_HOME/lib/tools.jar:$JAVA_HOME/lib/jconsole.jar:/opt/wildfly-8.2.0.Final/bin/client/jboss-cli-client.jar

(Note that for Windows the classpath separator is the semi-colon character instead of the colon)

Note, the server specific jar for JBoss AS 7.x and JBoss EAP 6.x is named jboss-client.jar and is present at the same JBOSS_HOME/bin/client directory location.

So we are passing -Djava.class.path as the parameter to the jconsole Java runtime, using the -J option. Notice that we have specified more than just our server specific jar in that classpath. That's because, using the -Djava.class.path is expected to contain the complete classpath. We are including the jars from the Java JDK lib folder that are necessary for JConsole and also our server specific jar in that classpath.

Running that command should bring up JConsole as usual and let's go ahead and select the "Remote process" option and specify the same URL as before:

service:jmx:http-remoting-jmx://localhost:9990

and the same username and password as before and click Connect. This time you should be able to connect and should start seeing the MBeans and others services exposed over JMX.

<vendor-specific-protocol><host><port>How about providing a script which does this necessary classpath setup?</port></host></vendor-specific-protocol>

<vendor-specific-protocol><host><port></port></host></vendor-specific-protocol>
<vendor-specific-protocol><host><port>
Since it's a common thing to try and use JConsole for remote access against WildFly, it's reasonable to expect to have a script which sets up the classpath (as above) and you could then just use that script. That's why WildFly ships such a script. It's in the JBOSS_HOME/bin folder and is called jconsole.sh (and jconsole.bat for Windows). This is just a wrapper script which internally invokes the jconsole tool present in Java JDK, after setting up the classpath appropriately. All you have to do is run:</port></host></vendor-specific-protocol>

$JBOSS_HOME/bin/jconsole.sh

<vendor-specific-protocol><host><port>What about using JConsole from a really remote machine, against WildFly?</port></host></vendor-specific-protocol>

<vendor-specific-protocol><host><port></port></host></vendor-specific-protocol>
<vendor-specific-protocol><host><port>
So far we were using the jconsole tool that was present on the same machine as the WildFly instance, which meant that we have filesystem access to the WildFly server specific jars present in the WildFly installation directory on the filesystem. This allowed us to setup the classpath for jconsole to point to the jar on the local filesystem?

What if you wanted to run jconsole from a remote machine against a WildFly server which is installed and running on a different machine. In that case, your remote client machine won't be having filesystem access to the WildFly installation directory. So to get jconsole running in such a scenario, you will have to copy over the JBOSS_HOME/bin/jboss-cli-client.jar to your remote client machine, to a directory of your choice and then setup the classpath for jconsole tool as explained earlier and point it to that jar location. That should get you access to JMX services of WildFly from jconsole on a remote machine.</port></host></vendor-specific-protocol>

<vendor-specific-protocol><host><port> </port></host></vendor-specific-protocol>

<vendor-specific-protocol><host><port>More questions? </port></host></vendor-specific-protocol>
<vendor-specific-protocol><host><port>If you still have problems getting this to work or have other questions, please start a discussion in the JBoss community forums here https://developer.jboss.org/en/wildfly/content.</port></host></vendor-specific-protocol>
Jaikiranhttp://email@example.com:blogger.com,1999:blog-30587633.post-72685253796623305092014-12-07T13:06:00.000+05:302014-12-07T13:07:31.996+05:30WildFly 8.2.0.Final release - Quick overview of the changes
It's been a while since I last wrote on this blog. Although I have had some topics that I wanted to blog about, I just haven't found enough time to do it. I finally decided to write this up today after I saw a mail from one of the JBoss community members, checking up on why there haven't been any updates here lately (thanks for checking, Bhaskar! :)).

Before I move on to some technical things, a quick personal update - It's now been more than a year now since I changed jobs. I no longer work at Red Hat, JBoss. My (almost) 5 years at JBoss have been very fruitful and I enjoyed being part of the (JBoss AS/WildFly) application server development team. Last year, I decided to move on to something different and the right opportunity came along and I decided to take it up. Some of you know that I've been involved with the JBoss community for longer than the 5 years that I had been employed at Red Hat. I have been a JBoss community member since around 2004/2005, so even though I have moved on from Red Hat, I am still active in the JBoss forums.

Now that you all know what I've been upto, let's move on to some technical things.

WildFly 8.2.0.Final released!

The WildFly team just released the 8.2.0.Final version of WildFly some days back. As usual, it's available for download on the project's download page http://wildfly.org/downloads/. This is mainly a bug fix (plus some features) release in the 8.x series. I for one, was pleased to see this release happen because it allows the community to receive bug fixes on top of 8.1.0.Final release, which has been tested/used in the community for quite some time now. The WildFly team has indicated that this will be the last release in the 8.x series which sounds reasonable, given that the development team has already moved on to work on the 9.x series. It's never easy to work/maintain more than one major version of the code, especially in the context of bug fixes and backward compatibility.

What does WildFly 8.2.0.Final contain?

The complete overview of changes in available in this announcement on Jason's blog http://wildfly.org/news/2014/11/20/WildFly82-Final-Released/. CDI spec upgrade and improved WebSocket support are the main items in terms of feature set. There's also this note in the release notes:

- EJBs in WARs now inherit the WAR security domain

There was a recent forum thread, where one of the users asked what that really means. Here's some background to that change https://issues.jboss.org/browse/WFLY-3102. As noted in that JIRA, this was feature request that was raised in the context of EJBs packaged in .war deployments. Most of you, I guess, will be aware that Java EE spec allows EJBs to be deployed as part of the .war deployment. What this means is that you can place your EJB classes within the .war/WEB-INF/classes or within a jar in .war/WEB-INF/lib. Although, this sounds straightforward for the end users, there are some technical implications to this (given the way Java EE "components" and "modules" are defined and configured within the server ecosystem). One such detail, is the way one configures the EJBs that are part of the .war deployment. Remember that if this EJB was part of a separate EJB module (within a .jar packaging outside of the .war) then one would use the ejb-jar.xml (and the WildFly specific jboss-ejb3.xml) as the deployment descriptors to configure it. This applies to EJBs deployed in a .war deployment too. i.e. one can use those same files for configuring EJBs. Now since these EJBs are part of a .war, the .war itself can/will have a deployment descriptor if its own (the web.xml and jboss-web.xml).

With that context, consider a case where the you have EJBs within the .war deployment and your .war deployment descriptor (the jboss-web.xml) configures a specific security domain for that deployment. Now remember that the EJBs too can configure a security domain (in jboss-ejb3.xml) and if none is configured and security is enabled on some EJBs, then the default "other" security domain gets used. So let's say your .war deployment, in which the EJBs reside, states that it wants to use "foo-bar" security domain and the EJBs, within that deployment, don't specify any specific security domain. So what should one expect in such scenario? Should the EJBs use the security domain configured at the .war level or should they default to the "other" security domain (since the EJB deployment descriptors don't specify any specific security domain configuration). The previous versions of WildFly had decided to use the default "other" security domain for the EJBs in such a case. Of course, the EJBs could use a jboss-ejb3.xml to set a different security domain, one which matches the jboss-web.xml. So that JIRA which I linked to earlier requested for a better, smarter and a more logical default in such cases. So starting this 8.2.0.Final version of WildFly, if you have a .war containing the EJBs and the EJBs don't define a security domain, then the security domain for any secured EJBs in that deployment *defaults* to the one that's defined at the .war deployment level. If the .war deployment doesn't set any specific security domain, then it ultimately, defaults to the "other" security domain. A good and logical change IMO. This will reduce some of the "surprises" that users have reported with previous version of WildFly, when it came to the security domain usage of EJBs in .war deployments.

For more about this, you can read the discussion here https://developer.jboss.org/thread/250375 and ask any questions you have around this, in that thread.

What are the other notable things in WildFly 8.2.0.Final?

Although, not specific to 8.2.0.Final, the WildFly release contain a "patch" distribution which you can use if you already are using WildFly 8.1.0.Final and just want to "upgrade" to this new release. WildFly 8 has patch management built in and one can apply this patch on top of an existing 8.1.0.Final version.

What's next for WildFly?

As noted earlier, the WildFly development team has moved on to the next version of the project. Work is now continuing on 9.x version which already has a Alpha version released. So going forward, from what I have read, the releases will happen in the 9.x series.

Jaikiranhttp://firstname.lastname@example.com:blogger.com,1999:blog-30587633.post-57521433740160612752014-01-22T19:29:00.000+05:302014-01-22T19:45:48.134+05:30WildFly 8.0 CR1 release and WildFly 8 book
I guess by now everyone is aware that the community JBoss AS server has been renamed to WildFly. The WildFly team has been busy pushing out releases of the 8.0 series during the past few months. It's been a month now since the 8.0 CR1 version of WildFly was released. This is a significant release since the 8.0 CR1 version passes the Java EE7 TCK 100%. The Final version of 8.0 is expected any time soon http://lists.jboss.org/pipermail/wildfly-dev/2014-January/001458.html.

Along with this good news about the WildFly 8.0 series nearing the final version, the other good news is that there's now a WildFly 8 administration guide available for purchase. The author of the book is Francesco Marchioni, who in the past has authored books on the JBoss AS series.

Brief review of the WildFly 8 book

The WildFly 8 book by Francesco is aimed at admins and does a good job of covering various administrative configurations for each of the major subsystems that form a part of the WildFly server. The author starts by covering the basics, from installation of the server and goes on to give an overview of the standalone and domain modes of the server. He then goes on to extensively explain each of the major subsystem administration configurations, like the new web subsystem which is backed by Undertow. There's also chapters on EJB and clustering configurations.

Francesco does a good job of covering the major subsystems and also keep the content concise. I found the book to be a good read from an administrator point of view. There are certain tidbits for developers too, but the book is mostly aimed at admins. If you are looking for some book to give you a quick and extensive overview of the subsystems in WildFly, then this is worth it.

Jaikiranhttp://firstname.lastname@example.com:blogger.com,1999:blog-30587633.post-1638025624155386842013-07-25T17:28:00.000+05:302013-07-25T17:32:51.079+05:30WildFly 8.0.0.Alpha3 released with support for EJB invocations over HTTP
A week back we released WildFly 8.0.0.Alpha3 version. As usual the download is available on WildFly downloads page. This release comes within a month of the 8.0.0.Alpha2 release. Keeping up with the goals of WildFly 8, this new release contains additional EE7 support, certain bug fixes and also some WildFly specific features. The entire release notes are available here.

In this article, I'll provide some details about one of the WildFly features which has made into this release.

WildFly ports

Traditionally, WildFly and previously named JBoss AS have opened different ports for different protocols and communication. For example, in the JBoss AS7 and now WildFly 8 series, by default the server opens the http port (which is by default 8080), remoting port (which is backed by JBoss Remoting and by default is 4447) and other such ports for usage by the applications deployed on the server. One of the goals of WildFly 8 (Final) is to have one single port open for all types of communication. This is meant to allow admins a better control of the server (firewall rules for example).

HTTP Upgrade support in Undertow

As some of you might know by now, the WildFly 8 series now uses Undertow as its web container. Undertow supports a standard feature called HTTP Upgrade. As can be read in that RFC, this feature allows the HTTP protocol to switch to a different protcol based on the presence of a header in the protocol data. This HTTP Upgrade feature acts as the backbone of the proposed "single port for communication" feature in WildFly.

EJB invocation over HTTP

Now that we have some background on HTTP Upgrade, let get to the details about the new feature that WildFly 8.0.0.Alpha3 introduces. Up until WildFly 8.0.0.Alpha2 (and previously in JBoss AS7 series) a project called JBoss Remoting has been the underlying protocol for remote communication with the server. The communication by default used to happen on the port 4447. Many of you will be familiar with this port, since this is what you used while looking up EJBs from a remote client.

Starting WildFly 8.0.0.Alpha3 (i.e. this new release), this port is no longer opened by WildFly by default. So how does one invoke EJBs or even use remote-naming (which too used this port) starting this version? The answer is simple, these remote clients will now have to use the HTTP port which by default is port 8080. The rest of the code will remain the same. This HTTP port is managed by the Undertow server which like I said earlier, has support for HTTP Upgrade. Internally, the EJB client API project (which is JBoss specific project dealing with remote EJB invocations) does the necessary plumbing to request Undertow to switch to JBoss "remoting" protocol while communicating on that HTTP port. Undertow then switches the protocol to "remoting" and the rest of the communication transparently happens as if it was the usual invocation on the remoting port.

So let's see some code to understand what exactly changes from previous version to the new version, from a remote client point of view. Let's take the example of the jboss-ejb-client.properties that's used to invoke EJBs. Earlier, you probably had:

remote.connections=default

# the server hostname/IP
remote.connection.default.host=10.19.20.12

# the port for communication
remote.connection.default.port=4447

(and some other properties)

Starting this release, the only thing that changes is the port number in that properties, rest of it remains the same. So:

remote.connections=default

# the server hostname/IP
remote.connection.default.host=10.19.20.12

# the port for communication (the HTTP port)
remote.connection.default.port=8080

So that's it from a typical client point of view.

For other new features and bug fixes, please take a look at the release notes.

[WildFly Home] [WildFly JIRA] [WildFly User Forum] [WildFly downloads] [WildFly nightly builds]

Jaikiranhttp://email@example.com:blogger.com,1999:blog-30587633.post-35118736012252040062013-06-22T20:31:00.000+05:302013-06-22T20:31:10.035+05:30WildFly community members nominated for JBoss Community Recognition Award - voting open
Every year, JBoss community members are rewarded for their work in the community as part of the JBoss Community Recognition Awards (JBCRA). This year we have 2 community members from the WildFly project (previously known as JBoss Application Server) who have been nominated in 3 different categories.

Nicklas Karlsson has been nominated in the Issue/JIRA category and Stephen Coy has been nominated in 2 categories - Community Leadership and New Features. Please do vote for them here https://www.jboss.org/jbcra/vote.html - it's just one page and takes less than a minute to vote. It's one way of thanking them for the help they have been providing in the community. Remember that these nominees are volunteers and are not Red Hat/JBoss employees so their contributions are that much more valuable.

The voting ends on July 26 2013. Don't wait for that date, vote now! :)

Jaikiranhttp://email@example.com:blogger.com,1999:blog-30587633.post-10281796657643262842013-06-03T16:56:00.000+05:302013-06-03T17:33:15.748+05:30WildFly 8.0.0.Alpha1 release and a bit of history
It's been around 2 weeks now since we released WildFly 8.0.0.Alpha1 version. The download is available on the WildFly downloads page. I'm sure many of you might be wondering what WildFly is and some of you who are aware of what it is, might not be aware that there has been a release. I'll try and answer some of these questions and also add some details about what this release contains.

So what's WildFly?

WildFly is the new name for the community project which was previously known as JBoss Application Server. Late in 2012, we decided that we had to rename the community project, JBoss Application Server, to something else. As part of that (long drawn out) process, community members were asked to suggest new names and a few selected names were voted to select the new name. Ultimately, WildFly turned out to be the winner.

Why did we change the name?

JBoss Application Server (both the name and the project) has been a very popular project over the years. Initially when it started off, it was known simply as JBoss. Anytime anyone referred to the name JBoss, people knew that they were talking about the JBoss Application Server community edition. Over the years though, the reference started to get hazy. The community edition JBoss Application Server also has a paid and fully supported version known as JBoss Enterprise Application Platform (JBoss EAP). Notice the "JBoss" name in there? So there's JBoss Application Server community edition and then there's JBoss EAP paid version. It did not stop there! Over the years, various community projects hosted at jboss.org started naming their projects with the name "JBoss" in it. So there was "JBoss ESB", "JBoss Transactions", "JBoss Messaging" and many such projects with the name "JBoss" in it. It's certainly no fault of those projects that they used "JBoss" as part of the name. It did make sense to use that name, since those projects were developed by JBoss community members. By the way, did you just notice the name "JBoss" even means a reference to the JBoss community as a whole?

So I guess at this point you might have realized where I'm headed with all this historical evidence. Clearly, the name "JBoss" had started to mean much more than just the JBoss Application Server community project. Although it was good thing from a brand point of view, it clearly wasn't too good from various other aspects. We had started seeing too much confusion about what each project/product stood for not just from a name point of view but also a release roadmap point of view. Take for example JBoss Application Server and JBoss EAP - users, typically those who are more busy with their application (rightly so) than trying to understand what each variant of project/product with the name "JBoss" in it meant, were just not sure which one to pick and which release of those had what features in it. Of course, it would take some explanation to help them understand this, but doing this on a regular basis was a clear sign that this isn't the right way forward.

So slowly during the past few years, there has been a conscious decision not to name new projects with "JBoss" in its name and also to rename some of the existing projects wherever possible. So for example, when "JBoss Messaging" project decided to release a completely new and better version, the project decided to name it "HornetQ". Similarly, JBoss Transactions is now known as Narayana. There are various examples of such renames and new names. Obviously, doing the same for JBoss Application Server would need some time and extra efforts since it was a really huge change for various reasons. But it had to be done ultimately and that's why it's now WildFly.

So what happens to the "JBoss" name in JBoss EAP?

The rename is only for the JBoss Application Server community edition. The paid version is still named JBoss Enterprise Application Platform (JBoss EAP). Since one of the original intentions of the rename was to clear the confusion between JBoss Application Server community edition and similar named JBoss EAP, the name change only applies to the community edition. So ultimately, over time, when someone refers to WildFly, we clearly know they are talking about the community project and very specifically the application server project.

How does WildFly 8.0.0.Alpha1 release relate to the previous JBoss AS7 releases?

WildFly 8.0.0.Alpha1 is the continuation of the release cycle of the application server community edition, which was previously known as JBoss AS7. The last release of JBoss AS7 was 7.1.1.Final (way back in March 2012) and WildFly 8.0.0.Alpha1 is now the next release of the same project with the new name.

Is WildFly 8.0.0.Alpha1 a release of a new project?

I know I already answered a variant of this question earlier, but I wanted to include the answer to this differently worded question too since I wanted it to be very clear that WildFly is just a rename of JBoss Application Server. It is not a new project. So WildFly 8.0.0.Alpha1 release is the continuation of the release cycle of the previously named JBoss Application Server project.

What's new in 8.0.0.Alpha1 release?

Now that we have addressed what WildFly is and a history around the name change, let's focus on the release itself. Some time back, Jason, the project lead of WildFly, listed down the goals of WildFly 8 release in the 2 dev mailing list threads here:

WildFly 8 roadmap (proposal) - http://lists.jboss.org/pipermail/jboss-as7-dev/2013-March/007884.html

WildFly 8 Schedule - http://lists.jboss.org/pipermail/wildfly-dev/2013-May/000062.html

So those are the goals and the schedule for WildFly 8.

WildFly 8.0.0.Alpha1 is the first milestone towards that. The release contains some of the new Java EE7 features, a new web server implementation named Undertow (as a replacement to JBossWeb web server) and some other new features. Of course, it also contains numerous bug fixes and since the previous release was more than a year back, the number of bug fixes are huge. Jason has summarized the WildFly 8.0.0.Alpha1 release in the dev mailing thread here http://lists.jboss.org/pipermail/wildfly-dev/2013-May/000139.html.

Please download this new version and give it a try. Like always, any feedback, questions or asking for help is always welcome in our WildFly user forums.

What's next for WildFly?

Like Jason noted in the WildFly 8 release schedule thread, we plan to push out a release almost every other month with the goal of having a 8.0.0.Final version at the end of this year. So, like with all the help that the community provided during AS7 releases:

Community help for JBoss AS 7.0 release - https://community.jboss.org/thread/169491
Community help for JBoss AS 7.1 release - https://community.jboss.org/thread/195430

please continue to do the same for WildFly releases.

In the coming weeks/months, we plan to blog more about the WildFly releases and the technologies that the WildFly runtime supports. In fact, Jason has asked in this dev mailing list thread http://lists.jboss.org/pipermail/wildfly-dev/2013-May/000144.html whether the community members will be willing to blog too. That's another way of contributing too. So if you have any blogs that you have written or plan to write on WildFly, do let us know about it in that thread.

Those of you who want to try out the nightly builds of WildFly, can get it from our continuous integration job mentioned here https://community.jboss.org/thread/224262.

By the way, what's that image at the beginning of this article?

Thanks for noticing! That's the logo for WildFly which the jboss.org team of artists (yeah, we do have team for that) helped us come up with :) Like it?

[WildFly Home] [WildFly JIRA] [WildFly User Forum] [WildFly downloads] [WildFly nightly builds]

Jaikiranhttp://email@example.com:blogger.com,1999:blog-30587633.post-64889475176808014292013-03-26T15:47:00.000+05:302013-06-10T09:47:35.315+05:30Java EE 7 and EJB 3.2 support in JBoss AS 8

 Update (June 10 2013): JBoss AS is now known as WildFly. This post was written before WildFly 8.0.0.Alpha1 was released. Any references to JBoss AS8 in this article should be considered as a reference to WildFly 8. Read my next article here http://jaitechwriteups.blogspot.in/2013/06/wildfly-release-and-history-behind-the-release.html which explains what WildFly is and why JBoss AS was renamed to WildFly.

Some of you might be aware that the Public Final Draft version of Java EE 7 spec has been released. Among various other new things, this version of Java EE, brings in EJB 3.2 version of the EJB specification. EJB 3.2 has some new features compared to the EJB 3.1 spec. I'm quoting here the text present in the EJB 3.2 spec summarizing what's new:

The Enterprise JavaBeans 3.2 architecture extends Enterprise JavaBeans to include the following new functionality and simplifications to the earlier EJB APIs:

Support for the following features has been made optional in this release and their description is moved to a separate EJB Optional Features document:

EJB 2.1 and earlier Entity Bean Component Contract for Container-Managed Persistence

EJB 2.1 and earlier Entity Bean Component Contract for Bean-Managed Persistence

Client View of an EJB 2.1 and earlier Entity Bean

EJB QL: Query Language for Container-Managed Persistence Query Methods

JAX-RPC Based Web Service Endpoints

JAX-RPC Web Service Client View

Added support for local asynchronous session bean invocations and non-persistent EJB Timer Service to EJB 3.2 Lite.

Removed restriction on obtaining the current class loader; replaced 'must not' with 'should exercise caution' when using the Java I/O package.

Added an option for the lifecycle callback interceptor methods of stateful session beans to be executed in a transaction context determined by the lifecycle callback method's transaction attribute.

Added an option to disable passivation of stateful session beans.

Extended the TimerService API to query all active timers in the same EJB module.

Removed restrictions on javax.ejb.Timer and javax.ejb.TimerHandle references to be used only inside a bean.

Relaxed default rules for designating implemented interfaces for a session bean as local or as remote business interfaces.

Enhanced the list of standard activation properties.

Enhanced embeddable EJBContainer by implementing AutoClosable interface.

As can be seen, some of the changes proposed are minor. But there are some which are useful major changes. We'll have a look at a couple of such changes in this article.

1) New API TimerService.getAllTimers()

EJB 3.2 version introduces a new method on the javax.ejb.TimerService interface, named getAllTimers. Previously the TimerService interface had (and still has) a getTimers method. The getTimers method was expected to return the active timers that are applicable for the bean on whose TimerService, the method had been invoked (remember: there's one TimerService per EJB).

In this new EJB 3.2 version, the newly added getAllTimers() method is expected to return all the active timers that are applicable to *all beans within the same EJB module*. Typically, an EJB module corresponds to a EJB jar, but it could also be a .war deployment if the EJBs are packaged within the .war. This new getAllTimers() method is a convenience API for user applications which need to find all the active timers within the EJB module to which that bean belongs.

2) Ability to disable passivation of stateful beans

Those familiar with EJBs will know that the EJB container provides passivation (storing the state of the stateful bean to some secondary store) and activation (loading the saved state of the stateful bean) capability to stateful beans. However, previous EJB versions didn't have a portable way of disabling passivation of stateful beans, if the user application desired to do that. The new EJB 3.2 version introduces a way where the user application can decide whether the stateful bean can be passivated or not.

By default, the stateful bean is considered to be "passivation capable" (like older versions of EJB). However, if the user wants to disable passivation support for certain stateful bean, then the user has the option to either disable it via annotation or via the ejb-jar.xml deployment descriptor.

Doing it the annotation way is as simple as setting the passivationCapable attribute on the @javax.ejb.Stateful annotation to false. Something like:

 @javax.ejb.Stateful(passivationCapable=false) // the passivationCapable attribute takes a boolean value
 public class MyStatefulBean {
 ....
 }

Doing it in the ejb-jar.xml is as follows:

 <?xml version="1.0" encoding="UTF-8"?>
 <ejb-jar xmlns="http://xmlns.jcp.org/xml/ns/javaee"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
 http://xmlns.jcp.org/xml/ns/javaee/ejb-jar_3_2.xsd"
 version="3.2">
 <enterprise-beans>
 <session>
 <ejb-name>foo-bar-bean</ejb-name>
 <ejb-class>org.myapp.FooBarStatefulBean</ejb-class>
 <session-type>Stateful</session-type>

 <passivation-capable>false</passivation-capable>
 </session>
 ...
 </enterprise-beans>
 </ejb-jar>

Two important things to note in that ejb-jar.xml are the version=3.2 attribute (along with the http://xmlns.jcp.org/xml/ns/javaee/ejb-jar_3_2.xsd schema location) on the ejb-jar root element and the passivation-capable element under the session element.

So, using either of these approaches will allow you to disable passivation on stateful beans, if you want to do so.

Java EE 7 and EJB 3.2 support in JBoss AS8:

JBoss AS8 has been adding support for Java EE 7 since the Public Final Draft version of the spec has been announced. Support for EJB 3.2 is already added and made available. Some other Java EE 7 changes have also made it to the latest JBoss AS 8 builds. To keep track of the Java EE 7 changes in JBoss AS8, keep an eye on this JIRA https://issues.jboss.org/browse/AS7-6553.

To use the already implemented features of Java EE 7 in general or EJB 3.2 in particular, you can download the latest nightly build/binary of JBoss AS from here. Give it a try and let us know how it goes. For any feedback, questions or if you run into any kind of issues, feel free to open a discussion thread in our user forum here.

[JBoss AS Home] [JBoss AS JIRA] [JBoss AS User Forum] [JBoss AS downloads] [JBoss AS nightly builds]

Jaikiranhttp://firstname.lastname@example.com:blogger.com,1999:blog-30587633.post-77963841863265398182013-01-27T19:15:00.000+05:302013-01-27T19:15:16.579+05:30Custom error pages for expired conversations involving CDI and JSF
It's been a while since I last blogged. I keep thinking of blogging something technical but end up getting busy with other things. This last week there was a very interesting discussion at the coderanch forums. It was even more interesting because it involved JBoss :)

Developers familiar with Java EE web applications would know that the web application deployment descriptor (web.xml) allows you to specify "error pages" which the container will display when a specific exception (class) or a error code is thrown by the server for a web request. Here's a quick example of how it looks like:

 <web-app>
 ...

 <error-page>
 <error-code>500</error-code>
 <location>/my-foo-bar-500-page.html</location>
 </error-page>

 <error-page>
 <exception-type>org.myapp.foo.bar.MyException</exception-type>
 <location>/my-foo-bar-exception-page.html</location>
 </error-page>
 ...

 </web-app>

Simple enough - a couple of custom error pages defined for a specific error code and an exception type respectively. All of this works fine.

In current days, more and more programming models and frameworks come into picture while developing web applications. CDI and JSF are some of those. CDI has this concept of scopes (ex: request scope, session scope, application scope, conversation scope). We won't go into the details of what those are and when those are used, but let's consider conversation scope in this blog since that's what the discussion was about in the forum thread that prompted this blog.

So CDI allows multiple requests to be part of a "conversation scope". A conversation has a "start" and an "end", both of which can be managed by the application. When the application involves JSF, any conversation (id) gets auto-propagated to the JSF request(s). Apart from an explicit start/end demarcation of conversations, a conversation can also timeout. A request which refers to a conversation which has ended or timed out will run into an exception.

So we know have a bit of background on CDI conversation scope. So let's consider a case where the application wants to present a good looking page when the "conversation no longer present" exception is thrown (maybe because of a timeout). We have seen how to write a web.xml for error-page configurations - it would be as simple as:

 <web-app>
 ...

 <error-page>
 <exception-type>org.jboss.weld.context.NonexistentConversationException</exception-type>
 <location>/my-foo-bar-exception-page.html</location>
 </error-page>
 ...

 </web-app>

Simple enough. The org.jboss.weld.context.NonexistentConversationException is the exception class type which gets thrown when the conversation has timed out (note that we are assuming that the web application is relying on Weld as the CDI spec implementation library). The above configuration works fine. The my-foo-bar-exception-page.html gets displayed when the org.jboss.weld.context.NonexistentConversationException is thrown.

BUT, let's now consider that we want to involve JSF in the error page just like the other parts of our application. So let's point the error-page to a URL pattern which maps to the JSF servlet:

 <web-app>
 ...

 <error-page>
 <exception-type>org.jboss.weld.context.NonexistentConversationException</exception-type>
 <location>/my-foo-bar-exception-page.xhtml</location>
 </error-page>
 ...

 </web-app>

Note that we changed the error page mapping to my-foo-bar-exception-page.xhtml (notice the xhtml extension) from my-foo-bar-exception-page.html. We'll again assume that the .xhtml resources are mapped to the JSF servlet so those requests are considered as JSF requests.

With this change to the web.xml, you'll notice that the my-foo-bar-exception-page.xhtml will no longer be displayed in you see a big stacktrace with repeatedly shows org.jboss.weld.context.NonexistentConversationException exception in the stacktrace thus giving an impression that the error-page configuration went wrong.

So what did we do wrong? Well, remember that earlier I mentioned that for JSF requests the conversation id gets propagated automatically. That's exactly what's happening here. The server notices the org.jboss.weld.context.NonexistentConversationException exception and then tries to render the error-page which is backed by JSF and since the conversation id gets propagated the server tries to find that non-existent conversation and ends up failing with the same org.jboss.weld.context.NonexistentConversationException and ultimately fails to render the error page. It's like going in circles to render that error page.

So how does one get past it? Keeping aside all the technical details, the obvious thing would be to not propagate the non-existent conversation id while rendering the (JSF backed) error page. So that's what we are going to do. CDI 1.1 (and Weld 1.1.2 and later) allows you to explicitly specify that a conversation shouldn't be propagated for a particular request. You can do this by passing along a parameter named "nocid" within that request. With that knowledge, let's now modify our web.xml to do the necessary changes so that our error page gets rendered properly:

 <web-app>
 ...

 <error-page>
 <exception-type>org.jboss.weld.context.NonexistentConversationException</exception-type>
 <location>/my-foo-bar-exception-page.xhtml?nocid=true</location>
 </error-page>
 ...

 </web-app>

Notice that we are passing the "nocid" parameter as part of the query string of the error page location. The value for "nocid" parameter really doesn't matter but for the sake of keeping that value logical, we have used the value "true" here. Once this change is done, you'll start noticing that the error page (backed by JSF) now renders correctly!

It took a while for us to get to this solution in that forum thread because it looked so simple that it should have "just worked", but it didnt' Here's the forum thread at coderanch that I've been talking about. Credit goes to Greg Charles for figuring out how to pass that nocid parameter.

Jaikiranhttp://firstname.lastname@example.com:blogger.com,1999:blog-30587633.post-71305040618545929312012-10-07T21:34:00.000+05:302012-10-07T21:35:29.252+05:30JBoss AS is being renamed
Those of you who missed this year's JavaOne event and still haven't heard about it, here's some news that all JBoss AS followers should be aware of - your favourite application server, JBoss AS, is being renamed.

JBoss AS or just JBoss, as we have all called it since the 3.x days will now be called something else. The reasons for the rename have been explained in this "Why rename JBoss AS, FAQ?". Mark Little has blogged about the this rename in his posts here and here. Read through those pages to understand what's being proposed.

So what's the new name going to be for the JBoss AS project? We don't know yet. In fact, the name will be picked by the community. Everyone is allowed to submit a name of their choice and those names will go through a voting process and one out of those names will be chosen. So if you can think of a name for JBoss AS then go suggest it here before the 14th of this month. Don't leave it for later, this is your chance to be known as the one who chose the new name!

Jaikiranhttp://firstname.lastname@example.com:blogger.com,1999:blog-30587633.post-46255217685913256912012-02-17T15:11:00.000+05:302012-02-20T22:36:03.179+05:30JBoss AS 7.1.0.Final "Thunder" released - Java EE 6 Full Profile certified!

After just about more than a year of development on JBoss AS7, we have now released 7.1.0.Final "Thunder"! The download is available at the usual place here. This is a really big achievement for the JBoss AS7 team and we are really proud about this release.

This release contains numerous bug fixes from 7.1.0.CR1b which was released a few months back. But the biggest news about this release is that JBoss AS 7.1.0.Final is Java EE 6 Full Profile certified! I'm sure a lot of our users will be very happy about this news. AS 7.0.x was Web Profile certified but I have seen in the forums that many of you were waiting for the Full Profile certification to happen. So here's a very good reason to start using JBoss AS7, if you haven't done yet.

Apart from the Full Profile certification, AS 7.1.0.Final contains a lot of bug fixes and other JIRA issues resolved. The entire release notes can be found here.

Like in some of my previous posts on AS7 releases, in this post I'll explain atleast one new feature of this release. Many of you would know that JBoss AS7 is very different compared to the previous JBoss AS versions, on various counts. One prominent difference is that we no longer have numerous XML files in the distribution, configuring various services. Instead we just have *one* single configuration file which governs the entire server. Furthermore, unlike previous JBoss AS versions, JBoss AS7 (prior to 7.1.0.Final) did not allow *deploying* XML files to configure datasources and JMS queues. However, the community members have been repeatedly asking for this feature and JBoss AS 7.1.0.Final now allows deploying of datasources and JMS queues via application specific XML files (in addition to configuring them centrally in the domain/standalone configuration file). So let's take a quick look at how it's done in 7.1.0.Final.

 Deploying datasource via -ds.xml files in JBoss AS 7.1.0.Final
The datasource file is expected to end with the -ds.xml suffix, like in previous JBoss AS releases. You can place the *-ds.xml file in the JBOSS_HOME/standalone/deployments folder or even package it in the application under the META-INF folder of the application. If it's a .war application, then the *-ds.xml is expected to be right under the WEB-INF folder of the .war.

The *-ds.xml is expected to follow the jboss-as-datasources xsd which looks like this. So you have a datasources element under which you can define multiple datasource elements. In this example, we'll try and create a MySQL datasource and deploy it as mysql-ds.xml.

Before creating the datasource, we first have to install the database driver. AS7 allows you install the database driver either as a deployment or as JBoss Module. For more details on this, see this article. In this post, we'll deploy the driver as a JBoss Module.

 Create and install the database driver
As a first step, we'll require the MySQL driver jar file. I downloaded the driver jar from the MySQL download site here. The step to create the JBoss Module for this driver involves creating a module.xml which looks like this and is named module.xml:

 <module xmlns="urn:jboss:module:1.1" name="mysql">

 <resources>
 <resource-root path="mysql-connector-java-5.1.18-bin.jar"/>
 </resources>
 <dependencies>
 <module name="javax.api"/>
 <module name="javax.transaction.api"/>
 </dependencies>
 </module>

We place the mysql-connector-java-5.1.18-bin.jar and this module.xml file in JBOSS_HOME/modules/mysql/main folder (you'll have to create the mysql/main folder). That completes the JBoss Module creation for the MySQL driver. Now let's install this driver so that it gets registered in the standalone/domain configurations. In this example, we'll be using the standalone server. So let's start the server using:

 ./standalone.sh

Once the server is up, let's open the Command Line Interface (CLI) utility which is shipped in AS7. The CLI startup script is in the JBOSS_HOME/bin folder and can be started as follows (more details about the CLI can be found here)

 ./jboss-cli.sh --connect

Once connected successfully, we'll add the jdbc-driver using the following command:

 /subsystem=datasources/jdbc-driver=mysql-5-driver:add(driver-name=mysql-5-driver, driver-class-name=com.mysql.jdbc.Driver, driver-module-name=mysql)

So here we are naming the driver as "mysql-5-driver" (you can name it anything). The driver-module-name points to the "mysql" JBoss Module that we created in previous step. The driver-class-name is the fully qualified classname of the MySQL driver. In this case, it's com.mysql.jdbc.Driver.

A successful execution of that command will show the output as success:

 [standalone@localhost:9999 /] /subsystem=datasources/jdbc-driver=mysql-5-driver:add(driver-name=mysql-5-driver, driver-class-name=com.mysql.jdbc.Driver, driver-module-name=mysql)
 {"outcome" => "success"}

The installation will be persisted in the configuration file which was used to start the server. In this case it's the standalone.xml and this is how it looks like after the driver has been installed:

 <subsystem xmlns="urn:jboss:domain:datasources:1.0">
 ...
 <drivers>
 ...
 <driver name="mysql-5-driver" module="mysql">
 <driver-class>com.mysql.jdbc.Driver</driver-class>
 </driver>
 </drivers>
 </datasources>
 </subsystem>

We are now done with the driver installation. Now let's move on and create the mysql-ds.xml file.

 Create the mysql-ds.xml file
As previously mentioned, the mysql-ds.xml should follow the jboss-as-datasources xsd. Here's how the file looks like in our case:

 <?xml version="1.0" encoding="UTF-8"?>
 <datasources>
 <datasource jndi-name="java:jboss/datasources/MySQLDS" enabled="true" use-java-context="true"
 pool-name="MySQLDS">
 <connection-url>jdbc:mysql://localhost:3306/test</connection-url>
 <driver>mysql-5-driver</driver>
 <security>
 <user-name>foo</user-name>
 <password>bar</password>
 </security>
 </datasource>
 </datasources>

Let's see what that xml file contains. The "jndi-name" is the name to which the datasource will be bound to (you can use a name of your choice. Ideally, it would be good to bind them in java:jboss/datasources/ namespace). The "enabled=true" indicates that the datasource should be enabled after being deployed. The "use-java-context" attribute is used to indicate that the JNDI name should be bound under the java: namespace. The "connection-url" is the URL to be used for connecting to the MySQL database (check MySQL documentation for more details about the connection-url). The "driver" element points to the installed JDBC driver that we created in the previous step. In our example, we named it mysql-5-driver and that's what we use here. Finally, the "security" section contains the username and password information for connecting to the database. Make sure you use the appropriate values for all these configurations.

So now let's place this mysql-ds.xml in the JBOSS_HOME/standalone/deployments folder and see JBoss AS7 hot deploy it (if the server is already running). The logs will show the following on successful deployment:

 14:05:55,829 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015876: Starting deployment of "mysql-ds.xml"
 14:05:55,847 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) JBAS010400: Bound data source [jboss/datasources/MySQLDS]

So that's it! We have successfully deployed the MySQL datasource through a -ds.xml file in 7.1.0.Final!

So download this new version and start deploying your applications and start using these features. We'll be blogging more about the features in this release, in the upcoming days (after the AS7 developers get some much needed sleep :) ). So keep an eye on the jboss.org blogs. If you run into any issues with AS7, feel free to visit our user forum and ask for help.

[AS7 Home] [AS7 JIRA] [AS7 User Forum] [AS7 documentation] [AS7 downloads] [AS7 nightly builds]

Jaikiranhttp://firstname.lastname@example.com:blogger.com,1999:blog-30587633.post-25188307707856919542012-02-06T12:57:00.002+05:302012-02-11T20:30:30.898+05:30JUDCon 2012, Bangalore - Photos and presentations uploaded
The photos and the presentations of JUDCon 2012 which was held in Bangalore have been uploaded. You can get the photos from here and the presentations from here. The videos will be uploaded soon.

Jaikiranhttp://email@example.com:blogger.com,1999:blog-30587633.post-6441290012079168932012-01-26T21:15:00.000+05:302012-01-28T11:45:57.183+05:30Very impressed by JUDCon 2012 in Bangalore
I just returned from the first ever JUDCon event in India which was organized in Bangalore. For those of you who couldn't make it (you really missed a very impressive event) here's an review of the event.

 The venue:

It was organized in the Nimhans convention centre in Bangalore on Jan 24th and 25th. The venue had very good WiFi facility (although it did make it's absence felt for a few seconds during Rado's live demo on mod_cluster :) ). I haven't been to previous JUDCon events, so I wasn't aware how good the connectivity usually is at these events. Apparently the connectivity here was among the best as compared to the previous events, as per Galder's review. So a big thank you to the organizers of the event, Saltmarch Media.

 Attendance:

To be honest, when I arrived for the event I was expecting an audience of around 100-150 people. I did know that there's a huge number of jboss.org community users from India (like Bruno later showed in his presentation) but I hadn't expected that many would show up at the event especially since it was weekday (for some of the JBUG events that I have organized earlier, I have always been requested that the event be scheduled on a weekend) and also because the event was close to a national holiday on 26th. But to my pleasant surprise the attendance was far more in number, a number that I had never expected. We were told that there were 700+ registrations for the event (remember, this is a paid event so most of them would definitely show up) and we could really see the large numbers during the presentations. Apparently this is the biggest JUDCon in terms of attendance itself. The audience was not just impressive because of the numbers but also because of the knowledge they had about various JBoss projects some of which are very new. We could see that the audience was very well informed based on the questions (a lot of them) they asked after the sessions. So full marks for all those who attended the event and made it a great success.

 Sessions:

Before the event started this week, due to some unavoidable last minute changes, a couple of sessions had to be changed. Luckily for me and those from the audience who would have liked to hear about EJB configurations in AS7, the session organizers decided to allow a session titled "Configure and deploy your EJB applications on AS7" on the second day of the event. Since this was a last minute change and because I had already made some arrangements to leave the event sometime in the afternoon on the second day, Satish Kale and Ravi Maurya (who are both from the Red Hat team) volunteered to present the session and I decided to provide them with the necessary help for creating the slides/content. I arrived in Bangalore one day earlier before the event and spent most of the time creating the presentation for the session.

The sessions were divided into 3 tracks: (1) JBoss AS7 (2) OpenShift/Cloud and (3) Rules,Workflow, SOA and EAI. The AS7 sessions were held in the Main Hall which had a very large seating capacity and the other tracks were held in two different halls which were a bit smaller compared to the main hall but still had enough room to accommodate around 100 (or more?) people in the audience. The smaller halls were always packed for whichever session I decided to take a look at. Infact, many of them were even standing due to the full house. You will get to see a proof once the videos and pictures of the event are uploaded at jboss.org :)

I had decided that I would be attending most of the AS7 sessions and the OpenShift ones. The event started on day one at 9 in the morning when Bruno delivered the keynote address to a packed house. Then I attended a couple of more sessions - one by Ales, on Android and the Cloud and the other by Greg Kable (who I finally got to meet!) on the Best Practices for using JPA2 with Hibernate. Like I said, the sessions were well attended and the audience had some very good questions in the end for the speakers. I even got to take home a couple of important best practice suggestions from Greg's presentation. I had always wondered whether field based annotations or property based annotations on entities was a preferred approach. If you too have been wondering about that, then wait for the Greg's video/presentation to be uploaded on jboss.org (I'll actually create a new blog entry once those are uploaded. So you can even watch this blog too).

By the way, speaking of Hibernate, if Steve's reading this blog (Hi Steve! :)) there was one specific question about Hibernate which got asked atleast 3 times during various sessions and once when I was having lunch. Many of you would know that Hibernate recently switched to Gradle as their build system. They were earlier using Maven like many other JBoss projects. Apparently some users are having problems using Gradle to build Hibernate. They mentioned that they had an internal set of testsuites which they run after building Hibernate themselves, before deciding whether or not to use the newer versions of Hibernate. Apparently there's some issue with using Gradle since they say it requires some native .so library which they don't have and that results in failure on their build systems. So the question they had was whether the Hibernate team would have some kind of Maven compatibility for the builds. I don't have any knowledge of Gradle, so all I could suggest was to open a forum thread asking this question and explaining their usecase. So that's a heads up to Steve :)

After those couple of morning sessions, we had a nice lunch at the venue. The food was good. Later during the noon, I attended the session on JBoss AS7 "What's new" by Bruno. Being part of the AS7 team, I already had an idea of what the session was going to cover but I decided to be in the audience to see their reaction to the new changes to AS7 and the feedback they had around it. It was nice to see that there were many users in the audience who had started using AS7 and were aware of many of the new developments around it. The feedback was mostly encouraging although some users did mention that they had some trouble trying to migrate application which had previous JBoss AS specific extensions and descriptors. But overall, they were really happy with AS7 because of the vast amount of improvements it has compared to previous versions.

The session after that, I attended Shane's presentation on Getting Started developing apps with AS7. This was a very technical one with a live demo of how to use the command line interface (introduced in AS7) for deploying/undeploying the applications. The session included quickstarts that are made available publicly here. The session was attended by a packed audience and was well accepted. Those of you who haven't had a chance to look at the quickstarts, then I would very highly recommend taking a look at https://github.com/jbossas/quickstart. It covers a vast range of technologies and has quickstart applications with comprehensive documentation for each of those applications. Thanks to Sande Gilda and Pete Muir for managing the quickstarts and thanks for everyone else that has been contributing. This is a big improvement compared to some of our previous JBoss AS releases which did not have readily usable quickstart examples.

After these sessions, I decided to meet some of the community users and also catch up with some of my JBoss colleagues. It was good to talk to many of the community users some of whom had apparently known me by my name on the community forums.

Later in the evening of day one we had one last event at around 5:30. Although it was the last one of the day, it really turned out to be the best one (in my opinion) and well participated one. The event was "Expert Q&A with the Red Hat team". Ray Ploski (I finally got to meet Ray too!) started off the session by asking some questions to the audience and the on-stage Red Hat team then went on to discuss a wide range of topics covering a lot of JBoss projects. Each of the on-stage Red Hat team members shared their experience on a wide range of topics right from the relevance of Java, post Oracle acquisition of Sun to the very new Ceylon language. There was also discussion around Drools, jBPM, AS7, EAP and other JBoss projects. You could clearly see that the audience was very knowledgeable. This session not just had some serious discussions on a variety of topics but also had its fun moments, thanks to Mike Brock ;) (you'll see it in the video once it's posted, towards the end of the session when one member from the audience asks a question which had something to do with multi-core processors). That session ended a very lively and exciting first day of the event. We then had dinner at the event, where the delegates were invited to join the JBoss team and have a chat with them. I got to meet some delegates who had very interesting experiences to share about JBoss projects. Some of them were curious why there wasn't any session on Arquillian.

That marked the end a very nice day one at the event.

The next day the sessions started at 10 in the morning. The first one, in the AS7 track was by Dimitris, who by the way, told me that he had an exciting first hand experience of the Bangalore traffic - actually, lot of my other team mates had a similar opinion, which was natural :). Ales, I think even has a video. If not, Rado has one for sure :). So back to the sessions - the first one for day two that I attended was by Dimitris titled "JBoss Application Server 7 - Reloaded". I loved this session and I'm sure many who attended it loved it too! Dimitris started off with the history of JBoss AS 2.x, 3.x days and went on explaining the various changes/improvements that had happened all the way till AS7. It was nice to listen to some of the stories behind the previous versions, some of which I wasn't aware of. Later in the session he explained about AS7 and the projects and kernel that make up AS7 and why AS7 performs so fast. He ended that session with a "Thank you" slide which was well appreciated by the audience because he had that slide in Kannada (the language spoken in Bangalore), Hindi, Greek (Dimitris is from Greece) and English!

The next session I attended was by Rado, on mod_cluster. Rado presented on mod_cluster, which although I had some idea about, was new to me. I found the session very informative technical and got to learn some nice facts about the project. Rado even had a live demo of the project against AS7. The session went off well and there were a lot of questions from the audience.

It was then time for lunch on day two. Since I planned to leave the event an hour after lunch, I had just one more session that I had planned to attend. Ales presented a session titled CapeDwarf - Running your Google App Engine applications on JBoss AS7. Being part of the JBoss team, I had heard about the CapeDwarf project a few times from Ales but did not have much idea about what it was all about. So this was my chance to get to understand it better. I attended the session and Ales explained what the project was all about and where it stands currently. He even had a demo where he showed that you could directly deploy your Google App Engine application (an application which uses Google App Engine APIs) against a JBoss AS7 instance enabled with CapeDwarf subsystem and without having to do any changes to your application. It was an impressive demo and presentation and I got to learn what the project was all about.

So that was the last session I could attend that day since I had to leave early. There still were some other sessions that I wished I could attend and even present the "Configuring EJB applications for AS7" but that wasn't to be. Later I got to know that the session on EJB went well, although I still have to catch up with Satish and Ravi to get to know more. A big thanks to Satish and Ravi for presenting this session since it was a last minute decision for them too after the previously decided sessions were cancelled.

I caught up, one last time for this event, with my JBoss colleagues before leaving the event. Turns out I missed getting a JUDCon t-shirt because I left early and forgot to submit the feedback form for the sessions :(

Overall, these 2 days at the event were real exciting and the event was really impressive. I got to meet my JBoss team mates, some of whom I had never met before and also got a chance to meet a lot of community members. I wish we had a few more days of this! A big thank you to all those who attended and made this a success and for those who couldn't attend, keep a watch on this blog - I'll post a link to the event photos/videos once they are uploaded. Also keep an eye on the jboss.org blog feeds where I'm sure you'll see many more reviews of this event.

Jaikiranhttp://email@example.com:blogger.com,1999:blog-30587633.post-71407091647007144962011-12-23T15:20:00.000+05:302011-12-23T15:20:26.419+05:30JBoss AS 7.1.0.CR1 "Flux Capacitor" released
It's been just one month since we released JBoss AS 7.1.0.Beta1. Within that one month we have been able to fix numerous issues in JBoss AS7, add more features and resolve various other JIRAs. As a result, we now have 7.1.0.CR1 "Flux Capacitor" available for downloads. This new release contains around 378 resolved JIRAs. The highlights of this release include:

EE6 Full Profile support is now feature complete. What this means is - all the features required for EE6 full profile support are now available in AS7.

Various improvements in AS7 management

Clustering improvement:

Stateful session bean replication support

Clustered SSO

So, go get a copy of this release from the downloads page and start using it. Start deploying your applications, for which you have been waiting for full EE6 profile support in AS7 and let us know how it goes. As usual, feel provide us feedback or suggestions or ask for help if you run into any issues, in our user forum. It's just a few more days before we reach 7.1.0.Final, so help us deliver a high quality 7.1.0.Final by trying out 7.1.0.CR1 and reporting any issues.

[AS7 Home] [AS7 JIRA] [AS7 User Forum] [AS7 documentation] [AS7 downloads] [AS7 nightly builds]

Jaikiranhttp://firstname.lastname@example.com