Eclipse RCP export failure

Even though the JCrypTool runtime in Eclipse is working perfectly fine, exporting the product via the Product Configuration Editor fails on OS X 10.8.2 with Java 1.7.0_09 (the same happened with 1.7.0_07). Every export crashes after 2 percent with the following exception:

/[…]/.metadata/.plugins/org.eclipse.pde.core/temp/org.eclipse.pde.container.feature/compile.org.eclipse.pde.[…]/build.xml:31: /Library/Java/JavaVirtualMachines/jdk1.7.0_09.jdk/Contents/Home/Classes does not exist.
The following error occurred while executing this line:
/[…]/build.xml:31: /Library/Java/JavaVirtualMachines/jdk1.7.0_09.jdk/Contents/Home/Classes does not exist.

I‘ve already re-installed Eclipse 4.2.1 Classic, tried Eclipse 4.2.1 for RCP Developers, deleted the workspace, cleaned projects, everything that came into my mind. No success. Any ideas?

Alphabetically sorting Eclipse RCP help pages and custom bookmark titles

Extending the Eclipse help in a RCP is easy. However, there seem to be some hidden features as we have lately discovered for JCrypTool. Since JCrypTool is heavily based on crypto plug-ins which do extend our platform, we do include lots of other plug-ins via anchors in the online help:

<topic label="Signatures" href="toc.html" sort="true">
  <anchor id="signaturePlugins" />
</topic>

sort=”true” does the magic here and sorts all plug-ins extending this anchor alphabetically.

The other latest change was the title element for each html head. Even though the title entered here is not visible, it is used for the bookmark title a user can create for each page. Adding it is strongly recommended, otherwise the pages’ path will be used.

JavaOne 2012 roundup

My first JavaOne ever is over. Had a great time there. San Francisco is a great city, and the weather was perfect, a least the first couple of days.

I did enjoy all keynotes, especially of course the Java Community Keynote with James Goslings‘ surprise visit and presentation.

Most sessions I‘ve attended were really great. Experiencing Adam Bien live was really a lot of fun. My other highlights were Modern Software Development Antipatterns by Ben Evans and Martijn Verburg (those guys rock!), Real-World Java EE 6 Tutorial by Paul Bakker and Bert Ertman (impressive knowledge) as well as several security related sessions. And of course my own session on Apache Camel Security. More people (about 60 showed up, more than 80 registrations) as expected were interested in a security topic.

The locations (the three JavaOne hotels) were closer together than expected, way less time-consuming walking as expected. But even the short distance made it impossible to attend all desired sessions in full length since an early show up at most sessions was required.

Plus of course the free beer and coffee (not at the same time) sponsored by IBM. A lot of cool bands in the evening. Oracle‘s overall organization was perfect, including always available helpful staff.

What I do not understand however is how technically interested people (a.k.a. geeks) are not able to mute their mobile when attending a session. I can‘t remember too many session without at least one mobile entertaining everybody with a lovely ringtone. This is totally disrespectful of the speaker and the other attendees.

What I didn't like that much: WLAN was a catastrophe, at least most of the time. OK, this is really a challenge, so many geeks with so many devices… But hey, it‘s 2012! And food was extremely poor. Welcome dinner on Sunday night was great, but the rest of the week was sandwich only. It was enough, but nothing special at all. And why they served drinks in cans is, for a so-called green conference, beyond me.

But anyway, JavaOne 2012 was a success for me and a great experience! Lets see whether I will get the chance to go there again.

Still some seats available in my JavaOne session on Apache Camel Security


Hurry up, JavaOne starts in one week! And there still some spots available in my session on Apache Camel Security. Save the date, October 3rd 2012 (Wednesday) at 10 a.m. at Parc 55 – Embarcadero.

My session will introduce you to Apache Camel Security and show how to secure your Camel routes and messages using Camels’ very own features only. You will end up with secured messages and routes which can only be accessed by the configured user groups. Since Camel tends to integrate services providing critical business data it’s about time to take security into account.

Slides are ready, demo is ready, the only thing missing is you… So what’s holding you back, see you there!

Btw, I will (try to) twitter about my week at JavaOne.

Total failure of Java security

