Category: Java

The article is written based on Windows Server, CollabNet Subversion 1.6.1, Apache 2.2. Windows XP or Vista would do as well.

Subversion comes with it’s own server – svnserve. By default there is no security. One can install svn+ssh, but on a windows server and windows client that is a bit stupid.

The other option is to setup an Apache server with mod_dav and mod_dav_svn. Fortunately the CollabNet Subversion binary comes with Apache pre-bundled with those modules. The binary even installs viewvc, which is rather nice.

Installation steps.

After installing the bundle, however, there are a lot of things to do. Most of them manually. I’ll try to describe most of them here.

Download Collabnet Subversion Server binary from CollabNet (no other place to download it from). Registration required.

So we decided to use Apache instead of svnserve, so while installing one doesn’t have to make it a service. Only Apache should be installed as a service. Another pro for Apache is that it can host multiple SVN repositories as opposed to only one by svnserve AFAIK.

Now is the time to suggest that one make the Apache server run with limited credentials. By default the service would be running with Local System account which has more privileges than God the users in the Administrators group. The concrete steps would be to create one user with compmgmt.msc. Remove it from the Users group (which removes all the default privileges) and give this user Modify right for the httpd directory (one will most probably find it in C:\Program files\Subversion\httpd) and all the repositories.

The configuration. When installing Apache asks where is the repositories basedir. Using a basedir means that all the repositories are subdirectories of the basedir:

Subversion/httpd/conf/httpd.conf:

<Location /svn>
  DAV svn
  SVNParentPath "D:/SVN Repositories/"    <— put the qoutes. installer does not do it
</Location>

Note: by default the installer does not put quotes around the dir, so if there are space characters, the server will not start. One should put the quotes himself/herself.

Now is the time to say that the Apache server is very verbose. Every error show up in the Event Viewer in the Applications tab. There are always pretty good descriptions of what is wrong. I definitely like this feature of Apache. Unfortutely one has to use Google to figure how to fix it.

Another place to look for errors is httpd/logs/errors.log. Pretty readable. I’m positively surprised.

I don’t like the basedir approach – repositories with me are in different dirs. I do it like this

<Location /svn/mycompany>

   DAV svn

   SVNPath "D:/My Company/Repository"                   <— put the qoutes

</Location>

Authentication. Very shortly – http basic and http digest. Http basic is very insecure (only base64). Http basic looks like this:

<Location /svn/mycompany>

   DAV svn

   SVNPath "D:/My Company/Repository"

   AuthType Basic

   AuthName "MyCompany subversion repository"

   AuthUserFile "C:\Program Files\Subversion/httpd/conf/svn_auth_file"

   Require valid-user

</Location>

Now, how to make the user’s file (svn_auth_file). Use htpasswd (only for http basic):

C:\Program Files\Subversion\httpd\bin>htpasswd -cm ..\conf\svn_auth_file mihail

New password: ******

Re-type new password: ******

Adding password for user mihail

C:\Program Files\Subversion\httpd\bin>htpasswd -m ..\conf\svn_auth_file ivan

New password: *****

Re-type new password: *****

Updating password for user ivan

The first time –c is used to create the file. Any subsequent user is with –m only (which stands for MD5 as far as I remember).

svn_auth_file:

mihail:$apr1$AzWq5tu5$k554PODb79n9TZwBxBDh..

ivan:$apr1$hlr9s6gK$oFLP1WtwvOLczyUSiP10v/

For http digest the configuration first the module has to be uncommented in httpd.conf:

LoadModule auth_digest_module modules/mod_auth_digest.so    <—uncomment this line

the configuration for the location is the following:

<Location /svn/mycompany>

…

AuthType Digest

…

And users are made with htdigest:

C:\Program Files\Subversion\httpd\bin>htdigest.exe –c ../conf/svn_auth_file "MyCompany subversion repository" mihail

Adding user mihail in realm MyCompany subversion repository

New password: ******

Re-type new password: ******

C:\Program Files\Subversion\httpd\bin>htdigest.exe ../conf/svn_auth_file "MyCompany subversion repository" ivan

Adding user ivan in realm MyCompany subversion repository

New password: ******

Re-type new password: ******

The file svn_auth_file looks a bit different now:

mihail:MyCompany subversion repository:3d16aced3eac2fc74ce5663df86d145b

ivan:MyCompany subversion repository:3ff20546c01028d5008651445b62d2e0

Note: keep in mind that the realms in svn_auth_file and the <Location AuthName should match.

Note: do not confuse htpasswd and htdigest. They produce users for http basic and http digest respectively and are not interchangeable.

For now there is a pretty usable svn server that supports multiple repositories and digest auth. But the communication with the server is plain and unencrypted http.

The svnbook is available here (most up-to-date version 1.5): http://svnbook.red-bean.com/en/1.5/svn.serverconfig.httpd.html. The chapter for servers is Chapter 6.

The next part is how to setup a SSL on top of Apache.

Do the following multiple times:

The first time you do it the container.root.ca.jks would be created. The subsequent times it will just be filled up with new and new keypairs (public and private keys).

In the world of windows there is no standard tool to see what's going on the network level.

I have been working quite a while with web services and encryption and signing, so it's vital to me to see what's going on when a web service is being called.

TCP proxies
The way I was doing it until recently was to use TCP proxies. TCP proxies open a TCP port and forward to some other host:port. In the process of doing so it dumps every connection on the screen or in a file.
For example if I want to listen what's going on a local (for the machine I'm working on) port 8080 the following had to be done: the software working on 8080 (a web service) is moved for example to 18080, then the proxy is opened at 8080 which forwards everything to localhost:18080.

There is one minor drawback to the whole story -  the clients have to be supplied with a port that is not the port where the service resides. So if the proxy is missing - the service is invisible.

I've used mostly tcpmon and wsmonitor. wsmonitor sucks a lot. tcpmon works, but cannot handle moderately heavy traffic and has a lot of quirks that are very annoying. Anyway until recently it was my primary way of doing things.

Reading direcly from the TCP/IP Stack
There has always been software that can plug something in the TCP/IP stack of the windows machine and thus sniff the traffic. The bad side is that the machine has to be tampered with some third-party software. And some machines cannot (should not) be tampered like that.

A third way
There seems to be a software that can sniff the traffic without plugging nasty stuff in the TCP/IP stack. On such example is SmartSniff. It has what they call a "Raw Sockets" way of sniffing and so far it's working great.

I had an issue compiling some java classes. Javac failed, Eclipse's compiler worked. The issue is described here.
I was blaming Eclipse, I was blaming java6's endorsing. I was thinking it was due to JAXB.

It comes out they all were innocent.

Here's my code:

The result with javac is:

After some research I think I simplified the problem:
(If I continue to simplify it would still fail to compile but at some
point it would start to compile which yesterday drove me crazy.
This is the most simplistic case that consistently fails to compile)

All of these changes fix the compilation error (from javac):

or

This all makes me think that the static import fails the next one only if the next one is an annotation (I've tried with a java.util.Collection - it compiled).
I have tried this with jdk6u3 and jdk6u10.
I don't have jdk 1.5. Can someone test it on jdk 1.5?

Update: GRRRRRRRRRRRRRR, Somebody found it before me:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6391197
It was reported on 27th of June, 2006 :'(

Here's what they say:

Workarounds:
1) switching the order of the import statements works (although they often get changed back by our development tools).
2) Commenting out the static import statements, then compiling, then putting the import statements back and
compiling again with the old classes still there also works. This means that the compiler errors happen at the strangest
of times, and in large programs it can be very difficult to work out how to workaround the problems.

I have some code.
I have two classes. They both have inner enums.
The two inner enums have an annotation.

But one of them does not compile. The other one compiles just fine.

In eclipse there's no error, but when I build the code from ant I get a compilation error - the annotation class is not found:

I spent some time looking for it - I thought that the classpath is wrong, I endorsed an updated version of the API (java 6). The issue persisted.

Then I decided to use javac directly:

Strangely enough I got the same error?! Then I did the same for the class that did compile successfully using ant - it worked.
So there was a difference between the two classes and I had to find it.

And I found it, can you find it?

Yes, you're correct. The second enum is not static.
This only happens with inner static enums. The anomaly does not occur if it's an inner static class. I don't know why.

