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.
I'm dedicated agile security architect/system architect/developer with specialty of open source framework.
August 16, 2012
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:
In short the installation follow:
- Download the apache maven binaries from the offical website http://maven.apache.org.
- Decompress the binaries. I use /home/magnus/bin/apache-maven-3.0.4 on my local laptop, but for a server I suggest /opt/apache-maven-3.0.4.
- Modify binary path and environment which I previously described here http://magnus-k-karlsson.blogspot.se/2012/04/how-to-set-javahome-environment.html.
$ 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.
You find module in $JBOSS_HOME/modules folder. To create a new module you need to do three things:
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:
- The changed classloading to a more OSGI like architecture.
- The simplification of have only one configuration file.
You find module in $JBOSS_HOME/modules folder. To create a new module you need to do three things:
- Create a folder hierarchy for files.
- Copy module jar files.
- 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 28, 2012
Java EE 6 Annotations - Summary
In my previous blog I have been writing about the CDI and Common Annotations:
- Java EE 6 Annotations - JSR 299: Contexts and Dependency Injection - Part 1
- Java EE 6 Annotations - JSR 299: Contexts and Dependency Injection - Part 2
- Java EE 6 Annotations - JSR 250: Common Annotations
Contexts and Dependency Injection, CDI
JavaServer Faces, JSF
Resource Injection
EJB Injection
EJB Types
Schedule
Transaction
- javax.ejb.TransactionAttribute
- javax.ejb.AfterBegin
- javax.ejb.BeforeCompletion
- javax.ejb.AfterCompletion
Lifecycle
- javax.annotation.PostConstruct (POJO/EJB)
- javax.annotation.PreDestroy (POJO/EJB)
- javax.ejb.PostActivate (EJB)
- javax.ejb.PrePassivate (EJB)
- javax.ejb.Remove (EJB)
Interceptors
Security
Java Persistence API, JPA
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:
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
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.
- JBoss Arquillian, http://www.jboss.org/arquillian.html
- Apache OpenEJB, http://openejb.apache.org/
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.
Subscribe to:
Posts (Atom)
