You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tomee.apache.org by "David Blevins (JIRA)" <ji...@apache.org> on 2011/03/10 08:20:00 UTC
[jira] Created: (OPENEJB-1442) Clarify and normalize all internal
module identifiers
Clarify and normalize all internal module identifiers
-----------------------------------------------------
Key: OPENEJB-1442
URL: https://issues.apache.org/jira/browse/OPENEJB-1442
Project: OpenEJB
Issue Type: Task
Components: container system
Reporter: David Blevins
Assignee: David Blevins
Fix For: 3.2
Currently we have three identifiers for a DeploymentModule: path, moduleId, and modulePackageName.
module.path is the physical location of the module file on disk. We need this for scanning and finding descriptors.
module.modulePackageName is the path to the module as the application knows it. We may have moved things around so it might be different.
module.moduleId is the spec defined <module-name> string or the vendor-specific override for that string.
ModulePackageName is really just used for resolving internal links which is all ultimately URI based, so modulePackageName has been changed to from String to URI and the link code improved to just use URIs rather than creating them temporarily. The new field name is moduleUri
Module.Path is now represented internally as a File rather than String.
Module.moduleId has been left the same, however the rules for defaulting its value have been significantly improved.
The setting of each of these fields has been consolidated to one class and is now consistent across all the module types. Changes to that logic now affect all module types. It is also far easier to read -- the previous "if" blocks were terrible. A clean-up was long overdue.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OPENEJB-1442) Clarify and normalize all internal
module identifiers
Posted by "David Blevins (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENEJB-1442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Blevins resolved OPENEJB-1442.
------------------------------------
Resolution: Fixed
> Clarify and normalize all internal module identifiers
> -----------------------------------------------------
>
> Key: OPENEJB-1442
> URL: https://issues.apache.org/jira/browse/OPENEJB-1442
> Project: OpenEJB
> Issue Type: Task
> Components: container system
> Reporter: David Blevins
> Assignee: David Blevins
> Fix For: 4.0
>
> Attachments: 0001-OPENEJB-1442-clean-up-remaining-misleading-moduleId-.patch
>
>
> Currently we have three identifiers for a DeploymentModule: path, moduleId, and modulePackageName.
> module.path is the physical location of the module file on disk. We need this for scanning and finding descriptors.
> module.modulePackageName is the path to the module as the application knows it. We may have moved things around so it might be different.
> module.moduleId is the spec defined <module-name> string or the vendor-specific override for that string.
> ModulePackageName is really just used for resolving internal links which is all ultimately URI based, so modulePackageName has been changed to from String to URI and the link code improved to just use URIs rather than creating them temporarily. The new field name is moduleUri
> Module.Path is now represented internally as a File rather than String.
> Module.moduleId has been left the same, however the rules for defaulting its value have been significantly improved.
> The setting of each of these fields has been consolidated to one class and is now consistent across all the module types. Changes to that logic now affect all module types. It is also far easier to read -- the previous "if" blocks were terrible. A clean-up was long overdue.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OPENEJB-1442) Clarify and normalize all
internal module identifiers
Posted by "Ivan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENEJB-1442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13024730#comment-13024730 ]
Ivan commented on OPENEJB-1442:
-------------------------------
I went ahead to commit Shawn's patch to trunk at revision: 1096422, and it did not bring any new failed junit case.
Thanks, Shawn.
> Clarify and normalize all internal module identifiers
> -----------------------------------------------------
>
> Key: OPENEJB-1442
> URL: https://issues.apache.org/jira/browse/OPENEJB-1442
> Project: OpenEJB
> Issue Type: Task
> Components: container system
> Reporter: David Blevins
> Assignee: David Blevins
> Fix For: 4.0
>
> Attachments: 0001-OPENEJB-1442-clean-up-remaining-misleading-moduleId-.patch
>
>
> Currently we have three identifiers for a DeploymentModule: path, moduleId, and modulePackageName.
> module.path is the physical location of the module file on disk. We need this for scanning and finding descriptors.
> module.modulePackageName is the path to the module as the application knows it. We may have moved things around so it might be different.
> module.moduleId is the spec defined <module-name> string or the vendor-specific override for that string.
> ModulePackageName is really just used for resolving internal links which is all ultimately URI based, so modulePackageName has been changed to from String to URI and the link code improved to just use URIs rather than creating them temporarily. The new field name is moduleUri
> Module.Path is now represented internally as a File rather than String.
> Module.moduleId has been left the same, however the rules for defaulting its value have been significantly improved.
> The setting of each of these fields has been consolidated to one class and is now consistent across all the module types. Changes to that logic now affect all module types. It is also far easier to read -- the previous "if" blocks were terrible. A clean-up was long overdue.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OPENEJB-1442) Clarify and normalize all internal
module identifiers
Posted by "Shawn Jiang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENEJB-1442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Shawn Jiang updated OPENEJB-1442:
---------------------------------
Attachment: 0001-OPENEJB-1442-clean-up-remaining-misleading-moduleId-.patch
This patch is to clean up remaining misleading moduleId/moduleUri usage.
> Clarify and normalize all internal module identifiers
> -----------------------------------------------------
>
> Key: OPENEJB-1442
> URL: https://issues.apache.org/jira/browse/OPENEJB-1442
> Project: OpenEJB
> Issue Type: Task
> Components: container system
> Reporter: David Blevins
> Assignee: David Blevins
> Fix For: 4.0
>
> Attachments: 0001-OPENEJB-1442-clean-up-remaining-misleading-moduleId-.patch
>
>
> Currently we have three identifiers for a DeploymentModule: path, moduleId, and modulePackageName.
> module.path is the physical location of the module file on disk. We need this for scanning and finding descriptors.
> module.modulePackageName is the path to the module as the application knows it. We may have moved things around so it might be different.
> module.moduleId is the spec defined <module-name> string or the vendor-specific override for that string.
> ModulePackageName is really just used for resolving internal links which is all ultimately URI based, so modulePackageName has been changed to from String to URI and the link code improved to just use URIs rather than creating them temporarily. The new field name is moduleUri
> Module.Path is now represented internally as a File rather than String.
> Module.moduleId has been left the same, however the rules for defaulting its value have been significantly improved.
> The setting of each of these fields has been consolidated to one class and is now consistent across all the module types. Changes to that logic now affect all module types. It is also far easier to read -- the previous "if" blocks were terrible. A clean-up was long overdue.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira