December 2009 Archives

Parancoe FAQ

Q) With parancoe you don’t need to implement methods that look like this “findByFirstNameAndLastName()”. Note that the implementation of the most commonly used operations like findById(), save(), delete(), findAll(), getReference() can be achieved easily without Parancoe (see link below).

http://best-practice-software-engineering.blogspot.com/2008/01/java-generic-dao.html
So why should I use parancoe to achieve this?

A) This is exactly the same solution (and almost the same implementation) we have in Parancoe.

What Parancoe is adding to this solution is:

  • automatic discovering of DAOs, without the need of writing the boring XML definitions in the Spring context. If you like to write the XML, you can write it extensively even with the Parancoe solution
  • personalization of the DAO interface, without writing the boring code but only the needed HQL/JPAQL (or neither that, if the query is very common)


Q) Parancoe is looking for files called development.properties, production.properties and test.properties. If those are not found, parancoe can not be initialized. To me this seems like very project specific files that should not be part of a framework. The solution for us would be to create the files and leave them empty.
A) This was a tentative of providing a simple solution for configuring (at runtime) and application for the different environments in which it can run (for example, but not limited to, development, testing, production).

If you don’t need it, you could override in your Spring context the definition of the abstractConf bean:

<bean id="abstractConf" abstract="true"></bean>


Q) Parancoe only works if the application complies with some undocumented rules about the package names. The entities and the daos must share the same package root. If the entities are in the org.entity package and the daos are in com.dao package, parancoe can not be used.

A) No, this limitation doesn’t exist. The discovering of DAOs and entities is configured separately. Following your example, this configuration should work in your Spring context:

<parancoe:define-daos basePackage="com.dao"/> <parancoe:discover-persistent-classes basePackage="org.entity"/>

If you experienced this limitation, there could be a bug, but not a such limitation by design.


Q) The transactionManager used by Spring is defined in a spring config file that is inside the Parancoe framework. It is defined to be the hibernate transaction manager. For the moment this is what we are using but we must be able to change it. E.g if we want to invoke a remote EJB in an existing transaction then we need to switch to the JTA transaction manager.

A) You can override the transaction manager definition in you Spring context with something like this:

<bean id="transactionManager" class="org.springframework.transaction.jta.JtaTransactionManager"> <property name="transactionManagerName" value="java:/TransactionManager"/> </bean>

Q) Parancoe has maven dependencies to libraries that we are not using. e.g a test dependency to the hsql database. It also has a dependency to its own parancoe-yaml project which has to do with database initialization (typically for testing purposes). At the moment this is built into our ear even if never used.

A) The purpose of Parancoe is to provide a highly productive development environment, with support for test on persistent classes. YAML and HSQL are part of this strategy.

If you don’t need such dependencies in your environment, you could exclude them in your Maven pom.xml.

But I firmly discourage that: tests (and automatic repeatable unit tests, in particular) are useful and necessary, and in a development environment encouraging convention-over-configuration are even more necessary.

Q) If we want to actually do the implementation of a dao interface we need to implement all the methods below. An implementation of the dao interface is needed if we want a method in the dao to do something other than just executing the query e.g write a record to some other table for tracking or reading from/writing to a file etc.

A) I don’t think you should consider that code as part of the DAO layer. I think is mostly business logic, and DAO composition.

Anyway, if you need to extend a Parancoe generic DAO, you can extend the org.parancoe.persistence.dao.generic.HibernateGenericBusinessDao class. For example:

public class MyDao extends HibernateGenericBusinessDao<MyEntity, Long> { // ...here your methods }

If you put that class in a package in which Spring is doing the scanning of components, it will be automatic discovered and wired to other beans:

<context:component-scan base-package="com.my.component.package"/> Continue Reading…

Posted by Enrico Giurin on Dec 10, 2009

Lookup tables

Here how to create a Lookup table annotated with JPA to use with the parancoe framework. This is a standard JPA annotated pojo, it means it could be used even out of the parancoe context.

As an example to represent gender of users.


package examples.parancoe.po;
import javax.persistence.Entity;
import javax.persistence.Id;

@Entity
public enum Gender {

    MALE(0L, "MALE"),
    FEMALE(1L, "FEMALE")
    ;

    private Long id;   
    private String description; 

    Gender(Long id, String description) {
        this.id = id;
        this.description = description;
    }
    @Id
    public Long getId() {        
        return id;
    }
    public void setId(Long id) {        
        this.id=id;
    }
    public String getDescription() {
        return description;
    }
    public void setDescription(String description) {
        this.description = description;
    }

}
Continue Reading…

Posted by Enrico Giurin on Dec 02, 2009