Watch the video below to get familiar with the Test Drive environment and the sample application:

Installation Instructions

1. Download flex-java-testdrive.zip, and unzip the file in your root directory.
2. Open a Command Window or Shell, navigate to /flex-java-testdrive/tomcat/bin, and start Tomcat (for instance: catalina run).
3. Open a browser and access http://localhost:8400/testdrive/InSync/InSync.html.

Importing the projects in Flash Builder 4

1. In Flash Builder 4, click File > Import > General > Existing Projects into Workspace.
2. Specify flex-java-testdrive/projects as the root directory and click finish.
3. Explore the projects: InSync is the Flex project and java-testdrive is the Java project for the server-side classes.

In the InSync project, the classes in the services and valueObjects packages have been generated automatically by Flash Builder 4. My next blog post will show you how to generate these classes based on existing Java services deployed in BlazeDS.

NOTE: Because BlazeDS 4 hasn’t yet been released, this version of the Test Drive uses a nightly build of BlazeDS 4.

Greg Wilson and Damien Mandrioli are also blogging about the new Tour de Flex real time dashboard today. Greg is the inspiration behind everything “Tour de Flex”, including the idea of the dashboard. He has the story behind the genesis of this project on his blog. Damien (from IBM/ILOG) did a fantastic job at building the client-side of the dashboard using the very cool ILOG Elixir components, and he walks you through the details on his blog.

My contribution to the project is the “real-time messaging” infrastructure. I provide the details below.

First the overall workflow…

The reason we are combining PHP and Java in this workflow is mostly historical. In the initial version of Tour de Flex, there was no Java involved: Greg was persisting loaded samples data (sample id and timestamp) directly from his PHP page. We later added LiveCycle Data Services to the picture to support the data push requirement of the dashboard, and we took the opportunity to move some code (such as the database persistence) from PHP to Java. Note that we are using LCDS for the performance and scalability of its high-end channels, but the application could also be deployed on BlazeDS.

A more straightforward architecture would be for the client to communicate directly with LCDS. For example, the client could invoke a remote object that would directly publish the loaded sample data (sample id and geolocation of the client) to the message destination. Alternatively, the client could use a Producer object to directly publish the message to the destination. Because some logic (such as geolocating the IP address and persisting the data) has to be executed at the server-side before routing the messages to the subscribed clients, you would have to write a custom message adapter if you used this approach.

We will probably streamline the workflow with one of these two approaches in the future, but in the meantime here is the source code for the servlet (logging and non-essential code removed for brevity):

package com.adobe.tdf;

import java.io.IOException;
import java.io.PrintWriter;
import java.util.Date;

import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import com.maxmind.geoip.Location;
import com.maxmind.geoip.LookupService;

import flex.messaging.MessageBroker;
import flex.messaging.messages.AsyncMessage;
import flex.messaging.util.UUIDUtils;

public class TDFServlet extends HttpServlet {

	// Unique clientID for the message service
	private String clientID = UUIDUtils.createUUID();

	// The geocoding service
	protected LookupService lookupService;

	// A DAO to store sample requests in a database
	protected SampleRequestDAO dao = new SampleRequestDAO();

	// The LCDS message broker
	protected MessageBroker messageBroker;

	// The LCDS messaging destination where real time sample requests information is pushed
	protected String destination; 

	public void init() throws ServletException {

		ServletConfig config = getServletConfig();
		destination = config.getInitParameter("messaging.destination.name");
		String path = config.getInitParameter("geocoding.database.path");
		try {
			// Load the geocoding database in init() to make sure we load it only once
			lookupService = new LookupService(path, LookupService.GEOIP_MEMORY_CACHE);
		} catch (IOException e) {
			// We swallow the exception here. If the database is not available, the feed
			// will still work but won't provide the location info.
		}
	}

	protected void doGet(HttpServletRequest request, HttpServletResponse response)
			throws ServletException, IOException {

		if (messageBroker == null)
		{
			messageBroker = MessageBroker.getMessageBroker(null);
		}

		SampleRequest sampleRequest = new SampleRequest();

		try {
			sampleRequest.setSampleId(Integer.parseInt(request.getParameter("sampleId")));
		} catch (Exception e) {
			String message = "A valid sampleId is required to process this request";
			throw new RuntimeException(message);
		}

		sampleRequest.setTimestamp(new Date());

		String ipAddress = request.getParameter("ipAddress");

		// Geolocate the IP address and add the info to the message
		if (lookupService != null && ipAddress != null)
		{
	                Location location = lookupService.getLocation(ipAddress);
			if (location != null)
			{
				sampleRequest.setLatitude(location.latitude);
				sampleRequest.setLongitude(location.longitude);
				sampleRequest.setCountry(location.countryCode);
				sampleRequest.setCity(location.city);
			}
		}

		try {
			dao.create(sampleRequest, ipAddress);
		} catch (RuntimeException e) {

		}

		String subtopic = request.getParameter("subtopic");
		if (subtopic == null) subtopic = "flex";

		// Publish the message to specified destination and subtopic.
		AsyncMessage msg = new AsyncMessage();
		msg.setDestination(destination);
		msg.setHeader("DSSubtopic", subtopic);
		msg.setClientId(clientID);
		msg.setMessageId(UUIDUtils.createUUID());
		msg.setTimestamp(System.currentTimeMillis());
		msg.setBody(sampleRequest);
		messageBroker.routeMessageToService(msg, null);

		PrintWriter out = response.getWriter();
	        out.println("<html><body>ok</body></html>");

	}

}

The servlet is responsible for three things:

1. Geolocate the IP address of the client requesting the sample. We currently use the MaxMind Geolocation API. The API is straightforward and the results seem pretty accurate.
2. Save the information about the loaded sample in a database. We keep track of historical data to be able to support future data visualization projects.
3. Publish the data about the loaded sample to a message destination. The servlet uses the Message Service Java API to directly push messages to the Flex destination (lines 97 to 104). Note that the same API exists for ColdFusion, so CF developers could use a CF page instead of this servlet to push messages to the client.

Channels

The messaging destination is set up to support different communication channels: RTMP, long polling, and regular polling. The client-side developer can decide which channel to use to communicate with the server. For example, if you wanted to use RTMP as the primary channel, fall back to long polling if the RTMP connection fails, and fall back to regular polling if the long polling connection fails you could set up your client-side ChannelSet as follows:

<mx:ChannelSet id="channelSet">
	<mx:RTMPChannel id="rtmp" url="rtmp://hostname:2037"/>
	<mx:AMFChannel url="http://hostname/context/messagebroker/amflongpolling"/>
	<mx:AMFChannel url="http://hostname/context/messagebroker/amfpolling"/>
</mx:ChannelSet>

• 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

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.

A relative newcomer on the list is Swiz, the work of Chris Scott. I figured I would give it a try, and create a Swiz version of the inSync application that I often use to try out and demonstrate different features and techniques in Flex and Adobe AIR. This is not an endorsement of Swiz over other frameworks. I simply wanted to share the sample application I built as part of my own research as a (neutral like a Swiss) Evangelist.

View the source code.

Application Highlights:

At his core, Swiz is a simple inversion of control framework. Using an IoC framework, the components of your application (for example, Views) don’t instantiate or even look up their dependencies (the objects they work with). The framework injects those dependencies when the components are created (hence the term “Dependency Injection” also used to describe this approach). The result is looser coupling and more reusable components. The components managed by the Swiz IoC framework are called beans.

1. Defining your beans

The beans of the inSync applications are defined in Beans.mxml:

<BeanLoader xmlns="org.swizframework.util.*" xmlns:mx="http://www.adobe.com/2006/mxml" xmlns:controllers="insync.controllers.*">

    <DynamicChannelSet id="myAmfChannel">
		<serverPort>8400</serverPort>
		<contextRoot>/lcds-samples</contextRoot>
    </DynamicChannelSet>

    <mx:RemoteObject id="contactService" destination="contacts" channelSet="{myAmfChannel}"/>

    <controllers:ContactController id="contactController"/>

</BeanLoader>

2. Bootstrapping Swiz

You bootstrap Swiz in the preinitialize event of the application. You can have multiple Beans configuration classes. You pass your configuration classes in an array as an argument of the loadBeans function. In inSync, we have only one configuration class (Beans.mxml).

Swiz.loadBeans( [Beans] );

3. Injecting dependencies

Swiz uses the [Autowire] custom metadata to inject beans into other beans and views.
In inSync, the contactService RemoteObject is injected into ContactController.as as follows:

[Autowire(bean="contactService")]
public var contactService:RemoteObject;

… and contactController is injected in the Views. For example, in ContactForm.mxml:

[Autowire(bean="contactController")]
public var controller:IContactController;

Because we use an interface, the View is not coupled to a specific implementation of the controller. If you don’t like to have a reference to the controller in your view, keep reading…

4. Dynamic Mediators

Swiz is an IoC framework. Beyond that, it doesn’t force you to use any specific design pattern. So, if you don’t like to have a controller in your view, you can, for example, set up the view to dispatch events instead. For example, in the save() function of ContactForm.mxml, you would replace:

controller.save(contact);

with:

Swiz.dispatchEvent(ContactEvent.SAVE, contact);

You could then listen to this event in some “mediator” class using Swiz.addEventListener(ContactEvent.UPDATE, someHandler), but the dynamic mediator feature of Swiz allows you to automate this process. For example, you could annotate the save() function of the ContactController class as follows:

[Mediate(event="ContactEvent.SAVE", properties="contact")]
public function save(contact:Contact):void
{
	executeServiceCall(contactService.save(contact), save_result, null, [contact]);
}

Swiz will automatically set up an event listener, invoke the annotated method when the event is dispatched, and pass the specified event properties (in this case: “contact”) as the function parameters.

5. Prototypes

By default, components defined in your Beans configuration classes are singletons. In other words, the same instance of a Bean gets injected everytime it is autowired. In some situations, you may want to inject a new instance of a Bean everytime it is autowired. For example, if you open multiple instances of the same View, you may decide you need one controller per view. Prototypes allow you to define non-singleton Beans in your Beans configuration class using the following syntax:

More on prototypes here.

<factory:Prototype xmlns:factory="org.swizframework.factory.*"
        id="contactController"
        className="insync.controllers.ContactController"/>

Installation instructions:

1. Install the BlazeDS turnkey server. (To be clear: you don’t have to use BlazeDS to use Swiz… That’s just the sample I wanted to build.)
2. Download insync-swiz.zip, and unzip it on your local file system.
3. Copy insync-swiz/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 insync-swiz/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 insync-swiz. You don’t have to select any “Application server type”.
10. Copy the Swiz swc and the flexlib swc (used for the SuperTabNavigator) from insync-swiz/flex/lib to the lib directory of your project
11. Copy the files and folders from insync-swiz/flex/src to the src directory of your project
12. Open Beans.mxml and make sure the serverPort and contextRoot properties in DynamicChannelSet match your server setup.
13. Run the application

Summary

Swiz was easy and enjoyable to work with. It is also non intrusive and definitely introduces some interesting ideas. A few lingering questions I didn’t have time to investigate…

• Swiz relies on introspection (describeType) to find its custom metadata in the objects added to the display list (with the exception of classes in the flash.* and mx.* packages). This has a performance impact. I’m not exactly sure how much of an impact it would have in real life apps yet…
• How well does Swiz work with Modules or Marshall Plan subapplications?

If you are looking for more information, check out the following resources:

• Chris Scott’s presentation at Flex 360
• Getting Started
• Chris Scott’s blog
• Sönke Rohde’s blog

From the press release:

Adobe Systems Incorporated today announced that it is working with SpringSource to simplify the development and deployment of rich enterprise Java(TM) applications through a collaboration that will provide integration between the Adobe(R) Flash(R) and SpringSource platforms. This collaboration will make it easy for Java developers to create enterprise-class rich Internet applications (RIAs) using Adobe Flex(R) software, a cornerstone of the Adobe Flash Platform, and Spring, the de facto standard for enterprise Java.

With support from Adobe, SpringSource is introducing Spring BlazeDS Integration, a new open source project to provide tight integration between Spring and BlazeDS, Adobe’s open source server-based Java remoting and Web messaging technology. A beta version of the Spring BlazeDS Integration will be available from SpringSource in mid-December.
Also in development for early next year is the SpringSource Adapter for Adobe(R) LiveCycle(R) Data Services ES(TM) which will provide integration with Adobe LiveCycle Data Services ES, enabling the creation of server push-based applications based on Adobe Flex for real-time and near real-time solutions.

Read the press release here or here

The Data Management Service provides a set of low level APIs on top of which you can build your own higher level / higher productivity framework. The Hibernate assembler provides an example of a “generic assembler”, but you can also create your own. When used in this fashion, the Data Management Service can provide, by far, the most productive way to build data-driven applications.

To illustrate this point, I have been showing a demo at a few conferences this year, and I finally decided to package it. The demo combines a generic assembler and the runtime configuration feature of LCDS to provide a zero (server-side) code, zero configuration strategy to build data-driven applications. The demo goes like this:

1. Create a table in MySQL Query Browser… just to show that I was starting from scratch.
2. Add a few rows in the new table (still in MySQL Query Browser)
3. Create a new project in Flex Builder, and with the help of a DynamicDataService class, build a data maintenance application in literally three lines of code.

The key point of the demo was that I didn’t have to write any server-side code, or even configure anything (no XML) at the server-side… a table was all I needed.

Here is a quick and rough version of the demo:

Follow the instruction below to try it on your system:

1. Download flex-dynamic-data.zip and unzip it on your local file system.

2. Copy bin/flex-dynamic-data.jar in /tomcat/webapps/lcds-samples/WEB-INF/lib.

   flex-dynamic-data.jar includes two classes: DestinationService and DynamicJDBCAssembler. DestinationService creates data management destinations on the fly. Each destination created by DestinationService uses an instance of DynamicJDBCAssembler to dynamically generate the appropriate SQL statements for the fill, getItem, createItem, updateItem and deleteItem operations. You never have to directly work with or configure these two classes: they are automatically invoked by the client-side DynamicDataService component. The source code is available in /flex-dynamic-data/src/java.

3. Open remoting-config.xml in lcds-samples\WEB-INF\flex and add the following destination:

   <destination id="destination-factory">
       <properties>
           <source>flex.dynamic.data.DestinationService</source>
       </properties>
   </destination>
   

4. Copy flex-dynamic-data.properties in /tomcat/webapps/lcds-samples/WEB-INF/classes.

   Open the file. Notice that the default database is set to the HSQLDB sample database (flexdemodb) shipping with the product.

5. Create a new Flex Builder project. Specify J2EE as the application server type, check the “Use remote object access service” checkbox, uncheck the “Create a combined Java/Flex project using WTP” checkbox, and point to the lcds-samples web application:

   • Root folder: c:\lcds26\tomcat\webapps\lcds-samples
   • Root URL: http://localhost:8400/lcds-samples
   • Context root: /lcds-samples

6. Add flex_dynamic_data.swc to your build path.

   flex_dynamic_data.swc includes the DynamicDataService class. The source code is available in /flex-dynamic-data/src/as.

7. Code the application as follows.

   <?xml version="1.0" encoding="utf-8"?>
   <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" xmlns:data="flex.dynamic.data.*">
   
   	<mx:ArrayCollection id="items"/>
   
   	<data:DynamicDataService id="ds" destination="dynamic.company"
   		ready="ds.fill(items)" />
   
   	<mx:DataGrid dataProvider="{items}" width="100%" height="100%" editable="true"/>
   
   </mx:Application>
   

8. Run the application.
9. Modify data (not the primary key)
10. Click the refresh button and notice that the data has been persisted.
11. Open a second browser and access the same URL. Modify data in one browser and notice that changes are automatically being pushed to the other browser.

Disclaimer: The mini framework provided with this sample is for demo purpose only. The goal is not to provide a production quality solution: I took many shortcuts and although it may be good for rapid prototyping, the specific strategy implemented here has serious limitations (single table, no support for associations, etc.). The goal is to illustrate what’s possible when building generic assemblers and runtime configuration, and hopefully generate a few ideas.

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.