• The Test Drive now includes an annotation-based configuration sample (the Company Manager sample). Spring annotations such as @Service, @RemotingDestination, @Autowired, @RemotingInclude, and @RemotingExclude make it really easy to configure your beans and make them available through Remoting. As an example, here is the source code for the CompanyDAO class:

  package flex.spring.samples.company;
  
  import java.sql.ResultSet;
  import java.sql.SQLException;
  import java.util.HashMap;
  import java.util.List;
  import java.util.Map;
  
  import javax.sql.DataSource;
  
  import org.springframework.flex.remoting.RemotingDestination;
  import org.springframework.flex.remoting.RemotingExclude;
  import org.springframework.flex.remoting.RemotingInclude;
  import org.springframework.beans.factory.annotation.Autowired;
  import org.springframework.stereotype.Service;
  import org.springframework.jdbc.core.simple.ParameterizedRowMapper;
  import org.springframework.jdbc.core.simple.SimpleJdbcInsert;
  import org.springframework.jdbc.core.simple.SimpleJdbcTemplate;
  
  import flex.spring.samples.industry.IIndustryDAO;
  
  @Service("companyService")
  @RemotingDestination(channels={"my-amf"})
  public class CompanyDAO implements ICompanyDAO {
  
  	private final SimpleJdbcTemplate template;
  	private final SimpleJdbcInsert insertCompany;
  
  	private IIndustryDAO industryDAO;
  
  	private final ParameterizedRowMapper<Company> rowMapper = new ParameterizedRowMapper<Company>(){
  		public Company mapRow(ResultSet rs, int rowNum) throws SQLException {
  			Company company = new Company();
  			company.setId(rs.getInt("id"));
  			company.setName(rs.getString("name"));
  			company.setAddress(rs.getString("address"));
  			company.setCity(rs.getString("city"));
  			company.setState(rs.getString("state"));
  			company.setZip(rs.getString("zip"));
  			company.setPhone(rs.getString("phone"));
  			company.setIndustry(industryDAO.findById(rs.getInt("industry_id")));
  			return company;
  		}
  	};
  
  	@Autowired
  	public CompanyDAO(DataSource dataSource, IIndustryDAO industryDAO) {
  		template = new SimpleJdbcTemplate(dataSource);
  		insertCompany = new SimpleJdbcInsert(dataSource).withTableName("COMPANY").usingGeneratedKeyColumns("ID");
  		this.industryDAO = industryDAO;
  	}
  
  	@RemotingInclude
  	public Company findById(int id) {
  		return template.queryForObject("SELECT * FROM company WHERE id=?", rowMapper, id);
  	}
  
  	@RemotingInclude
  	public List<Company> findAll() {
  		return template.query("SELECT * FROM company ORDER BY name", rowMapper);
  	}
  
  	@RemotingInclude
  	public List<Company> findByName(String name) {
  		return template.query("SELECT * FROM company WHERE UPPER(name) LIKE ? ORDER BY name",
  				rowMapper,
  				"%" + name.toUpperCase() + "%");
  	}
  
  	@RemotingInclude
  	public Company create(Company company) {
  		Map<String, Object> parameters = new HashMap<String, Object>();
          parameters.put("name", company.getName());
          parameters.put("address", company.getAddress());
          parameters.put("city", company.getCity());
          parameters.put("state", company.getState());
          parameters.put("zip", company.getZip());
          parameters.put("phone", company.getPhone());
          parameters.put("industry_id", company.getIndustry().getId());
          Number id = insertCompany.executeAndReturnKey(parameters);
  		company.setId(id.intValue());
  		return company;
  	}
  
  	@RemotingInclude
  	public boolean update(Company company) {
          int count = template.update("UPDATE company SET name=?, address=?, city=?, state=?, zip=?, phone=?, industry_id=? WHERE id=?",
  				company.getName(),
  				company.getAddress(),
  				company.getCity(),
  				company.getState(),
  				company.getZip(),
  				company.getPhone(),
  				company.getIndustry().getId(),
  				company.getId());
  		return (count == 1);
  	}
  
  	@RemotingExclude
  	public boolean remove(Company company) {
  		int count = template.update("DELETE FROM company WHERE id=?", company.getId());
  		return (count == 1);
  	}
  
  }
  

• The Test Drive is now using the M3 build of Spring 3 (as opposed to M2 in the previous builds of the Test Drive).
• I modified the configuration of the long polling channel to support more persistent connections per domain based on the browser capabilities.
• And of course compared to the M2 build, this version of the Test Drive includes a number of Messaging samples.

  Using the Messaging integration, setting up a destination can be as easy as:

  <flex:message-destination id="chat" />
  

  And here is how you configure a destination mapped to a JMS topic:

  <flex:jms-message-destination id="jms-chat" jms-destination="chatTopic" />
  

Installation Instructions:

1. Download the Spring / Flex TestDrive here: http://coenraets.org/downloads/spring-flex-testdrive-RC1v2.zip
2. Unzip it in your root directory
3. Navigate to /spring-flex-testdrive/tomcat/bin and start Tomcat (for instance: catalina run)
4. Open a browser and access http://localhost:8080
5. Follow the instructions

I will be joined by Mark Fisher from SpringSource and we will talk about Flex, Spring, BlazeDS and the integration of these technologies. Spring BlazeDS integration RC1 was released last week. One of the key features in RC1 is the integration of the Message service, and Mark is the lead developer on that feature.

I hope to see you there if you live in the greater Boston area.

Thu, May 14 6:00pm
Sun Microsystems – 1 Network Way, Burlington, MA
NEJUG Link

SpringSource just released the RC1 build for the Spring / BlazeDS integration project. The key new feature in RC1 is the integration of the BlazeDS Message Service.

I updated my Spring BlazeDS Integration Test Drive to showcase the messaging integration.

In addition to Remoting and Security samples, the Test Drive now includes the following Messaging samples:

• Chat: Messaging basics
• Simple Data Push: A simple data push example
• Traderdesktop: A more sophisticated data push example showing how to use subtopics
• JMS Chat: A chat application using a JMS topic and exchanging messages with a Swing-based client
• Collaboration: An example showing how to use messaging to remotely drive another client’s application

Installation Instructions:

1. Download the Spring / Flex TestDrive here: http://coenraets.org/downloads/spring-flex-testdrive-RC1.zip
2. Unzip it in your root directory
3. Navigate to /spring-flex-testdrive/tomcat/bin and start Tomcat (for instance: catalina run)
4. Open a browser and access http://localhost:8080
5. Follow the instructions

As always, I’d love to hear your feedback and your ideas to improve this Test Drive.

I will probably have another version next week with a couple of additional samples and more documentation for the Message Service, but I already wanted to make this version available to allow you to experiment RC1 samples.

Christophe

In this second part, we will discuss how you can make these objects available to the views of your application without tightly coupling these views to the framework, and without passing references around through potentially many levels of view containment.

We will build the “Spring ActionScript” version of the InSync contact management application I often use in this blog to explore new technologies. The application has two views: MainView and ContactForm. Both need a reference to a contact RemoteObject to work.

NOTE: This example is intentionally kept simple. In a more partitioned application, you may want to pass a more abstract controller around as opposed to a specific RemoteObject. We will use this approach in part 3.

The views could use applicationContext.getObject() to access their dependencies (in this case the contact RemoteObject), but this approach has a number of problems:

1. With a dependency on applicationContext, the views would be tightly coupled to the framework.
2. We would still need to pass a reference to the applicationContext object to the views. This is often solved using the singleton approach which has its own set of problems.

So, instead of the views instantiating or looking up their dependencies, a better approach would be to “inject” these dependencies into the views.

Unlike Swiz, “Spring ActionScript” doesn’t currently have built-in support for an [Autowire] annotation, but Christophe Herreman seems to imply that this feature is coming, and in the meantime, he provides some sample code to support “Spring ActionScript”-powered autowiring in your application. Using this custom code, the inSync application looks like this:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
	applicationComplete="applicationCompleteHandler()">

	<mx:Script>
	<![CDATA[

	import insync.views.MainView;
	import mx.utils.DescribeTypeCacheRecord;
	import mx.utils.DescribeTypeCache;
	import as3reflect.ClassUtils;
	import org.springextensions.actionscript.context.support.FlexXMLApplicationContext;

	private var applicationContext:FlexXMLApplicationContext;

	private function applicationCompleteHandler():void
	{
		applicationContext = new FlexXMLApplicationContext("applicationContext.xml");
		applicationContext.addEventListener(Event.COMPLETE, applicationContextComplete);
		applicationContext.load();
	}

	private function applicationContextComplete(event:Event):void
	{
		systemManager.addEventListener(Event.ADDED, addedEventHandler);
		var mainView:MainView = new MainView();
		addChild(mainView);
	}

	private function addedEventHandler(event:Event):void
	{
		var autowiredObject:Object = event.target;
		trace("Added to display list: " + autowiredObject);
		var typeInfo:DescribeTypeCacheRecord = DescribeTypeCache.describeType(autowiredObject);
		for each (var metaDataNode:XML in typeInfo.typeDescription..metadata)
		{
			if (metaDataNode.attribute("name") == "Autowired")
			{
				var propertyNode:XML = metaDataNode.parent();
				var property:String = propertyNode.@name.toString();
				trace("Found Autowired property: " + property);
				var objectName:String = property;
				var autowireByType:Boolean = true;

				for each (var arg:XML in metaDataNode.arg)
				{
					if (arg.attribute("value") == "byName")
					{
						autowireByType = false;
					}
				}

				if (autowireByType)
				{
					var clazz:Class = ClassUtils.forName(propertyNode.@type.toString());
					var objectNames:Array = applicationContext.getObjectNamesForType(clazz);
					if (objectNames.length == 1)
					{
						objectName = objectNames[0];
					}
				}
				trace("Autowiring: " + property + " in " + autowiredObject);
				autowiredObject[property] = applicationContext.getObject(objectName);
			}
		}
	}

	]]>
	</mx:Script>

	<mx:Style source="styles.css"/>

</mx:Application>

To be able to inject properties annotated with Autowired, we register as a listener for the ADDED event on systemManager, and introspect each object added to the display list. If the object has [Autowired] properties, those properties are injected (by name or by type) using applicationContext.getObject(objectName). This is also the approach taken by Swiz.

Timing

Before you inject objects into views, you need to make sure the applicationContext.xml file has been loaded and that the objects it defines have been instantiated. To that effect, the applicationContext dispatches an Event.COMPLETE event when it is ready. To make sure all the views of my application can be properly injected (if needed), the strategy I use in this application is to start instantiating the main view only after this event has been triggered. See addChild(mainView) in the applicationContextComplete handler.

The Views

With that infrastructure in place, the two views of the InSync application are easy to write. Their basic setup looks like this:

<?xml version="1.0" encoding="utf-8"?>
<mx:Canvas xmlns:mx="http://www.adobe.com/2006/mxml">

	<mx:Script>
		<![CDATA[

			import mx.rpc.remoting.mxml.RemoteObject;

			[Autowired]
			public var contactRemoteObject:RemoteObject;

		]]>
	</mx:Script>

</mx:Canvas>

Installation instructions

NOTE: If you already installed the Swiz version of inSync, you can skip steps 1, 3, 4, 5 and 6.

1. Install the BlazeDS turnkey server. (To be clear: you don’t have to use BlazeDS to use Spring ActionScript… That’s just what this sample is using.)
2. Download insyncspringas.zip, and unzip it on your local file system.
3. Copy insyncspringas/java/classes/insync to blazeds/tomcat/webapps/samples/WEB-INF/classes/insync.
4. Add the following destination to blazeds/tomcat/webapps/samples/WEB-INF/flex/remoting-config.xml:

<destination id="contacts">
        <properties>
            <source>insync.dao.ContactDAO</source>
            <scope>application</scope>
        </properties>
</destination>

5. Copy insyncspringas/sampledb/insync to blazeds/sampledb/insync
6. Edit server.properties in blazeds/sampledb, and modify the file as follows to add the insync database to the startup procedure.

   server.database.0=file:flexdemodb/flexdemodb
   server.dbname.0=flexdemodb
   server.database.1=file:insync/insync
   server.dbname.1=insync
   server.port=9002
   server.silent=true
   server.trace=false
   

