Posted on January 26, 2008 in Software Development by Rob Di Marco15 Comments »

I’m on a hot streak tonight… Another comon problem that I have had to solve recently is how to attach a build number to files that are being generated out of an Ant build script.

We have developed a versioning scheme (inspired by http://geekswithblogs.net/emanish/archive/2006/09/25/92219.aspx) for our releases where our release are named <major>.<minor>.<revision>.<build>. So a valid build number might be 1.18.2.1077. This means it belongs to the first major release of the software, the eighteenth minor version, it is the second attempt at a release for this minor version (usually bug fixes), and it is related to the SVN revision number 1077. Any time we are doing a build we are tagging in our Subversion repository to keep the build number tied to the tag. When I build a release, I want my artifacts to look like to look like this: app-1.18.2.1077.ear.

There are a few ways to do this, One way that I considered was to just include a property or Subversion tag in the build.properties file. But I did not want to maintain it and I have always loathed the auto tags that were available in CVS.

My second option was to use the <svn> Ant task. While this will probably work, I have varying degrees of success using the Java SVN library, especially when connecting to Subversion over SSH as we are doing for this application.

So, I decided to go with using the task in conjunction with svn info and svnversion to set the full.build.version property to the current release number. This assumes that the repository checked out is of the format svn://REPO_NAME/tags/<MAJOR>.<MINOR>.<REVISION>

<exec outputproperty="build.current.revision" executable="svnversion">
         <arg line="-n -c" />
         <redirector>
           <outputfilterchain>
             <tokenfilter>
                 <replaceregex pattern="^[0-9]*:?" replace="" flags="g"/>
             </tokenfilter>
          </outputfilterchain>
        </redirector>
</exec>
<exec outputproperty="build.current.version" executable="svn">
  <arg line="info" />
  <redirector>
  <outputfilterchain>
  <linecontainsregexp><regexp pattern="^URL:" /></linecontainsregexp>
   <tokenfilter>
     <replaceregex pattern=".*\/([^\/]+)$" replace="\1" flags="g"/>
   </tokenfilter>
  </outputfilterchain>
</redirector>
</exec>

<property name="full.build.version" value="${build.current.version}.${build.current.revision}" />

I’m sure that I could have gotten the revision from the svn info rather than svnversion, saving a command, but I wasn’t inspired enough to do it. Maybe when I have more time.

Popularity: 100% [?]

Posted on January 26, 2008 in Software Development by Rob Di MarcoNo Comments »

One of my clients is a large e-commerce company (>$500MMin annual revenuse through their website). They use Akamai for caching some of their image data, but some of the other images are served off of their server. They are trying to minimize the load on their JBoss instances and wanted to have Apache serve the static content when possible while JBoss handled the dynamic content. Both Apache and JBoss were running on the same Linux server.

This is a problem that I have faced a couple of times and every time I spend a few hours futzing with Apache configurations trying to get this to work. So I figure I should post the basic solution and never have to look hard for it again. Also, if someone has better suggestions, let me know.

Step 1: Activate the Requisite Modules

I use four modules for getting this to work

Make sure these are activated in your configuration

Step 2: Setting Up The Static Content

First step is to set up a directory location that will ahve the content. In my example, I am dealing with an exploded EAR in the Jboss home directory. This results in a configuration like

#
# Configure the static content directory and alias.  This is pointing at the cache
# file directory
# 

Alias /static-content/ "/usr/local/jboss/cache/app" 

#
# Do not allow any overriding from within the cache directory. #
<directory /usr/local/jboss/cache/app" >
  Options None
  AllowOverride None
  Order allow,deny
  Allow from all
</directory>

Step 3: Set up the rewrite rules

#
#  Rewrite all static content  to be served from the
#  static content directory
#
<IfModule mod_rewrite.c<
    RewriteEngine on 

    #
    # Setup the static content rule.  Any file that comes in that# we have on the filesystem, we should serve from there.
    #
    # We want this to be the last rule processed if we meet the conditions
    # and we need to pass through so that the static-content alias works.
    #
    RewriteCond /usr/local/jboss/cache/app/%{REQUEST_FILENAME} -f
    RewriteRule ^/?(.*)$ /static-content/$1 [L,PT]
</IfModule> 

<IfModule mod_proxy.c>

# No need to forward proxy
ProxyRequests Off 

# Make sure we clean up the headers
# you may also wish to use the mod_proxy_ajp to proxy
# over the ajp protocol

  ProxyPassReverse / http://localhost:8080/ 

# Needed to maintain proper host information
  ProxyPreserveHost On
</IfModule> 

Popularity: 51% [?]

Posted on January 25, 2008 in Software Development by Rob Di MarcoNo Comments »

Recently I’ve been doing a lot of different jobs:

  • President of my own company, 416 Software
  • Adjunct Professor for Penn State
  • Interim VP of Engineering for an unnamed startup doing cool things with email
  • Build/Release/JBoss Expert
  • General Software Consultant

but for my latest title….

Management Consultant.

Good to know someone takes my ranting seriously!

Popularity: 42% [?]