F3 had a simple system of software pixel filters, which could be applied to any Node or group of Nodes in a scene.
]]>F3 had a simple system of software pixel filters, which could be applied to any Node or group of Nodes in a scene. However, thanks to Chris, JavaFX 1.0 includes a much more complete set of effects, and a sophisticated framework that enables GPU hardware acceleration where available.
Underlying the simple declarative expression of effects at the JavaFX script level, effect implementations are described in a GPU-shader-like procedural language, which Chris created, called JSL. Chris's JSL compiler then compiles to various targets, either GPU-based (GLSL/HLSL), or CPU-based (Java/Native).
]]>Curiously, it sounds like something the agile guys might have written (had they not written the manifesto). I prefer this wording because of its greater applicability and more dynamic presentation.
]]>
Recently, the patterns & practices group at Microsoft went back and refined their Application
Architecture Guide, and while there's a lot about it that I wish they'd done differently
(less of a Microsoft-centric focus, for one), I think it's a great book for Microsoft-centric
architects to pick up and have nearby. In a lot of ways, this is something similar
to what I had in mind when I thought about the architectural catalog, though I'll
admit that I'd prefer to go one level "deeper" and find more of the "atoms" that make
up an architecture.
Nevertheless, I think this is a good PDF to pull down and put somewhere on your reference
list.
Notes and caveats: Firstly, this is a book for solution architects; if you're the
VP or CTO, don't bother with it, just hand it to somebody further on down the food
chain. Secondly, if you're not an architect, this is not the book to pick
up to learn how to be one. It's more in the way of a reference guide for existing
architects. In fact, my vision is that an architect faced with a new project (that
is, a new architecture to create) will think about the problem, sketch out a rough
solution in his head, then look at the book to find both potential alternatives (to
see if they fit better or worse than the one s/he has in her/his head), and potential
consequences (to the one s/he has in her/his head). Thirdly, even if you're a Java
or Ruby architect, most of the book is pretty technology-neutral. Just take
a black Sharpie to the parts that have the Microsoft trademark around them, and you'll
find it a pretty decent reference, too. Fourthly, in the spirit of full disclosure,
the p&p guys brought me in for a day of discussion on the Guide, so I can't say
that I'm completely unbiased, but I can honestly say that I didn't write any of it,
just offered critique (in case that matters to any potential readers).
Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services.
1-day or multi-day workshops available. Contact
me for details.
When I start a new project from scratch, there are no warnings, no clutter, no problems. But, as the code base grows, if I don’t pay attention, the clutter, cruft, warnings, and problems can start piling up. When there’s a lot of noise, it’s much harder to find the real warning that I really wanted to read among the hundreds of warnings I didn’t care about.
To make warnings useful again, I use a zero-tolerance policy about warnings from the build. Even if the warning isn’t important, I deal with it. If it’s relevant, but not critical, I still fix it. If the compiler warns about a potential null-pointer exception, I fix the cause, even if I “know” the problem will never show up in production. If the embedded documentation (Javadoc or similar) refers to parameters that have been removed or renamed, I clean up the documentation.
If it’s something I really don’t care about and that really doesn’t matter, I ask the team if we can change our warning policy. For example, I find that documenting the parameters and return value of a method in many cases doesn’t add any value, so it shouldn’t be a warning if they are missing. Or, upgrading to a new version of the programming language may make previously okay code now emit warnings. For example, when Java 1.5 introduced generics, all the old code that didn’t specify the generic type parameter would give a warning. This is a sort of warning I don’t want to be nagged about (at least, not yet). Having a set of warnings that are out of step with reality does not serve anyone.
By making sure that the build is always clean, I will not have to decide that a warning is irrelevant every time I encounter it. Ignoring things is mental work, and I need to get rid of all the unnecessary mental work I can. Having a clean build also makes it easier for someone else to take over my work. If I leave the warnings, someone else will have to wade through what is relevant and what is not. Or more likely, just ignore all the warnings, including the significant ones.
Warnings from your build are useful. You just need to get rid of the noise to start noticing them. Don’t wait for a big clean-up. When something appears that you don’t want to see, deal with it right away. Either fix the source of the warning, suppress this warning or fix the warning policies of your tool. Keeping the build clean is not just about keeping it free of compilation errors or test failures, warnings are an important and critical part of code hygiene.
]]>
The attack plays out like this: someone on your Twitter followers list sends you a
direct message saying, "hey! check out this funny blog about you... " with a hyperlink
to a website, "http://jannawalitax.blogspot.com/" . Clicking on the hyperlink takes
you to a website that redirects to a webpage containing what looks like the
Twitter login page. This is an attempt to get you to fill in your username, and more
importantly, your password.
Needless to say, I'd avoid it. If you do get suckered in (hey, I admit it, I did),
make sure to change your password immediately after.
What I find fascinating about this attack is that the direct messages come from people
that are on my followers list--unless Twitter somehow has a hole in it that allows
non-followers to direct-message you, it means that this is a classic security Ponzi
scheme: I use the attack to gather the credentials for the people that I'm following
directly, then log in and use those credentials to attack their followers, then use
those gathered credentials to attack their followers, and so on. Fixing this is also
going to be a pain--literally, everybody on Twitter has to change their password,
or the scheme can continue with the credentials of those who didn't. (Assuming Twitter
doesn't somehow lop the attack off at the knees, for example, by disallowing hyperlinks
or something equally draconian.)
We won't even stop to consider what damage might be done if a Twitter-user uses the
same password and login name for their Twitter account as they do for other accounts
(such as email, banking websites, and so on). If you're one of those folks, you seriously
might want to reconsider the strategy of using the same password for all your websites,
unless you don't care if they get spoofed.
There's two lessons to be learned here.
One, that as a user of a service--any service--you have to be careful about
when and how you're entering your credentials. It's easy to simply get into the habit
of offering them up every time you see something that looks familiar, and if supposed
"computer experts" (as most of the Twitterverse can be described) can be fooled, then
how about the casual user?
Two, and perhaps the more important lesson for those of us who build software, that
any time you build a system that enables people to communicate, even when you put
a lot of energy into making sure that the system is secure, there's always an angle
that attackers will find that will expose a vulnerability, even if it's just a partial
one (such as the gathering of credentials here). If you don't need to allow hyperlinks,
don't. If you don't need to allow Javascript, don't. Start from the bare minimum that
people need to make your system work, and only add new capabilities after they've
been scrutinized in a variety of ways. (YAGNI sometimes works to our advantage in
more ways than one, it turns out.)
Kudos, by the way, to the Twitter-keepers, who had a message describing the direct-message
phishing attack on the Twitter Home page within hours.
Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services.
1-day or multi-day workshops available. Contact
me for details.
RESTClient (rest-client)
RESTClient is hosted on Google Code as the rest-client project (not to be confused with the Python-based RESTClient project or even with the Google Code-hosted python-rest-client). RESTClient 2.2 is currently available and there is an article called RESTClient 2.1 - Getting Started that provides a nice introduction to RESTClient. A large set of screen snapshots of RESTClient can be found at http://flickr.com/photos/subwiz/tags/restclient/.
I like RESTClient because it is very simple (I was able to start using it quickly and without reading any instructions) and because it is Java Swing-based. The RESTClient download is an executable JAR that is less than 5 MB in size. Once downloaded, it does not need to be uncompressed, but can instead be directly executed with the command (for RESTClient 2.2):
java -jar restclient-2.2-jar-with-dependencies.jar
When RESTClient is started as shown above, the Swing-based GUI comes up as shown in the next screen snapshot.
This screen snapshot demonstrates how self-explanatory this tool is to use. One simply enters the URL of interest in the obviously named "URL" field and then selects the HTTP method to be used in the radio buttons underneath the again obviously named "HTTP Methods" header. The bottom of this simple GUI has tabs for looking at headers and at the response body and has a large field for displaying response status information. I will demonstrate some of this functionality toward the end of this blog posting.
The Sun-Provided HTTPServer
The RESTClient product described above, as its name suggests, covers my need for a simple REST client. For a simple REST server, I had thought about using a Java servlet with the appropriate methods corresponding to HTTP methods (doGet(), doPost(), doPut(), doDelete(), doHead(), doOptions(), and doTrace()) overridden for my use. However, I was really looking for the simplest solution that covered my needs and realized that the Sun-provided HTTPServer would work well here.
I have previously blogged about the HTTP Server and adapted the example I provided in that blog posting to a slightly more sophisticated (but still extremely basic) tool to tell me, from a server perspective, what a potential HTTP/REST client has requested. While I may tweak this a bit before the actual conference, I include its current state here. The first class shown, DustinHttpHandler, is the class that implements HttpHandler.
DustinHttpHandler.java
package dustin.rest;
import com.sun.net.httpserver.Headers;
import com.sun.net.httpserver.HttpExchange;
import com.sun.net.httpserver.HttpHandler;
import java.io.IOException;
import java.io.OutputStream;
import java.net.HttpURLConnection;
import java.util.List;
/**
* Simple HTTP-receiving server based on the Sun-provided HTTP Server. Written
* primarily to be with clients designed for interaction with REST-based
* web services. In other words, this simple HTTP Server implementation can be
* used as a REST-based web services simulator.
*
* @author Dustin
*/
public class DustinHttpHandler implements HttpHandler
{
/**
* Only method prescribed by the HttpHandler interface.
*
* @param httpExchange Encapsulation of HTTP request and response.
* @throws java.io.IOException
*/
public void handle(HttpExchange httpExchange) throws IOException
{
final String requestMethod = httpExchange.getRequestMethod();
final String response = buildResponse(httpExchange);
System.out.println("*** HTTP Request Method: " + requestMethod + "***");
httpExchange.sendResponseHeaders(HttpURLConnection.HTTP_OK, response.length());
final OutputStream os = httpExchange.getResponseBody();
os.write(response.getBytes());
os.close();
}
/**
* Build up the response String.
*
* @param httpExchange HTTP method associated with request.
* @return Response String.
*/
private String buildResponse(final HttpExchange httpExchange)
{
final StringBuffer buffer = new StringBuffer();
buffer.append("<html><head><title>Dustin's Simple Example</title></head>");
buffer.append("<body><table border='1'>");
appendHtmlTableRow(buffer, httpExchange.getRequestMethod(), "HTTP Method");
appendHtmlTableRow(buffer, httpExchange.getProtocol(), "Protocol");
appendApplicationState(buffer, httpExchange, "Application State");
appendRequestHeadersPortion(buffer, httpExchange.getRequestHeaders());
buffer.append("</table></body></html>");
return buffer.toString();
}
/**
* Append the application state (query parameters provided in the URL provided
* by the client) to the provided StringBuffer.
*
* @param buffer StringBuffer to which to append the client-provided
* application state.
* @param httpExchange Provides the handle to the client-provided state.
* @param label Label for the HTML table.
*/
private void appendApplicationState(
final StringBuffer buffer,
final HttpExchange httpExchange,
final String label)
{
appendHtmlTableRow(buffer, httpExchange.getRequestURI().getQuery(), label);
}
/**
* Append provided headers to the provided buffer.
*
* @param buffer Buffer to which headers information will be appended.
* @param headers Headers whose information needs to be appended to buffer.
*/
private void appendRequestHeadersPortion(
final StringBuffer buffer, final Headers headers)
{
appendHtmlTableWithHeaders(buffer, "Request Headers", headers);
}
/**
* Append provided HTTP response headers to provided StringBuffer.
*
* @param buffer Buffer to which to append the response headers information.
* @param headers Response headers to be appended to StringBuffer.
*/
private void appendResponseHeadersPortion(
final StringBuffer buffer, final Headers headers)
{
appendHtmlTableWithHeaders(buffer, "Response Headers", headers);
}
/**
* Append an HTML table row with potentially multiple headers.
*
* @param buffer Buffer to which to append the new HTML table row.
* @param headerLabel The highlighted label for the left column.
* @param headers The headers to be appended to the provided buffer.
*/
private void appendHtmlTableWithHeaders(
final StringBuffer buffer,
final String headerLabel,
final Headers headers)
{
appendSingleHeaderRow(buffer, headerLabel);
for (final Headers.Entry<String,List<String>> header : headers.entrySet())
{
appendHtmlTableRowMultipleValues(buffer, header.getValue(), header.getKey());
}
}
/**
* Build a two-column row for an HTML table with the elementString value
* being placed in the right column and the elementLabel being placed in
* the left column with heading emphasis.
*
* @param bufferToAppend Buffer to which to append HTML table row.
* @param elementString Normal table data element (right column) value.
* @param elementLabel Highlighted table header element (left column) value.
*/
private void appendHtmlTableRow(
final StringBuffer bufferToAppend,
final String elementString,
final String elementLabel)
{
bufferToAppend.append(
"<tr><th>" + elementLabel + "</th><td>" + elementString + "</td></tr>");
}
/**
* Append to buffer with an HTML table row that has potentially multiple
* values for a single value column (multiple values per header column).
*
* @param bufferToAppend Buffer to which to append HTML table row.
* @param elementStrings Multiple values to be appended in single values column.
* @param elementLabel Header label for left column of row.
*/
private void appendHtmlTableRowMultipleValues(
final StringBuffer bufferToAppend,
final List<String> elementStrings,
final String elementLabel)
{
bufferToAppend.append("<tr><th>" + elementLabel + "</th><td>");
for (final String value : elementStrings)
{
bufferToAppend.append(value + "\n");
}
bufferToAppend.append("</td></tr>");
}
/**
* Append a single-cell row for HTML table section headers.
*
* @param bufferToAppend Buffer to which to append the single-cell header row.
* @param value String to place in the single-cell header row; the section
* title.
*/
private void appendSingleHeaderRow(
final StringBuffer bufferToAppend,
final String value)
{
bufferToAppend.append("<tr><th colspan='2'>");
bufferToAppend.append(value);
bufferToAppend.append("</th></tr>");
}
}
The Main class that instantiates and uses the HttpHandler described above is called Main and its code listing is shown next:
Main.java
package dustin.rest;
import com.sun.net.httpserver.HttpServer;
import java.io.IOException;
import java.net.InetAddress;
import java.net.InetSocketAddress;
/**
* Simple executable to start HttpServer for HTTP request/response interaction.
*
* Run this class with a command line this:
* java -cp RESTfulJava.jar dustin.rest.Main
*
* The URL for connecting to this HTTPServer instance from a client will be
* http://localhost:8000/dustin
*/
public class Main
{
public static final int PORT = 8000;
public static final int BACKLOG = 0; // none
public static final String DEFAULT_URL_CONTEXT = "/dustin";
/**
* Main executable to run Sun's built-in JVM HTTP server.
*
* @param arguments The command line arguments; single argument for URL
* context expected.
*/
public static void main(final String[] arguments) throws IOException
{
final String hostName = InetAddress.getLocalHost().getCanonicalHostName();
final String urlContext = obtainUrlContext(arguments);
final HttpServer server =
HttpServer.create(new InetSocketAddress(PORT), BACKLOG);
server.createContext(urlContext, new DustinHttpHandler());
server.setExecutor(null); // allow default executor to be created
System.out.println("\n\nSimple HTTP Server is running. Use URL\n");
System.out.println(" http://" + hostName + ":" + PORT + urlContext);
System.out.println("\nto access this server.");
server.start();
}
/**
* Extract the URL Context from the command-line or use a default if no
* argument was provided on the command-line.
*
* @param commandLineArguments Command-line arguments.
* @return URL context.
*/
private static String obtainUrlContext(final String[] commandLineArguments)
{
String urlContext = DEFAULT_URL_CONTEXT;
final int numCmdLineArgs = commandLineArguments.length;
if (numCmdLineArgs > 0)
{
final String cmdProvidedContext = commandLineArguments[0];
urlContext = (cmdProvidedContext.startsWith("/"))
? cmdProvidedContext
: "/" + cmdProvidedContext;
}
return urlContext;
}
}
I intentionally have the code print the URL to call to access the HttpServer to make it easier for clients to connect. Note also that a command-line argument can be specified to override the context. This is effectively the resource representation portion in REST parlance.
It is easy to run this application to take advantage of the Sun-provided HttpServer. I built the JAR to be executable as shown in the Main-Class entry in the META-INF/MANIFEST.MF file shown below:
MANIFEST.MF of JAR file
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.7.0
Created-By: 11.0-b15 (Sun Microsystems Inc.)
Main-Class: dustin.rest.Main
With the JAR declared as an executable JAR (RestServer.jar), it is simple to run the application:
java -jar RestServer.jar
Leveraging the RESTClient with the Sun-Provided HTTP Server
In most cases, I plan to use the RESTClient with "real" REST-based web services and use the HTTP Server approach with "real" clients of REST-based web services. In that way, I have easy approaches to testing pieces of the REST interaction. However, it can still be interesting to use the two together and I intend to do so in my presentation to provide some background on HTTP methods and terminology.
When I run the HTTP Server-based RestServer with a command-line argument of "rest/example/name", it looks like this:
java -jar RestServer.jar rest/example/name
When running the above, I see the following expected output (with your own host of course and with a context different than "rest/example/name" if provided as a command-line argument):
Simple HTTP Server is running. Use URL
http://gandalf.marx.net:8000/rest/example/name
to access this server.
This means the simple HTTP Server is running and I can use CTRL-C to break it when I'm finished.
Running the RESTClient is really easy as discussed above:
java -jar restclient-2.2-jar-with-dependencies.jar
I can enter the URL provided by the standard output of the HTTP Server in the URL field of the RESTClient GUI, select an HTTP method with the radio button, and click on the green greater-than signs/arrows pointing right. When using POST method, and changing the tab at the bottom to "Body," the response body is shown as indicated in the following screen snapshot.
If I change the HTTP method to a different method type, the body returned looks the same, but with the different method indicated. The one exception is the HEAD method. As expected, there is no response body shown for the HEAD method because "the HEAD method is identical to GET except that the server MUST NOT return a message-body in the response" (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.4). The HEAD example is shown in the next screen snapshot.
One can also use a web browser to see the returned body (which is conveniently in HTML thanks to my simple implementation of the HttpHander). By default, the browser uses GET as shown in the following screen snapshot. I also have added an id parameter to the URL for this example to indicate how application state can be passed by the client to the server and how the server in the HTTPServer example can provide an indication of the query parameters received.
Conclusion
There are many tools that can be used in REST development and more are coming all the time. Because I often find myself preferring the simplest tool for the job, it is difficult to beat RESTClient and the HTTP Server that comes with the Sun-provided JVM for simple testing and simple demonstration of REST principles and implementations.
]]>function tak(x:Number, y:Number, z:Number): Number {
if (y >= x) z else tak(tak(x-1, y, z),
tak(y-1, z, x),
tak(z-1, x, y));
}
for (i in [1..1000]) {
tak(24, 16, 8);
}
time javafx -server -cp . Tak
real 0m10.724s
user 0m10.105s
sys 0m0.173s
Groovy
def tak(double x, double y, double z) {
return y >= x ?
function tak(x:Number, y:Number, z:Number): Number {
if (y >= x) z else tak(tak(x-1, y, z),
tak(y-1, z, x),
tak(z-1, x, y));
}
for (i in [1..1000]) {
tak(24, 16, 8);
}
time javafx -server -cp . Tak
real 0m10.724s
user 0m10.105s
sys 0m0.173s
Groovy
def tak(double x, double y, double z) {
return y >= x ? z : tak(tak(x-1, y, z),
tak(y-1, z, x),
tak(z-1, x, y));
}
int i = 0;
while (i++ < 1000) {
tak(24, 16, 8);
}
time java -Djava.ext.dirs=./groovy-1.6-RC-1/lib -server groovy.lang.GroovyShell tak.groovy
real 4m36.674s
user 4m29.272s
sys 0m3.842s
JRuby
def tak x, y, z
unless y < x
z
else
tak( tak(x-1, y, z),
tak(y-1, z, x),
tak(z-1, x, y))
end
end
i = 0
while i<1000
tak(24, 16, 8)
i+=1
end
time ./jruby-1.1.6RC1/bin/jruby -J-server tak.rb
real 4m24.735s
user 4m22.203s
sys 0m1.069s
Summary
For this benchmark, as you can see both JRuby and Groovy are around 25x slower than JavaFX script.
]]>It's not about SSL as a whole, it's just about MD5 signatures that some SSL certificates are signed with.
What would it mean to Java developers?
]]>It's not about SSL as a whole, it's just about MD5 signatures that some SSL certificates are signed with.
What would it mean to Java developers?
1. Double-check that certificates you rely on are not signed with MD5. Firefox lists this info in certificate details as Certificate Signature Algorythm.
2. Leave MD5 in year 2008 and start using sha1. Just start typing sha1sum instead of md5sum :)
Also, this is not the first time when rogue certificates get generated. Advanced Windows viruses are using false Microsoft certificates for quite some time already.
Beware!
]]>It's the end of the World's Slowest News Week here in Java land, which also happens to be simultaneously the last week of 2008 and the first of 2009. ]]>
It's the end of the World's Slowest News Week here in Java land, which also happens to be simultaneously the last week of 2008 and the first of 2009. The biggest news stories over the last year or so, I would submit, were the slow but steady rise of SpringSource, the real live birth of JavaFX, the proliferating number of JVM languages, and the downward spiral of Sun's financial situation, with its possible impact on Java.
So I put it to you: what will be exercising the minds of Java developers in the coming 12 months? My #1 guess is something off the 2008 list, the fate of Sun -- there's a good chance that there will be a merger, massive restructuring, or other similar crisis. This will have an impact on what should be the other big story: the development of Java 7, set for release in early 2010, but no doubt largely solidifying this year. Nothing about it is settled yet (good lord, people are still worked up about closures, or the lack thereof) and if Sun is busy selling itself off for parts or being absorbed by IBM/Fujitsu/the Sheinhardt Wig Corporation, the handling of the Java 7 transition may be rocky; it will definitely be a big test of the Java community's ability to manage a true open source project.
Any guesses as to what I'll be wrapping up come early 2010? Chime in in the comments!
]]>The official way of importing contacts is to keep them all in Gmail. For a number of reasons this is not very convenient, for one -- Gmail can import your contacts from CSV file only, it gives no other options.
]]>The official way of importing contacts is to keep them all in Gmail. For a number of reasons this is not very convenient, for one -- Gmail can import your contacts from CSV file only, it gives no other options.
The standard way for contacts exchange is via Vcard files/format. So, I created a Java Android application that helped me to import all my contacts to G1. The Import Contacts app is published on Andappstore and is downloadable from here. Just point your G1 browser there.
In my case I had all my contacts in Nokia N70 in sync with Outlook (win) and Evolution (linux). In Evolution I exported all contacts to a single Vcard file, uploaded it to G1 microSD card, and imported the file using my app.
Of course this is a workaround to the real and yet unresolved problem, but Android SyncML and OBEX implementation is not something that I'm going to do in the near future.
And also it was fun to know that it was impossible to delete all contacts from G1 at once. If you want to clean your address book you must clean Gmail contacts and synchronize it with G1 then -- awkward. So I added this 'Wipe all contacts' functionality to Import Contacts too.
Enjoy!
]]>Tools Used in these Examples
For the examples in this blog posting, I will be using the following tools:
FLEX_HOME to point to the main directory of my Flex 3 installation (where I unzipped it) and I have included %FLEX_HOME%\bin (or $FLEX_HOME/bin) on my PATH.
build.xml Ant build file in this posting that will build the Flex clients and will build the BlazeDS/JEE-powered server. However, these operations can be done individually as well. While I build a WAR file with my Ant build for the server-side deployment, one could simply edit directories and files in one's favorite server's deployment directory for the same effect. Similarly, one could build the Flex clients individually on the command line with the mxmlc command rather than using the build.xml file to do this. I am using Ant 1.7, but I am not aware of any features I am using specific to that version. Finally, I have my ANT_HOME environment variable set to my installation of Ant and have %ANT_HOME%/bin in my path for convenience in building.
The following screen snapshot demonstrates the versions of these tools used as described above.
Setting Up BlazeDS for the Application
I won't go into any greater detail regarding installation of the Flex SDK, of the Java SDK, of a Java EE-compliant web server, of Ant, or of an IDE or text editor than that provided above. However, I will briefly look a little closer at installation of BlazeDS.
BlazeDS is open source and its source can be downloaded here, but the source code for BlazeDS is not needed for any of the examples in this blog posting.
The BlazeDS download page includes release builds and nightly builds. I am using a release build for the examples here. BlazeDS 3.2 Release Build 3978 is available as of this writing and I am using BlazeDS 3.2 Release Build 3978 for these examples.
An advantage of using the Turnkey download is that Tomcat web server is included with it. However, I intentionally want the examples in this posting to be "bare bones" and so will use a separate JEE implementation. With the non-Turnkey binary BlazeDS release downloaded (it will be called something like blazeds-bin-3.2.0.3978.zip), "installation" simply involves unzipping the ZIP file and extracting the WAR file (blazeds.war) from it. The next screen snapshot shows the contents of this binary BlazeDS download, including the WAR file just mentioned.
With access to the blazeds.war file, we now need to expand the blazeds.war's contents. We have two choices here. One popular choice is to expand this WAR file's contents in a web server's deployment directory. Many web servers will then automatically deploy the contents of that expanded directory. However, I will be taking the second approach here and will rebuild the WAR file for deployment with an Ant script. This provides greater portability between web servers and allows me to show better what needs to be included in the server-side BlazeDS-powered WAR file via the build.xml file. You should be able to use the direct deployment of expanded directory approach and not need Ant for the server-side if you prefer that approach.
The next screen snapshot shows the contents of the blazeds.war file that needs to be expanded.
For my examples, I will be expanding the blazeds.war file's contents into the C:\blazeDSRemotingExample) directory. I typically remove the META-INF directory and its contents from the expanded directory, so that it looks something like that shown in the next two screen snapshots. Note that the red lines through directories in the first screen snapshot are intentional because the entries that they cross out will eventually be built up, but will not be there when blazeds.war is initially expanded (in other words, your newly expanded directory should only have the WEB-INF directory if you deleted the META-INF directory as I did).
As the immediately preceding image shows, the expanded blazeds.war contents include some expected subdirectories beneath WEB-INF including classes and lib. Because we will rebuild our server's WAR file with this same expanded directory structure, we already have the necessary directories we need for the web application's classpath.
Tailoring BlazeDS Web Descriptor Configuration for Custom Application
Up until now, we've merely unzipped the downloaded binary BlazeDS file and then expanded the blazeds.war file into a directory. Now it is time to begin tweaking the configuration files included with the blazeds.war file to accommodate our application.
One of the first things I like to do when customizing my own BlazeDS-based application based on the provided blazeds.war file is to upgrade the web application descriptor file (web.xml) to reflect Servlet 2.5 rather than Servlet 2.3. I provide more detail on this process in my blog entry on OpenLaszlo with Java Servlets 2.5 (OpenLaszlo also provides an older web.xml file). The most important changes to note are that the DTD-described file becomes W3C XML Schema described instead, the version attribute is obviously updated from 2.3 to 2.5, and the <display-name> element is removed as a nested element under the <servlet> element. This particular change of versions of the web.xml file is probably not absolutely necessary in this case because I'm not using Java EE 5 annotations, but I make the change every time anyway.
The less important changes that I make to the provided web.xml file include removal of commented out section specifically intended for WebSphere (which I'm not using here) and other comments. The other change I make is to change the text for the high-level <display-name> and <description> elements. Indeed, when I have completed the transformation, the new web.xml file still looks very similar to the one provided with the blazeds.war file. Several of these changes are depicted in the next screen snapshot taken of a diff run against the two versions of web.xml using the ExamDiff tool.
The new and customized web.xml file is shown next.
New and Customized web.xml File
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
version="2.5" xmlns="http://java.sun.com/xml/ns/javaee">
<display-name>Dustin's BlazeDS Hello World Example</display-name>
<description>An extremely simple BlazeDS Remoting Application</description>
<!-- Http Flex Session attribute and binding listener support -->
<listener>
<listener-class>flex.messaging.HttpFlexSession</listener-class>
</listener>
<!-- MessageBroker Servlet -->
<servlet>
<servlet-name>MessageBrokerServlet</servlet-name>
<servlet-class>flex.messaging.MessageBrokerServlet</servlet-class>
<init-param>
<param-name>services.configuration.file</param-name>
<param-value>/WEB-INF/flex/services-config.xml</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>MessageBrokerServlet</servlet-name>
<url-pattern>/messagebroker/*</url-pattern>
</servlet-mapping>
<welcome-file-list>
<welcome-file>index.html</welcome-file>
<welcome-file>index.htm</welcome-file>
</welcome-file-list>
</web-app>
Customizing Other BlazeDS Configuration Files
Besides the classes and lib subdirectories contained under WEB-INF in the directory expanded from the blazeds.war file, we also have subdirectories called src and flex. We will not customize a couple XML files inside the flex directory to tailor BlazeDS for our application's use.
The first file we'll look at is called services-config.xml. This file is central to all BlazeDS-based applications whether they are based on RPC or messaging. In fact, among other things, this file usually imports additional configuration files for things that are specific to proxying, to remoting, and to messaging.
I use the same approach with services-config.xml that I used with web.xml: I adapt the version provided by blazeds.war to work for the custom application. However, there is a twist in this one case. I want to have a slightly different version of this file for my Flex client than I have for my WAR that gets deployed on the server. Keeping the DRY principle in mind, my approach here is to create a services-config-template.xml file and use Ant's text substitution functionality to automatically generate the services-config.xml file to be used by both the Flex client and by the WAR that is deployed to the server. The next code listing shows the template file, which I placed in a newly created directory creatively called "templates".
templates/services-config-template.xml
<?xml version="1.0" encoding="UTF-8"?>
<services-config>
<services>
<service-include file-path="remoting-config.xml" />
<service-include file-path="proxy-config.xml" />
<service-include file-path="messaging-config.xml" />
</services>
<security>
<login-command class="flex.messaging.security.TomcatLoginCommand" server="Tomcat"/>
</security>
<channels>
<channel-definition id="my-amf" class="mx.messaging.channels.AMFChannel">
<endpoint url="http://@host@:@port@/{context.root}/messagebroker/amf"
class="flex.messaging.endpoints.AMFEndpoint"/>
</channel-definition>
<channel-definition id="my-secure-amf" class="mx.messaging.channels.SecureAMFChannel">
<endpoint url="https://@host@:@port@/{context.root}/messagebroker/amfsecure"
class="flex.messaging.endpoints.SecureAMFEndpoint"/>
<properties>
<add-no-cache-headers>false</add-no-cache-headers>
</properties>
</channel-definition>
<channel-definition id="my-polling-amf" class="mx.messaging.channels.AMFChannel">
<endpoint url="http://@host@:@port@/{context.root}/messagebroker/amfpolling" class="flex.messaging.endpoints.AMFEndpoint"/>
<properties>
<polling-enabled>true</polling-enabled>
<polling-interval-seconds>4</polling-interval-seconds>
</properties>
</channel-definition>
</channels>
<logging>
<target class="flex.messaging.log.ConsoleTarget" level="Error">
<properties>
<prefix>[BlazeDS] </prefix>
<includeDate>false</includeDate>
<includeTime>false</includeTime>
<includeLevel>false</includeLevel>
<includeCategory>false</includeCategory>
</properties>
<filters>
<pattern>Endpoint.*</pattern>
<pattern>Service.*</pattern>
<pattern>Configuration</pattern>
</filters>
</target>
</logging>
<system>
<redeploy>
<enabled>false</enabled>
</redeploy>
</system>
</services-config>
The code for the template version of services-config-template.xml shown immediately above includes Ant token markers (@host@ and @port@) that will be replaced by Ant with an actual host name and a port number for the client's version of services-config.xml). These same tokens will be replaced with BlazeDS-recognized tokens {server.name} and {server.port} for the server-side version of services-config.xml. Note that I was able to leave the BlazeDS template {context.root} in the template for the client-side version of services-config.xml because the mxmlc compiler allows me to specify its value for the client as an option.
I left the reference in services-config.xml to all three previously referenced files (remoting-config.xml, proxy-config.xml, and messaging-config.xml), but really only need the reference to remoting-config.xml for this blog post examples. As with the web.xml file, my approach to creation of that referenced remoting-config.xml file is to simply adapt the one provided with the expanded blazeds.war file. The only necessary change is to specify the Java classes that will be used on the server side. We haven't looked at this Java class yet, but the remoting-config.xml file shown in the next code listing tips us off that it will be a class named HelloWorldRemotingServer in a package named dustin.
remoting-config.xml
<?xml version="1.0" encoding="UTF-8"?>
<service id="remoting-service"
class="flex.messaging.services.RemotingService">
<adapters>
<adapter-definition id="java-object" class="flex.messaging.services.remoting.adapters.JavaAdapter" default="true"/>
</adapters>
<default-channels>
<channel ref="my-amf"/>
</default-channels>
<destination id="HelloWorld">
<properties>
<source>dustin.HelloWorldRemotingServer</source>
</properties>
</destination>
</service>
The above remoting-config.xml file specifies that the destination associated with this Java class on the server side can be referenced as "HelloWorld" (the 'id' attribute of the destination element).
Whew! That wraps up the BlazeDS configuration modifications. If you have not looked into this before, it looks worse than it really is. Most of the final content shown in the code listings above was already provided by the blazeds.war that we expanded. I only made some relatively small modifications to the web.xml and remoting-config.xml files. The services-config.xml file likewise only required some minor changes, but the more significant issue there was that I needed to prepare a different version of this file for the client than for the server. The server version of services-config.xml can resolve the BlazeDS tokens {host.name} and {host.port} based on the web server settings, but I specify a hard-coded host name and port for the client version of services-config.xml.
The Java Class
The contents of the remoting-config.xml file provided us with a sneak peek at some details about the Java class on the server. The definition of this simple Java class is shown next. Note that this file is placed in a subdirectory called dustin (because it is in the "dustin" Java package) under the src subdirectory under WEB-INF in our expanded directory.
HelloWorldRemotingServer.java (1st Version)
package dustin;
/**
* Simple "Hello World" example meant for use in BlazeDS remoting example.
* This is the server-side POJO that will be exposed to a Flex client via
* BlazeDS remoting.
*
* @author Dustin
*/
public class HelloWorldRemotingServer
{
/** No-arguments constructor. */
public HelloWorldRemotingServer() {}
/**
* Accept a String representing a name and return that name as part of a
* Hello message.
*
* @param nameToSayHelloTo Name to which Hello will be addressed.
* @return Hello address to provided name.
*/
public String processHello(final String nameToSayHelloTo)
{
return "Hello, " + nameToSayHelloTo + "!";
}
}
The important thing to note from the code listing for the Java class immediately above is that it is a regular Java class with no knowledge of Flex or ActionScript.
The Flex Client (Hello World Client)
The Java class we just looked at returns a provided String surrounded with a Hello World prefix and exclamation point. We'll now look at the Flex MXML code that can be used to invoke this Java object and this processHello(String) method via BlazeDS.
HelloWorldRemotingClient.mxml
<?xml version="1.0" encoding="UTF-8" ?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
width="1100" height="700">
<!-- Associate client with BlazeDS destination via RemoteObject. -->
<mx:RemoteObject id="remoteObject" destination="HelloWorld" />
<mx:Panel id="mainPanel" title="Simple BlazeDS Remoting Example - Hello World">
<mx:Form>
<mx:FormItem label="Provide Your Name">
<mx:TextInput id="textInput"
change="remoteObject.processHello(textInput.text)"/>
</mx:FormItem>
<mx:FormItem label="Server's Response">
<mx:Label text="{remoteObject.processHello.lastResult}"/>
</mx:FormItem>
</mx:Form>
</mx:Panel>
</mx:Application>
The MXML code above is very simple. The RemoteObject element (with an 'id' of "remoteObject") specifies a destination (via the 'destination' attribute) of "HelloWorld" (defined above in the remoting-config.xml file).
If you plan to use the build.xml file provided in this blog posting, this MXML file should be placed at parallel to the WEB-INF directory (as opposed to in the WEB-INF directory like the Java class and configuration files previously discussed).
Building it All
Even though I still need to show another Flex client, an ActionScript class, and another Java class whose instantiation is bound to the ActionScript class's instantiation, I am including the entire Ant build.xml file here for convenience. Some of the targets defined in this file will not work until the remaining classes discussed later in this blog posting are included.
build.xml (Ant)
<?xml version="1.0" encoding="UTF-8"?>
<project name="HelloWorldBlazeDSRemotingExample" default="all" basedir=".">
<description>Builds, tests, and runs the Dustin's Hello World BlazeDS Remoting Example.</description>
<!-- NOTE TO USERS: At least three properties set below may need to be
set for this build file to work with different deployment
environments. The three minimum properties to examine
are client.host, client.port, and app.dir.
-->
<!-- GENERAL PROPERTIES -->
<!--
*********************************************************************
Change server's host name and port (determined by web server
deployment of server side of code).
*********************************************************************
-->
<property name="client.host" value="localhost" />
<property name="client.port" value="8080" />
<!--
*********************************************************************
Change definition of app.dir if necessary (to where blazeds.war
has been uncompressed).
*********************************************************************
-->
<property name="app.dir" value="C:\\blazeDSRemotingExample" />
<property name="web.inf.dir" value="${app.dir}/WEB-INF" />
<property name="templates.dir" value="${app.dir}/templates" />
<property name="context.name" value="HelloWorldRemotingServer" />
<!-- GENERAL JAVA PORTION PROPERTIES -->
<property name="src.dir" value="${web.inf.dir}/src" />
<property name="classes.dir" value="${web.inf.dir}/classes" />
<property name="lib.dir" value="lib" />
<property name="dist.dir" value="${app.dir}/dist" />
<property name="javadoc.dir" value="${dist.dir}/javadoc" />
<property name="serverside.war" value="${context.name}.war" />
<!-- Nothing special needed for classpath! -->
<path id="classpath" />
<!-- BLAZEDS RELATED PROPERTIES -->
<property name="services.config.server.name"
value="services-config.xml" />
<property name="services.config.client.name"
value="services-config-client.xml" />
<property name="services.config.template"
value="services-config-template.xml" />
<!-- GENERAL FLEX PORTION PROPERTIES (FLEX CLIENT) -->
<property name="app.flex.dir" value="${web.inf.dir}/flex" />
<property name="flex.debug" value="true" />
<property name="flex.warnings" value="true" />
<property name="flex.context.root" value="${context.name}" />
<property name="flex.services"
value="${app.flex.dir}/${services.config.client.name}" />
<property name="flex.source.path" value="${web.inf.dir}" />
<property name="flex.publisher" value="Dustin" />
<property name="flex.title"
value="'Hello World BlazeDS Remoting Example'" />
<property name="flex.description"
value="'Simple client for BlazeDS Remoting example'" />
<property name="flex.verbose.stacktraces" value="true" />
<property name="flex.actionscript.warnings" value="true" />
<property name="flex.app.helloworld.name.root"
value="HelloWorldRemotingClient" />
<property name="flex.app.helloworld.name.source"
value="${flex.app.helloworld.name.root}.mxml" />
<property name="flex.app.helloworld.name.swf"
value="${flex.app.helloworld.name.root}.swf" />
<property name="flex.app.complexobject.name.root"
value="ComplexObjectRemotingClient" />
<property name="flex.app.complexobject.name.source"
value="${flex.app.complexobject.name.root}.mxml" />
<property name="flex.app.complexobject.name.swf"
value="${flex.app.complexobject.name.root}.swf" />
<target name="-init">
<mkdir dir="${dist.dir}" />
<mkdir dir="${javadoc.dir}" />
</target>
<target name="-copy-respective-services-config-files"
depends="-clean-generated-blazeds-config-files">
<copy file="${templates.dir}/${services.config.template}"
tofile="${app.flex.dir}/${services.config.server.name}" >
<filterchain>
<replacetokens>
<token key="host" value="{server.name}"/>
<token key="port" value="{server.port}"/>
</replacetokens>
</filterchain>
</copy>
<copy file="${templates.dir}/${services.config.template}"
tofile="${app.flex.dir}/${services.config.client.name}" >
<filterchain>
<replacetokens>
<token key="host" value="${client.host}"/>
<token key="port" value="${client.port}"/>
</replacetokens>
</filterchain>
</copy>
</target>
<target name="compile"
depends="compileJavaBasedServer, compileFlexBasedClients"
description="Compile Java and Flex code." />
<target name="compileJavaBasedServer"
description="Compile Java source code used for server side.">
<javac srcdir="${src.dir}"
destdir="${classes.dir}"
classpathref="classpath" />
</target>
<target name="compileFlexBasedClients"
description="Compile the Flex clients"
depends="compileFlexBasedHelloWorldClient,
compileFlexBasedComplexObjectClient" />
<target name="compileFlexBasedHelloWorldClient"
description="Compile Flex Hello World client application into SWF file.">
<exec executable="mxmlc">
<arg line="-debug=${flex.debug}" />
<arg line="-context-root=${flex.context.root}" />
<arg line="-services=${flex.services}" />
<arg line="-warnings=${flex.warnings}" />
<arg line="-publisher=${flex.publisher}" />
<arg line="-title=${flex.title}" />
<arg line="-description=${flex.description}" />
<arg line="-verbose-stacktraces=${flex.verbose.stacktraces}" />
<arg line="-show-actionscript-warnings=${flex.actionscript.warnings}" />
<arg line="-output ${dist.dir}/${flex.app.helloworld.name.swf}" />
<arg line="-- ${flex.app.helloworld.name.source}" />
</exec>
</target>
<target name="compileFlexBasedComplexObjectClient"
description="Compile Flex Complex Object client application into SWF file.">
<exec executable="mxmlc">
<arg line="-debug=${flex.debug}" />
<arg line="-context-root=${flex.context.root}" />
<arg line="-services=${flex.services}" />
<arg line="-warnings=${flex.warnings}" />
<arg line="-publisher=${flex.publisher}" />
<arg line="-title=${flex.title}" />
<arg line="-description=${flex.description}" />
<arg line="-verbose-stacktraces=${flex.verbose.stacktraces}" />
<arg line="-show-actionscript-warnings=${flex.actionscript.warnings}" />
<arg line="-output ${dist.dir}/${flex.app.complexobject.name.swf}" />
<arg line="-- ${flex.app.complexobject.name.source}" />
</exec>
</target>
<target name="war"
description="Build server's web application archive (WAR)."
depends="-init,
-copy-respective-services-config-files,
compileJavaBasedServer">
<war webxml="${web.inf.dir}/web.xml"
destfile="${dist.dir}/${serverside.war}"
filesonly="true">
<zipfileset dir="${web.inf.dir}"
excludes="web.xml
flex/${services.config.client.name}"
prefix="WEB-INF" />
</war>
</target>
<target name="all" depends="war, compileFlexBasedClients"
description="Build it all; the default target." />
<target name="clean" description="Remove generated files."
depends="-clean-generated-blazeds-config-files">
<delete dir="${dist.dir}" />
<delete dir="${classes.dir}/dustin" />
</target>
<target name="-clean-generated-blazeds-config-files">
<delete file="${app.flex.dir}/${services.config.server.name}"
quiet="true" />
<delete file="${app.flex.dir}/${services.config.client.name}"
quiet="true"/>
</target>
<target name="javadoc" description="Generate Javadoc-based documentation">
<javadoc doctitle="Dustin's Spring BlazeDS Integration Example"
destdir="${javadoc.dir}"
sourcepath="${src.dir}"
classpathref="classpath"
private="true"
author="Dustin" />
</target>
</project>
In the above build.xml file, there are three properties defined near the top that would most likely need to be changed for a different deployment environment. They are client.host, client.port, and app.dir. The first two are used to appropriately build the client's version of services-config.xml to reference the host and port on which the server BlazeDS-powered application will be running. Because I am using GlassFish defaults for my server, I define these properties respectively to localhost and 8080. The third property, app.dir defines the directory into which I expanded the contents of the blazeds.war file for editing.
Targets of specific interest in the above build.xml file include the compileFlexBasedHelloWorldClient target for building the Flex client with the mxmlc compiler and the war target for building the WAR file to be deployed on the server.
When I build the WAR and the client SWF file (same name as its source MXML file but with an .swf extension rather than the .mxml extension), I can then deploy the WAR and run the SWF client. The deployment of the WAR file is done with whatever mechanism your web serve provides. The SWF client can easily be executed by clicking on it or typing its full name on the command line. The following two screen snapshots show the client running by first showing how it initially appears and then showing how it appears once a name has been entered into the name field.
Binding Java to ActionScript
The above example demonstrates the ability to remotely call Java on the server from MXML on the client via the RemoteObject and BlazeDS. However, the example up to this point has only used simple mappings (in this case Strings). It is more interesting to now move onto an example of binding a more complex objects. The good news is that it is all still pretty easy.
For this slightly more complex example, we will expand the HelloWorldRemotingServer class to feature a method that accepts a domain object that is neither a primitive, a boxed version of a primitive, or a String. The revised version of HelloWorldRemotingServer is shown next:
HelloWorldRemotingServer.java (Finished Version)
package dustin;
/**
* Simple "Hello World" example meant for use in BlazeDS remoting example.
* This is the server-side POJO that will be exposed to a Flex client via
* BlazeDS remoting.
*
* @author Dustin
*/
public class HelloWorldRemotingServer
{
/** No-arguments constructor. */
public HelloWorldRemotingServer() {}
/**
* Accept a String representing a name and return that name as part of a
* Hello message.
*
* @param nameToSayHelloTo Name to which Hello will be addressed.
* @return Hello address to provided name.
*/
public String processHello(final String nameToSayHelloTo)
{
return "Hello, " + nameToSayHelloTo + "!";
}
/**
* Accept a last name and a first name and return the concatendated name as
* part of a James Bond like introduction.
*
* @param firstName Provided first name of person.
* @param lastName Provided last name of person.
* @return The James Bond like introductory message.
*/
public String processName(final String firstName, final String lastName)
{
return "Your name is " + lastName + ". " + firstName + " " + lastName + ".";
}
/**
* Accept a Person and return that person's name as part of a James Bond like
* introduction.
*
* @param person Person whose name will be returned.
* @return The James Bond like introductory message.
*/
public String processName(final Person person)
{
return "Your name is " + person.getLastName() + ". "
+ person.getFirstName() + " " + person.getLastName() + "!";
}
}
One of the newly added methods is called processName(String,String). This wouldn't make a very exciting example because it still uses two separate Strings. The more interesting example will be binding a Flex client to the processName(Person) method that expects a Person instance. For our newly updated class to compile, we need to define a Person class in the same package. That is shown next:
Person.java
package dustin;
/**
* Encapsulates a person's information.
*
* @author Dustin
*/
public class Person
{
/** Last name of person. */
private String lastName;
/** First name of person. */
private String firstName;
/** No-arguments constructor. */
public Person() {}
/**
* Constructor accepting names for this person.
*
* @param newLastName Last name of the person.
* @param newFirstName First name of the person.
*/
public Person(final String newLastName,
final String newFirstName,
final int newAge)
{
this.lastName = newLastName;
this.firstName = newFirstName;
}
/**
* Provide person's first name.
*
* @return Person's first name.
*/
public String getFirstName()
{
return this.firstName;
}
/**
* Set/change the person's first name.
*
* @param newFirstName New first name for the person.
*/
public void setFirstName(final String newFirstName)
{
this.firstName = newFirstName;
}
/**
* Provide person's last name.
*
* @return Person's last name.
*/
public String getLastName()
{
return this.lastName;
}
/**
* Set/change person's last name.
*
* @param newLastName New last name for person.
*/
public void setLastName(final String newLastName)
{
this.lastName = newLastName;
}
/**
* String representation of me.
*
* @return My String representation.
*/
@Override
public String toString()
{
return this.firstName + " " + this.lastName;
}
}
There is nothing remarkable about the Person class and there is no sign of any association with ActionScript or Flex in this Java class. In fact, the Person class is downright boring.
For Strings, primitives, and object/boxed versions of primitives, BlazeDS can typically map these types to appropriate ActionScript types. Now that we've introduced the Person type, however, we need to instruct BlazeDS how to use this Java class on the Flex-based client side. This is easily done by simply creating a parallel Person class in ActionScript that explicitly associates itself with the Java version of Person. The code for the ActionScript version of Person is shown next.
Person.as
package dustin
{
[Bindable]
[RemoteClass(alias="dustin.Person")]
public class Person
{
/** First name of person. */
private var _firstName:String;
/** Last name of person. */
private var _lastName:String;
/**
* Constructor accepting names of this newly instantiated person.
* Because each parameter has a default of null, this can be used as a
* no-arguments constructor.
*
* @param newFirstName First name to be used for this person.
* @param newLastName Last name to be used for this person.
*/
public function Person(
newFirstName:String = null,
newLastName:String = null)
{
_firstName = newFirstName;
_lastName = newLastName;
}
/**
* WRITE (set/change) firstName property.
*
* @param newFirstName New first name.
*/
public function set firstName(newFirstName:String):void
{
_firstName = newFirstName;
}
/**
* READ firstName property.
*
* @return My first name.
*/
public function get firstName():String
{
return _firstName;
}
/**
* WRITE (set/change) lastName property.
*
* @param newLastName new last name.
*/
public function set lastName(newLastName:String):void
{
_lastName = newLastName;
}
/**
* READ lastName property.
*
* @return My last name.
*/
public function get lastName():String
{
return _lastName;
}
}
}
Arguably the most interesting point about the ActionScript version of Person is the use of RemoteClass metadata tag ([RemoteClass(alias="dustin.Person")]) to explicitly associate this ActionScript class with the Java class. By naming the property write/set and read/get methods to match those in the Java class, the remaining binding of ActionScript object to Java object is handled by BlazeDS.
The ActionScript Person.as file should be placed in a newly created subdirectory named dustin (for the "dustin" package) parallel to the WEB-INF directory. We now need to move onto building a new Flex client to use this new method on the server-side.
I want to make one final observation regarding the Person class in ActionScript. The code would have been even more concise if I had made the data members public. In that case, they could be accessed directly and the set and get methods would not be necessary. Many of the online examples take this approach.
A New Flex Client (Complex Object Client)
The code for ComplexObjectRemotingClient.mxml is shown next. It should be placed in the same location as our previous Flex client (in expanded directory and parallel to the WEB-INF subdirectory).
ComplexObjectRemotingClient.mxml
<?xml version="1.0" encoding="UTF-8" ?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
width="1100" height="700">
<mx:Script>
import dustin.Person;
/**
* Prepare provided name information and send to server.
*
* @param firstName First name of person.
* @param lastName Last name of person.
*/
public function processAndSubmitName(firstName:String, lastName:String):void
{
const person:Person = new Person(firstName, lastName);
remoteObject.processName(person);
}
</mx:Script>
<!-- Associate client with BlazeDS destination via RemoteObject. -->
<mx:RemoteObject id="remoteObject" destination="HelloWorld" />
<mx:Panel id="mainPanel" title="BlazeDS Remoting Example - Complex Object Mapping">
<mx:Form>
<mx:FormItem label="Your First Name">
<mx:TextInput id="firstNameInput" />
</mx:FormItem>
<mx:FormItem label="Your Last Name">
<mx:TextInput id="lastNameInput" />
</mx:FormItem>
<mx:FormItem>
<mx:Button label="Submit Name!"
click="processAndSubmitName(firstNameInput.text, lastNameInput.text);" />
</mx:FormItem>
<mx:FormItem label="Server's Response">
<mx:Label text="{remoteObject.processName.lastResult}" />
</mx:FormItem>
</mx:Form>
</mx:Panel>
</mx:Application>
The new Flex client uses a little ActionScript to prepare the call to the server and instantiates one of our newly written Person objects in the process. The build.xml file shown previously already included the target for building this new client ("compileFlexBasedComplexObjectClient"). Note that the Java code also needs to be rebuilt and the WAR reassembled and redeployed to the web server because of the addition of methods to the server class.
The following two screen snapshots show the initial and final state of the new client when it is executed as the Hello World client was earlier.
As the above output shows, the method accepting a Person object (note the exclamation point in the returned message) has been contacted on the Java side from a remote Flex client.
Pictorial Overview of Directory/File Structure
One of the things that can be a little tricky about using BlazeDS or the mxmlc compiler if you have very little experience using them is the placement of files. Fortunately, most of this was already setup correctly by the blazeds.war file that we expanded. However, I did add some directories and files. In an effort to make it more clear where these directories and files are in relation to one another, I include the next screen snapshot of my final directory structure. I tried in the text above to describe where within these various directories each file should go.
The image above shows where to place MXML source files, ActionScript source files, and Java source files for the build.xml file described above to work properly. I did not provide descriptions of the nbproject subdirectory (used for NetBeans specifically), the images subdirectory (used to store the screen snapshots shown in this blog posting), or the WEB-INF subdirectory (it was provided by the expanding of blazeds.war). The only thing to note here is that I added the Java source code files (but not ActionScript source code files) into the src directory under WEB-INF.
Conclusion
This has turned out to be a rather lengthy blog entry. However, this is to be expected considering that I've intentionally tried to make this a complete and thorough introduction to BlazeDS/Java remoting and because I have included the code directly within the blog posting rather than as a separate attachment. Also, I've tried to avoid use of anything specific to FlexBuilder so that anyone with any text editor should be able to use my examples.
Despite the length of this blog entry, use of the BlazeDS remoting is pretty straightforward once you have tried it a couple times. It does get more complex when security constraints and other details are added back in, but one can choose how much one implements at each step and the examples above are nice for confirming that client-to-server communication is working properly.
Additional Resources
]]>The first thing I noticed was contact Name being a single field (no separate field for First, Second, Middle names). I've never seen this before, so I consider it an innovation. This makes it impossible for any application to sort contacts by the second name. Also it makes life a lot harder for ones who would want to import, export or synchronize contacts with any other application (except for Gmail which also has names as a single field).
]]>The first thing I noticed was contact Name being a single field (no separate field for First, Second, Middle names). I've never seen this before, so I consider it an innovation. This makes it impossible for any application to sort contacts by the second name. Also it makes life a lot harder for ones who would want to import, export or synchronize contacts with any other application (except for Gmail which also has names as a single field).
Second, Android defines a number of predefined phone types. Unfortunately these types can't be combined, so there's no chance to define a mobile work phone for your contact. Of course there is that 'other' type, but still it will add another task of mapping text-to-normal types to any contacts application.
]]>Without further preamble, here's what I said for 2008:
]]>Without further preamble, here's what I said for 2008:
Now, for the 2009 predictions. The last set was a little verbose, so let me see if
I can trim the list down a little and keep it short and sweet:
Well, so much for brief or short. See you all again next year....
Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services.
1-day or multi-day workshops available. Contact
me for details.
Continuing to explore the notion that JavaFX may well be Swing 2.0, I came across a couple of interesting how-to articles upon my return from my holiday journeys. ]]>
Continuing to explore the notion that JavaFX may well be Swing 2.0, I came across a couple of interesting how-to articles upon my return from my holiday journeys. The Lobo Project Blog explores the process of actually mingling JavaFX and Swing, putting JavaFX video into a Swing application, declaring the procedure "technically doable." The ability to do this sort of thing is crucial if the transition between UI technologies is to be at all smooth. Also of note is a piece in which a developer animates Mario in JavaFX, in which he grumbles "why the hell do they call this Java?" but is ultimately kind of impressed.
Speaking of which: for all those who feared that JavaFX had sucked all the oxygen away from S
