Drools Flow configuration using Spring

2010
05.28

There are a lot of Drools Flow users that ask us about how to use Drools Flow persistence without JTA transactions, so in order to give those users a proper answer we developed a solution based on the Spring integration. We added support to configure a JpaSessionServiceFactory to the Drools’ configuration namespace. Let’s see how to use it on a real example (you can donwload it from: http://www.plugtree.com/downloads/DroolsFlowSpring.tgz).
Firstly, you need to configure EntityManageFactory and SpringTransactionManager as follows:


<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.

Drools-Guvnor improvements adding fact constraints

2010
03.26

As you can see here I’m working with Esteban under the orders of Commander Salaboy on improving the user experience of writing rules.

Following those ideas we implemented some tools for configuring a WorkingSet, a mean for filter which Facts you are able to use inside Guvnor’s Guided Editor. But that’s not all what we’ve been doing, you can also define for each field a set of constraints that will restrict what users will be allowing to write inside a rule.

Since a video worth like a thousand posts, I’ve created one showing the new features using the Guvnor demo model. in the video you’ll see how to create a new working set. Once the Working Set is created, it shows how to add facts and define constraints for those facts, as you’ll I defined a Range constraint for a credit Applicant’s age field. And next to demonstrate how to use a WorkingSet to verify a rule, I’ve created a new rule adding a restriction that would make the Range Constraint to fire.

Guvnor FactConstraints Example from Pablo Nussembaum on Vimeo.

No le veo la utilidad a git-svn

2010
02.03

Ya que estoy trabando con un pequeño grupo de desarrolladores mejorando Drools me dieron ganas de probar git y ver si lo podíamos usar internamente para no tener que crear branchs en el repositorio central.

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.

Trabajando con Drools

2009
12.02

Una vuelta al mundo del blogging! Acá pueden ver en que estuve laburando en el último tiempo

Curso en el IEEE

2009
09.08

El Martes 29 de Septiembre voy a dar una charla en IEEE. La idea es contar qué herramientas existen para dar soporte al proceso de desarrollo ágil. Nos enfocaremos en cómo utilizar, dentro de un proyecto java, herramientas de control de versiones, de generación de versiones, frameworks de testing unitario y para al final lograr el objetivo de tener un servicio de Integración Continua automatizado. Para más información vean la página del IEEE y se pueden inscribir acá.  Y por supuesto todo esto no hubiese sido posible sin la ayuda de Juan.

Porque me gusta GIT

2009
02.16

Hace unos días Dieguito (aka DLL) me dijo que los manejadores de versiones distribuidos (dcvs, según sus siglas en inglés) no lo convencían y me preguntó porqué me gusta GIT.
Empecemos respondiendo cuales a mi manera de ver son las ventajas de un dcvs. La principal ventaja dada su naturaleza distribuida es que no hay un servidor central al cual conectarse para obtener y/o publicar cambios realizados a un proyecto, aunque nadie impide que los encargados de un proyecto definan a un repositorio como el central, en otras palabras esto permite que cada proyecto utilice el workflow que mejor le parezca. Por ejemplo la gente del kernel del linux utiliza un mecanismo estratificado donde Linus Torvals recibe updates de los desarrolladores en los que confía y a su vez estos hacen los mismo un nivel más abajo, creando así una estructura jerárquica. Como son distribuidos son menos propensos a fallas y o perdidas en el caso de que el servidor central falle total o parcialmente, ya que podremos usar cualquier otra instancia mientras que la falla persista. También permite que un grupo de desarrolladores trabajen en conjunto mandándose modificaciones unos a otros sin necesidad de polucionar el servidor con sus cambios. Hasta acá parece que sólo tiene ventajas para el grupo desarrollo, pero también es interesante que uno localmente puede crear sus propios ramas para experimentar cambios “locos” y/o “raros” sin necesidad de duplicar el checkout local, esto es posible ya que el checkout local tiene las mismas funcionalidades que el “repositorio central”.

Ahora volvamos a lo que me gusta de GIT que como no podía ser de otro manera son dos cosas. La primera es que no GIT no mantiene un historia lineal de cada archivo en el repositorio sino mantiene un historia de cambios hechos al repositorio, lo que permite que GIT sea capaz de detectar y mostrar como partes del código fue migrando de un archivo a otro, y creo que esta funcionalidad no existe en casi ningún otro dcvs. La segunda funcionalidad que me parece excelente es el comando stash, que basicamente lo que hace es guardar temporalmente todos los cambios, commiteados o no, en algún lugar para que podamos movernos a otra rama sin tener que copiar nuestros cambios o hacer multiples checkouts para trabajar simultaneamente en diferentes ramas de la misma aplicación.

Aprendiendo Lisp

2009
02.13

Ya que  por todos lados dicen que para ser un groso programador hay que saber Lisp con mi amigo Cucu nos pusimos a aprenderlo.

El primer reto fue implementar RLE (Run Lentgth Encoding), o sea dada una lista

rle '(1 1 1 2 2 3) = ((1 3) (2 2) 3)

A mi no gustó que Cucu haya definido el tipo de dato es distinto dependiendo de si hay o no repeticiones pero no iba a discutir un detalle tan nimio.
Y sin más acá les dejo mi solución:

(defun make-elem (c n)
  (cond ((eq 1 n) (list c))
    (t (list (list c n))))
  )

(defun acum (c n r)
  (cond ((null r) (make-elem c n))
    ((eq c (first r)) (acum c (+ 1 n) (rest r)))
    (t (append (make-elem c n) (rle r))))
  )

(defun rle (l)
  (cond ((null l) nil)
      (t (acum (first l) 1 (rest l))))
)

PD: Mi solución es más elegante que de Cucu, espero que se anime a postear la suya o al menos que pique en el amor propio para mejorarla!!

Gratamente sorprendido

2009
01.23

La verdad que no son muy interesantes los avances que hice con GIT. Lo único que estuve haciendo fue leer mucha documentación de cómo GIT guarda internamente la información y me empezé a empapar con el código de eGIT y además me saque una cuenta en github para algún día publicar mis cambios ;-) .

