Virgo 3.7.0 Released

 Today Florian announced the availability of Virgo 3.7.0. 

Virgo 3.7.0 brings several improvements (most notably Tomcat 8.5 and Spring Framework 4.2) and is paired by release 1.5.0 of the Virgo Tools, the Eclipse IDE integration.

This is the first official Virgo release since I joined the project as a committer, and it's also my first open source release in general. I am very happy and very proud of what we achieved.

Download Virgo and get Virgo Tools from the update site!

Read More

Virgo 3.7.0.M4 released

Virgo 3.7.0 M4 has been released.

The final 3.7.0 release is planned for end of Feb.

Read More

Virgo Tools 1.5

Since September 2015 I am a committer of the open source Eclipse Virgo project.

I have written several posts in the past about the Eclipse Virgo OSGi application server, and after having helped the project team with patches and bug fixes I have been invited by Florian, the project lead, to join the team as a committer.

I am an individual committer, contributing to the project in my spare time. I spent almost all of my effort on the Virgo Tools, the Eclipse plug-ins that integrate Virgo as a test environment in Eclipse. The most notable improvements of the upcoming version 1.5 of the Virgo tools will be:

1. Support for PDE Plug-in projects. This is the possibility to develop for the Virgo runtime using the Eclipse PDE Tools, Plug-in Development Environment. This was one of the most requested and long standing missing features. See here and here.
2. Improved support for plan projects. Virgo supports deployment of a number of artifacts, including Plans. Plans are XML files listing Bundles and other Plans to be activated. The Virgo Tools now provide fair support for having Plan files in Eclipse and deploying them to the test environment.
3. Bug fixes and documentation
4. Compatibility fixes for Eclipse Neon

We are currently planning to release the Virgo Tools 1.5 in January 2017 to be shortly followed by Eclipse Virgo 3.7.

Stay tuned!

Read More

Profiling Virgo with JProfiler

The information below has been tested with JProfile 5 on Linux 64bit, and assumes that the JProfiler Agent is installed in folder /opt/jprofiler5.
While this post refers to a rather old JProfiler version, I am sure the principles apply also to more recent JProfiler version. 
 
The following environment variables must be set before starting Virgo:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/jprofiler5/bin/linux-x64
export JAVA_OPTS="$JAVA_OPTS -Xbootclasspath/a:/opt/jprofiler5/bin/agent.jar -agentpath:/opt/jprofiler5/bin/linux-x64/libjprofilerti.so=port=8849" 

If your JProfiler installation is not located in /opt/jprofiler5 change the above paths accordingly.

A convenient method for setting the environment variables consists in creating a setenv.sh file in the Virgo bin folder. If such file exists, it will be invoked by the startup.sh script.

 

Additionally, it is necessary to modify the java6-server.profile file contained in the <VIRGO_HOME>/configuration folder to ensure that the property org.osgi.framework.bootdelegation contains the com.jprofiler package, as in the example below.
Note: do not replace the file content, just add the com.jprofile.*,\ line.

org.osgi.framework.bootdelegation = \
 org.eclipse.virgo.osgi.extensions.*,\
 org.eclipse.virgo.osgi.launcher.*,\
 org.eclipse.virgo.kernel.authentication,\
 com.sun.*,\
 com.jprofiler.*,\
 javax.xml.*,\
 org.apache.xerces.jaxp.*,\
 org.w3c.*,\
 org.xml.*,\
 sun.*

After applying the above changes, start Virgo and connect using the JProfiler GUI.

Read More

How to use Hyperic to monitor Eclipse Virgo 3.6

Few days ago I started looking for a monitoring tool to track the health status of our Virgo Server for Apache Tomcat instances.

As I could not find anything Virgo specific, I looked for an open source tool that supported Apache Tomcat 7.0.

First try was Moskito, but it does not seem to support the  OSGi-aware Tomcat that is embedded in Virgo. In any case I did not like the deployment approach, which requires to add Mosquito to every monitored Web App.

So I searched for monitoring tools that used Tomcat JMX support, as I believed such tools should be unaffected by the OSGi runtime, and I found Hyperic.

Hyperic 5.8 

Hyperic is developed by SpringSource and there exists both an enterprise distribution (vCenter Hyperic) and a free-to-use distribution.

Hyperic consists of the Hyperic Server and the Hyperic Agent.

The server is a Tomcat6-based Web application that uses PostgreSQL for storing historical data and which provides the monitoring console.

The agent is a stand-alone Java application that integrates with the O.S. via the well known Sigar native library (used by JMeter, Elasticsearch etc), and which features a number of plug-ins for different servers and database systems (WebSphere, WebLogic, JBoss, Tomcat, Apache, Oracle, DB/2,  PostgreSQL, MySQL and many more).

A screenshot taken from the SourceForge download page

Installation and usage

You must first install the Hyperic Server, typically on a dedicated machine that you will be using for monitoring. Then you must install the Hyperic Agent on every server machine that you want to monitor.

The Hyperic Agent will automatically discover running database systems and application servers on the machine where it is installed, and it will offer them as observable resources to the Hyperic Server.

From the Hyperic Server console the administrator can select what to monitor (e.g. Apache Tomcat, MySQL, but also operating system CPU, SWAP, file system, I/O, network etc)

The agent will then start sampling the requested items and will push the information to the console. which will be able to display historical data, paint graphs, and which can be configured to raise alerts when certain conditions are met (e.g. low disk space, high CPU usage, Tomcat process crashed etc etc).

Tweaking the Virgo installation to pretend it's Tomcat 7

Even if Virgo was created by SpringSource, Hyperic does not seem to support Virgo OOTB, or at least the open source edition does not seem to support Virgo.

It however supports Tomcat 7.0 via an agent plug-in called tomcat-plugin.jar.
A quick look at the plug-in sources reveals the Tomcat 7.0 discovery process:

1. The plug-in uses a Sigar query to identify running processes that are potential Tomcat servers. The query just looks for running Java processes that include parameter -Dcataliba.base=<some_path> in the command line.
2. The version of Tomcat is determined by checking the existence of some files that are specific to each Tomcat version. For Tomcat 7, the file is <catalina.base>/lib/tomcat-api.jar (see here).
3. Once Tomcat is identified, the agent will connect to the process to collect samples, provided that JMX support is enabled. Luckily enough JMX is enabled per default in Virgo.

To have Virgo recognized as Tomcat 7.0:

1. Set JAVA_OPTS to -Dcatalina.base=<VIRGO_INSTALLATION_FOLDER> before starting Virgo:
   

   export JAVA_OPTS=-Dcatalina.base=/home/giamma/virgo

   ./startup.sh

2.  Create an empty file named tomcat-api.jar in the Virgo lib folder:
   

   cd /home/giamma/virgo 

   touch lib/tomcat-plugin.jar

Now start Virgo and after few seconds it will show up as a Tomcat 7 server in the Hyperic console.
Note that the Hyperic template for Tomcat 7 will use wrong defaults for log files etc, but you can change them after enrolling the Virgo server in the Hyperic console.

In case you wonder, the catalina.base system property has no side effect on Virgo, see here.

Patching the Agent to monitor global data sources

The current Hyperic Agent plugin for Tomcat is capable of monitoring only data sources that are defined at the Web App level.

If you are using Tomcat global data sources as we are doing (see here for details), they will not be monitored by Hyperic.

However, you can easily patch the tomcat-plugin.jar as explained here. Just remember that after patching the plug-in you must replace it both in the Hyperic Agent and in the Hyperic Server.

./agent-5.8.2/bundles/agent-5.8.2/pdk/plugins/tomcat-plugin.jar

./server-5.8.2/hq-engine/hq-server/webapps/ROOT/WEB-INF/hq-plugins/tomcat-plugin.jar

Read More

Dependency Injection and Sisu

Dependency injection is certainly one of the most effective design patterns for writing clean, maintainable and testable code.

For these reasons it's been very popular over the past few years and a number of libraries/frameworks have been created to provide support for dependency injection. The most well known implementations are probably Google Guice, the Spring Framework and the OSGi Service Registry while Dagger is possibly the most recent yet significant addition to this group.

A standardization effort in dependency injection began in 2006 which resulted in JSR 299 first and then in JSR 330, now supported by Guice and Spring which changed their API to comply with the proposed specification.

So what is the best choice today for those who want to use dependency injection in their code? Well, in my humble opinion the answer is.... Eclipse Sisu!. The Sisu home page describes Sisu as

"a modular JSR330-based container that supports classpath scanning, auto-binding, and dynamic auto-wiring. Sisu uses Google-Guice to perform dependency injection and provide the core JSR330 support, but removes the need to write explicit bindings in Guice modules." 

The project is still in incubation phase, and the documentation is not yet complete, but after playing with Sisu for some time, I can state that it is an excellent product, one of those rare Java libraries that focus on doing just one thing but do that thing exceptionally well. The code itself is very well written and an interesting reading for every Java developer (apart from the unusual C-like formatting :-)).

Sisu is the type of middleware component you would normally expect to find at Apache.org, and the fact that its actually hosted at Eclipse foundation may be yet another indication that Apache is no more as succesful as it used to be.

Here are some great features of Sisu:

• Sisu can be used in both a Java SE environment and in an OSGi environment, and dependency injection becomes as simple as annotating relevant classes and letting Sisu magically discover them via class file scanning, or providing an index file.
• No knowledge of Google Guice is required, but usage of the Google Guice API is supported.
• Not only OSGi support is first class, but the author has also set the goal of integrating Sisu with the Equinox Registry and the OSGi Service Registry. Once accomplished this will bring a single, unified programming model helping portability between JavaSE and OSGi. 

Download Sisu now and start experimenting with it, chances are you'll be really amazed!

Read More

Tinybundles, a little gem for OSGi testing

In my OSGi applications I often make use of the OSGi extender pattern. An excellent example is available on Kai's Toedter blog.

As Peter Kriens explained:

In the Synchronous Bundle Listener event call back, the subsystem can look at the resources of the bundle and check if there is anything of its liking. If it is, it can use this resource to perform the necessary initialization for the new bundles.

Writing unit tests for a Synchronous Bundle Listener is often a tricky task. To test the behaviour of your extender you need to install and start (and later stop and uninstall) bundles via the OSGi API.

The API allows you to install a bundle by passing in an InputStream opened from a bundle file. So, the simplest solution usually consists in packaging a small test bundle as a binary resource in the test case  package, and to use the OSGi API from the test case class to install the bundle in the OSGi framework. This approach certainly works but is quite annoying because you need to repackage the test bundle every time you have to make a change.

Some time ago I found a better solution: the Tinybundles library. The project documentation is here, while sources for the library are available on github.

Tinybundles provides a convenient API to create an OSGi bundle from resources and classes available in your test case classpath:

TinyBundle bundle = TinyBundles.bundle()
            .add( TestActivator.class )
            .add( HelloWorld.class )
            .set( Constants.BUNDLE_SYMBOLICNAME, "test.bundle" )
            .set( Constants.EXPORT_PACKAGE, 
                HelloWorld.class.getPackage().getName() )
            .set( Constants.IMPORT_PACKAGE, 
                "org.apache.commons.collections" )
            .set( Constants.BUNDLE_ACTIVATOR, 
                TestActivator.class.getName() );

InputStream is = bundle.build(TinyBundles.withBnd());        
Bundle installed = getBundleContext().installBundle("dummyLocation", is);
installed.start();

In this way you can generate bundles on-the-fly within your test case for the purpose of testing your bundle listeners.

Simple, isn't it?

Read More