Adding HTTP Authentication for a user in Subversion

If you've already got your HTTP Authentication setup (instructions for that can be found here) then you can add a new user (eg. xyz) like this:

$htpasswd2 -m /etc/svn-auth-file xyz

Note that for Apache 2, you use the htpasswd2 command, NOT htpasswd.

Solution to the ORABEL-08021 "partnerlink not found" problem!

I was seeing an ORABPEL-08021 error when calling a Oracle BPEL web service via C# in .Net. Specifically, the error returned was:

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
  <env:Header/>
  <env:Body>
    <env:Fault xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
      <faultcode xmlns="">env:Server</faultcode>
      <faultstring xmlns="">ORABPEL-08021 Cannot find partner wsdl. parnterLink "MyService" is not found in process "MyService" (revision "1.0") Please check the deployment descriptor of the process to find the correct partnerLink name.
      </faultstring>
      <faultactor xmlns=""></faultactor>
    </env:Fault>
  </env:Body>
</env:Envelope>

The problem was that I was using the wrong URI to access the service. I was using:

http://myserver:8888/orabpel/default/MyService/1.0/MyService

and I should have been using:

http://myserver:8888/orabpel/default/MyService/1.0

So, my own silly fault really! Normally I can take the WSDL address (eg. http://myserver:8888/orabpel/default/MyService/1.0/MyService?wsdl) and just drop the "?wsdl" off the end to get the service endpoint. Not with these Oracle BPEL services though. If I had bothered to read the WSDL, I would have seen that the endpoint address is clearly specified. One more thing to note: with an Oracle BPEL service, you can also drop the version number off the end and it will still work, calling the latest version by default. eg:

http://myserver:8888/orabpel/default/MyService

Where should I put my .Net DLL for COM Interop?

I have a .Net DLL which I want to use from VB6 via COM interop. Where should I put it when I deploy it? (look here to see how to make a .Net DLL useable via VB6)

The key thing is that in order to use your .Net dll from VB6 you do need to register the .Net DLL. You don't need to to do anything special in the VB6 program - it doesn't matter how you reference the .Net DLL in your VB6 program. The command to register a .Net DLL is "regasm". This lives under "C:\Windows\Microsoft.Net\Framework\v2.0.50727" (or whatever .Net framework version you have).

There are three options for where to put your .Net DLL:

1. Put it in the GAC. If you want to share the same .Net DLL with more than one VB6 program then you can put it in the GAC (Global Assembly Cache). To do this, you can use an MSI file, or manually, you can copy it to c:\windows\assembly, and then register it via "regasm c:\winnt\assembly\mydotnet.dll".

2. Put it in the EXE folder. If you want the .Net DLL to live in the same place as your VB6 EXE then you can copy it to that folder, and then use "regasm c:\vb6\exe\folder\mydotnet.dll". Note that the .Net DLL has to be in the same folder as the VB6 EXE. So if you have VB6 EXE calling a VB6 DLL which calls your .Net dll then it must go in the EXEs folder - it won't find it in VB6 DLLs folder.

3. Put it in any folder via codebase. If you want the .Net DLL to live anywhere else, you can use use "regasm c:\program files\vanwills\mydotnet.dll /codebase". This will register the .Net DLL to the path you provide. This is a bit like the old VB6 regsvr32 command. So using this we can have the .Net DLL sitting in the "c:\vb6\dll\folder" folder.

The only other point to note is that .Net will always check the GAC first before other locations. So if we have a .Net DLL in the GAC, then even if we register the same DLL somewhere else via the "/codebase" option, it will always use the GAC DLL. You can get around this by changing the version number on the DLL - it will always load the version with the highest number first.

How to switch on log4net internal logging

If you want log4net to show its own internal logging, which is useful to find out where it is looking for your XML configuration file, you can add the following XML to your app.config file:

<configuration>
  <appSettings>
    <add key="log4net.Internal.Debug" value="true"/>
  </appSettings>
</configuration>

Note that if you are using log4net in a DLL, this goes into the app.config file for the EXE that is calling your DLL.

Log4Net using a named config file

Setting up Log4Net with your configuration in the app.config file is pretty straight-forward to do - a quick Google will lead to a number of posts on how to do this.

But if you decide to move your log4net config settings to an external file (convention seems to be "log4net.config") then there are a few misconceptions floating around. There are only two further steps you need to take to achieve this:

1. Copy the <log4net> ... </log4net> section out of your app.config and save it into a new file called log4net.config. You should totally remove it from the app.config file once you feel confident - it is no longer needed.

2. Modify your AssembyInfo.cs file by removing this:

[assembly: log4net.Config.XmlConfigurator
  (Watch = true)]

and replacing it with this:

[assembly: log4net.Config.XmlConfigurator
  (ConfigFile = "log4net.config", Watch = true)] 

Now if you fire up the IDE and run it, your logging should still work. If you don't see any logging, then check that the log4net.config is in the current application path - if you are running from the IDE then that will be where the EXE lives at "../MyProject/bin/Debug/". If you've placed the log4net.config file in your project home folder then you can get it working through the IDE with this:

[assembly: log4net.Config.XmlConfigurator
  (ConfigFile = "../../log4net.config", Watch = true)] 

Note that this will need to be reviewed come deployment time!

OR, even better, just select the config file in the IDE and, in the Properties window, change the "Copy to Output Directory" value to "Copy always". Now when you build it through the IDE it will follow your compiled file around. Nice!

Note that you do NOT need to add log4net.Config.XmlConfigurator.Configure() or log4net.Config.XmlConfigurator.Configure({file name}) to the code in your project! This does a manual configuration which overrides what is in the AssemblyInfo.cs file. If you get the AssemblyInfo.cs parameters right then that is all you need.

Email problems with CXF

I was having a problem sending emails from my Apache CXF web service. The emails just wouldn't get sent from within an exception handler on the web service.

CXF (2.0.4 in my case) provides it's own mail classes (geronimo-javamail_1.4_spec-1.0-M1.jar and geronimo-activation_1.1_spec-1.0-M1.jar). The solution was to remove references to these libraries from the Classpath, and instead use the Sun libraries (mail.jar and activation.jar).

This led to my second problem. Now my CXF emails would send, but they were displaying "(no subject)" for the subject. A bit of digging revealed that the Geronimo mail jars were still floating around in my deployed webapp library folder. Completely purging the web app and redeploying it fixed this.

Viewing what you are about to dcommit

If you have stacked up a bunch of Git commits in the master, and you want to see what changes are going to be pushed to Subversion at the next git svn dcommit, you can use the commands below:

  $git svn dcommit --dry-run (shows a list of commits that will be applied)
  Committing to http://xyz/svn/Project/trunk ...
  diff-tree bb2820965209ff83d016817b46268f289e65ab07~1 bb2820965209ff83d016817b46268f289e65ab07
  diff-tree cff6b4575f6f7797652f030cbb8b425f57f4e08a~1 cff6b4575f6f7797652f030cbb8b425f57f4e08a

This reveals that there are two commits that are going to Subversion. You can then view the file names involved in each commit via:

  $git diff-tree --stat bb2820965209ff83d016817b46268f289e65ab07~1 bb2820965209ff83d016817b46268f289e65ab07

Or you can view the actual source code changes in each commit, via:

  $git diff-tree -p bb2820965209ff83d016817b46268f289e65ab07~1 bb2820965209ff83d016817b46268f289e65ab07