BeanPot: Brief Guide to Configuration for Darwin Applications

Introduction

BeanPot is a bean container with dependency injection, similar to Spring or Guice (though much simpler). It is not necessary to use BeanPot for Darwin, but this configuration guide assumes that you are doing and would like to know more detail. The configuration file starts thus:

	<?xml version="1.0" encoding="ISO-8859-1" ?>
	<configuration>

BeanPot special objects

The definition of writer may be left out altogether if using ConsoleWriter because that is the default for the BeanPot. The writer is simply a logger of last resort and also an output generator for census beans, etc.

	<writer class="com.rubecula.beanpot.ConsoleWriter">
	</writer>
	

If you want to be able to monitor your beans via a JMX agent and the Jconsole application, you will need to include the following bean definition. You will also have to ensure that the beans you want to monitor are MBeans. Without going into too much detail here, the easiest way to accomplish that is to define an interface called xxxMBean where xxx represents the name of one of the classes or interfaces in the bean's class hierarchy.

	<MBeanPot></MBeanPot>

Beans

In general, the beans that you define here are the components of the system which enjoy permanent lifecycle status. Temporary objects are generally created dynamically by the Darwin system by factory classes and do not need to be configured. Following are examples of the various ways that you might want to define your beans.

First comes the beans tag:

	<beans>
	

Our first example bean is required for all Darwin evolutions. We call it the "Evolution" bean but its name is entirely arbitrary. What makes it special is that it implements Runnable and Configurable. It is the sine qua non of the Darwin beans. The Evolution bean manages the evolution of a set of evolvables. There are two ways to define the evolvables: the (recommended) "member" way and the "list" way. For an example of the member way of doing it see the Darwin configuration guide. For details of the constructor arguments and properties, see the API for Evolution_Calendar, which is a concrete implementation of Evolution which is based on calendar time (in seconds), starting from now. Thus it is suitable for an evolution that runs in real time. If you need an evolution that, for example, simulates the Jurassic period, then you need to define your own implementation of Evolution.

	<bean id="Evolution" class="com.rubecula.darwin.evolution.Evolution_Calendar">
		<constructor-arg class="Boolean">
			<value>false</value>
		</constructor-arg>
		<property name="ui">
			<value>!Applet</value>
		</property>
		<property name="evolvables" keyClass="com.rubecula.darwin.foundation.Evolvable"
			valueClass="Integer">
			<map>
				<entry key="!PepperedMoth" value="1" />
			</map>
		</property>
	</bean>

The peppered moth bean. All you need to note is that the definition of PepperedMoth does not directly reference the Evolution bean when configuring this way.

	<bean id="PepperedMoth" class="com.rubecula.darwin.domain.world.Taxon_Darwinian">
		<constructor-arg>
			<value>Biston betularia</value>
		</constructor-arg>
		<constructor-arg>
			<ref bean="Realm" />
		</constructor-arg>
		<constructor-arg>
			<ref bean="Genomic" />
		</constructor-arg>
		<constructor-arg>
			<ref bean="Phenome" />
		</constructor-arg>
		<constructor-arg>
			<ref bean="CensusTaker" />
		</constructor-arg>
		<constructor-arg>
			<ref bean="Mortality" />
		</constructor-arg>
		<constructor-arg>
			<ref bean="MateChoice" />
		</constructor-arg>
		<constructor-arg>
			<ref bean="Fecundity" />
		</constructor-arg>
		<property name="registry" valueClass="com.rubecula.darwin.domain.helper.Registry">
			<value>!Registry</value>
		</property>
		<property name="seedPopulation">
			<value>10</value>
		</property>
	</bean>

Closing tags...

	</beans>
	</configuration>