Transylvania Java User Group Roundup

I just got back from the presenting JBoss Application Server 7 at the Transylvania User Group last night. I didn't know much about Romania before I went, but I was impressed by the friendly people and enthusiastic crowd at the event, and was taken very well care of by Gabriel Pop, the organiser, and the other locals. Everything was great apart from that the only direct flights between Cluj and London mean getting up at 4am both going there and coming back :-) The centre of Cluj was pretty, and the restaurants I got taken to were excellent.

We covered why JBoss AS 7 is so fast and had a demo introducing Java EE 6. A majority of the crowd were Spring users but the feedback I got indicated that they were impressed by the simplified programming model introduced in Java EE 6. I got a few chuckles when I complained that the initial start of the application server during the demo was slow, since it started in 2 seconds. Restarting it it started in the 1.3s I am used to on my laptop.

I then went on to explain and demo the JBoss 7 management model, and then revisited the original EE 6 demo and tested it using Arquillian before adding JAX-RS features to it and deploying it to OpenShift using a mobile HTML 5 client to interact with the server via JAX-RS.

The feedback was very good after the event, I had lots of people using JBoss AS 5.x, WebLogic, WebSphere etc. coming up to me saying they now wanted to move to AS 7. And thanks to the people who hung around for dinner afterwards, it was fun - and yes I did manage to get up for my flight after 3 hours of sleep!

JBoss AS 7 at Transylvania JUG

I'll be going to Transylvania to present at the Transylvania Java User Group on 13 March.

I'll be talking about the recently released JBoss AS 7. I'll cover the road to Java EE 6 certification, how we did the performance improvements and our brand new management layer. There will be plenty of demos taking a basic EE application, testing it and getting it working in the cloud with a HTML 5 client.

Hope to see you there!

JBoss AS 7 at Devoxx

I just got back from my first ever Devoxx, and it is a really great conference - I was very pleasantly surprised! The auditoriums for the main talks were amazing.

Dimitris, Pete, Carlo, Dan, Lincoln, Aslak, Andrew, Max and I (apologies if I forgot anybody, there were quite a few of us) did a BOF on JBoss AS 7 with good attendance and some great questions from the audience. In hindsight I wish I'd prepared some demos for anticipated questions though.

It was a very nice experience to hang around the JBoss booth and finally meet some real AS 7 users after having worked on AS 7 the past year and a half. Users of older versions of the application server seemed to be impressed by the much improved configuration and domain management of AS 7. From the chats I had that seemed to be the thing people were most impressed by/disliked the most in previous versions.

Then there were numerous other talks by the usual JBoss suspects, all of which were great and packed. Since I'm biased and work on AS 7 I loved Andrew Rubinger and Dan Allen's talk on AS 7, and of course Pete Muir's talk on OpenShift. There will be more blogs from the rest of the team on our jboss.org events page.

Getting started with JBoss Application Server 7.0.0 CR1 in minutes

JBoss Application Server 7.0.0 CR1 was released this morning (GMT). I'm sure Jason Greene, the AS 7 lead will post more details in the next day or two. In the meantime, I'd like to give you a very quick overview of how to get this up and running in a few minutes.

The most time-consuming step is to grab it from http://download.jboss.org/jbossas/7.0/jboss-7.0.0.CR1/jboss-7.0.0.CR1.zip (later releases will be accessible from the main download page http://www.jboss.org/jbossas/downloads).

Now go to your download directory and unzip it to somewhere, and then go to the jboss-7.0.0.CR1/bin folder:

[kabir ~/Downloads]
$unzip -q jboss-7.0.0.CR1.zip -d ~/AS7

[kabir ~/Downloads]
$cd ~/AS7/jboss-7.0.0.CR1/bin/



Now that the slow part is done, let's start it up in single server mode:


[kabir ~/AS7/jboss-7.0.0.CR1/bin]
$./standalone.sh
=========================================================================

JBoss Bootstrap Environment

JBOSS_HOME: /Users/kabir/AS7/jboss-7.0.0.CR1

JAVA: /Library/Java/Home//bin/java

