<bean id="myEmf" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="dataSource" ref="ds" />
<property name="persistenceUnitName" value="org.drools.persistence.jpa.local" />
</bean>

<bean id="txManager" class="org.springframework.orm.jpa.JpaTransactionManager">
<property name="entityManagerFactory" ref="myEmf" />
</bean>

I’m not showing the datasource configuration because it heavily depends on your deployment but you can grab it from the example .

Secondly, you have to define a kbase that then would be used by the JpaSessionService:

<drools:kbase id="kbase1">
<drools:resource type="DRF" source="classpath:VariablePersistenceStrategyProcess.rf" />
</drools:kbase>

And finally, you need to define the JpaSessionService:

<drools:jpaSessionServiceFactory id="jpaSingleSessionCommandService" kbase="kbase1"
entityManagerFactory="myEmf" transactionManager="txManager">
<drools:variablePersisters>
<drools:persister forClass="javax.persistence.Entity" implementation="org.drools.persistence.processinstance.persisters.JPAVariablePersister"/>
<drools:persister forClass="java.lang.String" implementation="org.plugtree.labs.variablepersistence.StringVariablePersister"/>
<drools:persister forClass="java.io.Serializable" implementation="org.drools.persistence.processinstance.persisters.SerializableVariablePersister"/>
</drools:variablePersisters>
</drools:jpaSessionServiceFactory>

Bear in mind if that you don’t need to define customs variable persisters the configuration it’s only one line!.

Then you can inject it to your own beans or create a Spring Context manually, as shown in the this snippet:

ctx = new ClassPathXmlApplicationContext("beans.xml");
JPASingleSessionCommandService jpaService = (JPASingleSessionCommandService) ctx
.getBean("jpaSingleSessionCommandService");
SingleSessionCommandService service = jpaService.newStatefulKnowledgeSession();
int sessionId = service.getSessionId();
....
//do something
service.dispose();

Then in a future time retrieve the session:
SingleSessionCommandService service = jpaService.loadStatefulKnowledgeSession(sessionId);
//do something
....
service.dispose();

Warning note: when you use the flow persistence with JTA, it automatically reloads the state out the session after a rollback. We couldn’t do that behavior here since simple database connections doesn’t provide a listener mechanism as JTA transactions does.

Entonces como todo el mundo hace me puse a leer la man page de git-svn y ahí nomás me bajaron las expectativas de un plumazo en la session “caveats” dice:

…

For the sake of simplicity and interoperating with a less-capable system (SVN), it is recommended that all git svn users clone, fetch and dcommit directly from the SVN server, and avoid all git clone/pull/merge/push operations between git repositories and branches. The recommended method of exchanging code between git branches and users is git format-patch and git am, or just ‘dcommit’ing to the SVN repository.

…

You must therefore ensure that the most recent commit of the branch you want to dcommit to is the first parent of the merge. Chaos will ensue otherwise, especially if the first parent is an older commit on the same SVN branch.

git clone does not clone branches under the refs/remotes/ hierarchy or any git svn metadata, or config. So repositories created and managed with using git svn should use rsync for cloning, if cloning is to be done at all.

Lo que en español significa que sólo podes usar git-svn si no utilizas ninguno de los features interesantes en git, no podés clonar de mi copia y la mejor forma de compartir cambios es comiteando directo al repo svn… En conclusión para aprender una nueva parva de comandos me quedo svn.

Igualmente todavía tengo la esperanza que aparezca alguien que me diga el man page esta siendo muy alarmista y que todo es más sencillo.