OSGi Bundle of BouncyCastle / Alternate JCE Provider

BouncyCastle comes in the form of signed jar, and there is a good reason for doing so. Java JCE Reference Guide states very clearly that providers need to be signed by a trusted entity to be plugged into the JCE framework.

So, if you try to OSGi bundle BouncyCastle the resulting jar won't be signed anymore, and JCE won't be able to authenticate the BouncyCastle provider.

This is the reason we see problems like this: ZRTP integration (possible) OSGi bundle related problem and this: bouncy castle exception with osgi. Two workarounds would be to...

1. OSGi bundle BouncyCastle, but loose it's ability to be an alternate JCE provider
   
2. Add it in the org.osgi.framework.system.packages.extra list in the felix.client.run.properties and make sure it's in the class path as it is mentioned here.

If you finally choose to OSGi bundle BouncyCastle, make sure that no manifest merging occurs, or else OSGi won't be able to start your bundle, it will probably fail with something like this:

java.lang.NullPointerException
at java.util.jar.Manifest$FastInputStream.fill(Unknown Source)
at java.util.jar.Manifest$FastInputStream.readLine(Unknown Source)
at java.util.jar.Manifest$FastInputStream.readLine(Unknown Source)
at java.util.jar.Attributes.read(Unknown Source)
at java.util.jar.Manifest.read(Unknown Source)
at java.util.jar.Manifest.(Unknown Source)
at org.apache.felix.framework.searchpolicy.ContentLoaderImpl.calculateContentPath(ContentLoaderImpl.java:344)
at org.apache.felix.framework.searchpolicy.ContentLoaderImpl.initializeContentPath(ContentLoaderImpl.java:315)
at org.apache.felix.framework.searchpolicy.ContentLoaderImpl.getClassPath(ContentLoaderImpl.java:90)
at org.apache.felix.framework.searchpolicy.ContentClassLoader.findClass(ContentClassLoader.java:154)
at org.apache.felix.framework.searchpolicy.ContentClassLoader.loadClassFromModule(ContentClassLoader.java:94)
at org.apache.felix.framework.searchpolicy.ContentLoaderImpl.getClass(ContentLoaderImpl.java:166)
at org.apache.felix.framework.searchpolicy.R4Wire.getClass(R4Wire.java:105)
at org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.searchImports(R4SearchPolicyCore.java:505)
at org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClassOrResource(R4SearchPolicyCore.java:466)
at org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClass(R4SearchPolicyCore.java:185)
at org.apache.felix.framework.searchpolicy.R4SearchPolicy.findClass(R4SearchPolicy.java:45)
at org.apache.felix.moduleloader.ModuleImpl.getClass(ModuleImpl.java:216)
at org.apache.felix.framework.Felix.createBundleActivator(Felix.java:3468)
at org.apache.felix.framework.Felix._startBundle(Felix.java:1649)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1578)
at org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1172)
at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:265)
at java.lang.Thread.run(Unknown Source)
java.lang.NullPointerException
at org.apache.felix.framework.searchpolicy.ContentClassLoader.findClass(ContentClassLoader.java:154)
at org.apache.felix.framework.searchpolicy.ContentClassLoader.loadClassFromModule(ContentClassLoader.java:94)
at org.apache.felix.framework.searchpolicy.ContentLoaderImpl.getClass(ContentLoaderImpl.java:166)
at org.apache.felix.framework.searchpolicy.R4Wire.getClass(R4Wire.java:105)
at org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.searchImports(R4SearchPolicyCore.java:505)
at org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClassOrResource(R4SearchPolicyCore.java:466)
at org.apache.felix.framework.searchpolicy.R4SearchPolicyCore.findClass(R4SearchPolicyCore.java:185)
at org.apache.felix.framework.searchpolicy.R4SearchPolicy.findClass(R4SearchPolicy.java:45)
at org.apache.felix.moduleloader.ModuleImpl.getClass(ModuleImpl.java:216)
at org.apache.felix.framework.Felix.createBundleActivator(Felix.java:3468)
at org.apache.felix.framework.Felix._startBundle(Felix.java:1649)
at org.apache.felix.framework.Felix.startBundle(Felix.java:1578)
at org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1172)
at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:265)
at java.lang.Thread.run(Unknown Source)

Subversion, SourceGear's Diffmerge and Cygwin

A while back in my Arsenal Selection post I described a way to use SourceGear's Diffmerge with Mercurial. No that I started to commit stuff to my SIP Communicator branch, I needed to do the same with SVN (which I run under Cygwin).

It turns out to be a little trickier with SVN firstly because SVN is not that versatile as Mercurial and second because I use SVN under Cygwin which results in paths being delivered in diffmerge Cygwinized.

To enable a 3d party diff tool you need add something like this in your ~/.subversion/config file (c:\cygwin\home\your_user\.subversion\config):

diff-cmd = diffwrapper.sh

With the help of Eric's post Living with Subversion and Pete's post Subversion, KDiff3, and Cygwin I've built diffwrapper.sh to look like this:

#!/bin/sh

LEFT=`cygpath -d ${6}`
RIGHT=`cygpath -d ${7}`

# thanks to jtr for the sed regex
LEFT_NAME=`echo ${3} | sed 's/.*\/\([^/]*\)/\1/'`
RIGHT_NAME=`echo ${5} | sed 's/.*\/\([^/]*\)/\1/'` #src/net/java/sip/communicator/impl/protocol/jabber/OperationSetInstantMessageTransformJabberImpl.java (revision 0)

/cygdrive/c/Program\ Files/SourceGear/Vault\ Client/sgdm.exe /title1:"$LEFT_NAME" "$LEFT" /title2:"$RIGHT_NAME" "$RIGHT"

Now you need to make sure that diffwrapper.sh script is somewhere in your PATH. I've added in ~/bin, and did

echo export PATH="\$PATH:$HOME/bin" >> ~/.bashrc

Update: Friday, 24 July, 2009
Here's a mergewrapper.sh script

#!/bin/sh
local=`cygpath -d ${3}`
remote=`cygpath -d ${2}`
base=`cygpath -d ${1}`
merged=`cygpath -d ${4}`
/cygdrive/c/Program\ Files/SourceGear/Vault\ Client/sgdm.exe /result:"$merged" /title1:"Local" /title2:"Merged" /title3:"Remote" "$local" "$merged" "$remote"

Publishing your java.net SVN commits using Yahoo! Pipes

hapdaniel has a nice post about HTTPS, Pipes and YQL. Based on that post, here's a pipe that builds an RSS feed that shows your personal SVN commits to SIP Communicator.

Working with your SVN branch - Merge trunk changes to your branch

Now that the java otr library otr4j is functional, I wanted to merge any trunk changes back to my SIP Communicator branch, prior tto getting to work with SIP Communicator. I decided to post this because I always find my self googling for the answer..

this actually involves 4 commands:

1. svn update, you run svn update to sync your working copy so svn info will show you updated information.
2. svn info, running svn info will reveal the current HEAD revision (r2) as well as the revision of the last change of your branch (r1).
3. svn merge, having these two pieces of information you can run svn merge -r r1:r2 trunk_location
4. svn ci -m "Merged trunk changes r1:r2 into my branch"

Update: Friday, July 24, 2009

If you have time I would recommend reading at least Subversion in Action and Branching and Merging from the book Version Control with Subversion.

The procedure described above is not correct. It is simpler in >= 1.5 setups and, occasionally, more complicated in < 1.5 setups.

MiniMax and stsp on #svn channel on Freenode kindly answered my questions regarding some issues I had. I have to incorporate the outcome of the discussion here but until then here's the log.

OTR4j Authenticated Key Eexchange Log in Chainsaw V2

Screen capture of Chainsaw V2 visualizing otr4j running the Off-the-Record (OTR) Authenticated Key Exchange.

Progress by June 25

It's been a while I haven't update the blog. Well this is all but true for the otr4j library!

I have been working on it during the past 14 days, and I am pretty happy to announce that with the latest changes just a few minutes ago, goal "June 25" has been reached. That is, as of revision 068510f52f otr4j can successfully run an Authenticated Key Exchange, and exchange encrypted data.

Tomorrow I will write new tests and improve existing ones to make sure the implementation is fully functional.

After that I will dive into SIP Communicator and will start working for goal July 05.

Progress by June 11

Did a relatively big code refactoring. First of, I purged some elements that where obtrusive like huge javadocs and getters/setters. Both can be added at a later development stage when the library will be relatively stable.

Simplified how messages are assembled/disassembled. Now one can disassemble a message by calling the appropriate constructor, and can assemble messages by calling the toString() method of a message instance.

Implemented state transition handling and message reply dispatching mechanism when receiving

• Plain text messages (with or without whitespace)
  
• Query messages
• Error messages
• D-H Commit messages
• D-H key messages

Created or adopted existing test cases, for refactored functionality (assemble/disassemble) and new functionality of handling state transitions respectively.

The project now uses Mercurial. Get a local copy of the repository with this command:

hg clone https://otr4j.googlecode.com/hg/ otr4j