JAVA_OPTS: -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman

=========================================================================

11:55:25,759 INFO [org.jboss.modules] JBoss Modules version 1.0.0.CR4
11:55:26,009 INFO [org.jboss.msc] JBoss MSC version 1.0.0.CR2
11:55:26,077 INFO [org.jboss.as] JBoss AS 7.0.0.CR1 "White Rabbit" starting
11:55:26,955 INFO [org.jboss.as] creating http management service using network interface (management) port (9990) securePort (-1)
11:55:26,965 INFO [org.jboss.as.logging] Removing bootstrap log handlers
11:55:26,997 INFO [org.jboss.as.connector.subsystems.datasources] (Controller Boot Thread) Deploying JDBC-compliant driver class org.h2.Driver (version 1.2)
11:55:27,101 INFO [org.jboss.as.naming] (Controller Boot Thread) Activating Naming Subsystem
11:55:27,157 INFO [org.jboss.as.osgi] (Controller Boot Thread) Activating OSGi Subsystem
11:55:27,188 INFO [org.jboss.as.security] (Controller Boot Thread) Activating Security Subsystem
11:55:27,208 INFO [org.jboss.as.naming] (MSC service thread 1-4) Starting Naming Service
11:55:27,215 INFO [org.jboss.remoting] (MSC service thread 1-3) JBoss Remoting version 3.2.0.Beta2
11:55:27,229 INFO [org.xnio] (MSC service thread 1-3) XNIO Version 3.0.0.Beta3
11:55:27,248 INFO [org.xnio.nio] (MSC service thread 1-3) XNIO NIO Implementation Version 3.0.0.Beta3
11:55:27,518 INFO [org.apache.catalina.core.AprLifecycleListener] (MSC service thread 1-2) The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: .:/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java
11:55:27,539 INFO [org.jboss.as.remoting] (MSC service thread 1-3) Listening on /127.0.0.1:9999
11:55:27,575 WARN [org.jboss.osgi.framework.internal.URLHandlerPlugin] (MSC service thread 1-2) Unable to set the URLStreamHandlerFactory
11:55:27,576 WARN [org.jboss.osgi.framework.internal.URLHandlerPlugin] (MSC service thread 1-2) Unable to set the ContentHandlerFactory
11:55:27,590 INFO [org.jboss.as.ee] (Controller Boot Thread) Activating EE subsystem
11:55:27,593 INFO [org.jboss.as.jmx.JMXConnectorService] (MSC service thread 1-4) Starting remote JMX connector
11:55:27,604 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-3) Starting Coyote HTTP/1.1 on http--127.0.0.1-8080
11:55:27,732 INFO [org.jboss.as.connector] (MSC service thread 1-3) Starting JCA Subsystem (JBoss IronJacamar 1.0.0.CR2)
11:55:27,855 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) Bound data source [java:jboss/datasources/ExampleDS]
11:55:28,255 INFO [org.jboss.as.deployment] (MSC service thread 1-1) Started FileSystemDeploymentService for directory /Users/kabir/AS7/jboss-7.0.0.CR1/standalone/deployments
11:55:28,267 INFO [org.jboss.as] (Controller Boot Thread) JBoss AS 7.0.0.CR1 "White Rabbit" started in 2750ms - Started 91 of 146 services (55 services are passive or on-demand)!

And that's it! JBoss Application Server 7.0.0 started in 2750ms. Leave it running for now.

Go to http://localhost:8080/ for the welcome page which contains links to our admin console and documentation. Our documentation is being created online at https://docs.jboss.org/author/display/AS7/Documentation and there is a fair bit of content already, but make sure you check in regularly since for our next release we will be focussing 100% on our documentation. The docs include a more extensive quick start guide than this.

To deploy applications one way to do it is to copy them to the jboss-7.0.0.CR1/standalone/deployments folder. Since this is not a Java EE tutorial, let's use the first example war I could find online:



[kabir ~/AS7]
$curl http://gwt-examples.googlecode.com/files/Calendar.war > Calendar.war
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 529k 100 529k 0 0 312k 0 0:00:01 0:00:01 --:--:-- 356k

[kabir ~/AS7]
$cp Calendar.war jboss-7.0.0.CR1/standalone/deployments/



Now in the terminal window where you started AS 7 you should see that the application has been deployed:


11:55:28,267 INFO [org.jboss.as] (Controller Boot Thread) JBoss AS 7.0.0.CR1 "White Rabbit" started in 2750ms - Started 91 of 146 services (55 services are passive or on-demand)
12:05:13,713 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) Starting deployment of "Calendar.war"
12:05:14,262 INFO [org.jboss.web] (MSC service thread 1-3) registering web context: /Calendar
12:05:14,290 INFO [org.jboss.as.server.controller] (DeploymentScanner-threads - 2) Deployed "Calendar.war"


If you go to http://localhost:8080/Calendar you should see the deployed web app.

See the docs for more information about how to make JBoss AS 7 work for you!

And please report any issues at our users forum.

Microcontainer Inspector Tool Update

The Microcontainer Inspector Tool build did not work following the move to our new Maven repository at JBoss. I have updated the build and also changed the packaging to create a client jar and a server jar to be deployed. The Installation section of the original post have been updated with the new instructions.

This has made me wonder if the build will work for people who do NOT have the JBoss maven repositories set up as described here. If you are trying to build it and it does not work for you please leave me a comment and I'll fix the build.

JBoss User Group Belgium

I've been invited to talk at the Belgian JBoss User Group near Antwerp on 3rd June. The title of my talk will be "What's Cooking in JBoss AS 6" and I will talk about our current development model, ongoing optimizations and give a high-level overview of the new projects in AS 6 such as Weld, RestEasy, HornetQ and many more.

Hope to see you there!

JSR-330 and Qualifiers in the JBoss Microcontainer

The latest JBoss Microcontainer jboss-kernel 2.2.0.Alphas contain support for the @javax.inject.Inject and @javax.inject.Qualifier annotations from JSR-330.

While most of the use of the JBoss Microcontainer in JBoss AS uses explicitly named injection, e.g.

<?xml version="1.0" encoding="UTF-8"?>
<deployment xmlns="urn:jboss:bean-deployer:2.0">
   <bean name="MyDependency" class="org.jboss.test.Dependency"/>
   <bean name="MyBean" class="org.jboss.test.Bean">
      <property name="dependency"><inject bean="MyDependency"/></property>
   </bean>
</deployment>

The above means that when deploying the MyBean bean bean it will look up the MyDependency bean by name and inject that instance into MyBean's dependency property.

Contextual injection
We can also look up things by type, first let us see how to do this using xml. This has been supported by the Microcontainer for a while, so this might be familiar:

<?xml version="1.0" encoding="UTF-8"?>
<deployment xmlns="urn:jboss:bean-deployer:2.0">
   <bean name="MyDependency" class="org.jboss.test.Dependency"/>
   <bean name="MyBean" class="org.jboss.test.Bean">
      <property name="dependency"><inject/></property>
   </bean>
</deployment>

Now if the definition of MyBean's class is: package org.jboss.test;

public class Bean{
   Dependency dependency;

   public void setDependency(Dependency dependency){
      this.dependency = dependency;
   }
}

When creating MyBean this time, we have not given the name of the bean to use when configuring the dependency property. Instead the Microcontainer will check the type of the property, and find which beans are installed in the Microcontainer that can be cast to that type. In this case it finds MyDependency and uses that. If there had been more beans that could be cast to this type, an error would have been thrown. We'll see later how qualifiers can be used to resolve the ambiguities.

Using @javax.inject.Inject 
Now let us do the same using annotations. We first need to install the beans into the MC, the simplest way is to use an xml file to define the beans:

<?xml version="1.0" encoding="UTF-8"?>
<deployment xmlns="urn:jboss:bean-deployer:2.0">
   <bean name="MyDependency" class="org.jboss.test.Dependency"/>
   <bean name="MyBean" class="org.jboss.test.Bean"/> 
</deployment>