Parte del plan que no les conté, y les quiero contar en este post, es que migré mi laptop a Ubuntu (vale aclarar que todas mi compus de escritorio ya usaba Debian) ya que se me hacia un nudo en el estomago de sólo pensar en usar windows (no les doy el link para este :-P ) para aportar a un proyecto open source. Los resultados no pudieron ser más increíbles por empezar por la hibernación y suspención funcionó de una, dado mis previas experiencias con GNU/Linux y laptops no había sido muy satisfactoria. Y otra cosa que me pone muy contento es volver a tener el apt-get en las punta de mis dedos ;-) . Otro dos detalles muy lindos son el nuevo control para cambiar de usuario, modificar tu presencia en IMs y cierre de la session y el nuevo, para mi, icono de eject que aparece al lado de cada dispositivo removible (pendrives, camaras, mp3 players, etc.), y acá le pego unas imágenes para los vean por ustedes mismos.

icono de eject

Pero todos estos features son detalles sin importancia frente a no tener más miedo a lo que microsoft hace con mi computadora, porque es sabido que esta empresa se manda información de lo hacemos con nuestras computadoras y como si eso fuese poco nos prohibe realizar algunas tareas, por ejemplo nos impide copiar nuestro propios cds. Ya que no es resposibilidad del sistema operativo hacer que las leyes se cumplan o decidir si yo tengo los derechos para hacer algo (más sobre esto en el futuro…).

Nuevos caminos

2008
12.23

Gracias a la crisis mundial financiera me he quedado sin trabajo y me he propuesto utilizar esta oportunidad para devolverle algo a la comunidad y si es posible aprender algo nuevo en el camino. La idea es contribuir en el desarrollo del plugin de GIT para Eclipse y bloguear durante el proceso.

Ya se que a nadie le va interesar mucho pero igualmente me gustaría contarles como llegué a esta decisión. Lo que tenía claro desde el primer momento era que al ser yo un geek/nerd importante este blog no iba a estar libre de temas de tecnología, programación y demás nerdiadas. Después me di cuenta que no quería caer en el facilísmo de hacer un blog criticando a algunos de los tantos proyectos/frameworks que andan dando vuelta por ahí, porque la gente que ha participado en ellos dando de su tiempo y esfuerzo, no tienen que además soportar que venga cualquiera se monte un blog y los critique. Pero después pensándolo un poco mejor me dije “algunos de estos proyectos son un desastre y merecen ser defenestrados con una buena critica, pero… ¿ cómo ganarme el derecho ? “, entonces me contesté “primero hay que dejar de ser cualquiera y participar en un proyecto y ganarse el crédito para poder hablar del trabajo de los demás”.

Con esa última respuesta se empezaba a divisar el camino a seguir, el siguiente paso era elegir un proyecto. Los que primeros que surgieron fueron: Hibernate, donde ya me han aceptado algunos bug fixes, y o algo relacionado con GIT. Y terminé deciciendome por GIT porque es un aporte a dos comunidades a las cuales a admiro mucho. Sigan sintonizados!