0 Replies Latest reply on Jan 17, 2020 11:10 AM by bucpatr

    What is the Expected Behaviour of the Extends Meta?

    bucpatr

      In trying to solve come issues with generating POJO classes (see: Controlling Class Names and Packages of Generated POJO Classes) I have been digging into the hibernate tools source code to get a better understanding of how everything works. When looking at the code for EntityPOJOClass (org.hibernate.tool.hbm2x.pojo.ENTITYPOJOClass) I noticed something odd. The class has a method 'getExtends()' that is used by the ftl templates to generate the extends declaration for a generated java class. The code first looks at the superclass of the source class and uses the superclass name to generate the text. If no superclass is available, it will check for a "extends" attribute in the meta attributes and use that value instead.

       

      The problem is, the code is structured such that the superclass name will always take priority. To me that seems backwards. Would it not make more sense for an explicit "extends" meta to override the superclass name? Is there some aspect of this I'm not seeing?

       

      As an example of how this could cause problems, consider the following code:

       

      ValueOption.hbm.xml

      <?xml version="1.0"?>
      <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
      "http://www.hibernate.org/dtd/hibernate-mapping-3.0.dtd">
      <!-- Generated Jan 17, 2020 10:19:35 AM by Hibernate Tools 3.6.0.Final -->
      <hibernate-mapping>
          <class name="com.tura.common.domain.ValueOption" table="value_options" abstract="true">
      <!-- meta for class com.tura.common.domain.ValueOption-->
              <meta attribute="generated-class" inherit="false">com.tura.common.domain.ValueOptionDTO</meta>
              <id name="id" type="java.lang.Long" access="field">
                  <column name="id" />
                  <generator class="native"></generator>
              </id>
              <discriminator type="string">
                  <column name="DTYPE" length="31" not-null="true" />
              </discriminator>
              <property name="value" type="java.lang.String" access="field">
                  <column name="value" />
              </property>
          </class>
      </hibernate-mapping>
      
      

       

      AccentMaterial.hbm.xml

      <?xml version="1.0"?>
      <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
      "http://www.hibernate.org/dtd/hibernate-mapping-3.0.dtd">
      <!-- Generated Jan 17, 2020 10:19:35 AM by Hibernate Tools 3.6.0.Final -->
      <hibernate-mapping>
          <subclass name="com.tura.product.domain.AccentMaterial" extends="com.tura.common.domain.ValueOption" discriminator-value="ACCENT_MATERIAL">
      <!-- meta for class com.tura.product.domain.AccentMaterial-->
              <meta attribute="generated-class" inherit="false">com.tura.product.domain.AccentMaterialDTO</meta>
      <!-- Extends com.tura.common.domain.ValueOption -->
              <meta attribute="extends" inherit="false">com.tura.common.domain.ValueOptionDTO</meta>
          </subclass>
      </hibernate-mapping>
      
      

       

       

      Since we are generating custom class names, the extends declarations need to match the generated classes. When the POJO class for AccentMaterial is generated, we want the class declaration to be

      public class AccentMaterialDTO extends com.tura.common.domain.ValueOptionDTO{...}
      
      

       

       

      What the hbm2java actually produces however is

      public class AccentMaterialDTO extends com.tura.common.domain.ValueOption
      
      

      Notice that the extends statement is pointing back to the source Entity class (ValueOption) rather than the generated class (ValueOptionDTO).