JavaOne Photos, part 3

JavaOne Photos, part 2

Java One Photos, part 1

Unix Command - watch

I'm sitting here waiting for a huge rsync to complete over a slow network from slow disks to what I hope are faster disks.  To monitor the progress, I'm using the Unix watch command to periodically run a du on the directory being written to.  This gives me an idea of its growth and how far along I am:

watch --interval=1 du -sm /hudson

The -sm options to du just tell it to summarize the size in MB.

Externally Configuring Application Properties with Spring

I posted on another method for doing this a while back and this alternate approach was sent me some time ago so I thought I would share it here.  The issue trying to be addressed is the ability to deliver a single WAR file to multiple environments that each may need different configurations.  For example, a QA environment, an automated testing environment, a developer's personal environment, a customer's installation, or a hosted production instance.  To do this you need to externalize your applications configuration or build a UI and maintain the configuration in your database.  Using property files is a simple approach and works quite well and has some advantages over the database approach if your application instances are ephemeral.

You can have a default properties file and afterwards overwrite it with a file that is external to your application. The "properties overwrite file" is optional

<bean id="propertyConfigurer" 
 class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
 
</bean>
 

<bean id="propertyOverrideConfigurer"
        class="org.springframework.beans.factory.config.PropertyOverrideConfigurer">
       
          
</bean>

References:

1. http://static.springsource.org/spring/docs/2.5.x/reference/xsd-config.html 
2. http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/beans.html#beans-factory-overrideconfigure

Mock Server/Socket Process Testing

I recently had to do some development against a socket-level API daemon process that a 3rd party company runs as a service for us. During the initial set up period, I didn't have reliable access to the service for testing. I also wanted to test how my code handled getting weird and unusual responses from their server. I do my development on Windows 7 and the code is in Java and gets deployed to Linux machines. I run Cygwin and rely heavily on it. A simple solution was to use the nc command to create a server process listening on a port. My java process would then connect to this process and send a request. To simulate a response going to back to my process, I could simply cut-n-paste the XML response (as described in the vendor's API documentation). This was the command to start the mock server process listening on port 19110:

nc -t -l -p 19110

To test connections to this mock server process you can run:

nc localhost 19110

or

telnet localhost 19110

Tomcat 6 and Automatic Deploy

NOTE: I'm publishing this post quickly and I haven't had the time to properly explain it here and promise to come back to this topic. I've been asked several times about this behavior so I thought was worth documenting it.

Tomcat 6 has an "Automatic Application Deployment" feature that does the following:

• Every time a new .war file is deployed to the appBase folder (default is tomcat/webapps), tomcat automatically unpacks the new war file and generates a default Context element for it.
  


• Every time a new .war file is added or the docBase folder defined in the container changes, the unpacked content within the appBase folder is undeployed and the context settings, such as the /tomcat/conf/Catalina/localhost/myapp.xml, is automatically undeployed too.
  

This behavior has causes me trouble. I like to leave a context xml file in the conf/Catalina/localhost directory with a docBase pointing to where I assemble/compile by war file. Each time I do a new build, the context xml file under conf/Catalina/localhost is removed.

To disable tis auto-deploy behavior, modify Tomcat's server.xml file. Within the container, set the parameter of "autoDeploy" from "true" to "false".