自定义 Hibernate Tools 的模板

在主界面Hibernate Code Generation Configuration的某个具体配置中，勾选
use custom templates,并且指定template文件(.ftl)所在的目录
注意一点，template目录下的文件，依然要保持 hibernate-tools.jar这个包的路径，
即 daohome.ftl, 要放在 dao\daohome.ftl，不可直接放在template目录的根路径

hibernate-tools.jar的路径在
hibernateTools/plugins/org.hibernate.eclipse_3.2.4.GA-R200905070146-H18/lib/tools下

如果指示同步生成/更新hibernate.cfg.xml，这个文件会自动生成在 output directory下，和pojo同目录

生成后的refresh策略，不要选择entire workspace，很容易死锁，可以选择只刷新资源所在的项目

有几篇文章值得参考：
[url]http://www.blogjava.net/pauliz/archive/2009/11/13/302162.html[/url]
[url]http://docs.jboss.org/tools/2.1.0.Beta1/hibernatetools/html_single/#plugins[/url]
[url]http://xuliangyong.iteye.com/blog/148136[/url]
[url]http://windforwings.blogspot.com/2008/11/customizing-code-generation-in.html[/url](需翻墙,已转贴在下面，包括附件)

Customizing Code Generation in Hibernate
Labels: Java, Language, Technology

Hibernate includes set of tools that can generate Java code from hbm xml definitions. The code generation is rather less documented, and it is not straight forward to customize the code generation. While implementing hibernate in one of my projects, we needed to do just that - customize the code generation. Though many propose to use hibernate annotations instead of hbm xml files, we were not quite ready for that. Since during the design and development phase, most of our database structure was in flux, I felt more comfortable generating the bulk of our code rather than writing them by hand - less errors! So I took a bit of time to delve into hibernate tools and here's what we did...

Hibernate tools (hibernate-tools.jar) uses freemarker templates for code generation. The templates are located inside the jar file. We extracted the hibernate-tools.jar contents into a folder. Among other things there were two folders containing the templates used for code generation - pojo (to generate pojo classes) and dao (to generate the data access objects).

Our intention was to modify the code generation to:

1. Incorporate logging using log4j logger in the DAO methods.
2. Externalize the creation of hibernate session as our application wants to control the session scope. We would not use the session factory method of DAO.
3. The DAO contains many utility methods to fetch, persist and search data (finder methods). Since we externalized the hibernate session, all the utility methods in our DAO can now become static. This will make it easier for our application to use the utility methods without instantiating an object every time.
4. We would like to add finder methods for arbitrary properties as specified in the hbm, apart from the finders based on id and natural id into the DAO as static methods, instead of generating it with the POJO.
5. For ease of use our application would sometimes like to instantiate the DAO object and treat it as the POJO object while accessing the static methods as a DAO. This is not really a 'required' feature (and is against the design principles) and can be skipped though.
6. While generating POJO classes, we would like to limit the extra class code specified in hbm files to the parent class and not generate them in the component classes.
7. Add setter and getter validations to the property values in POJOs.
8. Since we added setter and getter validations, we would like to use them in class constructors as well. So we need to modify the class constructors to call the setter methods instead of directly assigning values to fields.


Now here's how we went about changing the templates (each item below corresponds to the objectives above) ...

1. Modified dao/daohome.ftl and introduced a static variable named log which is an instance of org.apache.log4j.Logger initialized with the name of the DAO class.
2. Modified all utility methods in dao/daohome.ftl and included a method parameter of type org.hibernate.Session and named _session. Inside the methods, we used _session instead of a call to sessionFactory.getCurrentSession(). We also removed the getSessionFactory method which was not used anymore.
3. Modified dao/daohome.ftl and made all utility methods static.
4. Created a new ftl in dao folder named PojoFinderMethods.ftl and included it in dao/daohome.ftl inside the class declaration. In the PojoFinderMethods.ftl, we examined each property declaration and if a finder attribute was declared, generated a method with name as the attribute value that fired a hbm query to match the property to a passed argument.
5. Modified dao/daohome.ftl and added extends clause to the class declaration.
6. Modified pojo/Pojo.ftl and included a condition !pojo.isComponent() around the line that included PojoExtraClassCode.ftl.
7. Modified pojo/PojoPropertyAccessors.ftl to look for "pre-cond" and "post-cond" attributes in the hbm specification. We expect java code in the attribute values which we plonk into the output. In cases where we used any external validators (like apache validator framework) we included them as additional imports in the hbm.
8. Modified pojo/PojoConstructors.ftl and changed the direct assignments to call the setter methods.


Once these were done, we modified our build.xml to point the template directory to the modified templates.

<hibernatetool destdir="${sourcedir}" templatepath="${hbmtemplatedir}">
   ...
<configuration configurationfile="...hibernate.cfg.xml"/>
<hbm2java jdk5="true" ejb3="false"/>
<hbm2dao/>
</hibernatetool>