Matt Raible - 27/Sep/07 09:41 PM Doesn't the current way things are arranged allow for more flexibility? For example, we could add generic finder methods for JPA and Hibernate, but not for iBATIS. If we were to implement this, we'd *have* to implement iBATIS or throw UnsupportedOperationException. I'm afraid if we start making AppFuse too modular, it can easily get out of hand and we'll end up with things like appfuse-aop, appfuse-security, etc. where each is a feature you can add to your app. Maybe it's a good idea, who knows. However, this seems like a low priority issue. I'd rather 1) implement generic finders in all 3 and 2) if we need to consolidate, move them into data-common.

Marcello Teodori - 04/Oct/07 06:21 AM My issue was mostly about removing the current duplication of each of the named interfaces: ./data/hibernate/src/main/java/org/appfuse/dao/GenericDao.java ./data/ibatis/src/main/java/org/appfuse/dao/GenericDao.java ./data/jpa/src/main/java/org/appfuse/dao/GenericDao.java ./data/hibernate/src/main/java/org/appfuse/dao/UniversalDao.java ./data/ibatis/src/main/java/org/appfuse/dao/UniversalDao.java ./data/jpa/src/main/java/org/appfuse/dao/UniversalDao.java by creating a new maven module or adding a single copy to data/common, than to add generic finder methods to those interfaces. Unfortunately I don't have any iBATIS experience, so I cannot be helpful on the subject of developing generic finder methods for that specific framework, but I would prefer the GenericDAO and UniversalDAO to have methods that are available across all implementations, otherwise it would be impossible to switch.