August 16, 2012

Eclipse Keyboard Shortcut Does not Work on Ubuntu 12.04

When I installed Eclipse on Ubuntu 12.04 (or rather just unzipped the eclipse binary in my home folder and started the eclipse executable) some common Eclipse keyboard shortcut was not working, like Organize Import Ctrl+Shift+O or Inspect when debugging Ctrl+Shift+I. And the problem was that they were conflicting with the OS Ubuntu keyboard shortcut. To remove/edit the Ubuntu keyboard shortcut simply open Ubuntu Keyboard and walk through conflicting Eclipse keyboard short and either remove the Ubuntu keyboard shortcut or reassign them to other keyboard shortcut.

In the example below I simple removed the Ubuntu keyboard shortcut for Zoom in and Zoom out, since I don't need them.


August 15, 2012

How to Install Maven 3 on Ubuntu

So far there Maven 3 package is not yet available in the general Ubuntu repository, so you will have to do it manually. There are several way to do that, but I think the easiest way is to do it manually.

In short the installation follow:
$ cat /etc/environment
PATH="/home/magnus/bin/apache-maven-3.0.4/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"
JAVA_HOME=/usr/lib/jvm/jdk1.6.0_31
M2_HOME=/home/magnus/bin/apache-maven-3.0.4

August 13, 2012

How to install MySQL DataSource on JBoss EAP 6 and AS 7.

The interior of the JBoss EAP 6 and the community version JBoss AS 7, which EAP version is based on, has changed a lot in the latest version. In this blog I will walk you through how to install a MySQL DataSource, and by doing that I will touch two important differences with the new version of JBoss.
  • The changed classloading to a more OSGI like architecture.
  • The simplification of have only one configuration file.
First we will create a new module. A module in this sense is a package of classes that will be available to all our application through your JBoss node. This is a big differences compared with older JBoss version where all deployed archive where directly available to other deployed application when deployed in the deployment root folder.

You find module in $JBOSS_HOME/modules folder. To create a new module you need to do three things:
  1. Create a folder hierarchy for files.
  2. Copy module jar files.
  3. Create module configuration file – module.xml.
$ mkdir -p $JBOSS_HOME/modules/com/mysql/main
$ cp mysql-connector-java-5.1.19.jar $JBOSS_HOME/modules/com/mysql/mainmysql-connector-java-5.1.19.jar
$ touch $JBOSS_HOME/modules/com/mysql/main/module.xml
Now edit the module.xml file:
<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="com.mysql">
    <resources>
        <resource-root path="mysql-connector-java-5.1.19.jar"/>
    </resources>
    <dependencies>
        <module name="javax.api"/>
    </dependencies>
</module>
Now you are ready to use configure your DataSource. Here I will use the JBoss Standalone and not the Domain configuration. In short the main differences between Module and Standalone JBoss configuration is if you want to reuse your configuration through several JBoss instance you shoud use the Domain configuration approach. In this blog I will use the Standalone configuration, but the differences of doing the other way around is not big.

The configuration of the JBoss can be done in several way: 1. CLI 2. Web interface 3. or manually through editing xml file. Which way you choose is up to you, here I will show the result.

$JBOSS_HOME/standalone/configuration/standalone.xml:
        <subsystem xmlns="urn:jboss:domain:datasources:1.1">
            <datasources>
                ...
                <datasource jndi-name="java:jboss/datasources/YourProjectDS" pool-name="YourProjectDS" enabled="true" use-java-context="true">
                    <connection-url>jdbc:mysql://localhost:3306/YourProjectDB</connection-url>
                    <driver>mysql</driver>
                    <security>
                        <user-name>uid</user-name>
                        <password>pwd</password>
                    </security>
                </datasource>
                <drivers>
                    ...
                    <driver name="mysql" module="com.mysql"/>
                </drivers>
            </datasources>
        </subsystem>

August 1, 2012

Search JAR Files after Specific Class

Ones in a while I need to search in a lot of jar files after a specific class class and that is what this command:

$ find . -name "*.jar" -a -exec bash -c "unzip -l {} | grep Foo.class" \; -print

July 27, 2012

Java EE 6 Annotations - JSR 250: Common Annotations

In my previous blog I was writing about the CDI annotation in EE 6, in this blog I will write about the The Common Annotations, namely:

Resource Injection:
Lifecycle:
Managed Bean:

javax.annotation.Resource and javax.annotation.Resources

The @Resource and @Resources are shortcut for doing jndi lookup, e.g. new new InitialContext().lookup(name).

javax.annotation.PostConstruct and javax.annotation.PreDestroy

The @PostConstruct and @PreDestroy are neat annotation to do initialization and clean up in a standardized way. I would recommend to use these annotation even if you are not deploying to an enterprise environment. The above annotation can be used on any bean, such EJB, MDB, Managed Bean, but if you annotate a POJO, you need to fetch that POJO with @Inject to make the PostConstruct and PreDestroy be called.

javax.annotation.ManagedBean

This annotation should NOT be mixed up with javax.faces.bean.ManagedBean or JMX Managed Bean. It is a lightweight component that enables resource injection, lifecycle callbacks and interceptors. I my self is not totally sure where this component fits in, but it's there.

Java EE 6 Annotations - JSR 299: Contexts and Dependency Injection - Part 2

In my previous blog http://magnus-k-karlsson.blogspot.se/2012/07/java-ee-6-annotations-jsr-299-contexts.html I wrote about the new CDI annotation in EE 6 and now you would probably want to test them. You can of course package your archive and deploy it to your a EE container, but that is clumsy, tedious and harder to debug. What you rather want to is to write a JUnit test cases and with that be able to debug/run it from your IDE. There are several way to do that, but two major solution are:

In this blog I will show how to do that with JBoss Arquillian, but Apache OpenEJB is also a good solution.

There is a rather good getting started guide at http://arquillian.org/guides/getting_started/, which I encourage you to read and here I will give you a shorthand version, but also give some more clarification about the Arquillian Maven dependency.

First add JBoss Maven User repository, which is described here, https://community.jboss.org/wiki/MavenGettingStarted-Users.

Then create an empty maven project. Modify your pom.xml accordingly

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="
        http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

 <modelVersion>4.0.0</modelVersion>
 <groupId>se.msc.examples</groupId>
 <artifactId>cdi-tutorial</artifactId>
 <version>1.0.0-SNAPSHOT</version>

 <properties>
  <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  <project.build.outputEncoding>UTF-8</project.build.outputEncoding>
 </properties>

 <dependencyManagement>
  <dependencies>
   <dependency>
    <groupId>org.jboss.arquillian</groupId>
    <artifactId>arquillian-bom</artifactId>
    <version>1.0.1.Final</version>
    <scope>import</scope>
    <type>pom</type>
   </dependency>
  </dependencies>
 </dependencyManagement>

 <dependencies>
  <dependency>
   <groupId>org.jboss.spec</groupId>
   <artifactId>jboss-javaee-6.0</artifactId>
   <version>1.0.0.Final</version>
   <type>pom</type>
   <scope>provided</scope>
  </dependency>

    <!-- Test Support -->
  <dependency>
   <groupId>junit</groupId>
   <artifactId>junit</artifactId>
   <version>4.8.1</version>
   <scope>test</scope>
  </dependency>

    <!-- Arquillian JUnit Integration -->
  <dependency>
   <groupId>org.jboss.arquillian.junit</groupId>
   <artifactId>arquillian-junit-container</artifactId>
   <scope>test</scope>
  </dependency>

    <!-- Arquillian container adapter for the target container -->
  <dependency>
   <groupId>org.jboss.arquillian.container</groupId>
   <artifactId>arquillian-weld-ee-embedded-1.1</artifactId>
   <version>1.0.0.CR3</version>
   <scope>test</scope>
  </dependency>
  
  <!-- Target Container - Weld EE Container -->
  <dependency>
   <groupId>org.jboss.weld</groupId>
   <artifactId>weld-core</artifactId>
   <version>1.1.5.Final</version>
   <scope>test</scope>
  </dependency>
  
  <dependency>
   <groupId>org.slf4j</groupId>
   <artifactId>slf4j-simple</artifactId>
   <version>1.6.4</version>
   <scope>test</scope>
  </dependency>
 </dependencies>

 <build>
  <finalName>cdi-tutorial</finalName>

  <plugins>
   <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>2.3.2</version>
    <configuration>
     <source>1.6</source>
     <target>1.6</target>
    </configuration>
   </plugin>

   <plugin>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.12</version>
   </plugin>
  </plugins>
 </build>
</project>

There are two importing thing to stress here. First we need to understand one imported design goal with Arquillian and that is it was meant to be conainer neutral, i.e. the Arquillian test should not be affected if you decided to run your EE test on a different EE Container. And this design goal is reflected in the  Arquillian Maven dependency module.

So with that in mind, the first dependency arquillian-weld-ee-embedded-1.1 is only an adapter and does not contain any real CDI implementation code, which is in this case the Weld implementation code.

The second imported thing to understand is that Weld does not support EJB or any other similar EE modules, it only supports CDI.

If you want more container support look at the following pom, https://raw.github.com/arquillian/arquillian-examples/master/arquillian-tutorial/pom-no-container-profiles.xml.