Oracle has announced that the end of life (EOL) of Java SE 6 has been set to February 2013. Which means that if you have not already upgraded to Java SE 7, now is the time. You can read more about the Oracle Java SE Support Roadmap here.
And for you folks that think that Java SE 7 is a new thing, well, I'm afraid that you are poorly updated. The Java SE 7 was released in February 2011.
If you have graphical interface for Ubuntu, you probably want to run synaptic, but sometime you don't and then it is good to know you Debian packages commands.
Update local cache of available packages
$ sudo apt-get update
Search after package
$ sudo apt-cache search <search_string>
Find out if a package is installed
$ sudo dpkg -s <package_name>
To install package
$ sudo apt-get install default-jdk
Get information about installed packaged
$ sudo dpkg -s <package_name>
Uninstall package
$ sudo apt-get purge <package_name>
Today I had a hard time to install Atheros AR8161 Ethernet Controller on Ubuntu 12.10 (Quantal). Below I will give you a fast guiding how I did.
First a few words about some common network commands that will help you along the way.
For more detailed information, please use the man command, e.g. man lspci.
And here are a few examples of running the above commands.
$ sudo lspci -vv | grep Ethernet
02:00.0 Ethernet controller: Atheros Communications Inc. AR8161 Gigabit Ethernet (rev 08)
Now how to solve your network problem. Whenever you have problem always try to solve it by reading the official vendor pages. I know I do the same thing ask google and millions of answer turns up, but not all of them are good. For me, I first tried to install the drivers from compat-wireless, because I was to lazy to install each official ubuntu packages and they turned up to be quite buggy. So always use official stuff, before going into more experimental things.
So lets do it the official way and that is to use http://askubuntu.com. And here the answer comes up http://askubuntu.com/questions/217361/how-do-i-install-drivers-for-the-atheros-ar8161-ethernet-controller-on-64-bit-12. AND PLEASE USE ANSWER 1, the other will lead you astray.
In this blog I will show you how to use PGP client GNU Privacy Guard (GnuPG) on RHEL 6.3. PGP can be used to encrypt files which can be stored somewhere on remote disc or by sending as attached files.
Installation was quite smooth, except founding the missing dependency package pinentry-gtk, which should be installed automatically.
$ yum install gnupg2 pinentry-gtk
A simple test to see that GnuPG is installed properly is to ask for each version.
$ gpg --version
gpg (GnuPG) 2.0.14
libgcrypt 1.4.5
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA
Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128,
CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
The first thing to do, after installation was successful, is to generate the necessary keys used for encrypting and decrypting files. To generate you private key pair, do the following.
$ gpg --gen-key
gpg (GnuPG) 2.0.14; Copyright (C) 2009 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection?
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)
Requested keysize is 2048 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 2y
Key expires at Thu 15 Jan 2015 08:39:54 PM CET
Is this correct? (y/N) y
GnuPG needs to construct a user ID to identify your key.
Real name: YOUR NAME
Email address: your.name@domain.com
Comment:
You selected this USER-ID:
"YOUR NAME <your.name@domain.com>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
You need a Passphrase to protect your secret key.
etc.
To be able to receive encrypted files, you need to export your public key. The text files generated below can be emailed as attachment or more preferable distributed in a more secure way, such as manually handed over via USB memory.
$ gpg --armor --output "key.txt" --export "YOUR NAME"
Now you are ready to use GnuPG. A good tutorial guide for the most common usage can be found here http://www.glump.net/howto/gpg_intro.
SELinux is a good thing, but when sitting on a test machine, you might not be interesting in configure SELinux to have you application running smoothly, without running into SELinux. So here I will show you how to disable SELinux. Remember that this is NOT recommended for a production environment.
First check the current status of SELinux.
$ sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: disabled
Policy version: 24
Policy from config file: targeted
Now to disable SELinux. Open /etc/selinux/config and edit the below.
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=disabled
Now restart you system and run sestatus again to verify that you configuration changes had taken affect.
ReferenceIn this blog I will show you how to install and configure Subversion (svn) on Red Hat Enterprise Linux (RHEL) 6.3.
First lets install subversion and apache web server, if you already have installed a apache web server, then leave out the httpd package below.
$ yum install subversion httpd mod_dav_svn
Now lets create a new subversion repository named 'demorepo'.
$ Create a new Apache directory
sudo mkdir -p /var/www/svn/demorepo
$ Create a new Subversion repository
svnadmin create /var/www/svn/demorepo
$ Change owner of apache svn
chown -R apache:apache /var/www/svn/demorepo
It is highly recommended to have some authentication to your subversion repository. Here I will use simple login using the built in Apache Web Server module mod_auth_basic. The module is per default installed and configured with the RHEL httpd package, we only need to add new users.
$ htpasswd -c /etc/httpd/conf/passwords magkar
Finally we need to configure the apache web server, for our new web location, but also to apply our authentication. We will facilitate the pre-configured configuration file /etc/httpd/conf.d/subversion.conf that comes with the mod_dav_svn package.
<Location /svn>
DAV svn
SVNParentPath /var/www/svn
# Limit write permission to list of valid users.
<LimitExcept GET PROPFIND OPTIONS REPORT>
# Require SSL connection for password protection.
# SSLRequireSSL
AuthType Basic
AuthName "Authorization Realm"
AuthUserFile /etc/httpd/conf/passwords
Require valid-user
</LimitExcept>
</Location>
Now we only need to restart our apache web server and test our demo subversion repository - http://localhost/svn/demorepo/.
$ service httpd restart
In this blog I will discuss and show you how to setup and use Artifactory as proxy (mirror) for remote repositories, such as Central Maven 2 repository or other remote repository, but also using for internal distribution for corporate releases.
First if you have not installed a Artifactory server, start with that. You can read about the installation steps in my previous blog - http://magnus-k-karlsson.blogspot.se/2013/01/how-to-install-artifactory-on-rhel-63.html.
The next step is to create a settings.xml for you company, that uses this newly installed Artifactory server as proxy/mirror. Creating you own settings.xml can be daunting task, but fear not Artifactory can create one for you. Simply open you web browser and open http://192.168.0.3:8081/artifactory/webapp/mavensettings.html. Here we will also select which internal repository we will use for internal distribution. You can create a new, but here we will use the already created repository 'libs-release'.
Then click Generate Settings and save it to ~/.m2/settings.xml. That was not so hard, lets try it out. Before you continue, make sure that you have installed Maven 3. If you are on a RHEL platform, please read my previous blog http://magnus-k-karlsson.blogspot.se/2013/01/how-to-install-maven-3-on-rhel-63.html.
Now lets create a simple project. I will use Apache Wicket Quickstart here, but you can use any maven project. Open http://wicket.apache.org/start/quickstart.html and copy past the maven command to your terminal.
$ mvn archetype:generate -DarchetypeGroupId=org.apache.wicket -DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=6.4.0 -DgroupId=com.mycompany -DartifactId=myproject -DarchetypeRepository=https://repository.apache.org/ -DinteractiveMode=false
...
Downloading: http://192.168.0.3:8081/artifactory/remote-repos/commons-collections/commons-collections/3.2.1/commons-collections-3.2.1.jar
Downloaded: http://192.168.0.3:8081/artifactory/remote-repos/commons-cli/commons-cli/1.0/commons-cli-1.0.jar (30 KB at 60.3 KB/sec
...
As you can see that maven now request all dependency from you local artifactory server instead from a remote repository. And if you open the artifactory server log you will see that the mirrored remote repository is populated.
$ less /var/log/artifactory/artifactory.log
...
2013-01-11 12:52:44,496 [http-bio-8081-exec-1] [INFO ] (o.a.r.HttpRepo :252) - repo1: Downloading content from 'http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-digest/1.0/plexus-digest-1.0.jar'...
2013-01-11 12:52:44,502 [http-bio-8081-exec-1] [INFO ] (o.a.r.HttpRepo :252) - repo1: Downloading content from 'http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-digest/1.0/plexus-digest-1.0.jar.sha1'...
...
Now if everything is working, lets continue by adding a new remote repository. Lets log into artifactory and select the Admin tab and then Repositories from the left menu and add a new remote repository. Here I will use the new JBoss EAP 6 repository, but you can choose any valid remote repository.
Repository Key: jboss-eap-repository
URL: http://repo1.maven.org/maven2
Public Description: JBoss EAP Maven Repository
Includes Pattern: **/*
Checksum Policy: Generate if absent
Max Unique Snapshots: 0
Handle Releases: true
Handle Snapshots: true
Use default for the rest of the settings.
After added, we will add this remote repository to virtual repository remote-repos. The advantage of using virtual repositories, is that we do not need to updated our settings.xml. The remote-repos is already there by default.
Al right. Now lets test it. Lets open up our wicket pom.xml and add the JBoss EAP Java EE Spec dependency.
<repositories>
<repository>
<id>jboss-eap-repository</id>
<name>JBoss EAP Maven Repository</name>
<url>http://maven.repository.redhat.com/techpreview/all/</url>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>jboss-eap-repository</id>
<name>JBoss EAP Maven Repository</name>
<url>http://maven.repository.redhat.com/techpreview/all/</url>
</pluginRepository>
</pluginRepositories>
<properties>
<wicket.version>6.4.0</wicket.version>
<jetty.version>7.6.3.v20120416</jetty.version>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<jboss.eap.spec.version>3.0.1.Final-redhat-1</jboss.eap.spec.version>
<jboss.eap.impl.version>6.0.1-redhat-1</jboss.eap.impl.version>
</properties>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.jboss.spec</groupId>
<artifactId>jboss-javaee-6.0</artifactId>
<version>${jboss.eap.spec.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>org.jboss.component.management</groupId>
<artifactId>jboss-dependency-management-eap</artifactId>
<version>${jboss.eap.impl.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
After editing you pom.xml, lets test it.
$ mvn clean install
...
Downloading: http://192.168.0.3:8081/artifactory/remote-repos/org/jboss/component/management/jboss-dependency-management-all/6.0.1-redhat-1/jboss-dependency-management-all-6.0.1-redhat-1.pom
Downloaded: http://192.168.0.3:8081/artifactory/remote-repos/org/jboss/component/management/jboss-dependency-management-all/6.0.1-redhat-1/jboss-dependency-management-all-6.0.1-redhat-1.pom (2 KB at 13.2 KB/sec
...
And in your artifactory server log.
...
2013-01-11 12:49:51,074 [http-bio-8081-exec-18] [INFO ] (o.a.r.HttpRepo :252) - jboss-eap-repository: Downloading content from 'http://maven.repository.redhat.com/techpreview/all/org/jboss/spec/jboss-javaee-6.0/3.0.1.Final-redhat-1/jboss-javaee-6.0-3.0.1.Final-redhat-1.pom'...
2013-01-11 12:49:51,518 [http-bio-8081-exec-18] [INFO ] (o.a.r.HttpRepo :252) - jboss-eap-repository: Downloading content from 'http://maven.repository.redhat.com/techpreview/all/org/jboss/spec/jboss-javaee-6.0/3.0.1.Final-redhat-1/jboss-javaee-6.0-3.0.1.Final-redhat-1.pom.sha1'...
...
In this blog I will show you how to install Artifactory on Red Hat Enterprise Linux 6.3.
Artifactory comes in two flavours:
In this blog I will show you how to install the Artifactory Open Source version. So lets get started. First download the latest RPM package from sourceforge - http://sourceforge.net/projects/artifactory/files/artifactory/. Then install it as root.
$ yum localinstall /home/magkar/Downloads/artifactory-2.6.6.rpm
You can read more about what files are installed and where in the Artifactory Installation Guide chapter RPM Installation - http://wiki.jfrog.org/confluence/display/RTF/RPM+Installation. Or list all installed files with rpm command.
$ rpm -ql artifactory
If you want more information about how to work with yum and rpm commands, please read my previous blog - http://magnus-k-karlsson.blogspot.se/2013/01/quickguide-to-most-common-yum-and-rpm.html.
If you are not happy with artifactory, you uninstall it with yum.
$ yum erase artifactory
Now lest test our Artifactory installation. Lets first start it. After started you can access it from http://your_server_ip:8081/artifactory.
$ service artifactory start
And to login use:
username: admin
password: password
And if you are happy with the installation, you can set the artifactory to start automatically when booting, by reading my previous blog here http://magnus-k-karlsson.blogspot.se/2013/01/how-to-autostart-program-at-bootup.html.
In RHEL 6 there is no package for Apache Maven 3 and if you search the official repo you will end up with.
$ yum search maven
...
jpackage-utils.noarch : JPackage utilities
But that package does not contain any maven binaries. So since there is no official package and I do not want to clutter my RHEL installation, by adding custom repositories, we will do it manually. And that is no big thing.
First download the apache maven binaries, I downloaded the zip file. And extract it in /usr/share.
$ unzip /home/magkar/Downloads/apache-maven-3.0.4-bin.zip -d /usr/share/
Now "install" it, i.e. create a soft link.
$ ln -s /usr/share/apache-maven-3.0.4/bin/mvn /usr/bin/mvn
And finally set all needed environment variables in /etc/environment. And for my RHEL 6.3 machine they look like this.
JAVA_HOME=/usr/lib/jvm/java
M2_HOME=/usr/share/apache-maven-3.0.4
Now test your installation of Apache Maven 3.0.4.
$ mvn -version
Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100)
Maven home: /usr/share/apache-maven-3.0.4
Java version: 1.6.0_24, vendor: Sun Microsystems Inc.
Java home: /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "2.6.32-279.19.1.el6.x86_64", arch: "amd64", family: "unix"
JBoss EAP 6 uses JGroups to handle cluster communication. JGroups is a full fledged communication API and you can read more about it here, http://www.jgroups.org/manual-3.x/html/index.html.
Default is JBoss EAP 6 configured to use UDP, but in this blog I will show you how to configure JBoss EAP 6 HA cluster to use TCP multicast networking instead.
JGroups is flexible API, that can stack several protocol on top of each other, or chain them if you like. The JGroups protocol can be divided into the following:
Now revisit our cluster domain example that I have previously described here http://magnus-k-karlsson.blogspot.se/2013/01/how-to-cluster-domain-jboss-eap-6-and.html. But now lets change the global configuration in ./domain/domain/configuration/domain.xml.
<profile name="ha">
...
<subsystem xmlns="urn:jboss:domain:jgroups:1.1" default-stack="tcpping">
<stack name="tcpping">
<transport type="TCP" socket-binding="jgroups-tcp"/>
<protocol type="TCPPING">
<property name="initial_hosts">127.0.0.1[7800],127.0.0.1[8000]</property>
<property name="port_range">0</property>
<property name="timeout">3000</property>
<property name="num_initial_members">2</property>
</protocol>
<protocol type="MERGE2"/>
<protocol type="FD_SOCK" socket-binding="jgroups-tcp-fd"/>
<protocol type="FD"/>
<protocol type="VERIFY_SUSPECT"/>
<protocol type="BARRIER"/>
<protocol type="pbcast.NAKACK"/>
<protocol type="UNICAST2"/>
<protocol type="pbcast.STABLE"/>
<protocol type="pbcast.GMS"/>
<protocol type="UFC"/>
<protocol type="MFC"/>
<protocol type="FRAG2"/>
<protocol type="RSVP"/>
</stack>
...
</subsystem>
...
</profile>
Now if you have already started the cluster you need to restart the Domain Controller and then log into the domain controller with you CLI tool and restart each cluster node.
# Restart you domain controller
$ ./domain/bin/domain.sh --host-config=host-master.xml
# Start the CLI tool at the domain controller
$ ./domain/bin/jboss-cli.sh
# Restart each cluster node, to pick up the new configuration.
[domain@localhost:9999 /] /host=server1/server-config=server-one:restart
{
"outcome" => "success",
"result" => "STARTING"
}
[domain@localhost:9999 /] /host=server2/server-config=server-two:restart
{
"outcome" => "success",
"result" => "STARTING"
}
Watch each cluser server node log for error, if any revisit the above and sort out problems. If everything OK, you should see something similar on server1.
[Server:server-one] 06:20:20,934 INFO [stdout] (ServerService Thread Pool -- 53)
[Server:server-one] 06:20:20,935 INFO [stdout] (ServerService Thread Pool -- 53) -------------------------------------------------------------------
[Server:server-one] 06:20:20,935 INFO [stdout] (ServerService Thread Pool -- 53) GMS: address=server1:server-one/ejb, cluster=ejb, physical address=127.0.0.1:7800
[Server:server-one] 06:20:20,935 INFO [stdout] (ServerService Thread Pool -- 53) -------------------------------------------------------------------
[Server:server-one] 06:20:20,988 INFO [stdout] (ServerService Thread Pool -- 52)
[Server:server-one] 06:20:20,988 INFO [stdout] (ServerService Thread Pool -- 52) -------------------------------------------------------------------
[Server:server-one] 06:20:20,988 INFO [stdout] (ServerService Thread Pool -- 52) GMS: address=server1:server-one/web, cluster=web, physical address=127.0.0.1:7800
[Server:server-one] 06:20:20,989 INFO [stdout] (ServerService Thread Pool -- 52) -------------------------------------------------------------------
...
[Server:server-one] 06:20:21,376 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 54) ISPN000078: Starting JGroups Channel
[Server:server-one] 06:20:21,376 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 53) ISPN000078: Starting JGroups Channel
[Server:server-one] 06:20:21,393 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 53) ISPN000094: Received new cluster view: [server2:server-two/ejb|13] [server2:server-two/ejb, server1:server-one/ejb]
[Server:server-one] 06:20:21,393 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 54) ISPN000094: Received new cluster view: [server2:server-two/web|13] [server2:server-two/web, server1:server-one/web]
...
[Server:server-one] 06:20:21,758 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 54) JBAS010281: Started repl cache from web container
[Server:server-one] 06:20:21,759 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 53) JBAS010281: Started repl cache from ejb container
And host server2.
[Server:server-two] 06:19:02,782 INFO [stdout] (ServerService Thread Pool -- 52)
[Server:server-two] 06:19:02,782 INFO [stdout] (ServerService Thread Pool -- 52) -------------------------------------------------------------------
[Server:server-two] 06:19:02,783 INFO [stdout] (ServerService Thread Pool -- 52) GMS: address=server2:server-two/ejb, cluster=ejb, physical address=127.0.0.1:8000
[Server:server-two] 06:19:02,783 INFO [stdout] (ServerService Thread Pool -- 52) -------------------------------------------------------------------
[Server:server-two] 06:19:02,835 INFO [stdout] (ServerService Thread Pool -- 53)
[Server:server-two] 06:19:02,836 INFO [stdout] (ServerService Thread Pool -- 53) -------------------------------------------------------------------
[Server:server-two] 06:19:02,836 INFO [stdout] (ServerService Thread Pool -- 53) GMS: address=server2:server-two/web, cluster=web, physical address=127.0.0.1:8000
[Server:server-two] 06:19:02,837 INFO [stdout] (ServerService Thread Pool -- 53) -------------------------------------------------------------------
...
[Server:server-two] 06:19:03,238 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 53) ISPN000078: Starting JGroups Channel
[Server:server-two] 06:19:03,238 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 54) ISPN000078: Starting JGroups Channel
[Server:server-two] 06:19:03,254 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 54) ISPN000094: Received new cluster view: [server1:server-one/web|11] [server1:server-one/web, server2:server-two/web]
[Server:server-two] 06:19:03,255 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 54) ISPN000079: Cache local address is server2:server-two/web, physical addresses are [127.0.0.1:8000]
[Server:server-two] 06:19:03,254 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 53) ISPN000094: Received new cluster view: [server1:server-one/ejb|11] [server1:server-one/ejb, server2:server-two/ejb]
[Server:server-two] 06:19:03,258 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 53) ISPN000079: Cache local address is server2:server-two/ejb, physical addresses are [127.0.0.1:8000]
...
[Server:server-two] 06:19:03,569 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 52) JBAS010281: Started repl cache from ejb container
[Server:server-two] 06:19:03,571 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 54) JBAS010281: Started repl cache from web container
Now in the JBoss EAP 6 Administration and Configuration Guide there is suggested to turn off the ServerAdvertise in the Apache Web Server mod_cluster, we do that and restart everything. After restart make sure that mod_cluster is up and running, by checking every cluster node is registered in the http://127.0.0.1:6666/mod_cluster_manager.
Now you can test the clustered application by open http://127.0.0.1/cluster/index.jsf.
When reading the official Oracle J2EE 6 Tutorial there are very few complete and runnable example. So in this blog I will have a go with a simple Hello World REST example. REST is build on top web service and some people might right now be sceptical. But the REST architecture is said to deliver. The other problem with web service, is that is so many implementation, depending on which platform you are deploying to. In this blog I will use the reference implementation of JAX-RS, Jersey - http://docs.oracle.com/javaee/6/tutorial/doc/giepu.html.
After that said, lets get started with our first runnable Hello World REST example with Jersey.
package se.msc.example.rest.jersey;
@javax.ws.rs.Path("/helloWorldRestJersey")
public class HelloWorldRestJersey {
@javax.ws.rs.GET
@javax.ws.rs.Path("/{param}")
public javax.ws.rs.core.Response getMsg(
@javax.ws.rs.PathParam("param") String msg) {
String entity = "Rest Jersey response " + msg;
return javax.ws.rs.core.Response.status(200).entity(entity).build();
}
}
And here is the web.xml that contains the dispatcher servlet.
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
version="3.0">
<display-name>Archetype Created Web Application</display-name>
<servlet>
<servlet-name>jersey-serlvet</servlet-name>
<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value>se.msc.example.rest.jersey</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>jersey-serlvet</servlet-name>
<url-pattern>/rest/*</url-pattern>
</servlet-mapping>
</web-app>
And finally our pom.xml, that shows the jersey dependency and a maven jetty plugin, which we will use for running our example.
<?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/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>se.msc.examples</groupId>
<artifactId>example-rest-jersey</artifactId>
<packaging>war</packaging>
<version>1.0-SNAPSHOT</version>
<name>Rest Example with Jersey (Reference Implementation of JAX-RS)</name>
<url>http://magnus-k-karlsson.blogspot.se/</url>
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<project.build.outputEncoding>UTF-8</project.build.outputEncoding>
<jetty.version>7.5.0.v20110901</jetty.version>
<jersey.version>1.16</jersey.version>
</properties>
<dependencies>
<!-- Jersey JAX-RS -->
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-core</artifactId>
<version>${jersey.version}</version>
</dependency>
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-server</artifactId>
<version>${jersey.version}</version>
</dependency>
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-servlet</artifactId>
<version>${jersey.version}</version>
</dependency>
<!-- Test Support -->
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.10</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<finalName>${project.artifactId}</finalName>
<plugins>
<plugin>
<inherited>true</inherited>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.5.1</version>
<configuration>
<source>1.6</source>
<target>1.6</target>
<encoding>${project.build.sourceEncoding}</encoding>
<showWarnings>true</showWarnings>
<showDeprecation>true</showDeprecation>
</configuration>
</plugin>
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>${jetty.version}</version>
<configuration>
<scanIntervalSeconds>1</scanIntervalSeconds>
<useTestClasspath>true</useTestClasspath>
<connectors>
<connector implementation="org.eclipse.jetty.server.nio.SelectChannelConnector">
<port>8080</port>
<maxIdleTime>3600000</maxIdleTime>
</connector>
</connectors>
</configuration>
<dependencies>
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-core</artifactId>
<version>${jersey.version}</version>
</dependency>
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-server</artifactId>
<version>${jersey.version}</version>
</dependency>
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-servlet</artifactId>
<version>${jersey.version}</version>
</dependency>
</dependencies>
</plugin>
</plugins>
</build>
</project>
Now lets test our application.
$ mvn jetty:run
For you people out there, that have wonder why you should override equals() and hashcode(), when writing your Entity Beans, please read this JBoss wiki https://community.jboss.org/wiki/EqualsandHashCode
One of the maybe most imported task after deployment, is to establish a good monitoring tool. The standardized tool for Java is JConsole.
To remotely connect to a application server, have previously been a pain, but the standardization work has finally given some fruit. The JBoss EAP 6 and AS 7 server now supports the JSR 160 - JMX Remote API for remote management and monitoring. The JSR 160 is a great leap forward, since the standard does not build upon RMI, which makes it really hard to use behind a firewall and only have access via SSH port. So now is JMXConnector used and under the hood uses JBoss its own remoting libraries. The only drawback with this is that you have to add these dependency libraries when starting jconsole. But Red Hat had already provided a ready cooked script for that.
So lets start trying this out. Start with by unzipping a fresh jboss-eap-6.0.1.zip to a new folder and start the server in standalone mode.
$ ./jboss-eap-6.0/bin/standalone.sh -Djboss.bind.address=192.168.0.3 -Djboss.bind.address.management=192.168.0.3
The next thing we need to is to create a management user, since the JMXConnector requires login. We create new users with the add-user.sh script.
$ ./jboss-eap-6.0/bin/add-user.sh
What type of user do you wish to add?
a) Management User (mgmt-users.properties)
b) Application User (application-users.properties)
(a): a
Enter the details of the new user to add.
Realm (ManagementRealm) :
Username : admin
Password :
Re-enter Password :
The username 'admin' is easy to guess
Are you sure you want to add user 'admin' yes/no? yes
About to add user 'admin' for realm 'ManagementRealm'
Is this correct yes/no? yes
Added user 'admin' to file '/home/magkar/tmp/jboss-eap-6.0/standalone/configuration/mgmt-users.properties'
Added user 'admin' to file '/home/magkar/tmp/jboss-eap-6.0/domain/configuration/mgmt-users.properties'
Is this new user going to be used for one AS process to connect to another AS process?
e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls.
yes/no? yes
To represent the user add the following to the server-identities definition <secret value="cGFzc3dvcmQ=" />
Now we are ready to start the jconsole on a remote machine, with the jconsole.sh script.
$ ./jboss-eap-6.0/bin/jconsole.sh
Before starting the jconsole, be sure that you have set the JAVA_HOME environment variable.
Now you can remotely login to service:jmx:remoting-jmx://192.168.0.3:9999, with the above credential.
In my previous blog I showed how to cluster with JBoss EAP 6.0.3 in standalone mode, but standalone mode is really used in production, where the domain mode is the preferred way to manage multiple JBoss installations.
In this blog I will also cluster two JBoss nodes, but started in domain mode. To achieve that we need a domain master (domain controller) and slave (host controller), that push and respectively receive configuration. The deployment scenario is the following.
I have in the deployment diagram also added the concerned configuration file for each artifact, which I hope will help you to remember which configuration files goes to which artifact. Lets get started, but first some prerequisites.
Prerequisites:
In this blog I will start everything up on the same machine, which is adequate for testing, but of course not for production, so when you move to production you need to change interfaces IP for each JBoss. But that is about it. Lets get started.
To simulate and keep things separated I have extracted the jboss-eap-6.0.1.zip into three folders:
The domain controller is configured with three configuration files.
Lets first define our server group in ./domain/domain/configuration/domain.xml.
<server-groups>
<server-group name="cluster-ha" profile="ha">
<jvm name="default"/>
<socket-binding-group ref="ha-sockets"/>
</server-group>
</server-groups>
Then we will leave the ./domain/domain/configuration/host-master.xml unaltered and use defaults. The part that points out that this is domain controller is the below.
<domain-controller>
<local/>
</domain-controller>
The last thing we need to do is to create a management user in the domain controller.
$ ./domain/bin/add-user.sh
What type of user do you wish to add?
a) Management User (mgmt-users.properties)
b) Application User (application-users.properties)
(a): a
Enter the details of the new user to add.
Realm (ManagementRealm) :
Username : domainadmin
Password :
Re-enter Password :
About to add user 'domainadmin' for realm 'ManagementRealm'
Is this correct yes/no? yes
Added user 'domainadmin' to file '/home/magkar/tmp/domain/standalone/configuration/mgmt-users.properties'
Added user 'domainadmin' to file '/home/magkar/tmp/domain/domain/configuration/mgmt-users.properties'
Is this new user going to be used for one AS process to connect to another AS process?
e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls.
yes/no? yes
To represent the user add the following to the server-identities definition <secret value="cGFzc3dvcmQ=" />
Now we are ready to start the domain controller.
$ ./domain/bin/domain.sh --host-config=host-master.xml
If you wanted to bind the domain controller to a specific IP, you would have used the -Djboss.bind.address.management. Which property you see in the interface element in the host-master.xml configuration file.
Now lets move onto the host controller.
A host controller is a slave to the domain controller which listen for configuration and start/stop instruction. The host controller then feeds that information to all server node on a physical machine. The host controller is not really something special to only domain mode, but is also present in a standalone mode, but then not really used.
Lets get started with the configuration for the host controller. Lets open ./host1/domain/configuration/host-slave.xml and define the server nodes that will be managed by this host controller.
<host name="server1" xmlns="urn:jboss:domain:1.3">
...
<servers>
<server name="server-one" group="cluster-ha" auto-start="false">
<socket-bindings port-offset="200"/>
</server>
</servers>
</host>
Since we are running everything on the same machine, we need to set the port-offset property. If this was running on a dedicated server you leave that out.
We use the server group that was defined in the domain controller.
Next we need to set up security to the domain controller. The host controller needs to know how to establish a connection to the domain controller. Here we use the same base64 password that we recieved when creating the management user for the domain controller.
<host name="server1" xmlns="urn:jboss:domain:1.3">
...
<security-realm name="ManagementRealm">
<server-identities>
<secret value="cGFzc3dvcmQ=" />
</server-identities>
...
</security-realm>
...
<domain-controller>
<remote host="${jboss.domain.master.address}" port="${jboss.domain.master.port:9999}" username="domainadmin" security-realm="ManagementRealm"/>
</domain-controller>
</host>
The last thing we need to change, and this is because we are running everything on the same machine is the management port.
<host name="server1" xmlns="urn:jboss:domain:1.3">
...
<native-interface security-realm="ManagementRealm">
<socket interface="management" port="${jboss.management.native.port:19999}"/>
</native-interface>
...
</host>
Now lets multiply the above configuration to host 2 also.
<host name="server2" xmlns="urn:jboss:domain:1.3">
...
<security-realm name="ManagementRealm">
<server-identities>
<secret value="cGFzc3dvcmQ=" />
</server-identities>
...
</security-realm>
...
<socket interface="management" port="${jboss.management.native.port:29999}"/>
...
<domain-controller>
<remote host="${jboss.domain.master.address}" port="${jboss.domain.master.port:9999}" username="domainadmin" security-realm="ManagementRealm"/>
</domain-controller>
...
<servers>
<server name="server-two" group="cluster-ha" auto-start="false">
<socket-bindings port-offset="400"/>
</server>
</servers>
</host>
Now we are ready to start the host controllers.
$ ./host1/bin/domain.sh --host-config=host-slave.xml -Djboss.domain.master.address=127.0.0.1
$ ./host2/bin/domain.sh --host-config=host-slave.xml -Djboss.domain.master.address=127.0.0.1
You should now see the following in the domain controller log.
[Host Controller] 02:05:43,589 INFO [org.jboss.as.domain] (slave-request-threads - 1) JBAS010918: Registered remote slave host "server1", JBoss EAP 6.0.1.GA (AS 7.1.3.Final-redhat-4)
[Host Controller] 02:06:54,395 INFO [org.jboss.as.domain] (slave-request-threads - 1) JBAS010918: Registered remote slave host "server2", JBoss EAP 6.0.1.GA (AS 7.1.3.Final-redhat-4)
To test is installation, we need a clustered application. I will as in my earlier blog borrow a ready application from https://github.com/akquinet/jbosscc-as7-examples/tree/master/cluster-example.
But now we will use the new JBoss CLI tool to deploy and start and stop our server nodes. See my previous blog on how to deploy with CLI http://magnus-k-karlsson.blogspot.se/2013/01/how-to-deploy-and-undeploy-in-jboss-eap.html.
$ ./domain/bin/jboss-cli.sh
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /] connect
[domain@localhost:9999 /] deploy /home/magkar/Downloads/cluster-example-1.0-SNAPSHOT.war --server-groups=cluster-ha
If you now look in each host controller log file, you should see the deployment. If everything is ok. Lets test the application, open http://127.0.0.1/cluster/index.jsf.
Now lets stop the server node, that you were served and test the replication.
[domain@localhost:9999 /] /host=server1/server-config=server-one:stop
{
"outcome" => "success",
"result" => "STOPPING"
}
And you should now see in that node server log.
[Server:server-one] 02:15:38,454 INFO [org.jboss.as] (MSC service thread 1-3) JBAS015950: JBoss EAP 6.0.1.GA (AS 7.1.3.Final-redhat-4) stopped in 1000ms
02:15:38,472 INFO [org.jboss.as.process.Server:server-one.status] (reaper for Server:server-one) JBAS012010: Process 'Server:server-one' finished with an exit status of 0
Lets now hit the application again.
In this blog I will show you how to cluster two JBoss standalone servers.
Prerequisites:
When you have the prerequisites up and running we are ready to start the JBoss servers. Here I will start with the most simple configuration, i.e. standalone-ha mode.
To simulate a more real situation I have unziped jboss-eap-6.0.1.zip to two different folders, jb1 and jb2. Now lets start each JBoss server.
$ ./jb1/bin/standalone.sh -Djboss.node.name=jb1 --server-config=standalone-ha.xml
Since we will be running two servers on the same machine we need to differentiate the servers ports. This can easy be made with the JBoss property port-offset.
$ ./jb2/bin/standalone.sh -Djboss.node.name=jb2 --server-config=standalone-ha.xml -Djboss.socket.binding.port-offset=200
Now you should see in each JBoss log file that it picked up mod_cluster.
04:26:42,195 INFO [org.jboss.modcluster.ModClusterService] (ServerService Thread Pool -- 54) Initializing mod_cluster 1.2.3.Final-redhat-1
04:26:51,782 INFO [org.jboss.modcluster.ModClusterService] (ContainerBackgroundProcessor[StandardEngine[jboss.web]]) Engine [jboss.web] will use jvmRoute: 4e6189af-0502-3305-8ff3-fad7fee8b516
Also verify that mod_cluster in Apache Web Server has detected the two JBoss servers.
If mod_cluster have not detected two server or they have not Status: OK, then stop here and check the Apache Web Server error log file (/etc/httpd/logs/error_log) and JBoss server log file (./jb1/standalone/log/server.log).
In my case had SELinux problem that stopped the second JBoss instance to be properly detected by mod_cluster in Apache Web Server. I received the following error message in /etc/httpd/logs/error_log.
(13)Permission denied: proxy: ajp: attempt to connect to 127.0.0.1:8259 (127.0.0.1) failed
To temporarily disable that, run the below on RHEL 6.3. For a lengthier description see http://sysadminsjourney.com/content/2010/02/01/apache-modproxy-error-13permission-denied-error-rhel/.
$ /usr/sbin/setsebool httpd_can_network_connect 1
Since the new JBoss load modules lazily, you will not see much in the log file, without a cluster application. You can write you own clustered application, but that is out of scope for this blog, so I copied a simple application from https://github.com/akquinet/jbosscc-as7-examples/tree/master/cluster-example.
Now deploy the clusterd application to each JBoss deploy folder $JBOSS_HOME/standalone/deployments/. And you see in each JBoss log file, that they have started Infinispan, and clustering have detected each other.
jb1
--------
12:56:42,923 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 26) ISPN000078: Starting JGroups Channel
12:56:42,932 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 26) ISPN000094: Received new cluster view: [jb1/web|0] [jb1/web]
12:56:42,935 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 26) ISPN000079: Cache local address is jb1/web, physical addresses are [127.0.0.1:55200]
12:56:42,941 INFO [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 26) ISPN000128: Infinispan version: Infinispan 'Brahma' 5.1.8.Final
12:56:42,942 INFO [org.infinispan.config.ConfigurationValidatingVisitor] (ServerService Thread Pool -- 26) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
12:56:43,054 INFO [org.infinispan.config.ConfigurationValidatingVisitor] (ServerService Thread Pool -- 23) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
12:56:43,104 INFO [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 23) ISPN000031: MBeans were successfully registered to the platform mbean server.
12:56:43,104 INFO [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 26) ISPN000031: MBeans were successfully registered to the platform mbean server.
12:56:43,192 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 26) JBAS010281: Started repl cache from web container
12:56:43,193 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 23) JBAS010281: Started default-host/mod_cluster-demo-server-1.2.0.Final cache from web container
12:56:43,211 INFO [org.jboss.as.clustering] (MSC service thread 1-2) JBAS010238: Number of cluster members: 1
12:56:43,251 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-1) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
12:56:43,262 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-1) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
12:56:43,269 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-1) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
12:56:43,376 INFO [org.jboss.web] (MSC service thread 1-1) JBAS018210: Registering web context: /mod_cluster-demo-server-1.2.0.Final
12:56:43,547 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS018559: Deployed "mod_cluster-demo-server-1.2.0.Final.war"
12:56:46,269 INFO [org.jboss.as.clustering] (Incoming-1,null) JBAS010225: New cluster view for partition web (id: 1, delta: 1, merge: false) : [jb1/web, jb2/web]
12:56:46,271 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-1,null) ISPN000094: Received new cluster view: [jb1/web|1] [jb1/web, jb2/web]
jb2
--------
12:56:46,602 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 55) ISPN000078: Starting JGroups Channel
12:56:46,612 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 55) ISPN000094: Received new cluster view: [jb1/web|1] [jb1/web, jb2/web]
12:56:46,613 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (ServerService Thread Pool -- 55) ISPN000079: Cache local address is jb2/web, physical addresses are [127.0.0.1:55300]
12:56:46,618 INFO [org.infinispan.factories.GlobalComponentRegistry] (ServerService Thread Pool -- 55) ISPN000128: Infinispan version: Infinispan 'Brahma' 5.1.8.Final
12:56:46,619 INFO [org.infinispan.config.ConfigurationValidatingVisitor] (ServerService Thread Pool -- 55) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
12:56:46,723 INFO [org.infinispan.config.ConfigurationValidatingVisitor] (ServerService Thread Pool -- 57) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
12:56:46,765 INFO [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 57) ISPN000031: MBeans were successfully registered to the platform mbean server.
12:56:46,765 INFO [org.infinispan.jmx.CacheJmxRegistration] (ServerService Thread Pool -- 55) ISPN000031: MBeans were successfully registered to the platform mbean server.
12:56:46,920 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 57) JBAS010281: Started default-host/mod_cluster-demo-server-1.2.0.Final cache from web container
12:56:46,962 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 55) JBAS010281: Started repl cache from web container
12:56:46,973 INFO [org.jboss.as.clustering] (MSC service thread 1-1) JBAS010238: Number of cluster members: 2
12:56:47,044 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-2) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
12:56:47,062 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-2) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
12:56:47,063 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-2) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
12:56:47,189 INFO [org.jboss.web] (MSC service thread 1-2) JBAS018210: Registering web context: /mod_cluster-demo-server-1.2.0.Final
12:56:47,393 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "mod_cluster-demo-server-1.2.0.Final.war"
After successful deployment, now lets try the web app, http://127.0.0.1/cluster/index.jsf.
Now to test the failover capability kill the server you was served for. And then hit http://127.0.0.1/cluster/index.jsf again.
When I wanted to install the JBoss EAP 6.0.1 native components and Webserver Connector natives on RHEL 6.3 I had some hard time. The only thing I knew was that I wanted to install them via RPM package, so I could get the nice built in management support for upgrades, reinstall and uninstall. But finding the correct packages was not that obvious.
As usual when knowing the answer everything is easy, which I'm going to present to you below.
First install JBoss EAP 6.0.1 via yum. That is described in the JBoss EAP 6 Installation Guide, which you can find here https://access.redhat.com/knowledge/docs/en-US/JBoss_Enterprise_Application_Platform/6/html/Installation_Guide/Install_JBoss_Enterprise_Application_Platform_6_using_the_Red_Hat_Network_RPM_installation.html
$ yum groupinstall jboss-eap6
If you then grab the yum group info for that group package and then the list the installed file, you will see that the JBoss EAP 6 native components are already bundled in the jboss-eap6 group package.
$ yum groupinfo jboss-eap6
Group: JBoss EAP 6
Mandatory Packages:
jbossas-appclient
jbossas-bundles
jbossas-core
jbossas-domain
jbossas-hornetq-native
jbossas-jbossweb-native
jbossas-modules-eap
jbossas-product-eap
jbossas-standalone
jbossas-welcome-content-eap
$ rpm -ql jbossas-hornetq-native
/usr/share/jbossas/modules/org/hornetq/main/lib
/usr/share/jbossas/modules/org/hornetq/main/lib/linux-x86_64
/usr/share/jbossas/modules/org/hornetq/main/lib/linux-x86_64/libHornetQAIO.so
$ rpm -ql jbossas-jbossweb-native
/usr/share/jbossas/modules/org/jboss/as/web/main/lib
/usr/share/jbossas/modules/org/jboss/as/web/main/lib/linux-x86_64
/usr/share/jbossas/modules/org/jboss/as/web/main/lib/linux-x86_64/libapr-1.so
/usr/share/jbossas/modules/org/jboss/as/web/main/lib/linux-x86_64/libcrypto.so
/usr/share/jbossas/modules/org/jboss/as/web/main/lib/linux-x86_64/libssl.so
/usr/share/jbossas/modules/org/jboss/as/web/main/lib/linux-x86_64/libtcnative-1.so
If you do not want install the JBoss EAP 6 via yum, you can do that manually which for example is described here - http://www.opensourcearchitect.com/tutorials/instaling-eap-600-rhel-6x. But I do not recommend that for JBoss EAP 6, because it is already nice packaged. If you are installing JBoss EAP 5.x, you probably want to take that path, but no for JBoss EAP 6.
The next thing is to install JBoss EAP 6 Webserver Connector Natives, but before doing that you need to install Apache Web Server, which I have earlier described here, http://magnus-k-karlsson.blogspot.se/2013/01/install-apache-web-server-on-red-hat.html
After you have installed Apache Web Server you only need to install two packages.
$ yum install mod_jk-ap22 mod_cluster-native
After installation you can list the installed files.
$ rpm -ql mod_jk-ap22
/usr/lib64/httpd/modules/mod_jk.so
/usr/share/doc/mod_jk-ap22-1.2.36
/usr/share/doc/mod_jk-ap22-1.2.36/LICENSE
/usr/share/doc/mod_jk-ap22-1.2.36/NOTICE
/usr/share/doc/mod_jk-ap22-1.2.36/README.txt
/usr/share/doc/mod_jk-ap22-1.2.36/TODO.txt
/usr/share/doc/mod_jk-ap22-1.2.36/mod_jk.conf.sample
/usr/share/doc/mod_jk-ap22-1.2.36/workers.properties.sample
/var/run/mod_jk
$ rpm -ql mod_cluster-native
/etc/httpd/conf.d/mod_cluster.conf
/usr/lib64/httpd/modules/mod_advertise.so
/usr/lib64/httpd/modules/mod_manager.so
/usr/lib64/httpd/modules/mod_proxy_cluster.so
/usr/lib64/httpd/modules/mod_slotmem.so
/usr/share/doc/mod_cluster-native-1.2.3
/usr/share/doc/mod_cluster-native-1.2.3/JBossORG-EULA.txt
/usr/share/doc/mod_cluster-native-1.2.3/README.txt
/usr/share/doc/mod_cluster-native-1.2.3/lgpl.txt
/usr/share/doc/mod_cluster-native-1.2.3/release.txt
/usr/share/selinux/packages/mod_cluster-native
/usr/share/selinux/packages/mod_cluster-native/mod_cluster-native.pp
/var/cache/mod_cluster
As you can see from the list of installed files, the mod_cluster-native package have already added a configuration file for the Apache Web Server - /etc/httpd/conf.d/mod_cluster.conf. After restarted you Apache Web Server you can test you mod cluster, by open a web browser and point it to http://127.0.0.1:6666/mod_cluster_manager.
In this blog I will show you how to install Apache Web Server on RHEL 6.3.
$ yum install httpd
$ service httpd start
$ netstat -tulpn | grep :80
tcp 0 0 1.1.1.64:80 0.0.0.0:* LISTEN
$ system-config-firewall
$ vi /etc/sysconfig/httpd
and change to
#
# The default processing model (MPM) is the process-based
# 'prefork' model. A thread-based model, 'worker', is also
# available, but does not work with some modules (such as PHP).
# The service must be stopped before changing this variable.
#
HTTPD=/usr/sbin/httpd.worker
$ service httpd restart
$ ps -ef | grep httpd
root 3060 1 0 10:52 ? 00:00:00 /usr/sbin/httpd.worker
apache 3062 3060 0 10:52 ? 00:00:00 /usr/sbin/httpd.worker
apache 3063 3060 0 10:52 ? 00:00:00 /usr/sbin/httpd.worker
root 3431 3231 0 11:20 pts/1 00:00:00 grep httpd
If you have trouble restart Apache Web Server after activating workers, you might need to define listening ip:port
$ vi /etc/httpd/conf/httpd.conf
#
# Listen: Allows you to bind Apache to specific IP addresses and/or
# ports, in addition to the default. See also the <VirtualHost>
# directive.
#
# Change this to Listen on specific IP addresses as shown below to
# prevent Apache from glomming onto all bound IP addresses (0.0.0.0)
#
Listen 1.1.1.64:80
#Listen 80
The first thing you probably want to learn better after have installed a RHEL or Fedora system, is how you manage your programs. And the answer to that is the command yum or rpm. Below follows a list of the most common yum and rpm commands.
$ yum search term
$ yum info package_name
$ yum list installed package_name
$ yum list all
$ rpm -ql package_name
$ repoquery -q -l --plugins package_name
* Note repoquery requires packages yum-utils to be installed.
$ yum provides \*filename_to_search_after
$ yum install package_name
$ yum check-update
$ yum update
RHEL (Red Hat Enterprise Linux) has a uniform way to auto start application when booting or more strictly said, how to enable a service.
$ chkconfig service_name on
And to verify/list that service is enable.
$ chkconfig --list service_name
And to list all services.
$ chkconfig --list
And to disable a service.
$ chkconfig service_name off
References:
In this blog I will present how to deploy application with JBoss EAP 6 and JBoss AS 7, both via the new Command Line Interface, CLI and the traditional way, by dropping deployable in deployment folder.
The easiest way is to start the JBoss in standalone and drop the deployable package in $JBOSS_HOME/standalone/deployments/ folder. If successfully deployed you will a get a new marker file in the deployment folder with extension .deployed.
To undeploy simply remove the deployable file.
And to redeploy simply touch a file with the same name as deployable + ".dodeploy".
The new and recommended way to manage deployments are via the CLI tool. Before you can proceed with the CLI you must first start your JBoss. Then you start the CLI with $JBOSS_HOME/bin/jboss-cli.sh.
To connect to local server simply type connect. And if you want to start a remote server, the easiest way is to open a SSH tunnel to the remote server and do the above.
$ connect
To deploy, use the deploy command. Remember that JBoss CLI has autocompletion, which means you can use the tab key for autocompletion of paths and commands.
deploy /tmp/demo-1.0-SNAPSHOT.war
To verify the deployment, you can either do that with the JBoss CLI tool.
$ cd deployment=
$ ls -l
demo-1.0-SNAPSHOT.war
Or open the standalone.xml file.
<deployments>
<deployment name="demo-1.0-SNAPSHOT.war" runtime-name="demo-1.0-SNAPSHOT.war">
<content sha1="303fe111257bf4f083d3f0e3f403b4f5e7e1de0c"/>
</deployment>
</deployments>
And to undeploy.
undeploy demo-1.0-SNAPSHOT.war
The development environment for Apache Wicket is really good. In this blog I will show you how to run Apache Wicket web application with the maven jetty plugin, but also how to debug your web application.
First lets get started with creating a simple Apache Wicket web application with the wicket maven archetype. If you are not familiar with maven archetype, please read http://maven.apache.org/guides/introduction/introduction-to-archetypes.html. To get the latest version of Apache Wicket, please visit http://wicket.apache.org/start/quickstart.html. In this blog I will make some changes to this Apache Wicket Quickstart, which I will describe below and why I have made them.
First remove the extra repository from the archetype command. This extra repository is not necessary and In my opinion you should as far as possible stick with standard repository, as long as possible. The final archetype command I used looks the following:
$ mvn archetype:generate -DarchetypeGroupId=org.apache.wicket -DarchetypeArtifactId=wicket-archetype-quickstart -DarchetypeVersion=6.4.0 -DgroupId=se.msc.examples -DartifactId=wicket -DinteractiveMode=false
After finished you can import the maven project into Eclipse or you preferred IDE. Now open the pom.xml. I made the following changes.
1. Add UTF-8 encoding to reporting.
<properties>
<project.build.outputEncoding>UTF-8</project.build.outputEncoding>
</properties>
2. Add wicket extra dependency.
<!-- OPTIONAL DEPENDENCY -->
<dependency>
<groupId>org.apache.wicket</groupId>
<artifactId>wicket-extensions</artifactId>
<version>${wicket.version}</version>
</dependency>
<dependency>
<groupId>org.apache.wicket</groupId>
<artifactId>wicket-datetime</artifactId>
<version>${wicket.version}</version>
</dependency>
3. Add the following configuration to the jetty-maven-plugin.
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>${jetty.version}</version>
<configuration>
<scanIntervalSeconds>1</scanIntervalSeconds>
<useTestClasspath>true</useTestClasspath>
<webXml>${basedir}/src/test/resources/override-web.xml</webXml>
<connectors>
<connector
implementation="org.eclipse.jetty.server.nio.SelectChannelConnector">
<port>8080</port>
<maxIdleTime>3600000</maxIdleTime>
</connector>
</connectors>
</configuration>
</plugin>
The scanIntervalSeconds configuration makes the jetty web server automatically restart whenever you make changes in you IDE. This makes coding easy and you can directly see you changes in your web browser.
The next configuration (useTestClasspath) adds you test code to the jetty web server classpath. This is convenient if you want to mock your server facade.
And with last configuration (webXml) you can switch the standard web.xml with a completely mocked web.xml, which may contain no security classpaths to you mocked classes.
To run the maven jetty plugin, simply open a terminal and write
$ mvn jetty:run
The last and maybe the most imported is the debug capability. The Apache Wicket archetype comes also with a jetty web server that is started from a java class /src/test/java/se/msc/examples/Start.java. And if you do not need the SSL support I recommend you to comment that code out. Now simple right click on Start class and select Debug As → Java Application. Add breakpoints and open that page in you web browser. Easy and elegant.
References: