Setting up Mercurial on Apache

Recently I started investigating the two major Distributed Version Control Systems (DVCS) mainly due to the historical SVN deficiency in handling renames. You may say that you don’t need a DVCS for tracking renames … Yes, in fact I know… it was only an excuse to start learning a DVCS after all there are plenty differences between a regular VCS and a DVCS.

My first option

After analysing whether I should stick with Git or Hg I decided to go with Hg since I have a trauma of using native applications originally written for Linux on Windows. Not that I am a Windows only user, in fact for a long time I had been using Linux as a Desktop option instead of Windows but you can’t deny that there is still a huge crowd that won’t switch from Windows over anything. The problem with native Linux applications that highly depend on a collection of shell scripts and other Linux dependent solutions is that they usually have a suboptimal performance on Windows, either they miss some functionality or they depend on a myriad of rare libraries. Have said that, I went with Mercurial on my first attempt.

First attempt with Hg

I wasn’t really lucky on my first attempt to install Hg. My first mistake was to pay too much attention to python.org’s warn on main downloads page:

If you don’t know which version to use, start with Python 2.7;

This warning is probably updated after each stable version is released but if I had seen the other advice on releases page I’d have thought twice:

Consider your needs carefully before using a version other than the current production version.

I chose to download latest python and build Hg myself and obviously it prove to be not that smart as it was my first experience with Hg.

Comes Git

As I gave up on Hg I decided to give a try on Git. First thing was to download msysGIT and surprisingly enough (following this tutorial) it was rather easy to set it up but its drawbacks were related to its tooling. As soon as I setup Git and tried to clone a repository over HTTPS with authentication I realized that JGIT does not support authentication over HTTP and as it was what I planned (in fact SSH on Windows is not very advisable since I have never seen a good free port of a SSH Server for Windows).
I had to get back to Hg but I decided to check whether I was taking a complex approach since Git employs a similar approach and had been much easier, I used what I learned with the tutorial used for Git setup.

Second attempt on Hg

As already mentioned, I decided to do something similar to what I done on Git, so, I chose CGI. I’ll highlight the important points for the installation here:

• The file to be downloaded is now named hgweb.cgi and not hgwebdir.cgi
• Download python 2.5 as noted here
• Unzip library.zip as noted here and edit the sys.path.insert line and the first line (the one with the #! (sha-bang) ) to point to python executable
• Configure style and templates entries under [web] on hgweb.config
• Configure an entry under [paths] for each repository (eg.: repository = c:/users/hg/repository)
• Enable pushing for the configured repositories
• Configure authorization on Apache. Either using htpasswd or ldap, but authorization is really recommended.
• Configure SSL on Apache (there is a short explanation on how to do this in portugues over here, the only thing is that SSLPassPhraseDialog builtin is not supported on Windows, so instead, provide a .bat file with a simple @echo yourpassword and use exec instead of builtin (eg.: SSLPassPhraseDialog exec:C:/Progra~1/Apache~1/Apache2.2/bin/passphrase.bat

Perform an hg init for each configured repository, start Apache and try cloning the repository over HTTPS (remember to provide your credentials if you configured any authentication method).

JBoss Seam application blueprint

I am a JBoss Seam user since its v2.0 alpha something (back in 2007). I still remember the hard decision in picking up the alpha and later beta version instead of sticking with the stable but feature missing 1.2.
Seam is an incredible framework for web applications, it covers the majority of the requirements you have in such applications. But this tremendous power comes with a price, it is often hard to find the best combination in the first application you develop. Its variety of contexts combined with the possibilities of handling the page data through injection and outjection results in a challenge for the Seam newbie, not to mention the possibilities of handling the flow between pages…

That’s the reason I thought about developing a blueprint for Seam applications… I know that for now SeamGen generated applications are considered blueprints for Seam applications but I really feel like there are plenty of missing parts. SeamGen applications don’t use Conversation scopes (only to give an example cause the list of Seam features that are not explored by a SeamGen application are enormous). I am also sure that I won’t develop THE blueprint for a Seam application but at least I’ll try to document all the knowledge I’ve gathered from a few projects and a few POCs.

Managing page flow and conversation demarcation

Seam has a neat feature for specifying page flow: pages.xml and view-id.page.xml files. The first one is able to specify navigation rules for every view in the application and should be used for specifying global rules as when Exceptions are thrown or for actions that have the same result independent of the current view. This post presents good practices for defining page flows using Seam. There is even one thing covered in this post that I recommend: specifying conversation demarcation on view-id.page.xml files but there is one thing suggested on this post that I need to investigate carefully: the impact of joining conversations instead of spawning new ones. I agree with the post that not joining may spawn unwanted conversations and thus increase memory usage but I cant say beforehand which are the drawbacks of joining a conversation.
A good way of redirecting the user to a new view with total control over conversation propagation is by using the s:button tag. This tag has one property named view that specifies the target view-id and another one called propagation in which you can specify the conversation propagation. The following example redirects to a view named “newUser.xhtml” and suspending the current conversation scope:

<s:button value="New User" view="/newUSer.xhtml" propagation="none"/>

And if this view required a conversation scope this could be specified on newUser.page.xml with the <begin-conversation> tag.

Authentication and authorization

Everytime that you are developing an application targeting a deploy on a full fledged J2EE application server and if possible, prefer to delegate authentication and authorization to the Application Server JAAS. The following code when configured on Seam components.xml delegates to the specified JAAS domain:

<security:identity jaas-config-name="myJAASDomainName" remember-me="true"/>

This avoids the rather limited approach of specifying an authenticator method on an application Seam component since a JAAS authenticated user will be propagated all the way down the EJB container (in case you are using it).

That’s all for now I’ll try to update this post as soon as I format more knowledge around JBoss Seam.