My first thought was to boot the server from a pen/flash/usb drive. At first glance I thought I could simply use the linux biosdisk utility from Dell available here.  The options are to create a disk image, write directly to a floppy drive, or create an RPM. I attempted using the first two options and made significant use of dd and fdisk without any luck. 

I’m wondering why it is so difficult to do this.  After Google’ing for hours, I found no good solution.  If anyone has a good idea on how to do this, I am all ears.  I am currently downloading a Fedora Core 7 Virtual Appliance so I can use revisor as mentioned here.

The question I have is how in the world do people update their BIOS’s if they do not run Windows on their server, and do not have access to a Windows machine or a floppy drive??

#!/usr/bin/ruby
#
#  connection_notifier.rb
#  ConnectionNotifier
#
#  Created by Paul Codding on 2008-09-27.
#  Copyright 2008 id3al Solutions
. All rights reserved.
#
#  Released under the BSD license.
require 'rubygems'
require File.dirname(__FILE__) + '/Growl'

class Connection
  include Comparable
  attr_accessor :protocol, :local_ip, :remote_ip, :local_port, :remote_port, :id

  def initialize(connection_entry)
    pieces = connection_entry.split(" ")
    @protocol = pieces[0]
    @local_ip = pieces[3].split(".")[0..3].join(".")
    @remote_ip = pieces[4].split(".")[0..3].join(".")
    @local_port = pieces[3].split(".").last.to_i
    @remote_port = pieces[4].split(".").last.to_i
    @id = pieces[4].split(".").join()
  end

  def (other_connection)
    @id  other_connection.id
  end

  def to_s
    "#{@protocol} connection established from #{@remote_ip} to port #{@local_port}"
  end
end

class ConnectionNotifier
  GROWL_APP_NAME="Connection Notifier"

  def initialize
    @ports = Array.new(1024)
    @ports.fill { |port| port += 1}
    @connections = Array.new
    @growl = GrowlNotifier.new(GROWL_APP_NAME,['Ruby Connection Notifier'],nil,
              OSX::NSWorkspace.sharedWorkspace().iconForFileType_('rb'))
    @growl.register()

    # Pre-populate connections array so we're not automatically notified about
    # existing established connections
    check_for_new_connections(false)
    build_list_of_listening_ports()
  end

  # Poll for changes in netstat output
  def poll
    while true do
      sleep(2)
      check_for_new_connections(true)
    end
  end

  # Check for a new connection in the output of netstat
  def check_for_new_connections(notify)
    netstat_output = `netstat -na`
    for connection_entry in netstat_output do
      if connection_entry.include?("ESTABLISHED")
        connection = Connection.new(connection_entry)

        if connection.local_port != nil && @ports.include?(connection.local_port.to_i) \
          && !@connections.include?(connection)
          @connections << connection
          if (notify)
            @growl.notify('Ruby Connection Notifier', 'Connection Established',
              connection.to_s)
          end
        end
      end
    end
  end

  def build_list_of_listening_ports
    netstat_output = `netstat -na`
    for connection_entry in netstat_output do
      if connection_entry.include?("LISTEN")
        connection = Connection.new(connection_entry)
        if !@ports.include?(connection.local_port)
          @ports << connection.local_port
        end
      end
    end
  end
end

conn = ConnectionNotifier.new
conn.poll

I’ve created a launch agent configuration for the script as well so it can start when you login. The configuration and source code is located in the ConnectionNotifier.zip file.

To run the script, either execute the script directly, or place the com.paulcodding.connection_notifier.agent.plist file in your ~/Library/LaunchAgents directory and log in again. Just note that you need to update the path to the script within the agent file before it will work. Once the script is running and you attempt a connection from an external machine, or the localhost you should see a growl notification like the image below.

Growl Notification

`report_activate_error':
RubyGem version error: actionpack(2.0.2 not = 1.13.6) (Gem::LoadError)

I found this very helpful article about getting actionwebservices to run under Rails 2.0.2. I’ve yet to see the issues that some other users have seen when using actionwebservices with Rails 2.0.2, but we shall see in the coming days of using it. One thing I had to do that I didn’t really like was to freeze the rails gems into the project. I would rather not have them in my subversion repository.Another issue encountered was with installing gems that needed compilation on my OS X Leopard machine.  Luckily I found a great article detailing the use of the ARCHFLAGS environmental variable. So to install my postgres gem all I had to do was this:

$ sudo -s# export ARCHFLAGS="-arch i386"# gem install postgres

After that, the gem was installed and I no longer received any compile time errors. This stems from the universal binary support mechanism in OS X.

 failed to lazily initialize a collection of role:
        your.Class.assocation no session or session was closed

If you are using lazy loading rather than eager loading for obvious reasons, and you’re trying to access associated objects in your view code, this error can be a bit difficult to resolve. Luckily there is the OpenSessionInViewInterceptor, or the OpenSessionInViewFilter. These solutions will keep the hibernate session open long enough for the view to render what is needed before it is closed, thus allowing you to access your lazy loaded associations without raising an exception. The detail of what this functionality provides can be found on the Hibernate website here.

Now, how does one get this to work in their application? Well, I’ve chosen to illustrate the basic steps necessary to implement the OpenSessionInViewInterceptor. You will need to modify 2 files. These being your applicationContext.xml, and YourApplication-servlet.xml files. We’ll start with the applicationContext.xml file. You will need to place the following snippet after you’ve defined your sessionFactory bean.

<bean id="openSessionInViewInterceptor"
    class="org.springframework.orm.hibernate3.support.OpenSessionInViewInterceptor">
    <property name="sessionFactory">
        <ref local="sessionFactory"/>
    </property>
    <property> name="flushModeName">
        <value>FLUSH_AUTO</value>
    </property>
</bean>

What does the FLUSH_AUTO do? Here is a quote from the javadoc for the interceptor:

“This interceptor will by default not flush the Hibernate Session, with the flush mode being set to FlushMode.NEVER. It assumes that it will be used in combination with service layer transactions that handle the flushing: the active transaction manager will temporarily change the flush mode to FlushMode.AUTO during a read-write transaction, with the flush mode reset to FlushMode.NEVER at the end of each transaction.”

We use the FLUSH_AUTO to automatically flush the session in this case because I am not using transactions.
Now comes the edit to your YourApplication-servlet.xml file, or whatever file you’ve used to define your URL Mappings. Add the following snippet to your URL mapping bean.

<property name="interceptors">
  <list>
    <ref bean="openSessionInViewInterceptor" />
  </list>
</property>

And that’s that, redeploy and you will no longer see that dreaded exception.

Sitemesh Integration

What do you have to do to integrate Sitemesh with your newly created Spring application? Well, here is the list of prerequisites:

• Download Sitemesh from OpenSymphony.
• Build the sitemesh-2.x.jar using ant.
• Copy the sitemesh-2.x.jar to the WEB-INF/lib directory of your web application

Now we can move on to integrating Sitemesh into your web application. To use sitemesh with your application only 1 file needs to be edited amazingly enough. Open up your web.xml file and add this snippet:

<!-- Sitemesh -->
<filter>
	<filter-name>sitemesh</filter-name>
	<filter-class>
		com.opensymphony.module.sitemesh.filter.PageFilter
	</filter-class>
</filter>

<filter-mapping>
	<filter-name>sitemesh</filter-name>
	<url-pattern>/*</url-pattern>
</filter-mapping>

So, now what? The next step is to setup the directory structure and files necessary to make things work. Refer to this page on the OpenSymphony site detailing the creation of your first decorator, and creating the WEB-INF/decorators.xml file. I’ve included a copy of my main.jsp file for reference:

<%@ taglib uri="http://www.opensymphony.com/sitemesh/decorator"
	prefix="decorator"%>
<%@ taglib prefix="spring" uri="http://www.springframework.org/tags"%>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
	<head>
		<title><spring:message code="application.title" /></title>
		<decorator:head />
		<%@ include file="/WEB-INF/view/includes/style.jsp"%>
		<%@ include file="/WEB-INF/view/includes/js.jsp"%>
	</head>
	<body>
		<div id="container">
			<%@ include file="/WEB-INF/view/includes/header.jsp"%>
			<div id="internalWrapper">
				<%@ include file="/WEB-INF/view/includes/links.jsp"%>
				<div id="content">
					<decorator:body />
				</div>
			</div>
			<%@ include file="/WEB-INF/view/includes/footer.jsp"%>
		</div>
	</body>
</html>

So, how do you get your Controllers to spit out decorated pages? Easy, just create a jsp that will be used as the content of the <decorator:body /> tag in the main.jsp file. When you’re returning your ModelAndView just refer to that jsp like the example below:

public ModelAndView list(HttpServletRequest request,
			HttpServletResponse response) throws Exception {
	List<DomainObject> userList = userService.findAll();
	request.setAttribute("userList", userList);
	return new ModelAndView("list.jsp", null);
}

Here is an example snippet of my url mapping for reference as to where the jsp is located:

<prop key="/users/*.html">userController</prop>

In this case my list.jsp is located in the users folder under my web root.

So, isn’t this easier than Tiles?

The first project involves the use of Growl, the notification system written for OS X, and snort. Snort is a great little IDS that I’ve been working with for quite some time. Ever since I checked out growl, I’ve been really excited to get something going that utilizes it. Luckily the project with snort is perfect for it. In short the project will use ruby to monitor the snort IDS alert logs for alerts and use Growl to send a notification to the user. Growl does have ruby bindings…hence the choice of ruby. I could use Objective-C, the only problem with that is that I don’t know the language :). So, ruby it is. I will keep everyone posted on the progress/caveats.

Part of the reason for this blog is to share information from developer to developer issues that I’ve encountered that have either been unable or too busy to find solutions to. In this case my solution is to let the reader know that the best bet client to use when consuming RoR web services in Java is Apache Axis. If anyone would enjoy a code example or two I’d be glad to oblige…although the artifacts generated by Axis 1.4 are fairly involved, the process is fairly easy especially when using the SoapUI tool to generate the artifacts based on the RoR WSDL e.g. http://localhost:3000/web_service_name/service.wsdl .