Wow, that’s a sentence I believed I would never write in my professional life: deactivate Java in your web browser immediately! In any browser and on any operating system. Instructions are e.g. available here and normally on your browser manufacturer home page. Turning it off does not have an impact on normal Java applications, those programs can operate normally. In case you are using an older Java version as 1.7: you should be fine and safe, at least with this bug (but there are other bugs in Java 1.6 that have been fixed in Java 1.7).

What happened? Java applets, as unimportant they are these days, are potentially harmful programs executed on your machine. You don’t want them to have access to everything. And for years we (including myself) believed that it is not possible to turn the Java applet security manager of or modify it. This security manager is always and automatically in place when launching a Java applet and it can’t be deactivated, replaced or modified by another one. It makes sure that untrusted (a.k.a. dangerous) code from another machine does not have access to the local computer and its resources. At least up to now.

There is no way to put lipstick on the pig; this is a total failure of Java security. Sandboxes (not only the Java sandbox) have always been a problematic area and of course did and do contain security holes (like most of the other applications). But are there any alternatives?

I think it’s time to remove Java support from web browsers. At least by default. It’s only required for Java applets, and honestly, how often do you run into those? Java web applications deliver, as other web applications, normally HTML to the client. They don’t need a Java runtime on the client. Removing Java support in web browsers does not affect those applications. And the client itself can keep on using Java applications, that’s no problem either. So where is the downside?

Yes, I like Java, yes, I develop Java (web) applications and I don’t want people and companies to stop using Java. It’s a great programming language and a great platform. But it’s time to rethink some old habits and get rid of mostly unused and insecure features that where only important in the past.

There are some good (German) technical details and some code available at heiseSecurity, some English details are available here.

Update, 08/30/12: Oracle has released Java 7 Update 7 which fixes this critical vulnerability. You should update your systems immediately!

Update, 09/03/12: Turns out the new release is still vulnerable, see here (in German). In case you do not use any Java applets better turn off the browser plugin permanently.

JavaOne Apache Camel Security Session Update

It‘s been a while since I last blogged about my JavaOne session. Slides are more or less finished, only the last touch is missing. First time for me with a totally Zen based presentation, I‘m looking forward to that! And I‘m working hard on a cool demo.

There is absolutely no Camel security knowledge required to attend my session! That‘s the stuff you will be learning. I recommend some (basic) Camel knowledge, I won‘t go into detail about that. You don‘t need any expert Camel knowledge, the basics are enough. And there are a two more JavaOne sessions on Camel, in case you want to fresh up your knowledge. Hopefully they will take place before my session.

JCrypTool Release Candidate 6 available

JCrypTool Release Candidate 6 is available for download! This release contains many improved and extended features as well as lots of bugfixes.

Download it today via the CryptTool Portal or via the update manager in your JCrypTool installation. Have a look at our wiki for detailed release information.

At least at the moment it looks like this will be our last release candidate before the final version 1.0. There is still a lot of work to do, and we will continue to provide weekly builds with extended features and bugfixes for download.

Nasty NullPointerException in org.springframework.beans.factory.BeanDefinitionStoreException

I had a lot of trouble with Camel 2.9.2/Spring 3.0.7 projects lately (though the issue is related to Spring, not Camel). During development, a lot of server starts (I used VMware vFabric tc Server Developer Edition v2.7, but others seem to be affected as well) failed with a really nasty exception:

org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from class path resource [spring/camel-context.xml]; nested exception is java.lang.NullPointerException

Stopping and starting sometimes helped, but often a couple of restarts were necessary to get everything working. The solution was to omit jaxb-impl version 2.2.4-1 in the Maven configuration by replacing it with the following dependency (exactly this version):


<dependency>
 <groupId>com.sun.xml.bind</groupI>
 <artifactId>jaxb-impl</artifactId>
 <version>2.2.3</version>
</dependency>

Integrating Jenkins build results into JIRA issues

After linking Subversion (or Git) with JIRA, the build server looks like a worthwhile target too. Aim of the JIRA integration for Jenkins is to link JIRA issues with the resulting build artifact and to answer the question “Which build contains the bug fix for issue 1234?”. The Jenkins JIRA plugin therefore updates the JIRA issue by adding a comment containing a link to the generated build artifact.

