Histos dot net

Swiz IoC / MVC Framework for Adobe Flex

Chris Scott (the creator of ColdSpring) has released a new IoC / MVC framework for Flex called Swiz.  This is really going to shake up the Flex MVC space and hopefully make people realize that Cairngorm is not the best option out there.  The moment I saw code generation tools springing up to help make life with Cairngorm easier it confirmed my belief (and those of my colleagues) that CG makes things more complicated than they need to be.

Chris and I have been talking about the design of Swiz for the past few months during its evolution.  As time goes on I hope to contribute in as many ways possible, including docs, sample apps and hopefully some framework code too.

Swiz on!

Spring Security 2 Released

The new 2.0 version of Spring Security (formerly Acegi Security) was recently released.  Some good information is available in a couple spots:

http://blog.springsource.com/main/2008/04/17/spring-security-20-final-release-no-more-dead-fairies/

http://blog.springsource.com/main/2007/12/06/whats-new-in-spring-security-2/

The new version promises to use a lot less XML configuration which was a huge detractor for the 1.x version.  Additionally the Domain Object Security looks interesting; think "ACLs for objects."  Docs on this module are available here:

http://static.springframework.org/spring-security/site/reference/html/domain-acls.html

Cairngorm has some issues

This is a really good post on some of the issues with Cairngorm that most people are not aware of:

http://blog.iconara.net/2008/04/13/architectural-atrocities-part-x-cairngorms-model-locator-pattern/

Cairngorm has achieved popularity  by virtue of its early entry into the Flex framework ecosystem and not necessarily because it's the best.  There should be at least one significant entry into this space very soon that is going to really shake things up.  Framework competition is good!

Spring AOP: CGLIB or JDK Dynamic Proxies?

Even if you're not a big fan of Aspect-Oriented Programming, if you use the Spring framework's transaction management your application will be using dynamic AOP proxies, albeit behind-the-scenes. Spring can use two different techniques for creating proxies at runtime: CGLIB or JDK dynamic proxies. If the target class implements one or more interfaces, then Spring will create a JDK dynamic proxy that implements every interface. If the target class implements no interfaces, Spring will use CGLIB to create a new class on the fly that is a subclass ("extends") the target class. This leads to one important difference: a JDK dynamic proxy cannot be casted to the original target class because it's simply a dynamic proxy that happens to implement the same interface(s) as the target. This has the effect of "nudging" you to program to interfaces if they're being used in your application's model, since proxies will usually be invoked through those interfaces. On the other hand, if interfaces are completely absent from your model, Spring will create CGLIB proxies that can be treated more-or-less just like the target class itself. There is also a way to force creation of CGLIB proxies in either scenario that is detailed in the Spring docs right here. If you're receiving strange ClassCastExceptions when working with your Spring-managed service layer, hopefully this tip will help you!

Easier testing with the Spring framework

Spring comes with some extremely useful convenience classes for test automation using JUnit.  In order to use them, be sure to add the spring-mock.jar to your project.  Here's a rundown of what's available in the org.springframework.test package:

• AbstractSpringContextTests: abstract subclass of JUnit's TestCase.  This class isn't very useful on its own, but it maintains a Spring context using a static Map to optimize performance while running tests.  Due to a "design decision" in JUnit 3, classes are destroyed/recreated between each test method invocation, so persisting state across method calls can't be done by placing code in the test case's constructor.  Storing dependencies in a static variable - while considering something of a "hack" - is a welcome improvement.
• AbstractDependencyInjectionSpringContextTests: abstract subclass of AbstractSpringContextTests.  This class will read Spring XML files from the classpath and autowire any dependencies into your test case.  Simply override getConfigLocations() and ensure that a setter exists for each dependency and Spring will do autowiring by type.
• AbstractTransactionalSpringContextTests: abstract subclass of AbstractDependencyInjectionSpringContextTests.  This class will wrap test method calls in a transaction and automatically rollback after execution, vastly increasing performance and eliminating the need for messy setUp() and tearDown() code to setup the database.  You must provide a bean in the context that implements PlatformTransactionManager in order for the transactionality to work.
• AbstractTransactionalDataSourceSpringContextTests: abstract subclass of AbstractTransactionalSpringContextTests.  This class will autowire a DataSource bean into your test case, making database connectivity relatively painless.

These classes have been a lifesaver and the performance increases help make running tests fast and easy.  One important note: these test classes still use the JUnit 3.x API.  If you've moved to JUnit 4, you may need to write an adapter class or wait for the Spring team to release some updated code.