Andrew Powell

Spring has been, is, and will continue to be the easiest way to deploy enterprise class services with your Java applications.  There is a common pattern to the way Spring lets you expose your beans as services.  What this means is that the methodology for exporting a bean as a Hessian service, a Burlap service, a WebService, or now, an AMF Service (via BlazeDS) is consistent.  This consistency is what BlazeDS needed to be accepted into the Spring world.

Until the release of the Spring / BlazeDS integration by Spring Source, Spring has always been a bit of an interloper when it comes to BlazeDS.  Sure, Jeff Vroom's SpringFactory has served many of us well for a long time, but it was always something extra that had to be added on to the BlazeDS configuration.   To make it work, the services-config.xml file had to be modified and you had to specify special properties within the remoting destinations of remoting-config.xml.  It was a lot of steps to make something that makes things simple work with BlazeDS. 

Using the Spring/BlazeDS integration, it is no longer necessary to touch anything in the services-config.xml (unless you're changing the channels) or the remoting-config.xml files.  It just works out of the box by exporting your spring beans just as you would for any other remote services.  This consistent methodology will make it easier for teams to choose to use BlazeDS, and in turn, Flex for projects.   It means that teams will get the benefit of AMF with, possibly, no refactoring of the service layer.  All one would need to do is generate the AS classes to match the resulting datatypes (XDoclet can help a ton here) and you're done with the middle tier.  This allows for more development time to be focused on the Flex layer instead of being mired in getting the middle tier setup.  

By becoming more like other remoting methodologies in Spring, it appears that AMF and BlazeDS are ready to become prime-time players.

IntelliJ IDEA, the most kick-ass Java IDE available, is now out and better than ever.  The main thing about 7.0.4 is that it now has great support for Ruby/JRuby.  This means that, essentially, IntelliJ is a viable Ruby IDE now, as well as a Java IDE.  It's also got some support for Flex, but it's not quite ready for prime time yet, IMO.

 

What's new in 7.0.4

I updated my bookshelf page the other day.  I added 10 more books which, as an RIA developer and consultant, I find very useful.  Click through and take a look, then buy from Amazon, or your favorite book store.

 

My Bookshelf

I get asked a lot:  "What is the best book for learning 'x'?".  Well, I decided that I would post my own bookshelf, a listing of all the books I personally own (tech related).  You can browse through the listing, and, if you like, purchase the book from Amazon.

My Bookshelf

By now, unless you've been under a rock, you know what ANT (another neat tool) can do for you as far as build files go. If you haven't then let me sum it up for you: With ANT, you can test, build, and deploy your applications. I was in need of a tool for my ANT builds that did a SVN update to grab the latest source before building. A little google goes a long way. I came upon the Subclipse site. Subclipse is a powerful SVN plugin for Eclipse. I use it al the time and know it well. After a bit of digging on their site, I came upon something I had not noticed before on their site: SvnAnt. What this nifty little task will allow you to do is checkout, commit, update, and any other SVN action right from your ANT build files. So, how do you use SvnAnt? Well first, after you download it, make sure to put the required jars in ANT's classpath. You also need to have the "svn" command available from the command line. After you have those requirements met, you configure your ANT build file like this: build.xml: <?xml version="1.0"?>
<!-- Sample build file used to retrieve svnant's sources -->
<project name="svn-test" basedir="." default="checkoutThis">

<!-- all properties are in build.properties -->
<property file="build.properties" />

<!-- path to the svnant libraries. Usually they will be located in ANT_HOME/lib -->
<path id="svnant.classpath">
<fileset dir="${lib.dir}">
<include name="**/*.jar"/>
</fileset>
</path>

<!-- load the svn task -->
<typedef resource="org/tigris/subversion/svnant/svnantlib.xml" classpathref="svnant.classpath" />

<target name="clean">
<delete dir="src_latest"/>
<delete dir="src_${svnant.version}"/>
</target>

<target name="checkoutLatest">
<svn username="${svnant.repository.user}" password="${svnant.repository.passwd}">
<checkout url="${svnant.latest.url}" revision="HEAD" destPath="src_latest" />
</svn>
</target>

<target name="checkoutThis">
<svn username="${svnant.repository.user}" password="${svnant.repository.passwd}">
<checkout url="${svnant.this.url}" revision="HEAD" destPath="src_${svnant.version}" />
</svn>
</target>

</project> build.properties: # -----------------------------------------------------------------------------
# build.properties
# This file is referenced by the sample build.xml file.
# -----------------------------------------------------------------------------

svnant.version=1.1.0-RC2

# -----------------------------------------------------------------------------
# all jar needed
# -----------------------------------------------------------------------------
lib.dir=lib

svnant.latest.url=http://subclipse.tigris.org/svn/subclipse/trunk/svnant/
svnant.this.url=http://subclipse.tigris.org/svn/subclipse/tags/svnant/${svnant.version}/

svnant.repository.user=guest
svnant.repository.passwd="" Happy building!