Sunday, October 28, 2012

My Little Take on Backend Development

Update 29-10-2012:
I found this blog post more comprehensively in defense of Java EE 6.
Original post:
This comes from someone who only just recently read about JTA and JTS. Take this with a grain of salt, so to speak.

I have some experience using the Spring Framework, mainly the Spring MVC sometime about 2years ago, and some again just recently (as indicated in my previous post).  Back then, it was first a multifinancing application, second a message broadcasting engine, sort of.  Neither of which I created from the ground up.  I was merely adding features and so on.  I couldn't compare it against the Java EE 6 at that time, lack of understanding of their internals and so on.

The message broadcasting engine had to be improved so that it could support more load.  There were topics such as clustering, high availability, parallelism, concurrency, etc.  I think it was then that I came across the JMS and some asynchronous processing features provided by the EJB 3.  That was to be my gateway to Java EE 6.   Afterwards it was a haphazard series of choice to learn the actor model, CSP, Scala, Erlang, Haskell, NoSQL, etc.

So I wonder what was it again, Spring Framework's winning points.  Their documentation is among the best.  Their framework itself is rock solid, for what it is.  What it is, really, is a little confusing, though.  It appears to be sort of an alternative to the Java EE stack, but heavily relies on it.  It manages the object lifecycles.  Java EE does that as well, manage object lifecycles.  Two things manage your object lifecycles.  Obviously you can run Spring Framework on a standard servlet container, but I see everywhere that it is recommended that you use, say, the JTA provided by the container when available.  It would be unavoidable that both containers will manage the object lifecycles if you used CMT alongside Spring.  And how is it that one could share a bean across deployments in Spring?  Even if you could, I think using Spring remoting, your object lifecycles management would be more complicated because it would be a communication between two unrelated containers.  It looks to me that the EJB specification is superior in this regard, with its local and remote beans concept and tighter integration with JTA and the rest of the Java EE specification.

Anyway, honestly I'm not a big fan of dependency injection, Spring or CDI.  It's a little too much magic for me.  Language level singleton object construction available in Scala and programmatic lookup and vending are easier to work with.

Friday, October 26, 2012

Integrating Spring Framework, Jetty, and JBoss Narayana

Update 29-10-2012:
This does not work. I posted this only after testing rollback in a transaction, and it worked. However, I couldn't get it to work as Hibernate's transaction manager alongside Spring; e.g. update operations miss the transaction scope. I tried many setup variations. If someone manages to get this working, it'd be great if you shared. For the time being I'm falling back to CMT provided by JBoss AS.
Original post:
I had to browse through quite many websites and tested some adaptations to eventually get this to work. Shame on me, it's not all that complex how it ends up.
Oh, and my syntax highlighter does this XML tag uppercase thing that is so uncalled for.
My stack goes as following:
  • Spring Framework 3.1.2.RELEASE
  • JBoss Narayana 4.17.1.Final
  • Apache Derby (network) DB 10.9.1.0
  • Jetty 8.1.7.v20120910
The Spring Framework of this version doesn't even need persistence.xml to be present, so configuration, linking data source, persistence unit, and transaction manager, in a single Spring context XML is possible and makes more sense.  The JBoss Narayana JTA guide shows that to incorporate JDBC connections within itself:
  1. Use the com.arjuna.ats.jdbc.TransactionalDriver that comes with the Narayana library
  2. Wrap a javax.sql.XADataSource by creating an implementation class of com.arjuna.ats.internal.jdbc.DynamicClass and bind the data source to a JNDI (programmatically).
    The TransactionalDriver will use the DynamicClass as its data source provider.
I stumbled at binding.  Admittedly I'm not quite sure how it works on Jetty.  I managed to make it work by, firstly, bind the XADataSource to JNDI using Jetty's context configuration. Here's how it looks like in my jetty-env.xml.

 
 jdbc/dbxa
 
  
   mydb
   username
   password
  
 

Secondly, I let my implementation of DynamicClass, in its concrete getDataSource(dbName:String):XADataSource method to perform JNDI lookup, cast it to XADataSource, and return it. Simple as that. Why did I even bother struggling with Spring JNDI binding and JMX and whatever else. Here's how it looks like:
public XADataSource getDataSource(String dbName, boolean create)
  throws SQLException {
 try {
  InitialContext ic = new InitialContext();
  ClientXADataSource40 xa = (ClientXADataSource40) ic
    .lookup("jdbc/dbxa");
  return xa;
 } catch (NamingException e) {
  throw new SQLException(null, e);
 }
}
Afterwards, I bind things together in the Spring context XML.
Since I already defined the credentials in the Jetty context configuration, I don't need to repeat it here. The driver properties bean is just:

 
  
   my.implementation.of.DynamicClass
  
 

Next is the data source bean. I have to prepend the JNDI with jdbc:arjuna:, that's just how it works.

 
  com.arjuna.ats.jdbc.TransactionalDriver
 
 
 
  
 

And then the EntityManagerFactory bean, which also replaces persistence.xml. I happen to use Hibernate, so that's HibernateJpaVendorAdapter for me.

 
 
 
 
  
   
   
   
  
 
 
 
  
 

I also need to define the Narayana transaction manager and user transaction implementation beans as well as the Spring transaction manager bean itself.




 
  
 
 
  
 

And lastly if you like annotations:
As a bonus, you can also set where Narayana will store its objects, default timeout, etc by defining this factory bean.

 
 
 
  
   60
   .\arjuna
   .\arjuna
  
 

That's all. You can add a logger for com.arjuna.ats and set it to trace or fine to see whether it works. I don't suppose I need to show an example of how transactional annotation is used right. And there's that org.springframework.transaction.support.TransactionTemplate and org.springframework.transaction.interceptor.TransactionAspectSupport to allow manual, programmatic transaction control.

Saturday, October 20, 2012

Lift Web Framework is Easy

It's ubiquituously said that the Lift web framework has a steep learning curve.  Hard to believe when

<div class="lift:surround?with=default;at=content" id="real_content">
 <h1>Welcome to your project!</h1>
 <lift:Hello.world />  
</div>
object Hello extends DispatchSnippet {
 val dispatch: DispatchIt = {
  case name => render(name) _
 }
 def render(name: String)(ignore: NodeSeq): NodeSeq = Text("Hello, " + name)
}
LiftRules.snippetDispatch.append {
 case "Hello" => id.openfx.openshop.snippet.Hello
}
simply wraps the page with the template 'default.html' and makes a snippet Hello.world lookup.

Everything in Lift is easy and transparent, I daresay. Most things can be reasoned as you write code, instead of having to read its specification. I can't quite describe it precisely, but I'll give it a shot anyway. Because Scala allows "mix in" of traits, there is, CMIIW, no hidden container-managed proxy code is needed. Let's compare this with CDI used in the JSF framework. To cater to different scopes, a CDI bean can be annotated with @RequestScoped, @SessionScoped, @ConversationScoped, etc. How does it look like when constructed? Honestly I don't know. I only know how it should work thanks to the CDI spec's documentation. But I think the container would have to create a specific proxy for each bean depending on its scope, and inject its proxy dependencies and so on. The proxy might also be different when you add @Stateful to, say, a @ConversationScoped bean.

On the other hand, in Lift, it's much simpler. Snippets are normal methods registered via the LiftRules object during boot. Request and session states are just plain objects extending either RequestVar or SessionVar, used directly by snippets. The separation between controller logic and session/request data is clear here. You know what's happening to your stuff by checking out what's inside what you're extending.