Setting up an Eclipse project so that one can debug BlazeDS code is a bit more complex than one might think. I’ve invested more time than I care to admit into understanding this – I’m a Java newbie – and still don’t understand it completely. Here are some notes on what I’ve learned in case you want to do the same thing, and a question.

First of all, the best guide that I’ve found for setting up Java debugging in Eclipse in general is Yakov Fain’s Debugging both Flex and Tomcat Java programs in Eclipse article. The procedure is fairly simple and it worked the first time I tried it. Of course, I’m using Tomcat on Windows so your mileage may vary. We have links to several other articles that take somewhat different approaches in the Debugging section of our Adobe Flex :: With Java page.

Once you’ve got things set up so that you can set breakpoints in your own Java code and step through it you can follow these steps to set up debugging for BlazeDS.

  • You’ll find a link for a zip file download of the latest stable release on this page. Download and unzip it, and place it in a location that makes sense within your folder hierarchy.
  • In Eclipse go into Window | Preferences | General | Workspace | Linked resources and set up a linked resource (use the New and Folder buttons) that points to the BlazeDS folder. Name it BLAZEDS_HOME.
  • Create a Java project for the [Tomcat]/webapps/blazeds/ folder. I assume that you’ve already got that installed. If not, check out this blog post.
  • Select the blazeds project in Project Explorer and go into Project | Properties | Java Build Path.
  • Select the Libraries tab.
  • Note that there are 5 .jar files with names that start with flex-messaging. You’re going to specify a “Source attachment” for one or more of these. The basic idea here is that while the .jar files are what Tomcat normally uses, we’re going to tell Eclipse where the source code that corresponds to these files is located. This will allow Eclipse to open source files for the classes in the .jar files where you can set breakpoints, then step through code.
  • You can specify the “Source attachment” for a .jar file by expanding it with its + icon, selecting “Source attachment”, clicking the Edit button, clicking the External Folder button, then browsing to and selecting the appropriate source code folder.
  • Here are the folders that correspond to the 5 .jar files:
    • flex-messaging-common.jar: [BLAZEDS_HOME]/modules/common/src/java/
    • flex-messaging-core.jar: [BLAZEDS_HOME]/modules/core/src/java/
    • flex-messaging-opt.jar: [BLAZEDS_HOME]/modules/opt/src/tomcat/ (if you’re using Tomcat – there are other options as well)
    • flex-messaging-proxy.jar: [BLAZEDS_HOME]/modules/proxy/src/java/
    • flex-messaging-remoting.jar: [BLAZEDS_HOME]/modules/remoting/src/java/
  • Which ones should you link to? Well, obviously, it’s not that hard to link to all of them. On the other hand, if you know that you’re probably only going to focus on one of these modules you could search for the class file in the modules folder, identify the desired module, and link to that module only.
  • Once you’ve done this you should be able to initiate debugging as described in Yakov’s article.

Now here’s my question:

Both /modules/common/src/ and /modules/core/src/ contain /java15/ as well as /java/ folders. Adobe tech support tells me that “java/ is for Java 1.4 compliant code and java15/ is Java 5 compliant code” but if you look into each folder it appears that /java/ contains most of the classes and /java15/ contains supplemental classes. Is this correct and, if so, shouldn’t we be linking to both /java/ and /java15/ folders in these two modules? (I’m assuming that we’re using a Java 5 compliant JRE.) And if that’s true, how can we do this in Eclipse?

For now I’m ignoring this issue as the /java/ folders seem to have most of the code that I’m interested in, but if you can clarify this please leave a comment.

Thanks,

Douglas

I'm in the process of implementing remoting using RemoteObject and BlazeDS in my Language Collaborative project's AIR-based player application. It seems that there aren't any example apps out there that show this particular scenario in action. Here's a quick one.

This example builds on my previous post on Running The BlazeDS Sample Applications in (non-turnkey) Tomcat, and assumes that you have completed the process described therein. If you're using the BlazeDS turnkey Tomcat install or some other J2EE server you should be able to translate. If any of these instructions are unclear it may be because you need to refer to that post.

  • Make a copy of the 'testdrive-remoteobject' sample app folder, name it 'testdrive-remoteobject-air', and place it into an Eclipse workspace.
  • Follow the instructions for setting up a Flex Builder project as specified in my previous post, with these changes:
    • Select 'desktop application' under 'application type', rather than 'web application'.
    • Perhaps this is obvious, but the project name, folder name, etc. will have "-air" appended onto them.
  • Open main.mxml and copy the following code below the existing code. We'll compare the two briefly, then delete the original code.
CODE:
  1. <?xml version="1.0" encoding="utf-8"?>
  2. <mx:WindowedApplication
  3.         xmlns:mx="http://www.adobe.com/2006/mxml"
  4.         backgroundColor="#FFFFFF"
  5.         creationComplete="init()">
  6.  
  7.     <mx:Script>
  8.         <![CDATA[
  9.             import mx.messaging.Channel;
  10.             import mx.messaging.ChannelSet;
  11.             import mx.messaging.channels.AMFChannel;
  12.  
  13.             public function init():void
  14.             {
  15.                 var cs:ChannelSet = new ChannelSet();
  16.                 var customChannel:Channel = new AMFChannel("my-amf", "http://localhost:8080/samples/messagebroker/amf");
  17.                 cs.addChannel(customChannel);
  18.                 srv.channelSet = cs;
  19.             }
  20.         ]]>
  21.     </mx:Script>
  22.  
  23.     <mx:RemoteObject id="srv" destination="product"/>
  24.  
  25.     <mx:DataGrid dataProvider="{srv.getProducts.lastResult}" width="100%" height="100%"/>
  26.  
  27.     <mx:Button label="Get Data" click="srv.getProducts()"/>
  28.  
  29. </mx:WindowedApplication>

Here's what we've changed:

  • We changed two Application tags to WindowedApplication.
  • We're dynamically setting up a channel for our RemoteObject. The code is fairly straightforward so I won't go into the details, but it's worthwhile to understand what this replaces. Typically our channels are set up using configuration files. There are a number of reasons why we might want to configure this or other config settings dynamically, but in this case our reason is that the default setting don't work correctly for an AIR application. I can't explain the details of why this doesn't work (perhaps someone from Adobe can add a comment) but let's take a quick look at the standard approach, and what we've changed.
    • Go to /webapps/samples/WEB-INF/flex/
    • Open remoting-config.xml. Note that in the default-channels tag 'my-amf' is specified. This means that all of the destinations defined below, such as 'product' (the one we use) will use the 'my-amf' channel.
    • Open services-config.xml. Search for "channel-definition id="my-amf"". Note that the 'my-amf' channel's endpoint URL is defined using several tokens: server-name, server-port and context-root. These tokens don't work properly when an app is compiled as an AIR app, thus the need to define the channel and its URL ourselves.
    • Note that while the typical configuration's approach is for our RemoteObject to find its channel set by looking at its destination, we can (and do) set RemoteObject's channelSet property directly, which overrides the channel set specified for its destination in the config files.
    • BTW, another (simpler?) approach would be to simply edit the definition for the my-amf channel in services-config.xml so that the endpoint URL is hardcoded rather than using tokens.
  • That's all that's needed. You can now delete the original code, save, compile, and run and/or debug your AIR application. :)
  • Reminder: If you get an error that says "RPC Fault faultString="flex.samples.DAOException : java.sql.SQLException: socket creation error" it may be because the sample database isn't running.

Here's a link to the docs on Run-Time Configuration for BlazeDS.

Adobe offers a turnkey version of BlazeDS that includes an integrated Tomcat server and a number of sample applications that are installed and ready to run. In my case I already have Tomcat installed and would like to run the samples there. Here are a few notes that may help to speed you on your way if you're trying to do the same thing. I'm on Windows but hopefully these notes will be fairly transferable to other platforms.

  • Download the turnkey version from this page. While you don't need the integrated Tomcat server, this version includes the sample applications.
  • The BlazeDS Installation Guide has two sections with potentially useful information - "BlazeDS J2EE web applications" and "Additional server-specific configuration" - but the first of these sections seems to suggest that you can get the sample apps without downloading the turnkey version. As far as I can see, this is incorrect. If I'm wrong, please add a comment.
  • Unzip the downloaded file.
  • You'll find 3 .war files at the root of your unzipped folder - blazeds.war, ds-console.war & samples.war. Put them into your Tomcat webapps folder and either install them using Tomcat Manager or install them by restarting Tomcat.
  • At this point you should be able to open http://localhost:8080/samples/ with your browser. You'll get a web page that will tell you how to start the sample database and run the sample applications. BTW, don't close the command prompt window once the database is started - that will kill the database. You should be able to run the sample programs at this point.
  • Next step: Setting up Flex Builder projects so that you can step through the code, then start to modify it. The http://localhost:8080/samples/ page links to another page entitled Opening the Samples Source Code in Flex Builder 3 (/samples/fb-project-setup.htm) which tells you how to do this.
  • Note that you'll be specifying several different locations as you set up your FlexBuilder project:
    • You'll copy source code, for example a 'testdrive-101' folder, into your Eclipse workspace, and tell Eclipse that this folder is your "project location".
    • You'll specify several pieces of information under "server location". These settings are discussed in Step 10 on the page just mentioned. You'll need to modify the settings that are shown there to match your Tomcat installation's location, and you'll probably want to replace the port number (8400) with 8080. If you'd like to understand what these setting are you can refer to the "Creating a Flex project with J2EE" section of http://livedocs.adobe.com/flex/3/html/help.html?content=projects_3.html
    • You'll also specify a "compiled flex application location" which will typically be a folder inside the "root folder" you just specified. For example, if your "project location" is at [eclipse_workspace]/testdrive-101/, then Flex Builder will probably suggest that you use /webapps/Samples/testdrive-101-debug/ as your "compiled flex application location". This is where the compiled SWF etc. will be deployed each time Flex Builder builds your project.
  • One final note: If you get an error that says "RPC Fault faultString="flex.samples.DAOException : java.sql.SQLException: socket creation error" it may be because the sample database isn't running.