Overriding pojo generation

damomurf · **Posted:** Thu Apr 13, 2006 1:17 am

Hibernate version:

Hibernate Tools 3.1 beta 4

Name and version of the database you are using:

Oracle 10g

Debug level Hibernate log excerpt:

Code:

[hibernatetool] 2006-04-13 14:23:52,566 [main] WARN  [hibernatetool] 2006-04-13 14:23:52,566 [main] WARN  org.hibernate.tool.hbm2x.template - org.apache.velocity.runtime.exception.ReferenceException: reference : template = pojo/PojoPropertyAccessors.vm [line 20,column 1] : $pkutils.generateCompositePKGetters($clazz, $pojo) is not a valid reference.
[hibernatetool] 2006-04-13 14:23:52,566 [main] INFO  org.hibernate.tool.hbm2x.template - ResourceManager : found pojo/PojoToString.vm with loader org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader
[hibernatetool] 2006-04-13 14:23:52,566 [main] INFO  org.hibernate.tool.hbm2x.template - ResourceManager : found pojo/PojoEqualsHashcode.vm with loader org.apache.velocity.runtime.resource.loader.ClasspathResourceLoader
[hibernatetool] 2006-04-13 14:23:52,566 [main] INFO  org.hibernate.tool.hbm2x.template - ResourceManager : found pojo/PojoExtraClassCode.vm with loader org.apache.velocity.runtime.resource.loader.FileResourceLoader
[hibernatetool] 2006-04-13 14:23:52,566 [main] DEBUG org.hibernate.tool.hbm2x.TemplateHelper - removeFromContext secondpassclassimports=$secondpassclassimports
[hibernatetool] 2006-04-13 14:23:52,566 [main] DEBUG org.hibernate.tool.hbm2x.TemplateHelper - removeFromContext pojo=org.hibernate.tool.hbm2x.pojo.ComponentPOJOClass(org.dais.efm.vo.efm.SchJobServicePK)
[hibernatetool] 2006-04-13 14:23:52,566 [main] DEBUG org.hibernate.tool.hbm2x.TemplateHelper - removeFromContext clazz=org.hibernate.mapping.Component([org.hibernate.mapping.Property(schId), org.hibernate.mapping.Property(shliSeq), org.hibernate.mapping.Property(scheduledDate), org.hibernate.mapping.Property(tdsId), org.hibernate.mapping.Property(tdsScheduleVariant), org.hibernate.mapping.Property(serviceType), org.hibernate.mapping.Property(fmanEntityCode), org.hibernate.mapping.Property(jobNo)])
[hibernatetool] 2006-04-13 14:23:52,566 [main] DEBUG org.hibernate.tool.hbm2x.TemplateHelper - removeFromContext secondclassimports=$secondpassclassimports
[hibernatetool] 2006-04-13 14:23:52,566 [main] DEBUG org.hibernate.tool.hbm2x.TemplateHelper - putInContext secondpassclassimports=import java.util.Date;
[hibernatetool] 2006-04-13 14:23:52,566 [main] INFO  org.hibernate.tool.hbm2x.VelocityProducer - Writing Pojo to C:\temp\...\SchJobServicePK.java
[hibernatetool] 2006-04-13 14:23:52,566 [main] ERROR org.hibernate.tool.hbm2x.template - Method generateCompositePKGetters threw exception for reference $pkutils in template TemplateHelper at  [115,1]

BUILD FAILED
D:\efm_workspace\efmv1\ant\hibernategen-new.xml:157: org.hibernate.tool.hbm2x.ExporterException: Error while processing template the second time

Velocity Template file: PojoPropertyAccess.vm

Code:

    // Property accessors
#foreach($property in $pojo.getAllPropertiesIterator())
#if($pojo.getMetaAttribAsBool($property, "gen-property", true))
#if($pojo.hasFieldJavaDoc($property))
    /**       
     * $pojo.getFieldJavaDoc($property, 4)
     */
