public class InternettFasade{
...
public String leverAnmeldelse(Anmeldelse anmeldelse){
    return anmeldelse.sendFaxTilAnsvarligPolitiDistrikt()
                     .sendEpostTilPolitiDistrikt()
                     .sendBekreftelseEpostTilAnmelder()
                     .lagre()
                     .referanseNummer();
}

Sterkt preget av min egen lille forståelse av Domain Driven Design så passer sånn type kode meg ypperlig. Noen vil sikkert arrestere meg og si at i DDD så er det ikke opp til entitetene selv å drive å lagre, men jeg liker nå det engang sånn. Skader det så mye også egentlig? Sikkert masse annet jeg har bommet på med DDD også. Når jeg først har slike fine entiteter/modeller så synes jeg det er storveis å bare sende de rundt omkring hos forskjellige fasader og servicer helt uten å tenke meg om de har injisert de riktige repositories/servicer/validatorer osv, osv.

Til å begynne med gjorde jeg injiseringen i forskjellige factories som populerte entitetene med det nødvendige. Etterhvert bli disse factories’ene ganske kompliserte. Selv fikk jeg i alle fall lyst til å ordne det slik at det var bare disse factories’ene som fikk lov til å opprette domenemodellene. Da først snakker vi om skikkelig kontroll. None shall pass og one factory to rule them all. Og straks har jeg litt ekstra uønsket kompleksitet og kode. Huff. Derfor ble jeg ganske interessert i å finne ut hva denne Spring load-time-weaving var for noe. Og kunne det gjøre akkurat det samme som en factory? Bare behind the scenes? Joda. Såklart. Hvorfor hadde jeg ellers giddet å skrive denne bloggen? Here’s how!

Hva?

Load-time-weaving er i korttekst runtime instrumentering av klassene dine. Det er slik fancy AOP som legger seg rundt objektene dine og slår inn straks noen prøver seg. Prøver seg i dette tilfelle med Spring-ltw er rett etter du har opprettet et AOP-instrumentert objekt. Jeg kan illustrere med et kodeeksempel

@Configurable
public class Ansatt{
    @Autowired
    private AnsattRepository repo;
    @Autowired
    private EpostService epostService;
    ...
    public Ansatt lagre(){
        repo.lagre(this);
        return this;
    }

Her har vi først fortalt at klassen skal instrumenteres runtime av Spring vha annoteringen @Configurable. Det som skjer nå er at hver gang, og hvor som helst i koden, det kjøres en new Ansatt() så vil Spring hoppe inn og injisere EpostService og AnsattRepository fra konteksten sin. Det gjelder ikke bare koden du skriver, men også knæshe xml-to-java bibliotek og lignende. Så nå blir det fullt ut mulig å gjøre for eksempel dette:
new Ansatt(ansattNr).giSparken().sendSluttPakkePaaEpost().lagre();

Hvordan?

Hvordan er like enkelt som å skrive new Person(). Vel.. Nesten da. Kors på halsen. Det første du må gjøre er å bruke Spring. Hvis du har slengt på @Configurable så mangler du en slik en i Spring contexten din:

<context:load-time-weaver />

Da begynner Spring straks å mase om at den mangler en java-agent. Det er et annet ord for instrumenteringen som er det siste du må fikse. Det kan du gjør på forskjellige måter:

Java argument

For de fleste tilfeller må man sende inn java agenten som et java-argument. For eksempel for å starte den superenkle og populære Jetty sender du inn Spring sin java-agent gjennom Maven slik(Linux):

export MAVEN_OPTS="-javaagent:$HOME/.m2/repository/org/springframework/spring-agent/2.5.6/spring-agent-2.5.6.jar"

Og da er det bare å mvn jetty:run

Tomcat, GlassFish, Oracle OC4J, WebLogic

Apache Tomcat

<Context>
<Loader loaderClass="org.springframework.instrument.classloading.tomcat.TomcatInstrumentableClassLoader"/>
</Context>

For at dette skal fungere så må Tomcat innstallasjonen kjenne til klassen TomcatInstrumentableClassLoader. Dvs du slenger
spring-tomcat-weaver.jar i lib katalogen til Tomcat, og vips - tilgjengelig java-agent! DET burde ikke være vanskelig å overbevise drift om å tillate!

Testing

Eclipse

Skal du teste at load-time-weaving koden din faktisk injiserer objektene som du håper må du også her tilby en java agent. Det gjør du ved å redigere vm argumentene til den testen eller koden du skal kjøre. Dette finner du under Run=>Run Configurations=>Arguments
Der mangler det en slik:
-javaagent:"${USER_HOME}/.m2/repository/org/springframework/spring-agent/2.5.6/spring-agent-2.5.6.jar

Maven

Ønsker du å kjøre enhets- eller integrasjonstester som bruker load-time-weaving så redigerer du argumentene for surefire-plugin slik at den instrumenterer likt Eclipse. Det kan du gjøre slik:

<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-surefire-plugin</artifactId>
	<configuration>
		<forkMode>once</forkMode>
		<argLine>
			-javaagent:${settings.localRepository}/org/springframework/spring-agent/${spring.version}/spring-agent-${spring.version}.jar
                </argLine>
		<useSystemClassloader>true</useSystemClassloader>
	</configuration>
</plugin>

Alt vel i paradis?

Veeel... Det koster litt. Skal du opprette en drøss med objekter så går det atskillig raskere å gjøre det på gamlemåten med en Factory. En helt enkel test jeg gjorde viste at med en Factory fikk jeg laget 200 objekter på samme tid som det tok å lage ett @Configurable objekt. Så hvis du får en case med å opprette tusen på tusen av objekter med et hardt krav til responstid så må du kanskje være litt oppfinnsom. Personlig har jeg ikke erfart at load time weaving har gitt merkbart dårligere responstid.

En ting som kanskje er enda litt mer irriterende for deg som sitter og utvikler load-time-weavet kode er at du ikke kan bruke det sammen med ditt favoritt mock rammeverk. Den ene utsletter dessverre den andre og plutselig fungerer ingen tester. Det mock-rammeverket ditt trodde var et Person-objekt er ikke lengre et Person-objekt etter ltw. Nå er det et cglib objekt som utgir seg for å være et Person objekt. Personlig har jeg ikke funnet en smart måte å omgå dette på, og endt opp med å ikke teste med load time weaving men heller sørge for at enhets og integrasjonstester dekker det som dekkes skal slik at det blir middag.

For de som har lyst til å leke litt med load-time-weaving eller bare se et kjempeenkelt eksempel så har jeg snekret sammen et lite kodeeksempel her:
http://github.com/judoole/ddd-ltw-spring

Hadn’t been for those re-occuring complaints from the users that “An unknown exception has occured” message with a big warning label pops up from time to time. A nice little feature you made to hide all of those unexpected exceptions that can, but should not, occur in your application. All in all a good thing as we would like to spare the user the experience of reading an unpleasant stacktrace from an external webservice error. But YOU, on the other hand. You would love to get your hands on the stacktrace from that Error that shouldn’t happen. So, how?

In Java-Land this is usually done by incorporating some form of logging that logs messages to file or almost whatever you would like. Most preferred being Log4J. Unfortunately I feel that a just-as-easy solution for Flex/Actionscript has yet to present itself. Until now. As a left-over artifact from the development of Spring Integration, the guys from Prana and Spring has made library called as3commons-logging. The library mimics Log4j in many ways and makes an excellent job doing so. Adding the as3commons-logging swc to your project then makes remote logging a peach. Here’s howto:

Some code

Step 1 of 3
Implement an ILoggerFactory like this. It’s responsibility will be to create Loggers for your classes:

public class RemoteLoggerFactory implements ILoggerFactory
{
        private var remote:RemoteObject;
 
        public function RemoteLoggerFactory(url:String, destination:String="remoteObjectLogger", fault:Function=null)
        {
                remote = createRemote(url, destination);
                remote.addEventListener(FaultEvent.FAULT, fault == null ? onRemoteFault:fault);
        }
 
        public function getLogger(name:String):ILogger
        {
                return new RemoteLogger(name, remote);
        }
 
        /** Creates a RemoteObject using SecureAMFChannel if https */
        private function createRemote(url:String, destination:String) : RemoteObject
        {
                var channelSet:ChannelSet = new ChannelSet();
                channelSet.addChannel(isHttps(url) ? new SecureAMFChannel(null, url) : new AMFChannel(null, url));
 
                var remoteService:RemoteObject = new RemoteObject(destination);
                remoteService.channelSet = channelSet;
 
                return remoteService;
        }
 
        private function isHttps(url:String) : Boolean
        {
                return url.indexOf("https") != -1;
        }
 
        /** Default FaultHandler. Just traces the message. */
        private function onRemoteFault(evt:FaultEvent) : void
        {
                trace("Could not log to server: "+evt.fault.message);
        }
}

Step 2 of 3
And then create the actual Logger which sends log messages to the backend, be that java, php, rails, .NET or name it.

public class RemoteLogger extends DefaultLogger
{
	protected var _level:uint;
	protected var remote:Object;
 
	public function RemoteLogger(name:String, remote:Object)
	{
        super(name);
        this.remote = remote;
	}
 
	override protected function log(level:uint, message:String, params:Array):void {
		if (level >= this._level) {
                        // add datetime
			var msg:String = "[" + new Date().toString() + "]";
			// add the name given to this logger. Usually the Class name
			msg += "[" + name + "]";
			// add message
			msg += " - " + MessageUtil.toString(message, params);
 
			var logLevel:String = LogLevel.toString(level);
			remote.log(logLevel, msg);
		}
	}
}

Step 3 of 3
Next instantiate your factory. Preferably as early as possible, so snapping in something like this at your Main mx:Application will do the trick.

private static var loggerSetup:* = LoggerFactory.loggerFactory = new RemoteLoggerFactory(ROOT_PATH+"messagebroker/amf");

And voila! It is now useable in any of your classes thiswise:

...
private static const logger:ILogger = LoggerFactory.getClassLogger(Jesus);
 
public function Jesus(){
      logger.info("Attention: We constructed Jesus.");
}

A dash of backend

The last but not least is to have a backend that can receive the messages and log them in a human readable way for later error debugging.
Why not splash out a java class with log4j? Well, this will do your trick:
Step 3.5

public class RemoteObjectLogger
{
        private static final String PRE_FLEX = "[FLEX]";
        protected final Log logger = LogFactory.getLog(getClass());
 
        public void log(String level, String message)
        {
                if ("INFO".equals(level))
                        logger.info(PRE_FLEX + message);
                else if ("DEBUG".equals(level))
                        logger.debug(PRE_FLEX + message);
                else if ("WARN".equals(level))
                        logger.warn(PRE_FLEX + message);
                else if ("ERROR".equals(level))
                        logger.error(PRE_FLEX + message);
                else if ("FATAL".equals(level))
                        logger.fatal(PRE_FLEX + message);
                else
                        logger.info(PRE_FLEX + "[" + level + "] - " + message);
        }
}

Try it

Would you like to see it in action? From top to bottom? Well I coded a small example for you to play with using Java as a backend. Svn the code from google-code. Only prerequisite is Maven installed. From there run compileAndRun and you are up and running!