Sencha Touch has a nice component called DataView that can dynamically render HTML based on a collection of data. With a DataView, you have the ability to specify a template ("itemTpl") which is a chunk of HTML rendered for each element in the Store. Unfortunately the framework only supports declaring this in Javascript, so you are left with some pretty nasty syntax:

Fortunately I was able to hack together a quick and dirty workaround for this based off Hogan.js, Twitter's Mustache-compatible HTML templating system. First I wrote a simple HTML template named myTemplate.mustache:

Then I used Hogan's "hulk" executable to compile the template to a Javascript file. If you have multiple templates, hulk will merge them into a single file. The template will be available in Hogan via its name, in this case "myTemplate". The output of the file isn't important nor is it very readable, so we'll skip that part.

Then I edited my main HTML file to include the Hogan library and my compiled templates:

Next I wrote a subclass of Ext's XTemplate to serve as an adapter between their template API and Hogan's. I haven't tested this very thoroughly yet; there are likely a bunch of other methods that need overriding to get this solid:

And then updated the original code snippet to use the following:

and presto, it just works :)

Adapting this for Mustache.js should be straightforward provided they expose a similar API with a synchronous render() method.

I've been a Hibernate user since 2005 and have used JPA + Hibernate Annotations since 2006 when 1.0 of the JPA spec was released.  Unlike many others I did not immediately jump to the JPA APIs (EntityManager, PersistenceContext, etc) and continued using the native Hibernate APIs (Session, SessionFactory, etc).  JPA was still missing quite a few useful features such as a Criteria API and I wasn't ready to give that up just to use a "standard API."  When JPA 2.0 was released in late 2009 the feature sets of the two products were generally comparable making the decision a little tougher.  But since I've never really bought into the "vendor portability" promise of JPA, I continued happily on with native Hibernate APIs to much success.

Over the past month or two, I've come to the decision it's time to fully embrace JPA.

JPA has grown beyond its original purpose as an object-relational mapping framework into a more generic persistence API.  NoSQL / data grid solutions have become incredibly important and popular over the past few years.  Several JPA-based implemenations for these solutions have already been developed, including Google App Engine / Big Table and Hibernate's own Object/Grid Mapper (OGM).  I started to experiment with GAE about a month ago and was surprised how quickly I could be productive with its JPA implementation.  While JPA likely isn't the best fit for the diverse range of NoSQL implementations out there, the ease of use for JPA developers is undeniable.

While industry trends are important, I've finally found the killer app for JPA: the Spring Data JPA project.  At its core, SDJ is about generating JPQL at runtime so you don't have to write tedious queries.  Some of the awesome features include:

• Out-of-the-box support for data pagination and sorting.
• Query creation from method names.  Creating a method signature of findByEmailAddressAndLastName(String emailAddress, String lastName) creating a backing query that does exactly what you'd expect.
• Specification API to define and combine predicates in a manner similar to the Criteria API.

Check out the reference documentation for Spring Data JPA.  The project just dropped its first 1.0 release candidate.  I'm excited to see what they'll come up with in future releases.

1. Head over to http://github.com and create an account.
2. Create a new repository next.  Please remember that unless you pay for a github account, any repository you create will be PUBLIC.  After creating the project, keep the page open so you can refer to "Next Steps" later.
3. Download and install msysgit from http://code.google.com/p/msysgit/downloads/list; look for a file in form of Git-version-date.exe with the "Featured"tag.  Use the installer's defaults.
4. Launch the "Git Bash" shell and setup your identity:
   • git config --global user.name "Your Name"
   • git config --global user.email "username@email.com"
5. Next create a SSH key pair for yourself using the following command:
   
   • ssh-keygen -C "username@email.com" -t rsa
6. The file will be created at c:\Users\username\.ssh\id_rsa.pub; copy the contents of this file and return to github.  Click on "Account Settings" and then "SSH Public Keys."  Add your key here by pasting the content into the provided text box.  Your local git installation and github accounts are now properly linked on this machine.
7. Refer back to the "Next Steps" section mentioned earlier.  Open "Git Bash" and follow the steps to create a new project and push it to GitHub.  Your project is now ready.  You can write some useful code!

If you prefer to avoid the command line for Git operations, launch the "Git GUI" and follow these steps when you want to make a commit and push:

1. Press the "Rescan" button to see your changes
2. Select the files you wish to commit from the list in the upper-left and choose "Commit" -> "Stage To Commit"
3. Enter a commit message at the bottom of the screen and press "Commit."  The changes are now saved in the local repository.
4. Click the "Push" button and examine the popup window.  Note that the "Destination Repository" is remote and named "origin"; this refers to the repo at github.  Click "Push" again to commit.
5. Your changes are now committed to github. You can verify this by browsing to the project home page.

I hope others find this tutorial useful.  A more detailed tutorial can be found here: http://kylecordes.com/2008/git-windows-go

• HF installs as a Flex Builder plugin which will delegate compilation to a separate OS-level process running either locally or on a remote machine.
• The compiler daemon process is persistent, meaning it continues to run across multiple builds.  This allows the Java virtual machine to optimize compilation execution each time that a build is run.  The JVM is *very* good at this.
• The Flex Builder plugin watches for file modifications and immediately pushes these changes to the compiler daemon process.  The daemon has an internal representation of the project file system and will launch internal incremental builds automatically when files change.

So, how fast is it really?  I benchmarked HFCD on two different machines.  I used the Flex 3.4.1 SDK for compilation and ran clean builds of my application each time.  My test project was a real-world Flex app currently in development consisting of about 15 modules and 350 MXML files and ActionScript classes.

2006 Intel Macbook Pro, Core Duo 2.16 GHz, 2 GB RAM, 7200 RPM HD, Leopard 10.5, 32-bit Java 5

• Stock: 135 seconds average
• HFCD (1st run): 155 seconds
• HFCD (successive): 75 seconds average

Intel Core i7 920 @ 3.2 GHz, HT off, 12 GB RAM, dual 7200 RPM HD's in RAID 0, Vista 64-bit, 32-bit Java 6

• Stock: 65 seconds average
• HFCD (1st run): 52 seconds
• HCFD (successive): 21 seconds average (!!!)

As indicated in the documentation, the performance of HFCD increases dramatically after the first build due to the numerous optimizations in HellFire and the JVM itself.  The Macbook was nearly 2x faster while the Windows box was just over 3x faster.  Very impressive and a real time saver!

I hope to post some new benchmarks soon.  I need to do some more research to get HFCD running on a 64-bit JVM as that isn't supported out of the box.  Also I'd like to configure my Macbook to delegate the compilation to my Windows box, especially to ascertain what kind impact the network topology has on build performance.

Launch the Eclipse plugin installer dialog and select "Subversive SVN Team Provider."

After installation, restart the workbench.  Then open the "SVN Repository Explorer" perspective.  The following dialog will be displayed automatically:

Choose a SVN connector (I typically use the latest SVNKit), click Finish, restart the workbench one more time and you're ready to go.  Hopefully the licensing issues will be resolved eventually so that Eclipse can ship with the Subversive SVN Team Provider by default but at least in the mean time the installation's been made pretty painless.

One common use case is to persist an object with HibernateTemplate and then verify the data was inserted correctly using JdbcTemplate. Usually Hibernate will not flush the data out to the DB until the transaction commits, meaning that the query done by JdbcTemplate won't be able to see the new data. This one isn't hard to work around: just call HibernateTemplate.flush() to execute the SQL on demand so that subsequent calls to JdbcTemplate will see the new data.

The second use case is a lot tricker: let's say you want to create some data with JdbcTemplate and then make sure that calls to HibernateTemplate will see that data. By default this will not work. You can actually insert with JdbcTemplate, make a call to load the data with HibernateTemplate (it won't find it) and then make another call to JdbcTemplate which will show that the data is there. The problem is that since JdbcTemplate is injected with a DataSource it doesn't really have any knowledge of the transactions from HibernateTransactionManager; thus operations from the two templates are isolated from one another.

Fortunately Spring offers a solution in the TransactionAwareDataSourceProxy class. Just like the name imples, this class acts as a wrapper for an existing DataSource so that all collaborators will participate in Spring-managed transactions. Configuration of this class is trivial:

<bean id="dataSource" class="org.springframework.jdbc.datasource.TransactionAwareDataSourceProxy">
<property name="targetDataSource">
<bean class="com.mchange.v2.c3p0.ComboPooledDataSource" destroy-method="close">
...
</bean>
</property>
</bean>

Note: you may or may not want to define the "real" DataSource as an inner bean that doesn't get registered in the ApplicationContext itself. If you are autowiring your DataSource purely by type, having two different implementations of DataSource will be a problem for you. Workarounds include autowiring using @Qualifier or using @Resource to inject the bean by name.

I was in the midst of writing some JUnit 4.x tests using SpringJUnit4ClassRunner and the @TransactionalConfiguration / @Transactional annotations for automatic rollback of @Test methods. I wanted to do some manipulation of the database prior to my tests using a separate method annotated with @Before. What I was reminded of very quickly is that Spring's class runner will not apply a transactional aspect to this method since it's not actually a @Test. This isn't a problem if you are using HibernateTemplate / HibernateCallback, since it ultimately has a reference back to your TransactionManager to handle transactions. But if you want to work with the raw Hibernate APIs it can be problematic.

There are two things to keep in mind: (1) SessionFactory.getCurrentSession() will only work if you have configured the SessionFactory appropriately, and (2) depending on the configuration, you may have to manage Transactions explicitly. The configuration property in question is "hibernate.current_session_context_class" and it is commonly configured one of three different ways:

1. Omitted the property from the configuration

Hibernate will throw an exception on calls to getCurrentSession() complaining that there is no CurrentSessionContext configured.

2. Configured with 'thread'

hibernate.current_session_context_class=thread

Hibernate will bind the Session returned from getCurrentSession() to the current thread and you must manage transactions programmatically. Generally all that's required is to call Session.beginTransaction(). You can also invoke Transaction.commit() or rollback() if you wish.

3. Configured with SpringSessionContext

hibernate.current_session_context_class=org.springframework.orm.hibernate3.SpringSessionContext

Hibernate will assume it is executing inside of a Spring transactional context (i.e. through a Spring transactional aspect) and Spring will now manage your transaction for you. However if you call getCurrentSession() outside of such a context, Hibernate will throw an exception complaining that no Session is bound to the thread.

What does all this mean?

1. Use SpringSessionContext if your operations will be done through classes that are invoked through a Spring-managed transactional context or if you can introduce HibernateTemplate and/or HibernateCallback wherever you need it.
2. Use "thread" if you need to raw with the raw Hibernate Session/Transaction API and remember that you'll need to manage transactions programmatically.

Sound interesting? Learn more at the Terracotta web site.

This is an excellent book. The prose is well-written and engaging and the book flows very well from section to section. There are massive amounts of Java code and configuration such that you very rarely have to picture anything in your mind, you can just read it there on the page. There are helpful diagrams where appropriate. It’s unlikely that a reader with a good understanding of Java will become confused at any point during the book. It’s informative and provides some excellent examples of real world use, including especially chapters on integration with things like like Spring, Hibernate, session replication and more. There is also an extensive chapter on using Terracotta to create a Master/Worker compute grid. If you’re looking to learn more about Terracotta I really can’t recommend this book enough: it helped fill so many gaps that I had after skimming some of the documentation and reading a few of the white papers.

The only real negative is that the book is slow to get started. The first two chapters (~40 pages) serve as an introduction and history to the technology respectively but taken together, it’s just a very lengthy introduction that rehashes a lot of the same concepts. Maybe this was tedious for me given that I’d already read a lot of documentation on Terracotta but it just seemed like the intro could have been a bit shorter.

I’ll now run down the other chapters in the book and detail some that I found particularly interesting.

Chapter 3 is a quick jump into the framework and some tooling while Chapter 4 gets into the nitty-gritty details of POJO clustering. This is important to read to understand how Terracotta does what it does. Chapter 5 talks about how to do caching and this is where you start to understand the real world problems that can be solved using the tool. Your database will thank you!

Chapter 6 is where it gets really interesting. Here you will learn how to use Terracotta as a 2nd-level cache provider for Hibernate to significantly boost performance over using something like Ehcache . More startling than that is a proposed architecture where the notion of POJO clustering is used to effectively put data structures that hold detached objects (those not attached to an active Hibernate Session). You are shown how to change application code that uses the Hibernate API in a “typical” fashion to achieve performance increases measured in orders of magnitude. This is truly an eye-opener.

Chapter 7 shows you how to cluster HTTP Sessions and how you can be freed from some of the annoying restrictions of the Servlet container Session API, such as implementing Serializable and religiously using setAttribute(). ; This is the sort of thing you can plug into an existing application very quickly and realize enormous scalability gains.

Chapter 8 is about clustering Spring beans. Spring and Terracotta follow a very similar philosophy in that they are non-invasive frameworks. As such, they compliment each other very nicely. This chapter shows how easy it is to cluster Spring beans: even easier perhaps than clustering POJOs as in Chapter 4. At this point, if you are a user of Spring and Hibernate, you’re starting to see how easy it can be to achieve seriously scalability and performance improvements.

Chapter 9 talks about Terracotta Integration Modules which is a sort of package that provides additional features to the Terracotta core: this is how integration with Hibernate and Spring are achieved. Chapter 10 gives an extended treatment of thread coordination, showing how well-written multithreaded code can be used with Terracotta to achieve thread coordination across multiple JVMs. Chapter 11 takes this further to detail the Master/Worker pattern for computing grids. Chapter 12 rounds things out by showing the visualization tools that can be used to monitor and debug an app using Terracotta.

As I said before, this is a great book. If you’re interesting in scaling out enterprise Java applications, you owe it to yourself to check out Terracotta and this book.

Can't use static constants as default values for function parameters

Example:

public class PropertyType {
public static const LISTING_RESIDENTIAL : String = "ListingResidential";
...
}

public function createSearch(propertyType : String = PropertyType.LISTING_RESIDENTIAL) : void {
...
}

Results in this compiler error:

1047: Parameter initializer unknown or is not a compile-time constant.

Of course the bigger complaint here might be that there are no enumerated types in ActionScript... but that's probably asking too much. :)

Fortunately Spring Security provides solutions to many common problems in Java EE space, including features like container portability, a flexible authentication provider model, authorization of service method invocation via AOP and even some very cool ACL support to enforce granular security at the domain object level. Integrating Spring Security with Blaze DS isn't as hard as you think either: I was able to bang out a quick proof of concept over a weekend.

The config for Spring Security 2 is quite straightforward with the new XML namespace support in your Spring config files:

<security:http>
<security:form-login>
</security:form-login>

This is basically a very stripped-down configuration since things like RememberMeServices (using cookies) don't usually apply in a Flex-based RIA. You can also throw in a very simple AuthenticationProvider like this one from the SS2 docs:

<security:authentication-provider>
<security:user-service>
<security:user name="jimi" password="jimispassword" authorities="ROLE_USER, ROLE_ADMIN"/>
<security:user name="bob" password="bobspassword" authorities="ROLE_USER"/>
</security:user-service>
</security:authentication-provider>

There are two items you need to add to your web.xml to bootstrap SS2 in a Servlet container:

<filter>
<filter-name>springSecurityFilterChain</filter-name>
<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>

<filter>
<filter-name>securityContextAwareFilter</filter-name>
<filter-class>org.springframework.security.wrapper.SecurityContextHolderAwareRequestFilter</filter-class>
</filter>

<filter-mapping>
<filter-name>springSecurityFilterChain</filter-name>
<url-pattern>/*</filter-mapping>
</filter-mapping>

<filter-mapping>
<filter-name>securityContextAwareFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

The first filter is standard part of any Spring Security configuration. The "SecurityContextHolderAwareRequestFilter" adapts SS2 to the Servlet environment so that calls like getPrincipal() and isUserInRole() behave as expected. This really comes in handy when you have other code in your projects that assumes a "standard" Java security setup.

Now we need a little config in the Blaze services-config.xml file:

<security>
<login-command class="net.histos.util.spring.SpringSecurityLoginCommand" server="Tomcat"/>
<security-constraint id="valid-user">
<auth-method>Custom</auth-method>
<roles>
<role>ROLE_USER</role>
</roles>
</security-constraint>
</security>

Blaze DS seems to require that a "server" attribute be specified for any LoginCommand even though this isn't really used in our implementation. The security-constraint isn't necessary if you are going to use SS2's service method invocation authorization support. However if your security requirements are more straightforward you can do role/destination based restrictions here. Then simply add this element to the appropriate destinations:

<security>
<security-constraint ref="valid-user"/>
</security>

The last part is some Java code. If you extend AppServerCommand you get a default impl for this method:

protected boolean doAuthorization(Principal principal, List roles, HttpServletRequest request) throws SecurityException

This method makes use of isUserInRole(), so by adding the servlet filter referred to above, this logic can work without any modification required. This leaves only two methods in your LoginCommand impl:

public Principal doAuthentication(String username, Object credentials) {
log.debug("doAuthentication");
// get the ProviderManager from app context
Map<string, providermanager=""> map = getContext().getBeansOfType(ProviderManager.class);
if (map.size() != 1)
throw new RuntimeException("Spring ApplicationContext must contain exactly one ProviderManager bean");
ProviderManager provider = map.get( map.keySet().iterator().next() );
// authenticate
String password = extractPassword(credentials);
Authentication auth = provider.authenticate( new UsernamePasswordAuthenticationToken(username, password) );
SecurityContextHolder.getContext().setAuthentication(auth);
return auth;
}

public boolean logout(Principal principal) {
log.debug("logout");
SecurityContextHolder.getContext().setAuthentication(null);
return true;
}

Those are the basics! As I said, this a proof of concept that I haven't had time to test extensively yet but it should get you started! One other note: I noticed while testing the Flex side that calling login() or logout() on a RemoteObject without calling a "regular" service method would result an error; apparently the ChannelSet hadn't been defined yet. I did a little digging and found that apparently you're supposed to call login() or logout() on the underlying ChannelSet itself. I wrote a very simple ChannelSet implementation that can be easily instantiated in MXML and bound as the channelSet property for your RemoteObjects:

package net.histos.flex.util
{
import mx.messaging.ChannelSet;
import mx.messaging.channels.AMFChannel;

public class SimpleChannelSet extends ChannelSet
{
public function set url(channelUrl : String) : void {
addChannel(new AMFChannel("defaultChannel", channelUrl));
}
}
}

<util:SimpleChannelSet id="channelSet" url="http://localhost:8080/testapp/messagebroker/amf"/>

Then simply invoke login() and logout() on the ChannelSet itself and you should have no problems.