#end
$templates.Ejb3PropertyGetAnnotation
    $pojo.getPropertyGetModifiers($property) $pojo.getJavaTypeName($property, $jdk5) $pojo.getGetterSignature($property)() {
        return this.$property.name;
    }
    
    $pojo.getPropertySetModifiers($property) void set$pojo.getPropertyName($property)($pojo.getJavaTypeName($property, $jdk5) $property.Name) {
        this.$property.Name = $property.Name;
    }
#end
#end

$pkutils.generateCompositePKGetters($clazz, $pojo)

I'm successfully generating customised POJOs for mapped data almost exactly as we require. I've added a custom utility class for the POJO generation (refered to as $pkutils in the output above). I've added logging into $pkutils so I know exactly what is being called within it's methods.

Things a falling apart when hbm2java comes to use the POJO templates to generate the PK objects for the mappings and the above error results. At first I didn't realise it was using the same template files, but it makes sense that it needs to.

I've mucked around for hours experimenting with VTL directives to work out what the problem is and all I can establish is that $clazz, $pojo and $pkutils are not null, but somehow the reference $pkutils.generateCompositePKGetters($clazz, $pojo) is causing a problem - but only when hbm2java is generating a PK object.

While I'm aware that things are moving to Freemarker, I've already spent days and days getting this far - the prospect of spending another few converting to Freemarker isn't really an option.

I've tried wrapping the customised code like so:

Code:

#if (!$pojo.getDeclarationName().endsWith("PK")
$pkutils.generateCompositePKGetters($clazz, $pojo) 
#end

but it seems to be ignored.

Anyone have any ideas?

max · **Posted:** Thu Apr 13, 2006 5:16 am

what is the signature of the method it is failing on ?

and pleased do you self a favor and use nightly build and use the freemarker version which would be much more informative about what is erroring. (i converted all hibernate templates in less than one day with velocity 2 freemarker tool available from freemarker.org)

damomurf · **Posted:** Mon Apr 17, 2006 10:30 pm

max wrote:

what is the signature of the method it is failing on ?

and pleased do you self a favor and use nightly build and use the freemarker version which would be much more informative about what is erroring. (i converted all hibernate templates in less than one day with velocity 2 freemarker tool available from freemarker.org)

Max, as usual, your response has been most helpful! :)

I bit the bullet and moved to the latest nightly build. (I wasn't to eager to attempt this as I originally thought it would involve access to the Subversion repository which isn't possible from here).

The template conversion was actually really simple and within a few minutes had helpful ClassCastExceptions being displayed.

(The actual cause of the issue is that during entity code generation $clazz is an instance of PersistentClass, yet while generating PK objects it becomes an instance of Component).

Thanks again for your help. Looking forward to freemarker in the final version. ;)

max · **Posted:** Tue Apr 18, 2006 2:50 am

no subversion access ? subversion is port 80 is it not ?

but great to hear you just proved my reason for moving to freemarker ;)

It is easy to do
and it has immediate effect ;)

damomurf · **Posted:** Tue Apr 18, 2006 2:55 am

max wrote:

no subversion access ? subversion is port 80 is it not ?

It is, but some of the sad proxies out there don't support proxying DAV (SVN) methods at all. I've a victim of that which makes Subversion access all bar useless to me, other than through the default "GET only" web interfaces.

but great to hear you just proved my reason for moving to freemarker ;)

Quote:

It is easy to do
and it has immediate effect ;)

I was dubious of the move initially, I'll admit - but it seems well founded now. Mind you, I didn't have much to customise - I'd hate to have had to change a lot of templates.

max · **Posted:** Tue Apr 18, 2006 3:03 am

well I think (or at least that is the idea) the most templates that needs converting is the one that was in the tools.

And if you were to do a big number of conversions like i did then using the velocity to freemarker tool were very good - it worked out of the box (except for the case of jsf/jsp generated code where I had to fix the usage of # which confused the converter)