Setup AppDynamics for FUSE ESB / Apache ServiceMix in 5 Minutes

AppDynamics  is a powerful tool for the analysis of distributed Java and .NET applications. As it has only low overhead costs (according to the vendor < 2%), it can also be used in production environments.

I use JBoss Fuse 6.0.0 on MacOS. But the setup is similar on other operation systems.
Follow theses steps:

1. Download AppDynamics Lite Java version from http://www.appdynamics.com/. Name and E-Mail address must be provided (and normally you will be contacted by the vendor...).
2. Unzip the downloaded ZIP file AppDynamicsLite.zip to your desired installation directory :

   unzip AppDynamicsLite.zip -d <APP_DYNAMICS_HOME>
   

3. Go to the installation directory:

       cd <APP_DYNAMICS_HOME>
   

4. Unzip the viewer package:

       unzip LiteViewer.zip
   

5. Enter the viewer directory:

       cd LiteViewer
   

6. Start the viewer:

       java -jar adlite-viewer.jar
   

7. Open URL http://localhost:8990/ with your browser. Default user is admin with password admin. You see an empty dashboard.
8. If you monitor an OSGI runtime with AppDynamics you have to extend the boot delegation parameter of FUSE ESB. SSee http://litedocs.appdynamics.com/display/ADLite/OSGi+Infrastructure for further explanations. As I use Felix, I have to add com.singularity.* to the org.osgi.framework.bootdelegation property. For easier upgrade of FUSE ESB, I do not edit /etc/config.properties but /etc/custom.properties. It is important that you don't forget to add all default values. And of course these values may change if you upgrade your FUSE ESB installation. Finally, I add following line to /etc/custom.properties:

       org.osgi.framework.bootdelegation=com.singularity.*,org.osgi.framework.bootdelegation=org.apache.karaf.jaas.boot,sun.*,com.sun.*,javax.transaction,javax.transaction.*,org.apache.xalan.processor,org.apache.xpath.jaxp,org.apache.xml.dtm.ref,org.apache.xerces.jaxp.datatype,org.apache.xerces.stax,org.apache.xerces.parsers,org.apache.xerces.jaxp,org.apache.xerces.jaxp.validation,org.apache.xerces.dom
   

   If your are not sure which OSGI framework you use, you can query your configuration in your Karaf console with

       shell:info
   

9. Configure AppDynamics agent for FUSE ESB. E.g., set $KARAF_OPTION in your shell:

       export KARAF_OPTS="$KARAF_OPTS -javaagent:<APP_DYNAMICS_HOME>/javaagent.jar"
   

   Or alternatively, add following statement to your start script /bin/karaf:

       KARAF_OPTS="$KARAF_OPTS -javaagent:<APP_DYNAMICS_HOME>/javaagent.jar"
   

10. Start your FUSE ESB (in the same shell where you set $KARAF_OPTIONS):

        cd <FUSE_ESB_HOME>/bin/fuse
    

11. Create some traffic on your FUSE ESB, e.g. invoke a web service etc.
12. Go back to your AppDynamics viewer browser window at http://localhost:8990/ and you should see some business transactions.
    
    
13. Finito.

FUSE ESB / Apache ServiceMix Worries...

Starting JBOSS FUSE ESB and received a million error messages in the log (short extract):

[510]% ./fuse
Please wait while JBoss Fuse is loading...
 29% [====================>                                                   ]ERROR: Bundle org.ops4j.pax.web.pax-web-spi [97] Error starting mvn:org.ops4j.pax.web/pax-web-spi/1.1.11 (org.osgi.framework.BundleException: Uses constraint violation. Unable to resolve bundle revision org.ops4j.pax.web.pax-web-spi [97.0] because it is exposed to package 'javax.servlet' from bundle revisions org.apache.geronimo.specs.geronimo-servlet_3.0_spec [269.0] and org.mortbay.jetty.servlet-api [263.0] via two dependency chains.

Chain 1:
  org.ops4j.pax.web.pax-web-spi [97.0]
    import: (&(osgi.wiring.package=javax.servlet)(version>=2.3.0)(!(version>=3.0.0)))
     |
    export: osgi.wiring.package=javax.servlet
  org.apache.geronimo.specs.geronimo-servlet_3.0_spec [269.0]

Chain 2:
  org.ops4j.pax.web.pax-web-spi [97.0]
    import: (&(osgi.wiring.package=org.ops4j.pax.web.service)(version>=1.1.11))
     |
    export: osgi.wiring.package=org.ops4j.pax.web.service; uses:=org.osgi.service.http
  org.ops4j.pax.web.pax-web-api [99.0]
    import: (&(osgi.wiring.package=org.osgi.service.http)(version>=1.0.0)(!(version>=2.0.0)))
     |
    export: osgi.wiring.package=org.osgi.service.http; uses:=javax.servlet.http
  osgi.cmpn [273.0]
    import: (osgi.wiring.package=javax.servlet.http)
     |
    export: osgi.wiring.package=javax.servlet.http; uses:=javax.servlet
    export: osgi.wiring.package=javax.servlet
  org.mortbay.jetty.servlet-api [263.0])
  ...

WTF? Deleted $FUSE_HOME/data directory, started FUSE again, and the errors are gone. It's a pain.

JBoss FUSE ESB vs. Apache ServiceMix vs. Apache Karaf vs. Apache Felix

What is JBoss FUSE ESB? And what is its relation to OSGI, Apache Felix, Eclipse Equinox, Apache Karaf and Apache ServiceMix?

• Felix and Equinox are both OSGI core runtimes
• Karaf is the ServiceMix Kernel and provides a "distribution" based on Felix or Equinox by adding features such as an admin console and blueprint configuration.
• ServiceMix is an integration container aka ESB powered by OSGI unifying the features of ActiveMQ, Camel, CXF, and Karaf (and other)
• JBoss Fuse ESB is an ESB based on ServiceMix adding bug fixes and extended documentation

Sources:

• http://felix.apache.org/
• http://www.eclipse.org/equinox/
• http://karaf.apache.org/
• http://servicemix.apache.org/
• http://www.redhat.com/products/jbossenterprisemiddleware/fuse/
• http://gnodet.blogspot.ch/2009/04/apache-karaf.html

Migrating Plug-in Configuration when updating Eclipse Release

I just downloaded the latest Eclipse Juno Release with the latest fixes etc. But how to migrate my plugins from my "old" Eclipse to the "new" one?

1. Export

First, you must export your plug-ins from your "old" Eclipse installation as follows:
1.0 Start your "old" Eclipse instance
1.1 Package explorer, right mouse click, choose Export

1.2 Choose Install: Installed Software Items to File

1.3 Select All and export to p2f file (remember the file path, as you will import this file into your "new" Eclipse instance)

2. Import

After exporting, you must import the exported p2f file to your "new" Eclipse installation as follows:
2.0 Shutdown the "old" Eclipse instance if you want to use the same workspace as used for the export and start your "new" Eclipse instance
2.1 Package explorer, right mouse click, choose Import

2.2 Choose Install: Install Software Items from File

2.3 Select your exported p2f file (see step 1.3 above)
2.4 Select All and Finish

That's it. Let me know if this was helpful!

JAVA_HOME setting on MacOS

I just downloaded the latest Java Update 1.7.09 for MacOS and installed it. And as usual, I had to fix the JAVA_HOME environmental property, so that all my Maven etc. tools still worked properly. In ~/.bash_profile, I added/updated following entries:

export JAVA_HOME6=/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
export JAVA_HOME7=/Library/Java/JavaVirtualMachines/jdk1.7.0_09.jdk/Contents/Home
export JAVA_HOME=$JAVA_HOME7
export PATH=$JAVA_HOME/bin:$PATH

I use JAVA_HOME6 and JAVA_HOME7 so that I can easily switch the standard Java version.

But, stop, stop, there must be a better way to do that, so that I don't have to update these lines after every Java download. And actually it is by using the not-so-well-known-but-very-useful command java_home:

The java_home command returns a path suitable for setting the JAVA_HOME environment variable. It determines this path from the user's enabled and preferred JVMs in the Java Preferences application. Additional constraints may be provided to filter the list of JVMs available. [...] The path is printed to standard output.

On my machine, java_home prints following path to the STDOUT:

[561]% /usr/libexec/java_home --version 1.7
/Library/Java/JavaVirtualMachines/jdk1.7.0_09.jdk/Contents/Home

So, I can change my .bash_profile as follows:

export JAVA_HOME6=`/usr/libexec/java_home --version 1.6`
export JAVA_HOME7=`/usr/libexec/java_home --version 1.7`
export JAVA_HOME=$JAVA_HOME7
export PATH=$JAVA_HOME/bin:$PATH

On my machine, my Java environmental parameters becomes:

[555]% env | grep JAVA
JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.7.0_09.jdk/Contents/Home
JAVA_HOME6=/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
JAVA_HOME7=/Library/Java/JavaVirtualMachines/jdk1.7.0_09.jdk/Contents/Home

Finito.

Create an XSD from XML using Trang

I recently needed to create an XML Schema XSD file from an existing XML file. A short research pointed me to Trang. Description from their website:

Trang, a program for converting between different schema languages, focused on RELAX NG; in particular, it can convert between the compact and XML syntaxes, it can convert between RELAX NG and DTDs, and it can convert from RELAX NG to W3C XML Schema

But beside the convertion between different schema languages, Trang is also able to create schemas based on XML files.

The creation of an XSD is done as follows for UTF-8 encoding using a JRE 1.5 or above:

java -jar trang.jar -i encoding=UTF-8 message.xml message.xsd

Or, with explicit input and output format if the former command does not work as expected:

java -jar trang.jar -I xml -O xsd -i encoding=UTF-8 message.xml message.xsd

Easy.

Short novice guide for importing a project to Subversion

My new employer uses Subversion as the central version control system, so I'm trying to take the first steps as my former employer still used the good old CVS. (This also means that you don't find advanced infos here but only novice infos.)
(And of course, it would be nice, if my new employer would use Git, however, Subversion and Git can co-exist as you may know already. But this is not the subject of this blog entry.)
So, how to import an existing project to Subversion? I don't mind loosing the history of the project, of course this makes the whole migration process a lot easier.

1. Create a Subversion repository

First, a central Subversion repository has to be created if it does not exist already:

$ svnadmin create /svn/repos

2. Import an existing project to the trunk

So, let's import the project directory myproject to Subversion. I already learned that the recommended structure should be as follows:

myproject/
  trunk/
  tags/
  branches/

As in a non-Subversion project, the trunk, tags and branches directories usually do not exist yet, they have to be created first. The import sequence for the project directory myproject becomes as follows:

$ cd <parent directory of the project directory myproject>
$ mkdir myproject_svn myproject_svn/tags myproject_svn/branches
$ mv myproject myproject_svn/trunk
$ svn import myproject_svn file:///svn/repos/myproject

As the Subversion repository is locally visible, I use the file:// schema.
Don't forget the myproject in the last command or all files in svn_myproject will be imported directly into the root directory of the repository.
You cannot work directly with the created myproject_svn directory above, you first have to checkout it again:

svn checkout file:///svn/repos/myproject/trunk -d myproject

3. Create a branch

Creating a branch is just a Subversion copy:

$ cd myproject
$ svn copy trunk/ branches/myproject-branch
$ svn status
A +  branches/myproject-branch

Here, the trunk/ directory is copied recursively in the working directory brances/myproject-branch. The output of the command svn status indicates that the directory is ready to be added to the repository. The + says that branches/myproject-branch is just a copy and nothing new.
When commiting, Subversion creates the directory in the repository:

$ svn commit -m"creating new branch"
Adding         branches/myproject-branch
Committed revision 987.

Subversion does not really copy all files, but just creates a new repository entry pointing to the original tree, so this is also called a "cheap copy". Please refer to the Subversion documentation for more detailed infos.
The one step method without the need of a temporary directory is as follows:

$ svn copy file:///svn/repos/myproject-trunk \
  file:///svn/repos/myproject/branches/myproject-branch \
  -m"creating new branch"