Codedrop™ Weblog

The beauty of ruby makes it simple to add some colorful syntax highlighting to log messages that are displayed in your capistrano scripts.  Here’s a chunk of code I added to my utility.rb file that is included by my capfile that performs the magic.


def colorize(text, color_code)
"#{color_code}#{text}\033[0m"
end

def red(text); colorize(text, "\033[31m"); end
def boldred(text); colorize(text, "\033[1;31m"); end
def green(text); colorize(text, "\033[32m"); end
def boldgreen(text); colorize(text, "\033[1;32m"); end
def yellow(text); colorize(text, "\033[33m"); end
def boldyellow(text); colorize(text, "\033[1;33m"); end
def blue(text); colorize(text, "\033[34m"); end
def boldblue(text); colorize(text, "\033[1;34m"); end
def purple(text); colorize(text, "\033[35m"); end
def boldpurple(text); colorize(text, "\033[1;35m"); end
def cyan(text); colorize(text, "\033[36m"); end
def boldcyan(text); colorize(text, "\033[1;36m"); end
def white(text); colorize(text, "\033[37m"); end
def boldwhite(text); colorize(text, "\033[1;37m"); end


def inform(text); green(text); end
def highlight(text); boldgreen(text); end
def warning(text); yellow(text); end
def alert(text); red(text); end
def section(text); "\n\n#{"*" * 50}\n#{text}\n#{"*" * 50}";

Now by utilizing the wrapper methods like this:

task :testconfig do
logoutputDir = Logging.initialize("#{$deployDir}/logs", $envNameName, $envNameNum)
Logging.info inform("*" * 75)
Logging.info inform(" Starting... ")
Logging.info " Env: " + highlight('development')
Logging.info " Date: " + highlight(Time.now.to_s)
Logging.info " User: " + highlight('jsmith')
Logging.info " Logs Dir: " + highlight('/tmp/projectX/log')
Logging.info inform("*" * 75)
Logging.info inform(".. informational message ...")
Logging.info warning(".. warning message ...")
Logging.info alert(".. alert message ...")
Logging.info highlight(".. highlighted message ..")
Logging.info inform("*" * 75)
Logging.info inform(" Done! ")
Logging.info " Date: " + highlight(Time.now.to_s)
Logging.info " Dist: " + highlight('/tmp/projectX/dist')
Logging.info inform("*" * 75)
end

You'll get pretty output like this:

Sample console output

After having utilizing TIBCO’s Designer product for a number of months, several blaring deficiencies come to mind.. .here’s a list of my top complaints.  I expect I’ll be adding to this list as I continue to discover new ‘features’ within the product.

1. Unable to open 2 versions of the same project at the same time.  Unless you rename the tibco project, designer does not let you open two version of the same project.
2. Internal editor for java sources is like trying to write a java program in notepad.  Why not allow it to link to an external editor?
3. No Subversion (svn) support.  Has perforce and cvs but no svn?.. get with the times already
4. Service deployments (.ear) files on a linux environment consume the max amount of memory allotted.. (approx 512mb per .ear).  This makes a SOA architecture hard to achieve if end up having to bundle services into a single .ear due to hardware constraints… imagine 60 services with this overhead.
5. Generated files do not present themselves in a standard order.  Often if you resave a project the xml will be re-ordered, thus triggering your source control tool to think there is an uncommitted change even if there isn’t one.
6. When defining a process archive designer prevents you from adding multiple process starters.  Strangely if you add them all at once instead of one by one this is ok.  This could be the scenario when you have a service with multiple processes that listen on different queues.  Why designer isn’t consistent I don’t know..  stop assuming to ‘know’ what I’m trying to do!
7. (UPDATED 26-Jul-2010) Parse Data activity does not handle reading a csv input with embedded  double quotes.   Typically CSV files identify these values by surrouding entire column contents in “, and any embedded quotes are doubled up..  This is actually what the Parse Data documentation prodivded by TIBCO states.  Unfortunately it doesn’t work that way.

For example:

1, Bob, Sanders, “Height 5’4″”, Weight: 153lbs”, 100, “NSW, Victoria”

Would not parse correctly as the 5’4″ text would signify the end of the column and “, Weight: 153lbs would end up as the next value.  After talking with TIBCO support, apparently this is a known issue (BW-7947) and will be resolved in BW6. Geez, thanks.

Now I realize no software of this nature is foolproof, but really, some of these things are pretty basic.  I think these guys need to stepup their QA when your selling to major enterpises who utilize the stuff in mission critical areas.

Neat way to pre-initalize something in capistrano before a task is run

on :start do
verifyParametersAndInitialize()
end

callback options:

1. :before, triggered before a task is invoked
2. :after, triggered after a task is invoked
3. :start, triggered before a top-level task is invoked via the command-line
4. :finish, triggered when a top-level task completes
5. :load, triggered after all recipes have loaded
6. :exit, triggered after all tasks have completed

After working in a rails environment for the past year I found it terribly difficult to go back to traditional database deployment / upgrade practices.

Migrations are a beautiful way to properly version, co-ordinate and apply the changes you need to your various database environments.  I never knew of a way to do this in a non-rails environment, until now. Step in AutoPatch.

Some alternatives to AutoPatch exist such as migrate4j and Liquibase. Each with their own flavor of how to tackle the problem. AutoPatch was the winner for me as you don’t have to write your migrations in some custom DSL (xml in the case of Liquibase, or java for migrate4j). Our existing .sql scripts worked just fine!

Our shop is currently using Capistrano for deployments. Blending Autopatch with Capistrano was relatively straightforward. Below are two sample tasks that can be added to facilitate AutoPatch’s cmd line info and migrate calls.

desc "Display database migration levels."
task :dbinfo do
cmdAPClasspath = "#{deployDir}/applications/database/lib/oracle/ojdbc14_g.jar" \
+ ":#{deployDir}/dist/prepare/database" \
+ ":#{deployDir}/lib/java/tk-autopatch-1.2-b-cvs.jar" \
+ ":#{deployDir}/lib/java/log4j-1.2.8.jar" \
+ ":#{deployDir}/lib/java/commons-logging-1.0.3.jar" \
+ ":#{deployDir}/lib/java/commons-collections-3.2.1.jar" \
+ ":#{deployDir}/lib/java/commons-lang-2.2.jar" \
+ ":#{deployDir}/lib/java/tk-util-1.1.2.jar"
cmdAPPatchInfo = "java -cp #{cmdAPClasspath} " \
+ "com.tacitknowledge.util.migration.jdbc.MigrationInformation #{systemName}"
system(cmdAPPatchInfo)
end

desc "Apply database migrations."
task :dbmigrate do
cmdAPClasspath = "#{deployDir}/applications/database/lib/oracle/ojdbc14_g.jar" \
+ ":#{deployDir}/dist/prepare/database" \
+ ":#{deployDir}/lib/java/tk-autopatch-1.2-b-cvs.jar" \
+ ":#{deployDir}/lib/java/log4j-1.2.8.jar" \
+ ":#{deployDir}/lib/java/commons-logging-1.0.3.jar" \
+ ":#{deployDir}/lib/java/commons-collections-3.2.1.jar" \
+ ":#{deployDir}/lib/java/commons-lang-2.2.jar" \
+ ":#{deployDir}/lib/java/tk-util-1.1.2.jar"
cmdAPPatchInfo = "java -cp #{cmdAPClasspath} " \
+ "com.tacitknowledge.util.migration.jdbc.StandaloneMigrationLauncher #{systemName}"
system(cmdAPPatchInfo)
end

Gmail’s great… and who doesn’t have a gmail account nowadays. One thing I’ve always wondered was how to search for all unread messages, and not just those on the current page?… Who wants to seatch backwards page by page looking for unread messages anyways…

Well after years of using it today I finally found the answer. Simply search for ‘label:unread‘ messages and your set!.. wonder what other nifty searches you can preform?

Setting up trac on dreamhost isn’t a very well documented process.  The one-click install does setup a project, but your left with bare bones install and no help on getting the initial admin account created.  I found the dreamy-trac installation script worked well.  Beyond this and the basic config changes you have to do I found the following settings are required in your trac.ini file in order to get your email notifications working on Dreamhost when you use GMail as your mail provider.

[notification]
smtp_enabled = true
use_tls = true
mime_encoding = base64
smtp_server = smtp.gmail.com
smtp_port = 587
smtp_user = user
smtp_password = password

Here’s a nice use of linux find to locate all ssl certificate files on a filesystem stored in directories name /certificates that excludes pesky .svn results:


find . -path "*/certificates/*" -not \( -name .svn -prune \)

I recently used this technique for pulling all certificates that were scatterred throughout a svn repository. Taking this output you can then easily copy them to another location (say for production deployment)

find . -path "*/certificates/*" -not \( -name .svn -prune \) -exec cp '{}' ./deploy/dist/certificates ';'

To go one step further integrating this into an ANT build proved to be a pain in the butt.  The ant exec task was causing me alot of grief so ended up using antcontrib tasks like this:


<target name="distCerts"
description="Prepare folder with all certificates required for deployment.">
<delete  dir="${projectRoot}/deploy/dist/certificates"/>
<mkdir dir="${projectRoot}/deploy/dist/certificates"/>
<shellscript shell="sh" dir="${projectRoot}">
find ./servicegroup -path "*/certificates/*" -not \( -name .svn -prune \) -exec cp '{}' ./deploy/dist/certificates ';'
find ./deploy/certificates -path "*" -not \( -name .svn -prune \) -exec cp '{}' ./deploy/dist/certificates ';'
</shellscript>
</target>


… much easier!

3 days wasted trying to solve a TIBCO issue with EMS messages. 

Heres the scenario:

Utilizing a TIBCO service with a “JMS Queue Requestor” that communicated with a backoffice java service (spring, jboss rules).  The TIBCO service published messages to a specific ems queue.. MYSERVICE.REQUEST and would listen for responses to queue MYSERVICE.RESPONSE.  The backend service would pick up messages from the MYSERVICE.REQUEST queue and write the response back to MYSERVICE.RESPONSE.  Fairly standard flow here.

We started making use of a static reply queue and adding correlation_id on the JMS request msg so that random temporary queues would not be created (easier for debugging) for the response.  Suddenly we received random occurrences where  the message response no longer matched the associated request.  I was able to easily recreate this problem in a development environment by creating a perl program that made several simultaneous requests to our service on different threads.  With as few a 2 threads errors started occuring all the time.

After some time going through our custom java code I ended up utilizing GEMS to monitor the EMS queues incoming/outgoing responses.  All looked fine here… so that pointed back at TIBCO.  Thus leading me to eventually stumble across the solution in the TIBCO support forums.  The solution is posted below but I find it Interesting that BW Designer interface allows you to create this scenario in the first place.  Seems like a bug to me….  This ‘feature’ could easily cost a business many days and could be a critical failure point if it made its way into production systems.. imagine a financial application where messages were getting mixed up.  Surely there can be more controls to prevent this scenario with the development tools.

** This highlights an important point to all you IT decision makers out there.  Don’t just buy into the marketing/sales pitch when investigating software alternatives… Get valid references and speak to people using the product to get their true feedback on the product.

How to correlate EMS messages in a request response scenario

Case1

Consider the scenario where you are using a JMS Queue Requestor which sends a request and waits for a reply. Additionally, you have a corresponding process (say a JMSQueue receiver) which receives these requests and sends back replies (Reply To JMS Message).

JMS request/reply activity uses temporary destinations to ensure that reply messages are received only by the process instance that sent the request. While sending each request the JMS Queue requestor creates a temp queue for the reply. It then sends the temp reply queue name along with the request message. The temporary queue name is unique for each process instance.

If the replyToQueue queue (static) is specified then all replies will be sent to the same queue and there will be no guarantee that the correct reply will be received by the process instance that sent the request.

You can use an expression for the replyToQueue to create different replyToDestinations for each request.

Case2

In Case1, if you need to use constant destinations for all replies and you do not want to use temporary destinations, then proceed with the following. Instead of using JMSQueueRequestor you can use the pair of JMSQueueSender and Wait for JMSQueueMessage Activities and then map the messageID of the JMSSender as the event key of the Wait for JMS activity and use the JMSCorrelationID header of the input message as the Candidate Event Key.

Running the TIBCO stack on a RHEL 4.7 environment I recently hit a problem where uploading a new .ear file through the Adminstrator console would error and render a blank page.  Some digging into the logs yielded an error when trying to write to a temporary folder that was under /tmp.  Restarting the entire system would re-create the new directory under /tmp but after a few days it dissappeared (o/s cleaned it up) and the error re-occurred.

Setting the java.property.java.io.tmpdir environment variable acts as a permanent fix for this as you can specify a custom directory that will not be purged automatically.

Modify these config files:

<tibco_home>/administrator/domain/<domain_name>/bin/tibcoadmin_<domain_name>.tra
<tibco_home>/tra/domain/<domain_name>/hawkagent_<domain_name>.tra

To add the following:

# CUSTOM – Specify the location of the temporary files for upload.  System default of
# /tmp will error after a few days as the dirs get cleaned out.
java.property.java.io.tmpdir=<path>

ie. java.property.java.io.tmpdir=/opt/tibcotmp

** NOTE: Using a custom token in your comment (ie: CUSTOM) will allow easy identification of all config files that you modified you add a custom property that is outside the normal configuration.

Found a great article at carbonfive.com on how to configure application with Spring utilizing various techniques.  My favorite from this article is included below:

Optional External Properties

There’s another use case that applies to some projects. Often in non-developer environments, system admins want to keep properties for the environment outside of the deployable archive or the application server, and they don’t want to deal with keeping those files in a Tomcat context file; they prefer a simple properties file. They also don’t want to have to place the file in a hard-coded location (e.g. /var/acmeapp/application.properties) or they may keep configuration for multiple servers in the same network directory, each file names after the server. With a little trickery, it’s easy to support an optional external properties file that isn’t in a hard-coded location. The location of the file is passed as a single system property to the JVM, for example: -Dconfig=file://var/acmeapp/server1.properties.

Here’s the configuration to make it happen:

<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="ignoreUnresolvablePlaceholders" value="true">
</property>

<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="ignoreResourceNotFound" value="true">
    <property name="location" value="${config}">
</property>

</property></bean></bean>

The first definition enables basic property resolution through system properties (in fallback mode). The second bean loads the resource from the location resolved from the system property -Dconfig. All spring resource urls are supported, making this very flexible.

Best Practices

• Deploy the same exact artifact (e.g. war, ear, etc) across all environments by externalizing configuration. This may seem daunting, but the emergent benefits are huge in terms of simplicity.
• Only make things that can safely change across environments configurable. Also, only things that need to be configurable should be configurable, it’s easy to go overboard.
• Configure the minimal properties search path that meets your requirements.
• When looking for properties files in the project tree, use classpath resources whenever possible. This makes finding those files easy, consistent, and insensitive to the working-dir, which is great when running tests from your IDE and command line.
• Aim for a zero-configuration check-out, build, run-tests cycle for the environment where its happens most: development.