Seam Paradox: For full zero turn around avoid JPA?

[luxspes]

I guess the title of this post says it all: Seam Paradox: For full zero turn around avoid JPA?
AFAIK Seam components support zero turnaround, but @Entity do not... so the paradox is that
if I use plain JDBC (or something else that can be reloaded) then Seam has full zero turnround, as if I were using
JavaRebel but for free...
But JPA is the recommended way to do persistence with Seam...
Paradoxical no? (Or I am mistaken?)

[blabno]

What does it mean zero turnaround ?

[asookazian]

http://www.zeroturnaround.com/

he's referring to incremental hot deployment via the special Seam classloader:

But if you really want a fast edit/compile/test cycle, Seam supports incremental redeployment
of JavaBean components. To make use of this functionality, you must deploy the JavaBean
components into the WEB-INF/dev directory, so that they will be loaded by a special Seam
classloader, instead of by the WAR or EAR classloader.
You need to be aware of the following limitations:
• the components must be JavaBean components, they cannot be EJB3 beans (we are working
on fixing this limitation)
• entities can never be hot-deployed
• components deployed via components.xml may not be hot-deployed
• the hot-deployable components will not be visible to any classes deployed outside of WEB-INF/
dev
• Seam debug mode must be enabled and jboss-seam-debug.jar must be in WEB-INF/lib
• You must have the Seam filter installed in web.xml
• You may see errors if the system is placed under any load and debug is enabled.
If you create a WAR project using seam-gen, incremental hot deployment is available out of the
box for classes in the src/hot source directory. However, seam-gen does not support incremental
hot deployment for EAR projects.

A co-worker at my new job was inquiring about how the incremental hot deployment works when the user is in the middle of execution of a wizard (LRC) use case.  Say you're on page 1, hot deploy a JavaBean change for page 2 that eliminates an instance variable, for example.  Then proceed to page 2 after the hot incremental deployment of page 2's JavaBean.  What happens now?  IIRC, your HttpSession is not invalidated and you can typically proceed with the processing of your use case, but what if an injection is removed, etc.?

If you want to eliminate JPA as your persistence layer, then maybe using iBATIS would solve your problem of being able to incrementally hot deploy persistence changes (although iBATIS uses xml files to embed the SQL in, so maybe that will not work with the Seam special classloader).  Then I guess Spring JdbcTemplate or straight-up JDBC is the solution...

[asookazian]

We are currently dealing with implementing hot deployment (re-deployment or auto-deployment) of our packaged EAR in OC4J 10.1.2.  I do not recommend using this particular app server, it has some pretty bad limitations compared to even JBoss 3.x.

[amitev]

A couple of years ago Gavin King made a post about hot-redeploy of hibernate entities and why this is very hard to do. He told that the entities loading is a complex two-phase task. First task is to scan the classes. The second task is to assemble information about the relations and constraints.

BTW there was a task in JBossAS jira about session beans hot redeploy but i can't find it now.

[asookazian]

The hot redeployment of JPA/Hibernate entity classes is not critical (how often do you modify those classes?)

I have been experimenting with JRebel 3.0-M2 (I believe M3 is out now) and have had some very good results with hot redeployment of interface changes as well as Seam/EJB annotations.  There are some bugs I've identified that they have fixed.

I'm really looking forward to JRebel 3 and Seam 3 and keep your ears peeled for SDouglas' fakereplace as well (although I'm not sure it will have the EJB3 hot redeploy support but we'll see)...

[luxspes]

Arbi Sookazian wrote on Apr 12, 2010 22:38:


The hot redeployment of JPA/Hibernate entity classes is not critical (how often do you modify those classes?)

I guess it dependes on how anemic your domain model is ;-) (The more anemic, the less you need to modify your Entities...)