How to Kill thread-dump from Tomcat or JBoss

January 26, 2010 · Leave a Comment
Filed under: Featured, Tomcat 

Getting a thread-dump is one of the first steps in troubleshooting a misbehaving Java application. There are a few good ways todo this task but the easiest of them all is

kill -3 <PID>




This will send the thread-dump to your stdout logs.

Securing JBOSS JMX and Web

November 21, 2009 · Leave a Comment
Filed under: Featured, JBoss 

Install

Install JBoss Application server 4.2 or EAP 4.2

Download from here. Install in the usual way. For the zip distribution simply unzip in a directory of your choice.
If you are installing JBoss Application Server you’ll end up having a directory called jboss-4.2.X.GA where X is the minor version of the server you’ve downloaded. Current latest version is 4.2.1.
If you are installing JBoss EAP 4.2 then you’ll probably have a directory called jboss-eap-4.2.
I will call $JBOSS_HOME “jboss-eap-4.2/jboss-as” or jboss-4.2.X.GA depending on the what you’ve installed.

Set HUDSON_HOME

Just  export HUDSON_HOME=<some dir> (UNIX) or set HUDSON_HOME=<some dir> (Windows) before starting JBoss Server.

Deploy hudson.war

Copy hudson war to “$JBOSS_HOME/server/<your server>/deploy”. <your server> will most probably be “default” but could be “production” if you have installed JBoss EAP and have more than 2G RAM.

Start JBoss Server

cd  $JBOSS_HOME
bin/run.sh -b 0.0.0.0 -c  <your server>
Important! If you need security, e.g will enable hudson security and have network connections to untrusted networks make sure to secure your jmx and web console before starting the server that way! JBoss EAP is secured by default but you should follow “getting started” instructions for the community release. Until you do, start the server with “-b 127.0.0.1″ to be locally accessible only.

Access Hudson GUI

Open in a browser http://<machine name>:8080/hudson

Additional Configuration

JBoss startup

I would recommend setting at least 2 options when starting jboss as a container for hudson- “-Djava.awt.headless=true” and “-Xmx<some reasonable value>“.
The first one is even required for hudson if there is no X server available by an UNIX installation but will safe you from troubles anyways. More information about headless mode here.
Then setting maximum available memory for use by the server depends on jobs that will be executed as well hudson plug-ins that get used. We’ve hit out of memory issues with the junit report plug-in as it needs much memory to prepare big reports. Keep in mind that you will need to have enough memory to handle communications with slaves. And when getting OOM be sure to understand where does it come from – master or slave. To be able to handle the large number junit tests per job we’ve had to boost memory on both – master and slaves.

To pass these options you can set the environment variable JAVA_OPTS:

Linux: export JAVA_OPTS="$JAVA_OPTS -Djava.awt.headless=true -Xmx<some reasonable value>"

Windows: set JAVA_OPTS=%JAVA_OPTS% -Djava.awt.headless=true -Xmx<some reasonable value>

As well you can modify run.sh/bat to avoid having that environment variable set for the child processes (jobs are one of them) you run. I use the following ugly bash script to avoid modifying that:

#!/bin/bash

if [[ `dirname "$0"` != "." ]]; then
   cd `dirname "$0"` || exit 2
   exec $SHELL -- `basename "$0"` "$@"
fi

(
JAVA_OPTS="$JAVA_OPTS -Djava.awt.headless=true $MAX_JAVA_MEM"
cd $JBOSS_HOME/bin
. run.sh -c default -b 0.0.0.0 -u $MCAST_ADDR -g Hudson
) &> ~/hudson.log < /dev/null &

Make sure to have JBOSS_HOME and MAX_JAVA_MEM set.

Securing Hudson

Configure login when delegating auth to container

FOR MORE COMPLETE DOCUMENTATION SEE http://www.jboss.org/community/docs/DOC-12188

I’ll describe one easy way to do. It’s most suitable for local installations or where you have the jboss server hudson dedicated. You could ofcource implement whatever authentication mechanism you need. Refer to the JBoss manual pages for more information. User forums and mailing lists are the best place to get help.
First you’ll need to deploy hudson unarchived:

  • cd $JBOSS_HOME/server/<your server>/deploy/
  • mkdir hudson.war
  • unzip <path>/hudson.war
  • cd hudson.war/WEB-INF
  • create file jboss-web.xml containing:

<jboss-web>
<security-domain>java:/jaas/jmx-console</security-domain>
</jboss-web>

Configure JBoss AS to do auth and secure

  • Most steps are already done when using the JBoss Enterprise Application Platform
  • cd  $JBOSS_HOME/server/<your server>/conf/props
  • add “hudson=admin” to jmx-console-roles.properties
  • add “hudson=passwd” to jmx-console-users.properties
  • restart server
    Then:
  • enable security
  • login as user “hudson” with password “passwd”

Secure jmx and web console:

  • edit $JBOSS_HOME/server/<your server>/conf/login-config.xml
    • uncomment “<application-policy name = “jmx-console”>” lines
    • uncomment “<application-policy name = “web-console”>” lines
  • edit $JBOSS_HOME/server/<your server>/deploy/jmx-console.war/WEB-INF/jboss-web.xml
    • uncomment <security-domain>
  • edit $JBOSS_HOME/server/<your server>/deploy/jmx-console.war/WEB-INF/web.xml
    • uncomment lines after “A security constraint that restricts access…”
  • edit $JBOSS_HOME/server/<your server>/deploy/management/console-mgr.sar/web-console.war/WEB-INF/jboss-web.xml
    • uncomment <security-domain>
  • edit $JBOSS_HOME/server/<your server>/deploy/management/console-mgr.sar/web-console.war/WEB-INF/web.xml
    • uncomment lines after “A security constraint that restricts access…”

Secure jmx-invoker:

  • edit  $JBOSS_HOME/server/<your server>/deploy/jmx-invoker-service.xml
    • uncomment after “Uncomment to require authenticated users”

Secure HTTP-invoker:

  • edit  $JBOSS_HOME/server/<your server>/deploy/http-invoker.sar/invoker.war/WEB-INF/web.xml
    • find <web-resource-name>HttpInvokers</web-resource-name>
    • add additional <url-pattern> elements
      • <url-pattern>/JNDIFactory/*</url-pattern>
      • <url-pattern>/EJBInvokerServlet/*</url-pattern>
      • <url-pattern>/JMXInvokerServlet/*</url-pattern>

You did twice the same so now you might be able to setup a different security domain for your hudson installation and not “jmx-console” what  I suggest above (see creating jboss-web.xml). See links below for more.

Configure login redirect to SSL

First you need to configure a SSL connector. Please refer to  http://www.jboss.org/community/docs/DOC-11989 which is a thorough resource if you cannot get it going with the commented out example configuration.
Then you need to have the following in hudson’s web.xml:

   <security-constraint>
    <web-resource-collection>
      <web-resource-name>Hudson</web-resource-name>
      <url-pattern>/loginEntry</url-pattern>
      <url-pattern>/login</url-pattern>
      <!--http-method>GET</http-method-->
    </web-resource-collection>
    <auth-constraint>
      <role-name>*</role-name>
    </auth-constraint>
    <user-data-constraint>
      <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>
  </security-constraint>

Hudson (JBoss) HTTP listening port

Edit $JBOSS_HOME/server/<your server>/deploy/jboss-web.deployer/server.xml and change `<Connector port=”8080″‘ to `<Connector port=”<some port>”‘.

Context root and Virtual host

If you want to have hudson on “/”  instead of “/hudson” by modifying jboss-web.xml.

<context-root>/</context-root> <!-- deploy to context root - not recommended - see below -->
<virtual-host>host.example.com</virtual-host> <!-- if you want a specific virtual host -->

You’d better leave it be deployed under “/hudson”, otherwise some locations get inaccessible. To have both – convenience and usability you can use a simple redirection. To do that create the following files under server deploy directory:

 redirect-hudson.war/redirect.jsp
 redirect-hudson.war/WEB-INF/jboss-web.xml
 redirect-hudson.war/WEB-INF/web.xml

redirect.jsp should contain:

<%
  response.sendRedirect("/hudson");
%>

jboss-web.xml should contain:

<jboss-web>
    <context-root>/</context-root>
    <!-- <virtual-host>hudson.example.com</virtual-host> -->
</jboss-web>

web.xml could be something like:

<?xml version="1.0" encoding="UTF-8"?>

<web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" version="2.4">

  <display-name>Redirecting to Hudson</display-name>
  <description>
     Redirecting to Hudson.
  </description>

  <welcome-file-list>
     <welcome-file>redirect.jsp</welcome-file>
  </welcome-file-list>

</web-app>

Links

Sun Publishes Glassfish vs. JBoss Comparison Guide

October 21, 2009 · Leave a Comment
Filed under: Featured, GlassFish, JAVA, JBoss, Weblogic, WebServers 

Poor Redhat.  First SpringSource declares war and now Sun is joining in.  Today Sun made available a 14 page Glassfish vs. JBoss Comparison Guide, (Sun login required to download).  Check it out.  It actually makes for pretty interesting reading and if I was eager to see Redhat/JBoss’s response to SpringSource, they’ve now got me besides myself with excitement waiting to hear how they respond to both SpringSource and Sun!  It’s going to be epic!!

Or if you are not a Sun USER, you can download the PDF from here Glassfish vs Jboss.PDF

In Relation To JBoss Developer Studio 2.1 EAP 5 support and

September 28, 2009 · Leave a Comment
Filed under: Featured, JBoss 

Just a quick note to inform that JBoss Developer Studio 2.1 are now available from the JBoss CSP and what i’m very happy to announce, it is also available from our new update site.

Official Update Site

Until now upgrading JBoss Developer Studio required a full install, but we can now finally remove that obstacle (at least for 2.x releases).

The update site is from now on the official supported way of upgrading JBoss Developer Studio 2.x.

The site to use when upgrading from 2.0 to 2.1 is available at http://devstudio.jboss.com/updates/2.1 (customers has or will receive the username/password).

Instructions on how to use it can be found here.

JBoss Enterprise Application Platform 5

The major new functionality in this release is the support for JBoss EAP 5 incl. Seam 2.2. This means you can add the EAP 5 server and start, stop and deploy your applications directly from Developer Studio.

Those who uses EAP 4.x, Developer Studio continues to support previous releases of EAP and any of your JBDS 2.0 projects will also continue to work.

Note, for now we provide only the stand alone JBoss Developer Studio 2.1. You need to install the EAP separately and just use the Installer or the JBoss Server view to add your EAP server.

JBoss Tools 3.0.2

This release contains JBoss Tools 3.0.2 which beyond the changes for EAP 5 and AS 5 support has 47 issues fixed.

Have fun!

Common Java/J2EE » JBoss 5 and MDB Automatic Destnation Creation

September 21, 2009 · 2 Comments
Filed under: Featured, JBoss 

In JBoss 4 an automatic creation of a destination was made if a queue was not exist. If you upgrade from JBoss 4 to JBoss 5 and have MDB’s you probably encountered the error of destination not bound. In JBoss 5 creation of destination if not exist is not automatic. Add your destinations in {JBOSS_HOME}/server/your_config/deploy/messaging/destinations-service.xml

    jboss.messaging:service=ServerPeer

 jboss.messaging:service=PostOffice
 queue/MyQueue
 10000
 3