Eclipse 4.4.0 – Tool bar item visibility based on the currently active perspective

Displaying trimmed window tool bar items based on the currently active perspective in an Eclipse 4.4.0 RCP application would seem like a straightforward task but it actually involves a fair bit of tinkering and there are a few not so obvious pitfalls along the way.

After reading section 31.2 of Lars Vogel’s Eclipse 4 RCP tutorial the obvious approach was to associate a ‘visible-when’ expression with each of my perspective-specific tool bar items. The first problem I encountered was the fact that expressions are not evaluated for items added directly to the main tool bar (see Bug 400217). By ‘added directly’ I mean added as children of the tool bar element in the e4xmi application model. Luckily, when added as ToolBar Contributions visible-when expressions are evaluated as expected.

The next problem I encountered was how to determine the currently active perspective from within a visible-when expression. I couldn’t find any up to date documentation regarding the names of predefined context variables and none of the variables listed in Command Core Expressions were available in my Eclipse Luna 4.4.0 RCP application. To determine which context variables were available I added the following @CanExecute method to one of my tool bar item command handlers:

public boolean canExecute(final IEclipseContext ictx) {
    final EclipseContext ctx = (EclipseContext) ictx.getParent();
    System.out.println("### START ###");
    for (final Entry<String, Object> entry : ctx.localData().entrySet()) {
        System.out.println(String.format("Key: '%s', value: '%s'", entry.getKey(), entry.getValue()));
    System.out.println("### END ###");
    return true;

The following entry was included in the output from this method:

 Key: 'org.eclipse.e4.ui.model.application.ui.advanced.MPerspective', value: 'org.eclipse.e4.ui.model.application.ui.advanced.impl.PerspectiveImpl@2d778add (elementId: my.example.perspective.Edit, tags: [], contributorURI: platform:/plugin/my.example.application) (widget: Composite {}, renderer: org.eclipse.e4.ui.workbench.renderers.swt.PerspectiveRenderer@7fc44dec, toBeRendered: true, onTop: false, visible: true, containerData: null, accessibilityPhrase: null) (label: Edit, iconURI: null, tooltip: , context: PerspectiveImpl (my.example.perspective.Edit) Context, variables: [])'

Based on this output I wrote the following following Property Tester to query the elementId of the active perspective:

 * Property tester that checks the <code>elementId</code> of the currently active perspective
public class PerspectivePropertyTester extends PropertyTester {

     * @param receiver the currently active {@link MPerspective}
     * @param property the property to test, in this case 'elementId'
     * @param args additional arguments, in this case an empty array
     * @param expectedValue the expected value of {@link MPerspective#getElementId()}
    public boolean test(final Object receiver, final String property, final Object[] args, final Object expectedValue) {
        final MPerspective perspective = (MPerspective) receiver;
        return perspective.getElementId().equals(expectedValue);

This was then configured in plugin.xml as follows:

<?xml version="1.0" encoding="UTF-8"?>
   <extension point="org.eclipse.core.expressions.propertyTesters">
      <propertyTester class="my.example.application.propertytester.PerspectivePropertyTester"
   <extension point="org.eclipse.core.expressions.definitions">
      <definition id="my.example.expression.isEditPerspective">
         <with variable="org.eclipse.e4.ui.model.application.ui.advanced.MPerspective">
            <test forcePluginActivation="true"
      <definition id="my.example.expression.isPreviewPerspective">
         <with variable="org.eclipse.e4.ui.model.application.ui.advanced.MPerspective">
            <test forcePluginActivation="true"

As a footnote I should also note that subscribing to UIEvents.UILifeCycle.PERSPECTIVE_OPENED events does not work as expected (see Bug 408681) so the above approach is probably the best option. You could, of course, set the visibility of tool bar items programmatically when switching perspective but this is far from ideal.


Unit Testing HTTPS Clients with a Self-signed Certificate


A quick and easy way to eliminate PKIX path building failed: unable to find valid certification path to requested target without making dangerous changes to your default trust store.


  1. Create a new keystore and associated key entry by executing the following command (N.B. The password values for the -keypass and -storepass options must be identical for Tomcat to work):
    keytool -genkey -alias tomcat -keyalg RSA -keypass <password> -keystore <user-home>/tomcat.jks -storepass <password>
  2. Enter and confirm your details.
  3. Uncomment the “SSL HTTP/1.1 Connector” entry in $CATALINA_BASE/conf/server.xml.
  4. Add keystoreFile and keystorePass attributes with the appropriate values. The result should now resemble the following:
    <!-- Define a SSL HTTP/1.1 Connector on port 8443
    	This connector uses the JSSE configuration, when using APR, the
    	connector should be using the OpenSSL style configuration
    	described in the APR documentation -->
    <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
    	maxThreads="150" scheme="https" secure="true"
    	keystoreFile="${user.home}/tomcat.jks" keystorePass="<password>"
    	clientAuth="false" sslProtocol="TLS" />
  5. Restart Tomcat and deploy your HTTPS constrained resources.
  6. Add a @BeforeClass method to any tests generating HTTPS requests. Use this method to set the and system properties. For example:
    public static void setUp() {
    	System.setProperty("", "<user-home>/tomcat.jks");
    	System.setProperty("", "<password>");
  7. JSSE now uses the new keystore created in steps 1 and 2 as opposed to the default, <java-home>/jre/lib/security/cacerts, trust store.

Rational Software Architect – Java to UML Transformations

Over the past few weeks I’ve been evaluating IBM’s Rational Software Architect (RSA) for WebSphere 7.5 . Whilst RSA is an incredibly powerful piece of software, there are a number of features that are conspicuous by their absence. Perhaps the most prominent of these is the inability of the Java to UML transformation to generate relationships other than Generalisation or Realisation. For example, it won’t generate Association or Usage elements. This makes it pretty useless when it comes to visualising the structure of existing code

You could argue that RSA’s raison d’etre is not the reverse engineering of UML models from Java code, but rather the architecture and development of new applications. This is true, but it misses the point as a number of RSA’s design contract management protocols (notably, "Reconciled Modelling" and "Conceptual Models Drive Development") rely on the reverse transformation of Java code.

According to Rational Support this issue has been logged as a request for enhancement, but when or if it makes it into a future release is anyone’s guess. In the meantime here’s an illustration of the problem.

Step 1 – Create a simple UML model with a composite aggregation navigable from both ends

Figure 1. Class diagram view

Class Diagram 1

Figure 2. Project explorer view

Model 1

Step 2 – Run a reconciled UML to Java transformation on the model

This produces the following java classes (minus the auto-generated comments):

package uml;

import java.util.Set;

public class Whole {

	private Set part;

package uml;

public class Part {

	private Whole whole;

Step 3 – Comment out both private fields in the generated source and run the reverse transformation

As you’d expect, the composite aggregation relationship has now been deleted from the model.

Figure 3. Class diagram view

Class Diagram 2

Figure 4. Project explorer view

Model 2

Step 4 – Uncomment both fields and rerun the reverse transformation

Unfortunately this doesn’t produce the results you’d expect. Rather than explicitly creating an Association element in the UML model, the composite aggregation becomes implicit via the generated attributes for each class. By itself this isn’t a major drama, but it does introduce an inconsistency in your model if you have existing relationships that are modelled explicitly, as was originally the case. To visualise the recreated association you have to filter the attributes to "show as association". However, this only produces uni-directional associations which results in difficult to read diagrams full of unnecessary clutter and noise. The only workaround is to manually recreate the association in the model, which at best wastes time and at worst introduces errors.

Figure 4. Class diagram view (show as attribute)

Class Diagram 3

Figure 4. Class diagram view (show as association)

Class Diagram 4

Figure 5. Project explorer view

Model 3

The Kernel Package: Basic UML to Java

At first glance the UML specification can seem a little daunting. Java developers know all about classes, interfaces, and inheritance, but how do these concepts map to the UML? In Java terms, what are Elements, NamedElements, RedefinableElements, Classifiers, Features, etc.? This post aims to bridge the representational gap between some of the key UML Kernel package elements and the corresponding concepts that manifest themselves in a simple Java class.

The following code depicts a simple interface, abstract superclass, concrete subclass hierarchy in Java.

package math;

public interface Operation {
  double perform();

package math;

public abstract class BinaryOperation implements Operation {
  protected final double operand1;
  protected final double operand2;

  protected BinaryOperation(final double operand1, final double operand2) {
    this.operand1 = operand1;
    this.operand2 = operand2;

  public abstract double perform();  

package math;

public final class Addition extends BinaryOperation {

  public Addition(final double operand1, final double operand2) {
    super(operand1, operand2);

  public double perform() {
    return operand1 + operand2;

Class Diagram

UML model class diagram

N.B. The remainder of this post assumes the elements are contained in model called "model".


An element is a constituent of a model. The interface, classes, member variables, operations, parameters, etc. in the example code above are all elements. Elements can own other elements and have comments attached to them. The hierarchy of elements (listed outermost first) for the operand1 parameter of the BinaryOperation constructor is as follows:

  • <package> model
  • <package> math
  • <class> BinaryOperation
  • <operation> BinaryOperation
  • <parameter> operand1

NamedElement (extends Element)

A named element has a simple name, a qualified name, and an optional visibility. The perform method in the Operation interface has following named element attributes:

  • name = perform
  • qualifiedName = model::math::Operation::perform
  • visibility = public

PackageableElement (extends NamedElement)

The only difference between named elements and packageable elements is the requirement that packageable elements always have a visibility. For named elements the visibility attribute is optional. Classes and interfaces are both packageable elements.

Namespace (extends NamedElement)

A namespace is simply a container for named elements. In the code example, the following elements are also namespaces:

  • <package> math
  • <interface> Operation
  • <class> BinaryOperation
  • <class> Addition
  • <operation> perform
  • <operation> BinaryOperation
  • <operation> Addition

This is all pretty straightforward. Packages contain named elements such as sub-packages, classes, and interfaces; classes contain named member variables and methods, and operations contain named parameters.

Package (extends PackageableElement, Namespace)

A package is essentially a namespace with the additional constraint that its directly owned elements must also be packageable elements. Because a package is itself a packageable element it can be nested within other packages. In the example the package math contains the packageable elements <interface> Operation, <class> BinaryOperation, and <class> Addition.

RedefinableElement (extends NamedElement)

A redefinable element is an element that has the capacity to be overridden. It adds a single boolean attribute, isLeaf. Setting isLeaf to true is equivalent to applying the final modifier, as is the case in the Addition class.

Type (extends PackageableElement)

A type constrains the values that may be represented by a typed element. In Java terms this equates to a primitive type, interface, or class.

TypedElement (extends NamedElement)

A typed element extends a named element by adding an optional association to a type. For example, the operand1 instance member variable in the BinaryOperation class is a typed element with an association to the type double<PrimitiveType>. The value it represents must be no less than java.lang.Double.MIN_VALUE and no greater than java.lang.Double.MAX_VALUE. Similarly, if we declared a variable of type Operation in some client object it would be constrained to referencing the set of Objects that directly or indirectly realise the Operation interface. (See StructuralFeature below).

Classifier (extends Namespace, RedefinableElement, Type)

A classifier is a namespace that can contain features (see Feature below). Classifiers also have the capacity to own generalisations, which in effect means they can extend other classifiers. In the example code, Addition owns a Generalisation relationship that targets BinaryOperation. Classifier adds a single boolean attribute, isAbstract. This is semantically equivalent to the abstract modifier in Java. The value for the BinaryOperation classifier is true.

Feature (extends RedefinableElement)

Features define the behavioural or structural characteristics of classifier instances. They can also be static, in which case they define a feature of the classifier itself. The following elements, owned by the BinaryOperation classifier, are all examples of non-static features:

  • <property> operand1
  • <property> operand2
  • <operation> BinaryOperation
  • <operation> perform

StructuralFeature (extends Feature, MultiplicityElement, TypedElement)

The structure of a classifier is defined by its structural features. In Java, a structural feature is an interface constant or a class member variable (static or non-static). StructuralFeature defines a single boolean attribute, isReadOnly. Supplying a value of true is equivalent to applying the final modifier to a Java member variable. In the case of the BinaryOperation classifier the following elements are structural features:

  • <property> operand1
  • <property> operand2

BehaviouralFeature (extends Feature, Namespace)

By defining a behavioural feature, a Classifier states that it will respond to a designated request by invoking a behaviour. A behavioural feature is also a Namespace in the sense that it may own zero or more named parameters. BehaviouralFeature defines an association to zero or more Types representing the exceptions that may be raised during its execution.

Interface (extends Classifier)

The UML concept of an interface and the Java concept of an interface are pretty much identical. As with Java, all the features of a UML interface must have public visibility.

Class (extends Classifier)

As in Java, a UML class defines a set of objects that share the same specification of features, constraints, and semantics. A class owns a set of attributes and a set of operations. These are represented by instances of Property and Operation respectively.

MultiplicityElement, Property, Operation, Parameter, and other elements

Like Interface and Class, many of these elements are self explanatory. The aim of this post has been to focus on the more abstract elements of the Kernel package, so I won’t list their details here. If you’d like further information, please consult the UML specification.

JMS Patterns – Generic Message Handler

Refactoring some JMS code got me thinking about message validation, type casting, and payload extraction. Having recently read Adam Bien’s excellent book “Real World Java EE Patterns – Rethinking Best Practices” I decided to implement the “Payload Extractor” pattern. However, I couldn’t help feeling there’s something not quite right about it. In particular I didn’t like having to implement an empty onMessage method, and some of the reflection overhead seemed unnecessary. Don’t get me wrong; EJB 3 interceptors are great for extracting cross-cutting concerns, but in this case the implementation of the bean is entirely dependent upon the presence of the interceptor.

The alternative I came up with uses a generic abstract superclass and the Template Method pattern. In my opinion, this approach has several advantages:

  • The solution handles both message type checking and payload extraction.
  • Less reflective code. Determining the expected type happens once during object construction. Message type checking and payload extraction use simple instanceof and isAssignableFrom checks.
  • There’s no empty onMessage method in the concrete subclass.
  • Concrete subclasses can also access the dead letter handler if the need arises.
  • More robust compile time checks. The generic abstract method forces you to implement a correctly typed consume method. In the Payload Extractor pattern this check doesn’t happen until runtime, at which point any coding errors will simply masquerade as invalid messages.

You could argue that using an interceptor frees you from having to use inheritance. However, in this case, I don’t see this as a problem. It’s generally accepted best practice to not place business logic in your Message-Driven Beans, so scenarios in which your listener is required to inherit from another class should be rare.

public abstract class GenericMessageHandler<T> implements MessageListener {

    private final Class expectedType;
    private DeadLetterHandler deadLetterHandler;

    public GenericMessageHandler() {
        final ParameterizedType parameterizedType =
            (ParameterizedType) getClass().getGenericSuperclass();
        expectedType = (Class) parameterizedType.getActualTypeArguments()[0];

    public void onMessage(final Message message) {
        if (matchesExpectedType(message)) {
        } else {
            final Object payload = extractPayload(message);
            if (matchesExpectedType(payload)) {
            } else {

    protected DeadLetterHandler getDeadLetterHandler() {
        return deadLetterHandler;

    protected abstract void consume(T obj);

    private boolean matchesExpectedType(final Object obj) {
        return obj != null && expectedType.isAssignableFrom(obj.getClass());

    private Object extractPayload(final Message message) {
        try {
            if (message instanceof ObjectMessage) {
                return ((ObjectMessage) message).getObject();
            } else if (message instanceof TextMessage) {
                return ((TextMessage) message).getText();
            return null;
        } catch (JMSException e) {
            throw new IllegalStateException("Error extracting payload", e);

    private void invokeConsume(final Object obj) {
        consume((T) obj);

Payload Extraction Example –

public class MailQueueHandlerBean extends GenericMessageHandler<Email> {

    private Mailer mailer;

    public void consume(final Email email) {

In the above example MailQueueHandlerBean expects messages of type ObjectMessage with a payload of type Email. As you can see, the implementation is super-lean and there’s no ambiguity about who’s performing what.

Message Type Check Example –

public class RawDataQueueHandlerBean extends GenericMessageHandler<BytesMessage> {

    private DataProcessor dataProcessor;

    public void consume(final BytesMessage bytesMessage) {
        try {
            if (bytesMessage.getBodyLength() == 0) {
            } else {
                final byte[] data = // extract byte array
        } catch (JMSException e) {
            throw new IllegalStateException("Error extracting bytes", e);