So I'm thinking that in the ProblematicClass the annotation is not visible because the import of XmlType is not visible.
I was correct - this one works:

I just supplied the FQN of @XmlType.

So eclipse is working, javac is not. Now is the time to say that Eclipse is not using javac. I thought it was using jikes (made by IBM), but that's not correct. Eclipse is using its own incremental compiler part of JDT Core. JDT stands for Eclipse Java Development Tools.

http://www.eclipse.org/jdt/core/:

So either javac or Eclipse's compiler is wrong. I would bet that javac is following the spec more strictly.

This is the second time I'm catching Eclipse's compiler of misconduct. The first time was something related to a very complex case with generics - one of the compilers said it was a warning, the other - error.

Update: I was wrong. I was trying to report the problem. I was making a pretty simple case. I used a different annotation: @javax.annotation.Resource. It worked both on Eclipse and on javac.
So the problem is somehow linked with JAXB.

JAXB is an API bundled with Java 6 (an 'endorsed standard' a 'standalone technology'). The version bundled was JAXB 2.0. If one wants to use a newer version, say JAXB 2.1, an 'Endorsed Standards Override Mechanism' had to be used.

Info on JAXB here.
Info on endorsed mechanism here.

I'm currently with JDK 6 update 10. Somewhere I saw that 'endorsed standard override mechanism' was no longer necessary.

It looks like the problem is more on javac side than on Eclipse's compiler.

I will investigate further.

Update2: It comes out that 'Endorsed Standards Override Mechanism' was existing prior to java 6. Only the standalone technologies were added in Java 6.

Update3: It comes out that 'Endorsed Standards Override Mechanism' is still used.

Update4: It comes out that this bug is very hard to reproduce. My simple examples at some point just started compiling 🙁

Update5: I just created some code that consistently reproduces the bug. I'll write it in a new entry to be cleaner.

Update6: I fixed coloring and finished the new article on the bug.

Still crashes on some update sites - it did hang on a modal window while downloading SoapUI.

Great new shortcut - middle button closes tabs as in browsers (only IE does not do that) - VERY, VERY COOL.

In a project where requirements change on a daily basis, refactoring is one's biggest friend.
I'm currently in such a project - not my kind of thing but reality sometimes sucks.
Anyhow, I've tried to look at it from the bright side.

I'm currently perfecting my refactoring skills in eclipse.

Here's what I can share.

Everybody knows about
Ctrl + Shift + R - find resource (file )
Ctrl + Shift + T - find type (class)

Alt+Shift+C - Change method signature

Alt+Shift+S - Context menu for source generation.

Alt+Shift+X, J - Launch current focused code as Java Console App
Alt+Shift+D, J - Debug current focused code as Java Console App
Ctrl + L - go to line - when watching stack traces. NEW
Ctrl + O - find method in class.   NEW
Ctrl + T - Hierarchy of a class (subclasses + base classes).   NEW

But do you know these:
Alt+Shift+X, Q - Launch current focused script as an Ant Build Script (focused on a target in the 'Outline' window launches only that target, very handy)
Ctrl + >, Ctrl + < - Navigates through warnings and errors in a source file. Extremely handy.

Ctrl + 1 - launches the solution box or whatever that's called.
Ctrl + 3 - finds any window.
Middle button closes tabs as in browsers (only IE does not do that) - VERY, VERY COOL. Ganymede (Eclipse 3.4) only.
Ctrl + E - list of all the open windows (by Joke). NEW
Ctrl + J - incremental search (like Ctrl + F, F3 in browsers (real browsers, IE can't do that)), then arrow up/down to go to next previous, Enter to stop (by rado). NEW

Ctrl + Shift + / - collapse all. NEW2
Ctrl + Shift + * - expand all. These are very nice in long classes. NEW2

Debugging
Ctrl + Shift + I - inspect selected source code while debuging.
The 'Display' window is my biggest friend - inside it you can write code and evaluate it with Ctrl + Shift + D (print result in the box) and Ctrl + Shift + I ( inspect the code in a context window.

That's for now, I'll update this regularly. If someone uses something regularly that is not here, please tell.

We have the following:
(The code is taken from here http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Throwable.html#printStackTrace())

What does ... 1 more or ... 3 more means?

This is what it means: