OpenJPA
  1. OpenJPA
  2. OPENJPA-1011

Instantiate meta-model classes for JPA 2.0 from XML descriptors

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: 2.0.0, 2.1.1, 2.2.0
    • Fix Version/s: 2.4.0
    • Component/s: None
    • Labels:
      None

      Description

      JPA 2.0 has introduced a specification for strictly-typed dynamic query construction. The type-strictness is based on availability of a meta-model. The user application can either use meta-model API to access the type information or instantiate the meta-model (referred as canonical meta-model) with a set of auto-generated classes for compile-time binding. This issue refers to instantiating the canonical meta-model at compile-time.
      The process involves processing source code annotations or xml descriptors.

      Annotation processing support in Java platform has significantly changed across JDK version 5 and 6. In JDK5, the annotation processing was supported by a command-line tool named apt based on com.sun.mirror API library. In JDK 6, the annotation processing is more seamlessly integrated with javac compilation process with javax.annotation API libraries.

      It is not obvious at this point on how to hook into compiler life-cycle when source code has no annotation and persistence meta-data is only available in XML descriptors.

        Issue Links

          Activity

          Hide
          Albert Lee added a comment -

          Moved fix version to 2.3.0 in preparation for 2.2.0 release.

          Show
          Albert Lee added a comment - Moved fix version to 2.3.0 in preparation for 2.2.0 release.
          Hide
          Pinaki Poddar added a comment -

          Kevin,
          For a bug, there has to be code. Right?
          But there is no code for it at all.

          I logged this issue (classify it whichever way you like) to make is
          explicit that I am keeping the task i.e. generating this metamodel classes
          sourcing the orm.xml rather than annotations completely out of scope. But
          now as the annotation based generation has been stabilized, it is worth to
          attempt this task on the basis of what exists in code.

          Regards –

          Pinaki

          From: "Kevin Sutter (JIRA)" <jira@apache.org>
          To: Pinaki Poddar/Dallas/IBM@IBMUS
          Date: 07/21/2011 08:58 AM
          Subject: [jira] [Commented] (OPENJPA-1011) Instantiate meta-model
          classes for JPA 2.0 from XML descriptors

          [
          https://issues.apache.org/jira/browse/OPENJPA-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069038#comment-13069038
          ]

          Kevin Sutter commented on OPENJPA-1011:
          ---------------------------------------

          In my mind, this JIRA sounds more like a bug than a new feature. I know
          that the generation of the metamodel code is not a requirement of the spec,
          but since the orm.xml can provide an entity's meta data, we should be
          processing it.

          In the mean time, there are a couple of alternatives... If you are a
          WebSphere RAD customer, or even just use Eclipse with the Dali plugin, you
          can use the metamodel code generation facility within these tools to
          process the orm.xml file. Depending on your development environment, this
          may be an alternative until OpenJPA can update their tooling.

          construction. The type-strictness is based on availability of a meta-model.
          The user application can either use meta-model API to access the type
          information or instantiate the meta-model (referred as canonical
          meta-model) with a set of auto-generated classes for compile-time binding.
          This issue refers to instantiating the canonical meta-model at
          compile-time.
          descriptors.
          across JDK version 5 and 6. In JDK5, the annotation processing was
          supported by a command-line tool named apt based on com.sun.mirror API
          library. In JDK 6, the annotation processing is more seamlessly integrated
          with javac compilation process with javax.annotation API libraries.
          when source code has no annotation and persistence meta-data is only
          available in XML descriptors.


          This message is automatically generated by JIRA.
          For more information on JIRA, see: http://www.atlassian.com/software/jira

          Show
          Pinaki Poddar added a comment - Kevin, For a bug, there has to be code. Right? But there is no code for it at all. I logged this issue (classify it whichever way you like) to make is explicit that I am keeping the task i.e. generating this metamodel classes sourcing the orm.xml rather than annotations completely out of scope. But now as the annotation based generation has been stabilized, it is worth to attempt this task on the basis of what exists in code. Regards – Pinaki From: "Kevin Sutter (JIRA)" <jira@apache.org> To: Pinaki Poddar/Dallas/IBM@IBMUS Date: 07/21/2011 08:58 AM Subject: [jira] [Commented] ( OPENJPA-1011 ) Instantiate meta-model classes for JPA 2.0 from XML descriptors [ https://issues.apache.org/jira/browse/OPENJPA-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069038#comment-13069038 ] Kevin Sutter commented on OPENJPA-1011 : --------------------------------------- In my mind, this JIRA sounds more like a bug than a new feature. I know that the generation of the metamodel code is not a requirement of the spec, but since the orm.xml can provide an entity's meta data, we should be processing it. In the mean time, there are a couple of alternatives... If you are a WebSphere RAD customer, or even just use Eclipse with the Dali plugin, you can use the metamodel code generation facility within these tools to process the orm.xml file. Depending on your development environment, this may be an alternative until OpenJPA can update their tooling. construction. The type-strictness is based on availability of a meta-model. The user application can either use meta-model API to access the type information or instantiate the meta-model (referred as canonical meta-model) with a set of auto-generated classes for compile-time binding. This issue refers to instantiating the canonical meta-model at compile-time. descriptors. across JDK version 5 and 6. In JDK5, the annotation processing was supported by a command-line tool named apt based on com.sun.mirror API library. In JDK 6, the annotation processing is more seamlessly integrated with javac compilation process with javax.annotation API libraries. when source code has no annotation and persistence meta-data is only available in XML descriptors. – This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
          Hide
          Kevin Sutter added a comment -

          Since I'm not ready to call this a "bug", I changed this from a "new feature" to an "improvement"... Sound any better? And, I raised the Priority. We'll see if we can get any takers...

          Show
          Kevin Sutter added a comment - Since I'm not ready to call this a "bug", I changed this from a "new feature" to an "improvement"... Sound any better? And, I raised the Priority. We'll see if we can get any takers...
          Hide
          Kevin Sutter added a comment -

          In my mind, this JIRA sounds more like a bug than a new feature. I know that the generation of the metamodel code is not a requirement of the spec, but since the orm.xml can provide an entity's meta data, we should be processing it.

          In the mean time, there are a couple of alternatives... If you are a WebSphere RAD customer, or even just use Eclipse with the Dali plugin, you can use the metamodel code generation facility within these tools to process the orm.xml file. Depending on your development environment, this may be an alternative until OpenJPA can update their tooling.

          Show
          Kevin Sutter added a comment - In my mind, this JIRA sounds more like a bug than a new feature. I know that the generation of the metamodel code is not a requirement of the spec, but since the orm.xml can provide an entity's meta data, we should be processing it. In the mean time, there are a couple of alternatives... If you are a WebSphere RAD customer, or even just use Eclipse with the Dali plugin, you can use the metamodel code generation facility within these tools to process the orm.xml file. Depending on your development environment, this may be an alternative until OpenJPA can update their tooling.
          Hide
          Donald Woods added a comment -

          moving target to 2.1.0

          Show
          Donald Woods added a comment - moving target to 2.1.0

            People

            • Assignee:
              Pinaki Poddar
              Reporter:
              Pinaki Poddar
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:

                Time Tracking

                Estimated:
                Original Estimate - 672h
                672h
                Remaining:
                Remaining Estimate - 672h
                672h
                Logged:
                Time Spent - Not Specified
                Not Specified

                  Development