Notice that we did not define any injection for the dependency property in this case, instead we use @javax.inject.Inject on MyBean's class to define the injection:

package org.jboss.test; 

import javax.inject.Inject; 

public class Bean{

   Dependency dependency;

   @Inject
   public void setDependency(Dependency dependency){ 
      this.dependency = dependency;
   } 
} 

What happens now is that when MyBean is deployed we find the @javax.inject.Inject annotation on the dependency property and this causes a lookup of the bean to be found. As in the last example it looks up the bean by type, and throws an error if more that one can be found.

Qualifiers to the rescue
If we deploy the following beans:

<?xml version="1.0" encoding="UTF-8"?>
<deployment xmlns="urn:jboss:bean-deployer:2.0">
   <bean name="SomeDependency" class="org.jboss.test.SomeDependency"/>
   <bean name="TestDependency" class="org.jboss.test.TestDependency"/>
   <bean name="MyBean" class="org.jboss.test.Bean"/>
</deployment>

with the following classes

package org.jboss.test;

public class SomeDependency extends Dependency{
}
- - - - - - - - -
package org.jboss.test;

public class TestDependency extends Dependency{
}
- - - - - - - - -
package org.jboss.test;

import javax.inject.Inject;

public class Bean{
   Dependency dependency;

   @Inject
   public void setDependency(Dependency dependency){
      this.dependency = dependency;
   }
}

Now we have an ambiguity since both TestDependency and SomeDependency can be cast to org.jboss.test.Dependency. To give the Microcontainer a hint about which of these instances should be used we can use a qualifier. A qualifier is any annotation that has been annotated with the @javax.inject.Qualifier annotation. For example:

package org.jboss.test;

import javax.inject.Qualifier;

@Qualifier
@Retention(RUNTIME)
public @interface Test{
}

Now we can use this qualifier on our beans by adding it to TestDependency's class and to the Bean.dependency injection point:

package org.jboss.test;

@Test
public class TestDependency extends Dependency{
}
- - - - - - - - -
package org.jboss.test;

import javax.inject.Inject;

public class Bean{
   Dependency dependency;

   @Inject @Test
   public void setDependency(Dependency dependency){
      this.dependency = dependency;
   }
}

Now the Microcontainer will look up all beans that can be cast to org.jboss.test.Dependency AND that have the @org.jboss.test.Test annotation. In this case only TestDependency satisfies those criteria and is used for injection.

Qualifiers via xml
As part of implementing qualifiers in the Microcontainer we built in native support for qualifiers and came up with something somewhat more powerful that what is indicated by JSR-330. First let's deploy the classes from the previous example without any annotations:

package org.jboss.test;

public class SomeDependency extends Dependency{
}
- - - - - - - - -
package org.jboss.test;

public class TestDependency extends Dependency{
}
- - - - - - - - -
package org.jboss.test;

import javax.inject.Inject;

public class Bean{
   Dependency dependency;

   public void setDependency(Dependency dependency){
      this.dependency = dependency;
   }
}

This time the injection and qualifier annotations are driven by xml:

<?xml version="1.0" encoding="UTF-8"?>
<deployment xmlns="urn:jboss:bean-deployer:2.0">
   <bean name="SomeDependency" class="org.jboss.test.SomeDependency"/>
   <bean name="TestDependency" class="org.jboss.test.TestDependency">
      <qualifier content="Annotation">@org.jboss.test.Test</qualifier>
   </bean>
   <bean name="MyBean" class="org.jboss.test.Bean">
      <property name="dependency">
         <inject>
            <qualifier content="Annotation" type="Required">@org.jboss.Test</qualifier>
         </inject>
      </property>
   </bean>
</deployment>

Now, we're saying that TestDependency provides the @org.jboss.test.Test qualifier, and when injecting Bean.dependency we want to inject any bean that is of type Dependency and that has the @org.jboss.test.Test qualifier. As when using "real" annotations it will pick out the TestDependency bean. The qualifier content is Annotation which means the parser will try to create an annotation from the body of the qualifier annotation. When qualifier annotations are applied in this way, they do not need to be annotated with @javax.inject.Inject.

A qualifier does not have to be an annotation, simple strings can be used by omitting the content attribute:

<?xml version="1.0" encoding="UTF-8"?>
<deployment xmlns="urn:jboss:bean-deployer:2.0">
   <bean name="SomeDependency" class="org.jboss.test.SomeDependency"/>
   <bean name="TestDependency" class="org.jboss.test.TestDependency">
      <qualifier>test</qualifier>
   </bean>
   <bean name="MyBean" class="org.jboss.test.Bean">
      <property name="dependency">
         <inject>
            <qualifier type="Required">test</qualifier>
         </inject>
      </property>
   </bean>
</deployment>

Qualifiers can also be used in other places supporting the inject element, such as parameters to constructors and install methods.

Bean level qualifiers
In the previous example we applied qualifiers to a particular property. As a convenience you can choose default qualifiers that should be applied when doing injection at bean level. This is useful when you have a lot of properties that need injecting, here is an example:

<?xml version="1.0" encoding="UTF-8"?>
<deployment xmlns="urn:jboss:bean-deployer:2.0">
   <bean name="SomeDependency" class="org.jboss.test.SomeDependency"/>
   <bean name="TestDependency" class="org.jboss.test.TestDependency">
      <qualifier>test</qualifier>
   </bean>
   <bean name="SomeOtherDependency" class="org.jboss.test.SomeOtherDependency">
      <qualifier>test</qualifier>
   </bean>
   <bean name="TestOtherDependency" class="org.jboss.test.TestOtherDependency">
      <qualifier>test</qualifier>
      <qualifier>other</qualifier>
   </bean>
   <bean name="MyBean" class="org.jboss.test.Bean">
      <qualifier type="Required">test</qualifier>
      <qualifier type="Optional">other</qualifier>
      <property name="dependency"><inject/></property>
      <property name="otherDependency"><inject/></property>
   </bean>
</deployment>

Now we are saying that when doing contextual injection into MyBean's properties, the candidate beans MUST have the test qualifier, and that the other qualifier can be used to further strip out ambiguities. If we have the following bean classes:

package org.jboss.test;

public class SomeDependency extends Dependency{
}
- - - - - - - - -
package org.jboss.test;

public class TestDependency extends Dependency{
}
- - - - - - - - -
package org.jboss.test;

public class SomeOtherDependency extends OtherDependency{
}
- - - - - - - - -
package org.jboss.test;

public class TestOtherDependency extends OtherDependency{
}
- - - - - - - - -
package org.jboss.test;

import javax.inject.Inject;

public class Bean{
   Dependency dependency;

   OtherDependency otherDependency;

   public void setDependency(Dependency dependency){
      this.dependency = dependency;
   }

   public void setOtherDependency(OtherDependency otherDependency){
      this.otherDependency = otherDependency;
   }
}

then TestDependency is used for MyBean.dependency and TestOtherDependency is used for injection into MyBean.otherDependency.

Custom qualifiers
If the above qualifiers are not enough to narrow down what you want to inject, you can create custom qualifiers as shown in this simple example. If we deploy the following beans we end up with Dependency3 being injected into MyBean.dependency:

<?xml version="1.0" encoding="UTF-8"?>
<deployment xmlns="urn:jboss:bean-deployer:2.0">
   <bean name="TestMatcherAndParser"
      class="org.jboss.test.kernel.qualifiers.support.TestMatcherAndParser"/>
      <bean name="QualifierMatchers" class="org.jboss.kernel.spi.qualifier.QualifierMatchers">
         <constructor factoryMethod="getInstance">
      </constructor>
      <install method="addParser">
         <parameter><inject bean="TestMatcherAndParser"/></parameter>
      </install>
      <install method="addMatcher">
         <parameter><inject bean="TestMatcherAndParser"/></parameter>
      </install>
      </bean> 
      <bean name="Dependency1" class="org.jboss.test.SomeDependency">
         <qualifier>test</qualifier>
      <qualifier content="Test">Hello-xxx</qualifier>
      </bean>
      <bean name="Dependency2" class="org.jboss.test.Dependency">
         <qualifier>test</qualifier>
      </bean>
      <bean name="Dependency3" class="org.jboss.test.TestDependency">
         <qualifier>test</qualifier>
         <qualifier content="Test">Hola-xxx</qualifier>
      </bean>
      <bean name="MyBean" class="org.jboss.test.Bean">
         <qualifier type="Required">test</qualifier>
      <qualifier type="Required" content="Test">xxx-Hola</qualifier>
    </bean>
</deployment>

The magic behind understanding content="Test" lives in the TestMatcherAndParser bean which is installed via the QualifierParser singleton:

package org.jboss.test.kernel.qualifiers.support;

import java.util.Set;
import org.jboss.beans.metadata.api.model.QualifierContent;
import org.jboss.dependency.spi.ControllerContext;
import org.jboss.kernel.spi.qualifier.QualifierMatcher;
import org.jboss.kernel.spi.qualifier.QualifierParser;

public class TestMatcherAndParser implements QualifierMatcher, QualifierParser{
   public TestMatcherAndParser(){
   }

   //QualifierParser methods
   public QualifierContent getHandledContent(){
      return QualifierContent.getContent("Test");
   }

   public Object parseSupplied(ClassLoader cl, Object rawQualifier){
      return new Supplied((String)rawQualifier);
   }

   public Object parseWanted(ClassLoader cl, Object object){
      return new Wanted((String)object);
   }

   //QualifierMatcher methods
   public Class getHandledType(){
      return Wanted.class;
   }

   public boolean matches(ControllerContext context, Set<Object> suppliedQualifiers, Wanted qualifier){
      for (Object supplied : suppliedQualifiers){
         if (supplied instanceof Supplied)
            return qualifier.getString().equals(((Supplied)supplied).getString());
      }
      return false;
   }

   private static class Supplied{
      String string;

      public Supplied(String string){
         int i = string.indexOf("-xxx");
         if (i >= 0)
            string = string.substring(0, i);
            this.string = string;
      }

      public String getString(){
         return string;
      }
   }
}
- - - - - - - - -
package org.jboss.test.kernel.qualifiers.support;

public class Wanted{
   String string;
   public Wanted(String string){
      this.string = string;
      if (string.startsWith("xxx-"))
         string = string.substring(4);
         this.string = string;
      }

   public String getString(){
      return string;
   }
}

TestMatcherAndParser implements the QualifierParser and QualifierMatcher interfaces. The getHandledContent() method is what links this parser to content="Test". When parsing a qualifier with that content type supplied from from a bean (e.g. the qualifier entries in Dependency1 and Dependency3) we end up in the parseSupplied() method which creates an instance of Supplied. Similarly when parsing a qualifier with that content type from a bean wanting to inject something we end up in the parseWanted() method which creates an instance of Wanted.

So for Dependency1 we end up with a Supplied containing the string Hello and for Dependency3 we end up with a Supplied containing the string Hola. We end up with a Wanted containing the string Hola for MyBean.
Next when checking the qualifiers when doing injection into MyBean and checking

<qualifier type="Required" content="Test">xxx-Hola</qualifier>

behind the scenes the microcontainer finds all the contexts that are of the correct type and which have supplied qualifiers where type content="Test", i.e. the contexts Dependency1 and Dependency3. Then for each of these contexts it calls matches() with all the qualifiers for the candidate bean along with the parsed Wanted qualifier for MyBean.

When checking Dependency1 it calls matches() with the Supplied containing Hello and the Wanted containing Hola which does not match, and for Dependency2 it calls matches() with the Supplied containing Hello and the Wanted containing Hola which matches, meaning that only Dependency1 matches all the criteria. When calling matches() the ControllerContext (with information about the candidate bean's name, type, instance and other things) is passed in as well.

In the provided example we are only doing a silly little check where the Supplied gets rid of the final -xxx and the Wanted gets rid of the leading -xxx. The point here is that it is simple to implement more advanced qualifier checking than is provided out-of-the-box, and this mechanism has already been used to provide support for matching OSGi properties.