7. Start the database (startdb.bat or startdb.sh)
8. Start BlazeDS
9. In Flex Builder, create a new Flex project called insyncspringas. You don’t have to select any “Application server type”.
10. Copy spring-actionscript.swc and as3reflect.swc from insyncspringas/flex/lib to the lib directory of your project
11. Copy the files and folders from insyncspringas/flex/src to the src directory of your project
12. Open applicationContext.xml and make sure the remoteObject endpoint value matches your server setup.
13. Run the application

Note on Autowiring and Performance

Annotation-based dependency injection is elegant and easy to work with. However, the current implementation that requires a describeType on every object added to the display list has a performance impact. This is maybe something that the Flex framework could help with in the future. For example, we could inject code at compile time to dispatch an AutowireEvent for each Autowired property when a class is instantiated. We would leave it up to the frameworks to provide a specific injection implementation. That would give these frameworks a better event to listen to, and they wouldn’t have to introspect all the objects added to the display list. An alternative would be to have a compiler hook to allow annotation-based code injection at compile time.

In the meantime, you’ll have to identify if the performance impact of the current approach is acceptable in the context of your application. If not, there are ways to improve the basic approach described above:

• Using Swiz, Aral Balkan uses an autowire property on the views that require autowiring. In the autowiring code, he then uses the hasOwnPropety(“autowiring”) function to identify if the object needs to be autowired before using describeType. This approach still requires some level of introspection on each object added to the display list.
• Swiz now makes sure it doesn’t perform describeType on classes in the mx packages. This approach could also be added to the code above.
• Another approach would be for you to programmatically dispatch an AutowireEvent in the initialize event of the views that need to be autowired. This approach is maybe less elegant than a simple annotation, but wouldn’t have the performance impact of introspecting all the objects added to the display list. It would also work for any object in your application, not only the views.

I recently spent some time exploring “Spring ActionScript”. There aren’t a lot of resources available yet, so I figured I would contribute my own exploration.

Note: Also, to avoid confusion, this project is independent from the Spring/BlazeDS integration project I have been writing about a lot lately. These two projects could however complement each other nicely.

In this first post, I’ll cover the basics… Imagine you have an application that uses RemoteObject to access the back-end of your application. Unless your application is made of only a couple of components and will forever communicate with the same server, there are two issues you’ll have to deal with early on:

1. How to externalize the service configuration (channels, endpoints, etc) from your code
2. How to provide the different components of your application with a reference to that service

Notes:

1. This first example is intentionally kept very simple. In a more partitioned application, you may want to pass a more abstract controller around as opposed to a specific RemoteObject. This will be covered in part 3 of this series.
2. The Spring ActionScript framework is an inversion of control framework: You don’t have to use RemoteObject, any specific data access strategy, or even connect to a back-end to use it… This is just the test case I wanted to build.

Objects configuration and wiring

Spring Actionscript uses an XML file to configure and wire its components. The advantage is that you can change the configuration and the wiring of your components, or even swap the implementation of a component without having to recompile. This leads to a great deal of flexibility during development, testing, and in your production environment.

On the other hand, when you declare classes in an XML configuration file, the compiler is not aware of what you are doing: The configuration and wiring of your components is not checked at compile time, and more importantly, classes defined in the XML configuration file but not referenced directly in your code will not be linked in your SWF. This is however not a major issue as you can easily tell the compiler to include these classes (see part 3 of this series).

In this first example, we will simply configure a RemoteObject…

<?xml version="1.0" encoding="utf-8"?>
<objects>

	<object id="channelSet" class="mx.messaging.ChannelSet">
		<method-invocation name="addChannel">
			<arg>
				<object id="amfChannel" class="mx.messaging.channels.AMFChannel">
					<property name="url" value="http://localhost:8400/lcds-samples/messagebroker/amf"/>
				</object>
			</arg>
		</method-invocation>
	</object>

	<object id="contactRemoteObject" class="mx.rpc.remoting.mxml.RemoteObject">
		<property name="channelSet" ref="channelSet" />
		<property name="destination" value="contacts" />
		<property name="showBusyCursor" value="true" />
	</object>

</objects>

Notice that we first configure a ChannelSet object. In this case, we define a single AMF channel. We then configure our RemoteObject, and inject its channelSet property with the ChannelSet object we just configured.

Externalizing this configuration and the wiring between the RemoteObject and the ChannelSet from your code has many benefits… Without recompiling, you could for example:

1. Change the AMF channel URL, point to another server, another port, another endpoint.
2. Add more channels (fall back channels) to the ChannelSet.
3. Change the channel type. For example, switch from AMFChannel to RTMPChannel.
4. Change the target destination

As a (simpler) alternative you could also configure your RemoteObject as follows:

<?xml version="1.0" encoding="utf-8"?>
<objects>

	<object id="remoteObject" class="mx.rpc.remoting.mxml.RemoteObject"	abstract="true">
		<property name="endpoint" value="http://localhost:8400/lcds-samples/messagebroker/amf" />
		<property name="showBusyCursor" value="true" />
	</object>

	<object id="contactRemoteObject" parent="remoteObject">
		<property name="destination" value="contacts" />
	</object>

</objects>

Note that to avoid repetition, you can configure an “abstract” object (in this case “remoteObject”) that includes configuration settings applicable to all the concrete versions of that object (in this case “contactRemoteObject”).

Obtaining a configured object in the application.

Now that the RemoteObject is configured, let’s build a simple application using the RemoteObject we just configured.

<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" xmlns:local="*"
	initialize="applicationCompleteHandler()">

	<mx:Script>
		<![CDATA[
			import mx.rpc.AsyncResponder;
			import mx.controls.Alert;
			import mx.rpc.events.FaultEvent;
			import mx.rpc.events.ResultEvent;
			import mx.rpc.AsyncToken;
			import mx.rpc.remoting.mxml.RemoteObject;

			import org.springextensions.actionscript.context.support.FlexXMLApplicationContext;

			private var applicationContext:FlexXMLApplicationContext;

			private var remoteObject:RemoteObject;

			private function applicationCompleteHandler():void
			{
				applicationContext = new FlexXMLApplicationContext("applicationContext.xml");
				applicationContext.addEventListener(Event.COMPLETE, applicationContextLoaded);
				applicationContext.load();
			}

			private function applicationContextLoaded(event:Event):void
			{
				remoteObject = applicationContext.getObject("contactRemoteObject");
				var token:AsyncToken = remoteObject.getContacts();
				token.addResponder(new AsyncResponder(resultHandler, faultHandler, token));
			}

			private function resultHandler(event:ResultEvent, token:AsyncToken):void
			{
				dg.dataProvider = event.result;
			}

			private function faultHandler(event:FaultEvent, token:AsyncToken):void
			{
				Alert.show(event.fault.faultString);
			}

		]]>
	</mx:Script>

	<mx:DataGrid id="dg" width="100%" height="100%"/>

</mx:Application>

The first step when you build an application using the Spring ActionScript framework is to create an ApplicationContext object and use it to load your configuration. Once the configuration is loaded, you can obtain fully configured objects using the applicationContext’s getObject method, and from here it’s then business as usual.

Next Steps

In this first example, we looked at how the Spring ActionScript framework can help you externalize the configuration and the wiring of your components, and how you can easily get configured objects in your application using the applicationContext.

In part 2, “Autowiring”, we will discuss how you can make these objects available to the views of your application without tightly coupling these views to the framework, and without passing references around through potentially many levels of view containment.

If you are interested in this integration, make sure you check out the Spring / BlazeDS Integration page on the SpringSource web site and the new Spring / BlazeDS Integration Test Drive.

SpringSource recently announced the Spring / BlazeDS Integration project. You can read more about the project and download the bits at http://www.springsource.org/spring-flex.

To help developers get started with the integration, I put together a new “Spring / BlazeDS Test Drive”. This Test Drive consists of a minimal version of Tomcat with BlazeDS and the “Spring / BlazeDS integration” preconfigured and ready to use. It also includes a series of samples running “out-of-the-box” that should allow you to get up and running integrating Flex (and Adobe AIR) with Spring in minutes.

Installation Instructions:

1. Download the Spring / Flex TestDrive here: http://coenraets.org/downloads/spring-flex-testdrive.zip
2. Unzip it in your root directory
3. Navigate to /spring-flex-testdrive/tomcat/bin and start Tomcat (for instance: catalina run)
4. Open a browser and access http://localhost:8080
5. Follow the instructions

As always, I’d would love to hear your feedback and your ideas to improve this Test Drive.

Christophe

The Test Drive Server includes:

1. An updated version of my 30 minutes Test drive for Java developers
2. A brand new Flex Data Management Services tutorial
3. Flex/Spring integration samples running “out-of-the-box”
4. Flex/Hibernate integration samples running “out-of-the-box”
5. Flex/JMS integration samples (JMS powered by ActiveMQ) running “out-of-the-box”
6. A new version of my Real Time Market Data application with advanced messaging features: Java API (no JMS in this version), subtopics, etc.
7. Collaboration Dashboard

Installation Instructions

1. Proceed to the Test Drive Server download page
2. Expand fds-tomcat.zip

   NOTE: The instructions in the documentation assume that you expand fds-tomcat in your root directory. You can expand fds-tomcat anywhere else. Just make sure you adjust the path in the samples and tutorial instructions accordingly.

3. Open install.htm in the fds-tomcat directory for information on running the Test Drive Server.

Disclaimer: The Test Drive Server is currently not an officially supported product. I’ll of course do my best to answer your questions, and your feedback is very much appreciated. It is intended to allow Java Developers to quickly evaluate or/and get started with Flex in a Java environment.

ERRATA: On page 4 in the tutorial PDF: “On the Java Settings page, specify fdms-tomcat/classes as the Default output folder, and click Finish”. The name of the folder is incorrect: it should read: Specify “fds-tomcat/classes” as the Default output folder (The screen shot is correct).

More Info

The Flex Test Drive Server includes the following products, frameworks, and libraries (All these products are configured to work together “out-of-the-box” when you install the Test Drive Server) :

• Tomcat 5.5.20
• Flex Data Services (FDS 2.0.1)
• JOTM (JTA implementation)

  The Flex Data Management Services leverage the Java Transaction API (JTA). Because
  Tomcat doesn’t provide a JTA implementation, the Test Drive Server includes JOTM (an open source implementation of the Java Transaction API). You don’t need JOTM if your application server implements the full Java EE stack.

• ActiveMQ (JMS implementation)

  The Flex Data Services integrate with JMS (see integration examples in the Test Drive Server). Because Tomcat doesn’t provide a JMS implementation, we use ActiveMQ (an open-source JMS provider) as part of this Test Drive Server. You don’t need ActiveMQ if your application server implements the full Java EE stack, or if your application doesn’t use JMS.

• Spring 2

  Flex integrates with the Spring framework through the Flex SpringFactory (see integration examples in the Test Drive Server). Spring 2 is part of the Flex Test Drive Server to demonstrate this Flex/Spring integration.

• Hibernate 3.2

  Flex integrates with the Hibernate through the Flex HibernateAssembler(see integration examples in the Test Drive Server). Hibernate is part of the Flex Test Drive Server to demonstrate this Flex/Hibernate integration.

• HSQLDB 1.8

  To allow you to run the tutorial “out-of-the-box” without setting up a database, the Test Drive server
  includes an HSQLDB database. HSQLDB is a lightweight Java RDBMS that is particularly well
  suited to run samples. hsqldb.jar (in [tomcat_root]\webapps\ROOT\WEB-INF\lib) includes both
  the RDBMS engine and the JDBC driver. The HSQLDB database server is automatically started as part of the Tomcat startup process.

Spring is one of the most popular Java frameworks. It is based on a lightweight component container that implements the Inversion of Control (IoC) pattern. Using an IoC container, components don’t instantiate or even look up their dependencies (the objects they work with). The container is responsible for injecting those dependencies when it creates the components (hence the term “Dependency Injection” also used to describe this pattern). The result is looser coupling between components. The Spring IoC container has proven to be a solid foundation for building robust enterprise applications.

The Flex and Spring integration process is actually very straightforward. Based on the interest in combining these technologies, I wrote a document providing background information, configuration information, and three examples with source code.

You can read the “Using Flex with Spring” document here.

UPDATE (1/12/2007): I put together a Tomcat-based Test Drive Server that includes these samples running out-of-the box. Read this post for more info.