The JIRA Plugin requires Jenkins, sadly it does not work with Hudson any more (this includes the latest Eclipse Hudson 3.0 milestone 2 release). It is possible to install the JIRA plugin in Hudson, even to configure it. However, including JIRA as post build action results into a java.lang.NoSuchMethodError: hudson.scm.ChangeLogSet$Entry.getCommitId()Ljava/lang/String; exception and a failed build.

Installation and initial configuration
Installation is simple: Open the Plugin Manager, install the JIRA Plugin and restart Jenkins:

JIRA Plugin installation

The following initial configuration must be done only once on the Manage System page, in a corporate environment supposedly by a Jenkins administrator. Add a new JIRA configuration and provide the URL to your issue tracker, as well as username and the password. This user requires write access to all projects using the Jenkins JIRA integration. Since the username will show up as comment author, a service user like jenkins_ci or something similar makes it easier understandable where those comments are coming from. Finally, check the Record Scm changes checkbox and save your changes.

JIRA Plugin configuration

In case a certificate exception like sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target shows up at the URL textfield, Jenkins doesn’t find or recognize the JIRA server certificate (especially if it is a self-generated one). Simply obtain this certificate and import it using the Java keytool (replace [jira-domain] with your domain name):

keytool -import -alias [jira-domain] -keystore $JAVA_HOME/jre/lib/security/cacerts -file file.cer

The JDK (or JRE) entered for the keystore must be the one configured for Tomcat. You have to use this keystore (Linux requires usage of the sudo command)! Password of the global cacerts keystore should be changeit. Jenkins (Tomcat) needs to be restarted after the import. In case the exception is still there, either the imported certificate was not the correct one, the alias is not correct or the given Java path is not the Java installation used by Tomcat.

Individual project configuration
Now every project can use the JIRA integration. First of all, create your JIRA project and your SVN (or Git) repository as usual. Then start a new Jenkins build or modify an existing one. Set up all required build steps as usual.

Each project must enable the JIRA Jenkins connection individually. This requires write access for the Jenkins service user to your JIRA project. This user will update the corresponding issues with a comment after a build.

After this initial organizational task and the basic project setup, the projects Post-build Actions in its build configuration must be updated by selecting Update relevant JIRA issues. No additional JIRA configuration is required here. But it may make sense to periodically poll the SCM by configuring a schedule (like every couple of minutes). Otherwise you’ll have to start the build manually.

JIRA Plugin Post-build Actions

Day to day project usage
There are no special tasks or steps required to take advantage of the Jenkins JIRA integration. The only requirement is, that a SVN/Git commit contains the JIRA issue ID in the commit message (e.g. as it is done automatically by Eclipse Mylyn with an active task). Every new commit included in a new build will be searched for JIRA issue IDs. Each issue will contain the same comment created by the Jenkins JIRA plugin pointing to the generated artifact.

JIRA issue updates by Jenkins

Camel Security @ JavaOne – What is it all about?

As JavaOne 2012 is coming closer, it's time for some more information on my session CON3418 – Confident Data Transfers with Apache Camel Security.

As you might have already guessed, it's all about Apache Camel security. So, what exactly is so special about Camel security? Well, it is of course possible to secure any Camel communication with SSL/TLS, like any other http communication or web service calls for example. Not really special and associated with some disadvantages too. And that's where Camel security comes to the rescue. In fact, Camel security consists of more than one part, payload and route security are the important ones in this case. Payload security takes care of encrypting or signing the message content (a.k.a. payload). This can be classic cryptography (classic does not stand for the real classic cryptography like Caesar encryption) with the Crypto data format or XML based cryptography (XML Encryption) with the XMLSecurity data format. And of course digital signatures of the message content. In the other part of the session I will talk about route security. Route security protects the routes itself, taking care of who (user or user group) can call a route or particular route section. This is done with the Camel components for Apache Shiro or Spring Security.

A lot to talk about. And a lot of ideas and recommendations for securing your Apache Camel routes in your integration projects. Hope to see you in my session! And for the Camel fans: There is a second session on Apache Camel: CON2430 – Next Generation: Systems Integration in the Cloud Era with Apache Camel

As I'm making progress in creating the slides/ demos for my session, I will provide some previews here in my blog the next couple of weeks. Make sure to come back regularly…