Hades

Just to get you right: you want to have the DAO base class to be configurable via the namespace rather than the factory class, right?

I want to specify the factory class used when creating new Dao instances via the namespace configuration. Something like:

<hades:dao-config base-package="org.synyx.**.dao" dao-factory-class="org.synyx.hades.dao.orm.CustomDaoFactoryBean" />

Ultimately I want to control the base Dao implementation being used (i.e. GenericJpaDao, GenericHibernateJpaDao or a custom implementation).

I went ahead and made the changes necessary for this to work and included them along with a simple test cases in the attached svn diff file.

Hopefully this will help get this into the next release.

Thanks for the patch, that will make things easier a lot. I am a little torn between exposing the factory class or rather the DAO base class. The latter would reduce the need to implement an additional custom factory, whereas the former would hand out more power to the user. I'd like to stick to the simpler approach (configure the DAO base class) but fear, there will be a perfectly valid request popping up some time with the requirement to expose the factory class as well. Suppose we'd do so and suddenly have both types being configurable which would be quite a mess then.

I'll probably discuss this with the rest of the team before taking further steps but feel free to share your opinion.

In my particular instance I think I need the ability to override the factory class. Maybe there's a different way but I don't see how with the current code base.

The end result I'm trying to get to is to add methods not provided by GenericDao to all of my Dao instances without the need for a bunch of custom implementations. For example, I would like to mimic the Hibernate 'load' method by using the EntityManager's 'getReference' method. To do this I want to be able to extend GenericDao with a new interface that adds the 'load' method. Obviously, I then need an implementation that extends GenericJpaDao that provides the functionality for the new 'load' method.

With the current factory class any method not defined in GenericDao, ExtendedGenericDao or the dao's specific interface require the use of a custom implementation even if the Dao base class provides the implementation. Unless that behavior is changed I need to override the factory to not require a custom implementation.

I guess I could look at modifying the factory to see if the Dao base class implements a method before declaring it a custom method. That combined with the ability to set the Dao base class in the config would work for me.

Okay, that all makes perfect sense. So I'll probably stick to the approach provided in your patch as this hands out the full power to the user and we have a clean solution path for advanced topics like the ones you described.

With the current factory class any method not defined in GenericDao, ExtendedGenericDao or the DAO's specific interface require the use of a custom implementation even if the DAO base class provides the implementation. Unless that behavior is changed I need to override the factory to not require a custom implementation.

I think, this is a valid point, too. So even, when the method is declared on an interface extending GenericDao wee should check if the method is implemented by the DAO base class and dispatch to that instead of regarding it as finder. Could you please open another ticket for that? Just skimmed the factory implementation with that topic in mind. In the current state you should still face the problem of not getting the additional method called on the base class without copying large protions of the factory class, don't you?

I think, this is a valid point, too. So even, when the method is declared on an interface extending GenericDao wee should check if the method is implemented by the DAO base class and dispatch to that instead of regarding it as finder. Could you please open another ticket for that?

I went ahead and figured out how to implement an approach that allows you to override just the dao base class. It requires the above modifications to the 'isCustomMethod' method in GenericDaoFactory and some other nasty generics walking to find the domainClass when it's specified on an interface that extends GenericDao by passing type variables. I'll open a seperate ticket for that and upload the patches. I actually prefer the dao base class approach even though it involves some ugly reflection.

Just skimmed the factory implementation with that topic in mind. In the current state you should still face the problem of not getting the additional method called on the base class without copying large protions of the factory class, don't you?

Yes, I basically have to override the validate logic in the factory class. If 'isCustomMethod' was protected I could probably just override that and test whether the methods declaring class is assignable to the dao base class.

Fixed with r7873.