Hi,

I've got a couple of projects that use the hbm2java ant task to generate EJB3 entities from hibernate mapping files.

One project uses only table-per-class-hierarchy for sub-classes, the other exclusively uses table-per-sub-class.

I've started tidying up the code in this area but I've got a bit stuck trying to determine from the PersistentClass I get in the template generation which inheritance strategy applies...

Anyone any suggestions?

Thanks

Andy

the type of PersistentClass can be used for it...but probably safer to look at how the SessionFactoryImpl decides to create the different persisters based on the Configuration data.....you can also look in HbmBinder to see what the different tags gets bound too - and use that info in the templates.

Hi + thanks for the reply.

I don't have an instance of SessionFactoryImpl to hand - perhaps I should explain a bit more about what I'm trying to do:

Basically, I am trying to make the code used to generate annotations in hbm2java pluggable, along the lines that a RevEngStrategy makes descisions about reverse engineering from a db pluggable.

This is driven by my experience over the last 4 months where 2 different projects for two completely seperate customers have wanted to generate EJB3 entities from .hbm.xml maping files...

In each case, we ended up checking out the hibernate-tools project and "mangling" EntityPOJOClass.java to change or extend the strings created for annotation values (default cascade options, lazy load as default, version property etc) and rebuilding hibernate-tools.jar...

It strikes me that this is really not the way to do it.

So, as somthing to keep me occupied in the hotel bar last night I had a go at creating my own extension of HibernateToolTask.java which accepted a nested element for my own PluggableAnnotationGeneratorPojoExporter (extends from POJOExporter) which puts an instance of a configurable imlementation of my Ejb3EntityAnnotationBuilder interface into the same context as the "pojo" variable for .ftl templates. Finally I altered Ejb3TypeDeclaration.ftl to use my annotation builder rather than using pojo.whatever() direct.

It all hangs together :) - its a bit long-winded but it means I havent changed any hibernate classes...

Where I ground to a halt was using the PersistentClass returned by pojoClass.getDecoratedObject() to determine what kind of inheritance was going on in the entities and therefore what inheritance strategy annotations to include - any thoughts?

Cheers,

Andy

I did not say you needed an instance of SessionFactoryImpl; I said that you could look in the code that is has to decide what persister to create....its the same info you need.



I agree that a strategy might be relevant for hbm2java - but I don't agree that deciding which inheritance strategy is something hbm2java should care about...that is the job of the reverse engineering.

remember that hbm2java just needs to "dump" the existing hbm model - not try and redo/rebuild it.



yes..and here the inheritance is set in stone. (the mapping states what the inheritance is, right ?)



no - it aint ;)

[qote]
So, as somthing to keep me occupied in the hotel bar last night I had a go at creating my own extension of HibernateToolTask.java which accepted a nested element for my own PluggableAnnotationGeneratorPojoExporter (extends from POJOExporter) which puts an instance of a configurable imlementation of my Ejb3EntityAnnotationBuilder interface into the same context as the "pojo" variable for .ftl templates. Finally I altered Ejb3TypeDeclaration.ftl to use my annotation builder rather than using pojo.whatever() direct.

It all hangs together :) - its a bit long-winded but it means I havent changed any hibernate classes...
[/quote]

I still don't get why you want hbm2java to generate something different than what is simply mapped ;)



look in HbmBinder and/or SessionFactoryImpl to find the logic.....

Ah, gotit - I'll go and read the code.

I'm not changing the inheritance defined by the mapping files, just trying to reflect the mappings in the generated annotations - hbm2java for entities didn't generate the annotations for either table-per-subclass or table-per-hierarchy, at least not in the version I was using. Perhaps it does now, I'll go and check...

Thanks,

Andy

ah ok - I just got "thrown off" because you said reveng from db and have hbm2java to generate the apropriate inheritance....which is kinda impossible since reveng from db does not do inheritance ;)

jpa annotations might very well not generate proper annotations code - would be great to get that ;)

The overall scheme I've been using is reverse engineer from db to hibernate mapping files once then manually adjusting the mappings to include inheritance, toString/equals properties etc and then generating the entities from there.

I'll let you know how I get on. I'll be quite happy to contribute it if it turns out to be useful :)

cool.