You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Pinaki Poddar (JIRA)" <ji...@apache.org> on 2009/01/06 21:18:44 UTC

[jira] Created: (OPENJPA-850) Support equivalent names for plug-in value

Support equivalent names for plug-in value
------------------------------------------

                 Key: OPENJPA-850
                 URL: https://issues.apache.org/jira/browse/OPENJPA-850
             Project: OpenJPA
          Issue Type: New Feature
          Components: lib
            Reporter: Pinaki Poddar
            Assignee: Pinaki Poddar
             Fix For: 2.0.0


Plug-in values are identified or stored in the configuration using a key that consists of a prefix followed by a moniker that is available via Value.getProperty() method. This feature will support multiple equivalent moniker for the same value. This is needed because JPA 2.0 Specification defines certain pre-defined property key in javax.persistence.*  namespace that has pre-existing openjpa.* equivalents. To support a configuration that uses new property key e.g. "javax.persistence.jdbc.driver" and retain backward compatibility with a configuration that uses equivalent 'openjpa.ConnectionDriverName', a seamless solution should be provided that can add equivalent property names to a Value. The configuration processing and finding a Value in a Map should be upgraded to account for the fact that a Value can have more than one names. 
The implementation must follow the following guidelines 
a) The 'primary name' of the Value will have the exact same semantics of existing Value.getProperty() method 
b) configuration processing layer should mutate any Value that is specified with a new equivalent javax.persistence.* key to its openjpa.* equivalent. This will ensure that post-configuration processing layers are not impacted (or burdened) by this extra feature of a Value having equivalent name.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (OPENJPA-850) Support equivalent names for plug-in value

Posted by "Jeremy Bauer (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/OPENJPA-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeremy Bauer updated OPENJPA-850:
---------------------------------

    Issue Type: Sub-task  (was: New Feature)
        Parent: OPENJPA-807

> Support equivalent names for plug-in value
> ------------------------------------------
>
>                 Key: OPENJPA-850
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-850
>             Project: OpenJPA
>          Issue Type: Sub-task
>          Components: lib
>            Reporter: Pinaki Poddar
>            Assignee: Pinaki Poddar
>             Fix For: 2.0.0
>
>   Original Estimate: 120h
>  Remaining Estimate: 120h
>
> Plug-in values are identified or stored in the configuration using a key that consists of a prefix followed by a moniker that is available via Value.getProperty() method. This feature will support multiple equivalent moniker for the same value. This is needed because JPA 2.0 Specification defines certain pre-defined property key in javax.persistence.*  namespace that has pre-existing openjpa.* equivalents. To support a configuration that uses new property key e.g. "javax.persistence.jdbc.driver" and retain backward compatibility with a configuration that uses equivalent 'openjpa.ConnectionDriverName', a seamless solution should be provided that can add equivalent property names to a Value. The configuration processing and finding a Value in a Map should be upgraded to account for the fact that a Value can have more than one names. 
> The implementation must follow the following guidelines 
> a) The 'primary name' of the Value will have the exact same semantics of existing Value.getProperty() method 
> b) configuration processing layer should mutate any Value that is specified with a new equivalent javax.persistence.* key to its openjpa.* equivalent. This will ensure that post-configuration processing layers are not impacted (or burdened) by this extra feature of a Value having equivalent name.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Resolved: (OPENJPA-850) Support equivalent names for plug-in value

Posted by "Pinaki Poddar (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/OPENJPA-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pinaki Poddar resolved OPENJPA-850.
-----------------------------------

    Resolution: Fixed

done. 

> Support equivalent names for plug-in value
> ------------------------------------------
>
>                 Key: OPENJPA-850
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-850
>             Project: OpenJPA
>          Issue Type: New Feature
>          Components: lib
>            Reporter: Pinaki Poddar
>            Assignee: Pinaki Poddar
>             Fix For: 2.0.0
>
>   Original Estimate: 120h
>  Remaining Estimate: 120h
>
> Plug-in values are identified or stored in the configuration using a key that consists of a prefix followed by a moniker that is available via Value.getProperty() method. This feature will support multiple equivalent moniker for the same value. This is needed because JPA 2.0 Specification defines certain pre-defined property key in javax.persistence.*  namespace that has pre-existing openjpa.* equivalents. To support a configuration that uses new property key e.g. "javax.persistence.jdbc.driver" and retain backward compatibility with a configuration that uses equivalent 'openjpa.ConnectionDriverName', a seamless solution should be provided that can add equivalent property names to a Value. The configuration processing and finding a Value in a Map should be upgraded to account for the fact that a Value can have more than one names. 
> The implementation must follow the following guidelines 
> a) The 'primary name' of the Value will have the exact same semantics of existing Value.getProperty() method 
> b) configuration processing layer should mutate any Value that is specified with a new equivalent javax.persistence.* key to its openjpa.* equivalent. This will ensure that post-configuration processing layers are not impacted (or burdened) by this extra feature of a Value having equivalent name.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.