You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@oodt.apache.org by "Chris A. Mattmann (JIRA)" <ji...@apache.org> on 2011/02/22 16:19:38 UTC
[jira] Created: (OODT-147) Completely refactor TypeHandling code
Completely refactor TypeHandling code
--------------------------------------
Key: OODT-147
URL: https://issues.apache.org/jira/browse/OODT-147
Project: OODT
Issue Type: Improvement
Components: file manager
Affects Versions: 0.2, 0.1-incubating
Environment: indep. of env.
Reporter: Chris A. Mattmann
Assignee: Chris A. Mattmann
Priority: Critical
Fix For: 0.3
The o.a.oodt.cas.filemgr.structs.type.* package contains code originally intended to strongly type Metadata elements within CAS file manager. IOW, it was originally conceived to make declaring a type for an Element easy. Consider the un-typed CAS file manager policy below:
{code}
<element id="urn:oodt:ProductReceivedTime" name="ProductReceivedTime">
..
</element>
{code}
which currently doesn't specify its type as a {noformat}Date{noformat} when it clearly is a {noformat}Date{noformat} element.
Type handling was supposed to take care of this. As it stands, there are a number of fundamental disconnects with type handling:
# There are absolutely 0 examples of how to use it. The existing example is not tailored for the general audience and does little to inform a user of what Type handling is supposed to do.
# Type handlers are attached to Product Type (repo manager) policy when instead they really should be a part of the Validation layer policy (i.e., elements.xml)
# Type handlers aren't configurable.
# There is no way to map a TypeHandler alias or name (e.g.., instead of having to declare the FQCN o.a.oodt.cas.filemgr.structs.type.DateTypeHandler, we should be able to specify DateType).
# The TypeHandler interface is dependent on a ProductType.
In order to address the above concerns I'm going to attach a patch that does the following:
# Moves type handler declarations to Validation layer policy (elements.xml).
# Refactors the TypeHandler interface to be configurable.
# Refactors the TypeHandler interface to be independent of ProductType.
# Allows for easy aliasing of TypeHandlers.
# By default assigns all default CAS elements that ship with the CAS file manager a default type.
# Adds a bunch more documentation.
# Adds unit tests.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OODT-147) Completely refactor TypeHandling code
Posted by "Brian Foster (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OODT-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998015#comment-12998015 ]
Brian Foster commented on OODT-147:
-----------------------------------
Not to start a he said you said, but you specifically total me that ElementId is computer ID and ElementName is human readable ID . . . there is code in the filemgr which relies on such a concept . . . for example in DataSourceCatalog assumes ElementName is unique:
{code}
public Metadata getReducedMetadata(Product product, List<String> elems) throws CatalogException {
...
elementIds += " OR element_id = '" + this.validationLayer.getElementByName(elems.get(i)).getElementId() + "'";
....
}
{code}
either way . . . even if you think i am misquoting you . . . i believe we should create an issue against the filemgr which adds the above method to ValidationLayer and ensures ElementName everywhere is treated as if it is not unique . . . the reason i'm being persistant here is because this particular issue is one of the primary reasons i had to branched the filemgr in wengine for PEATE . . . so i could add such methods to the ValidationLayer.
> Completely refactor TypeHandling code
> --------------------------------------
>
> Key: OODT-147
> URL: https://issues.apache.org/jira/browse/OODT-147
> Project: OODT
> Issue Type: Improvement
> Components: file manager
> Affects Versions: 0.1-incubating, 0.2
> Environment: indep. of env.
> Reporter: Chris A. Mattmann
> Assignee: Chris A. Mattmann
> Priority: Critical
> Labels: file, handling, manager, oodt, type
> Fix For: 0.3
>
>
> The o.a.oodt.cas.filemgr.structs.type.* package contains code originally intended to strongly type Metadata elements within CAS file manager. IOW, it was originally conceived to make declaring a type for an Element easy. Consider the un-typed CAS file manager policy below:
> {code}
> <element id="urn:oodt:ProductReceivedTime" name="ProductReceivedTime">
> ..
> </element>
> {code}
> which currently doesn't specify its type as a {noformat}Date{noformat} when it clearly is a {noformat}Date{noformat} element.
> Type handling was supposed to take care of this. As it stands, there are a number of fundamental disconnects with type handling:
> # There are absolutely 0 examples of how to use it. The existing example is not tailored for the general audience and does little to inform a user of what Type handling is supposed to do.
> # Type handlers are attached to Product Type (repo manager) policy when instead they really should be a part of the Validation layer policy (i.e., elements.xml)
> # Type handlers aren't configurable.
> # There is no way to map a TypeHandler alias or name (e.g.., instead of having to declare the FQCN o.a.oodt.cas.filemgr.structs.type.DateTypeHandler, we should be able to specify DateType).
> # The TypeHandler interface is dependent on a ProductType.
> In order to address the above concerns I'm going to attach a patch that does the following:
> # Moves type handler declarations to Validation layer policy (elements.xml).
> # Refactors the TypeHandler interface to be configurable.
> # Refactors the TypeHandler interface to be independent of ProductType.
> # Allows for easy aliasing of TypeHandlers.
> # By default assigns all default CAS elements that ship with the CAS file manager a default type.
> # Adds a bunch more documentation.
> # Adds unit tests.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OODT-147) Completely refactor TypeHandling code
Posted by "Chris A. Mattmann (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OODT-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997946#comment-12997946 ]
Chris A. Mattmann commented on OODT-147:
----------------------------------------
Haha, yeah I probably did to keep you off the critical path on that! :)
I think in reality we could always have multiple definitions of elements, with different TypeHandlers attached to them to solve the e.g., DataVersion, issue (e.g., elements are attached to product types keyed off ID, so it's perfectly acceptable to have):
{code:xml}
<!-- assume that Project1Type is an alias for some type handler -->
<element id="urn:project:DataVersion" name="DavaVersion"
type="Project1Type"/>
<!-- assume that Project2Type is an alias for a type handler-->
<element id="urn:project2:DataVersion" name="DataVersion"
type="Project2Type"/>
{code}
I'm working on supporting this in my patch...
> Completely refactor TypeHandling code
> --------------------------------------
>
> Key: OODT-147
> URL: https://issues.apache.org/jira/browse/OODT-147
> Project: OODT
> Issue Type: Improvement
> Components: file manager
> Affects Versions: 0.1-incubating, 0.2
> Environment: indep. of env.
> Reporter: Chris A. Mattmann
> Assignee: Chris A. Mattmann
> Priority: Critical
> Labels: file, handling, manager, oodt, type
> Fix For: 0.3
>
>
> The o.a.oodt.cas.filemgr.structs.type.* package contains code originally intended to strongly type Metadata elements within CAS file manager. IOW, it was originally conceived to make declaring a type for an Element easy. Consider the un-typed CAS file manager policy below:
> {code}
> <element id="urn:oodt:ProductReceivedTime" name="ProductReceivedTime">
> ..
> </element>
> {code}
> which currently doesn't specify its type as a {noformat}Date{noformat} when it clearly is a {noformat}Date{noformat} element.
> Type handling was supposed to take care of this. As it stands, there are a number of fundamental disconnects with type handling:
> # There are absolutely 0 examples of how to use it. The existing example is not tailored for the general audience and does little to inform a user of what Type handling is supposed to do.
> # Type handlers are attached to Product Type (repo manager) policy when instead they really should be a part of the Validation layer policy (i.e., elements.xml)
> # Type handlers aren't configurable.
> # There is no way to map a TypeHandler alias or name (e.g.., instead of having to declare the FQCN o.a.oodt.cas.filemgr.structs.type.DateTypeHandler, we should be able to specify DateType).
> # The TypeHandler interface is dependent on a ProductType.
> In order to address the above concerns I'm going to attach a patch that does the following:
> # Moves type handler declarations to Validation layer policy (elements.xml).
> # Refactors the TypeHandler interface to be configurable.
> # Refactors the TypeHandler interface to be independent of ProductType.
> # Allows for easy aliasing of TypeHandlers.
> # By default assigns all default CAS elements that ship with the CAS file manager a default type.
> # Adds a bunch more documentation.
> # Adds unit tests.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OODT-147) Completely refactor TypeHandling code
Posted by "Chris A. Mattmann (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OODT-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris A. Mattmann updated OODT-147:
-----------------------------------
- push out to 0.5
> Completely refactor TypeHandling code
> --------------------------------------
>
> Key: OODT-147
> URL: https://issues.apache.org/jira/browse/OODT-147
> Project: OODT
> Issue Type: Improvement
> Components: file manager
> Affects Versions: 0.1-incubating, 0.2
> Environment: indep. of env.
> Reporter: Chris A. Mattmann
> Assignee: Chris A. Mattmann
> Priority: Critical
> Labels: file, handling, manager, oodt, type
> Fix For: 0.5
>
>
> The o.a.oodt.cas.filemgr.structs.type.* package contains code originally intended to strongly type Metadata elements within CAS file manager. IOW, it was originally conceived to make declaring a type for an Element easy. Consider the un-typed CAS file manager policy below:
> {code}
> <element id="urn:oodt:ProductReceivedTime" name="ProductReceivedTime">
> ..
> </element>
> {code}
> which currently doesn't specify its type as a {noformat}Date{noformat} when it clearly is a {noformat}Date{noformat} element.
> Type handling was supposed to take care of this. As it stands, there are a number of fundamental disconnects with type handling:
> # There are absolutely 0 examples of how to use it. The existing example is not tailored for the general audience and does little to inform a user of what Type handling is supposed to do.
> # Type handlers are attached to Product Type (repo manager) policy when instead they really should be a part of the Validation layer policy (i.e., elements.xml)
> # Type handlers aren't configurable.
> # There is no way to map a TypeHandler alias or name (e.g.., instead of having to declare the FQCN o.a.oodt.cas.filemgr.structs.type.DateTypeHandler, we should be able to specify DateType).
> # The TypeHandler interface is dependent on a ProductType.
> In order to address the above concerns I'm going to attach a patch that does the following:
> # Moves type handler declarations to Validation layer policy (elements.xml).
> # Refactors the TypeHandler interface to be configurable.
> # Refactors the TypeHandler interface to be independent of ProductType.
> # Allows for easy aliasing of TypeHandlers.
> # By default assigns all default CAS elements that ship with the CAS file manager a default type.
> # Adds a bunch more documentation.
> # Adds unit tests.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (OODT-147) Completely refactor
TypeHandling code
Posted by "Brian Foster (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OODT-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997933#comment-12997933 ]
Brian Foster edited comment on OODT-147 at 2/22/11 6:10 PM:
------------------------------------------------------------
haha . . . chris, it is attached to ProductTypes and not Elements because you wouldn't let me when i first implemented it . . . this is because different TypeHandlers many times have to be specified for the same ElementName depending on the ProductType. For example, DataVersion is a field usually shared across multiple ProductTypes, however usually this field is very different for each ProductType (i.e. one ProductType may have a version which is of the format v01.02 where others are just integers -- the former requires a TypeHandler which enforces v\d{2}\.\d{2} and the latter would probably have a type handler which enforces \d{3}. If this where to be attached to Elements, then ElementName could not be unique (since i would need two Elements which the same name but different ids such that each of the Eleents could have their own TypeHandler and then attached to the appropriate ProductType and you where set on having ElementName unique (not just ElementId).
was (Author: bfoster):
haha . . . chris, it is attached to ProductTypes and not Elements because you wouldn't let me when i first implemented it . . . this is because different TypeHandlers many times have to be specified for the same ElementName depending on the ProductType. For example, DataVersion is a field usually shared across multiple ProductTypes, however usually this field is very different for each ProductType (i.e. one ProductType may have a version which is of the format v01.02 where others are just integers -- the former requires a TypeHandler which enforces v\d{2}\.\d{2} and the later would probably have a type handler which enforces \d{3}. If this where to be attached to Elements, then ElementName could not be unique (since i would need two Elements which the same name but different ids such that each of the Eleents could have their own TypeHandler and then attached to the appropriate ProductType and you where set on having ElementName unique (not just ElementId).
> Completely refactor TypeHandling code
> --------------------------------------
>
> Key: OODT-147
> URL: https://issues.apache.org/jira/browse/OODT-147
> Project: OODT
> Issue Type: Improvement
> Components: file manager
> Affects Versions: 0.1-incubating, 0.2
> Environment: indep. of env.
> Reporter: Chris A. Mattmann
> Assignee: Chris A. Mattmann
> Priority: Critical
> Labels: file, handling, manager, oodt, type
> Fix For: 0.3
>
>
> The o.a.oodt.cas.filemgr.structs.type.* package contains code originally intended to strongly type Metadata elements within CAS file manager. IOW, it was originally conceived to make declaring a type for an Element easy. Consider the un-typed CAS file manager policy below:
> {code}
> <element id="urn:oodt:ProductReceivedTime" name="ProductReceivedTime">
> ..
> </element>
> {code}
> which currently doesn't specify its type as a {noformat}Date{noformat} when it clearly is a {noformat}Date{noformat} element.
> Type handling was supposed to take care of this. As it stands, there are a number of fundamental disconnects with type handling:
> # There are absolutely 0 examples of how to use it. The existing example is not tailored for the general audience and does little to inform a user of what Type handling is supposed to do.
> # Type handlers are attached to Product Type (repo manager) policy when instead they really should be a part of the Validation layer policy (i.e., elements.xml)
> # Type handlers aren't configurable.
> # There is no way to map a TypeHandler alias or name (e.g.., instead of having to declare the FQCN o.a.oodt.cas.filemgr.structs.type.DateTypeHandler, we should be able to specify DateType).
> # The TypeHandler interface is dependent on a ProductType.
> In order to address the above concerns I'm going to attach a patch that does the following:
> # Moves type handler declarations to Validation layer policy (elements.xml).
> # Refactors the TypeHandler interface to be configurable.
> # Refactors the TypeHandler interface to be independent of ProductType.
> # Allows for easy aliasing of TypeHandlers.
> # By default assigns all default CAS elements that ship with the CAS file manager a default type.
> # Adds a bunch more documentation.
> # Adds unit tests.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (OODT-147) Completely refactor
TypeHandling code
Posted by "Chris A. Mattmann (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OODT-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998041#comment-12998041 ]
Chris A. Mattmann edited comment on OODT-147 at 2/22/11 9:12 PM:
-----------------------------------------------------------------
Hi Brian:
bq. Not to start a he said you said, but you specifically total me that ElementId is computer ID and ElementName is human readable ID
And how specifically is what I'm saying in violation of that statement (that I did make, to leverage as an analogy to illustrate the concept)? The element ID *is* the only part of the Element that I've said *must* be unique.
bq. there is code in the filemgr which relies on such a concept . . . for example in DataSourceCatalog assumes ElementName is unique:
So? That's an implementation of an extension point for the Catalog. It's not a concrete, core class. There are other Catalog implementations. Furthermore, the above code *does not* rely on the fact that the Element name is unique -- as I said -- the behavior of getElementByName is such that it should only return the first (and possibly only) matching Element with the given name. If there is only one element (or even many Elements) the Catalog implementation still functions as expected.
bq. i believe we should create an issue against the filemgr which adds the above method to ValidationLayer and ensures ElementName everywhere is treated as if it is not unique
I'm happy to add the above method, but there isn't anything else across the file manager that needs to be done.
bq. the reason i'm being persistant here is because this particular issue is one of the primary reasons i had to branched the filemgr in wengine for PEATE . . . so i could add such methods to the ValidationLayer.
So basically what you're saying is that you had to branch an entire major component of the system rather than simply extending the existing component and writing your own ValidationLayer, as was intended when the extension point was created? I'm not buying that, sorry. ValidationLayers are hidden in the catalog implementation and thus don't have any specific contract on their particular interface other than a few core methods. You could have arbitrarily added methods to *your ValidationLayer implementation* without changing *any of the core code* in the File Manager.
was (Author: chrismattmann):
Hi Brian:
bq. Not to start a he said you said, but you specifically total me that ElementId is computer ID and ElementName is human readable ID
And how specifically is what I'm saying in violation of that statement (that I did make, to leverage as an analogy to illustrate the concept)? The element ID *is* the only part of the Element that I've said *must* be unique.
bq. there is code in the filemgr which relies on such a concept . . . for example in DataSourceCatalog assumes ElementName is unique:
So? That's an implementation of an extension point for the Catalog. It's not a concrete, core classes. There are other Catalog implementations. Furthermore, the above code *does not* rely on the fact that the Element name is unique -- as I said -- the behavior of getElementByName is such that it should only return the first (and possibly only) matching Element with the given name. If there is only one element (or even many Elements) the Catalog implementation still functions as expected.
bq. i believe we should create an issue against the filemgr which adds the above method to ValidationLayer and ensures ElementName everywhere is treated as if it is not unique
I'm happy to add the above method, but there isn't anything else across the file manager that needs to be done.
bq. the reason i'm being persistant here is because this particular issue is one of the primary reasons i had to branched the filemgr in wengine for PEATE . . . so i could add such methods to the ValidationLayer.
So basically what you're saying is that you had to branch an entire major component of the system rather than simply extending the existing component and writing your own ValidationLayer, as was intended when the extension point was created? I'm not buying that, sorry. ValidationLayers are hidden in the catalog implementation and thus don't have any specific contract on their particular interface other than a few core methods. You could have arbitrarily added methods to *your ValidationLayer implementation* without changing *any of the core code* in the File Manager.
> Completely refactor TypeHandling code
> --------------------------------------
>
> Key: OODT-147
> URL: https://issues.apache.org/jira/browse/OODT-147
> Project: OODT
> Issue Type: Improvement
> Components: file manager
> Affects Versions: 0.1-incubating, 0.2
> Environment: indep. of env.
> Reporter: Chris A. Mattmann
> Assignee: Chris A. Mattmann
> Priority: Critical
> Labels: file, handling, manager, oodt, type
> Fix For: 0.3
>
>
> The o.a.oodt.cas.filemgr.structs.type.* package contains code originally intended to strongly type Metadata elements within CAS file manager. IOW, it was originally conceived to make declaring a type for an Element easy. Consider the un-typed CAS file manager policy below:
> {code}
> <element id="urn:oodt:ProductReceivedTime" name="ProductReceivedTime">
> ..
> </element>
> {code}
> which currently doesn't specify its type as a {noformat}Date{noformat} when it clearly is a {noformat}Date{noformat} element.
> Type handling was supposed to take care of this. As it stands, there are a number of fundamental disconnects with type handling:
> # There are absolutely 0 examples of how to use it. The existing example is not tailored for the general audience and does little to inform a user of what Type handling is supposed to do.
> # Type handlers are attached to Product Type (repo manager) policy when instead they really should be a part of the Validation layer policy (i.e., elements.xml)
> # Type handlers aren't configurable.
> # There is no way to map a TypeHandler alias or name (e.g.., instead of having to declare the FQCN o.a.oodt.cas.filemgr.structs.type.DateTypeHandler, we should be able to specify DateType).
> # The TypeHandler interface is dependent on a ProductType.
> In order to address the above concerns I'm going to attach a patch that does the following:
> # Moves type handler declarations to Validation layer policy (elements.xml).
> # Refactors the TypeHandler interface to be configurable.
> # Refactors the TypeHandler interface to be independent of ProductType.
> # Allows for easy aliasing of TypeHandlers.
> # By default assigns all default CAS elements that ship with the CAS file manager a default type.
> # Adds a bunch more documentation.
> # Adds unit tests.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OODT-147) Completely refactor TypeHandling code
Posted by "Brian Foster (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OODT-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997933#comment-12997933 ]
Brian Foster commented on OODT-147:
-----------------------------------
haha . . . chris, it is attached to ProductTypes and not Elements because you wouldn't let me when i first implemented it . . . this is because different TypeHandlers many times have to be specified for the same ElementName depending on the ProductType. For example, DataVersion is a field usually shared across multiple ProductTypes, however usually this field is very different for each ProductType (i.e. one ProductType may have a version which is of the format v01.02 where others are just integers -- the former requires a TypeHandler which enforces v\d{2}\.\d{2} and the later would probably have a type handler which enforces \d{3}. If this where to be attached to Elements, then ElementName could not be unique (since i would need two Elements which the same name but different ids such that each of the Eleents could have their own TypeHandler and then attached to the appropriate ProductType and you where set on having ElementName unique (not just ElementId).
> Completely refactor TypeHandling code
> --------------------------------------
>
> Key: OODT-147
> URL: https://issues.apache.org/jira/browse/OODT-147
> Project: OODT
> Issue Type: Improvement
> Components: file manager
> Affects Versions: 0.1-incubating, 0.2
> Environment: indep. of env.
> Reporter: Chris A. Mattmann
> Assignee: Chris A. Mattmann
> Priority: Critical
> Labels: file, handling, manager, oodt, type
> Fix For: 0.3
>
>
> The o.a.oodt.cas.filemgr.structs.type.* package contains code originally intended to strongly type Metadata elements within CAS file manager. IOW, it was originally conceived to make declaring a type for an Element easy. Consider the un-typed CAS file manager policy below:
> {code}
> <element id="urn:oodt:ProductReceivedTime" name="ProductReceivedTime">
> ..
> </element>
> {code}
> which currently doesn't specify its type as a {noformat}Date{noformat} when it clearly is a {noformat}Date{noformat} element.
> Type handling was supposed to take care of this. As it stands, there are a number of fundamental disconnects with type handling:
> # There are absolutely 0 examples of how to use it. The existing example is not tailored for the general audience and does little to inform a user of what Type handling is supposed to do.
> # Type handlers are attached to Product Type (repo manager) policy when instead they really should be a part of the Validation layer policy (i.e., elements.xml)
> # Type handlers aren't configurable.
> # There is no way to map a TypeHandler alias or name (e.g.., instead of having to declare the FQCN o.a.oodt.cas.filemgr.structs.type.DateTypeHandler, we should be able to specify DateType).
> # The TypeHandler interface is dependent on a ProductType.
> In order to address the above concerns I'm going to attach a patch that does the following:
> # Moves type handler declarations to Validation layer policy (elements.xml).
> # Refactors the TypeHandler interface to be configurable.
> # Refactors the TypeHandler interface to be independent of ProductType.
> # Allows for easy aliasing of TypeHandlers.
> # By default assigns all default CAS elements that ship with the CAS file manager a default type.
> # Adds a bunch more documentation.
> # Adds unit tests.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (OODT-147) Completely refactor
TypeHandling code
Posted by "Chris A. Mattmann (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OODT-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997946#comment-12997946 ]
Chris A. Mattmann edited comment on OODT-147 at 2/22/11 6:31 PM:
-----------------------------------------------------------------
Haha, yeah I probably did to keep you off the critical path on that! :)
I think in reality we could always have multiple definitions of elements, with different TypeHandlers attached to them to solve the e.g., DataVersion, issue (e.g., elements are attached to product types keyed off ID, so it's perfectly acceptable to have):
{code:xml}
<!-- assume that Project1Type is an alias for some type handler -->
<element id="urn:project:DataVersion" name="DataVersion"
type="Project1Type"/>
<!-- assume that Project2Type is an alias for a type handler-->
<element id="urn:project2:DataVersion" name="DataVersion"
type="Project2Type"/>
{code}
I'm working on supporting this in my patch...
was (Author: chrismattmann):
Haha, yeah I probably did to keep you off the critical path on that! :)
I think in reality we could always have multiple definitions of elements, with different TypeHandlers attached to them to solve the e.g., DataVersion, issue (e.g., elements are attached to product types keyed off ID, so it's perfectly acceptable to have):
{code:xml}
<!-- assume that Project1Type is an alias for some type handler -->
<element id="urn:project:DataVersion" name="DavaVersion"
type="Project1Type"/>
<!-- assume that Project2Type is an alias for a type handler-->
<element id="urn:project2:DataVersion" name="DataVersion"
type="Project2Type"/>
{code}
I'm working on supporting this in my patch...
> Completely refactor TypeHandling code
> --------------------------------------
>
> Key: OODT-147
> URL: https://issues.apache.org/jira/browse/OODT-147
> Project: OODT
> Issue Type: Improvement
> Components: file manager
> Affects Versions: 0.1-incubating, 0.2
> Environment: indep. of env.
> Reporter: Chris A. Mattmann
> Assignee: Chris A. Mattmann
> Priority: Critical
> Labels: file, handling, manager, oodt, type
> Fix For: 0.3
>
>
> The o.a.oodt.cas.filemgr.structs.type.* package contains code originally intended to strongly type Metadata elements within CAS file manager. IOW, it was originally conceived to make declaring a type for an Element easy. Consider the un-typed CAS file manager policy below:
> {code}
> <element id="urn:oodt:ProductReceivedTime" name="ProductReceivedTime">
> ..
> </element>
> {code}
> which currently doesn't specify its type as a {noformat}Date{noformat} when it clearly is a {noformat}Date{noformat} element.
> Type handling was supposed to take care of this. As it stands, there are a number of fundamental disconnects with type handling:
> # There are absolutely 0 examples of how to use it. The existing example is not tailored for the general audience and does little to inform a user of what Type handling is supposed to do.
> # Type handlers are attached to Product Type (repo manager) policy when instead they really should be a part of the Validation layer policy (i.e., elements.xml)
> # Type handlers aren't configurable.
> # There is no way to map a TypeHandler alias or name (e.g.., instead of having to declare the FQCN o.a.oodt.cas.filemgr.structs.type.DateTypeHandler, we should be able to specify DateType).
> # The TypeHandler interface is dependent on a ProductType.
> In order to address the above concerns I'm going to attach a patch that does the following:
> # Moves type handler declarations to Validation layer policy (elements.xml).
> # Refactors the TypeHandler interface to be configurable.
> # Refactors the TypeHandler interface to be independent of ProductType.
> # Allows for easy aliasing of TypeHandlers.
> # By default assigns all default CAS elements that ship with the CAS file manager a default type.
> # Adds a bunch more documentation.
> # Adds unit tests.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OODT-147) Completely refactor TypeHandling code
Posted by "Paul Ramirez (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OODT-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997857#comment-12997857 ]
Paul Ramirez commented on OODT-147:
-----------------------------------
+1, having types will be nice. It looks as the current TypeHandler was possibly trying to do this? Although it also seems to be a blend of value mapping and met extractor functionality. Although, I've never used it so I'd probably have to lean on Brian, since he wrote that code, to describe what use cases it was trying to satisfy.
Starting with the basic types such as Integer, Double, Date, etc. would be nice as I'm sure there is a lot of functionality that would satisfy many of the use cases that would come along. Some minimal implementation of these types plus an extension place for adding one's own type would be a big win.
If the current functionality of the TypeHandler code is to do value mapping for queries and metadata then that should likely be more thought out.
> Completely refactor TypeHandling code
> --------------------------------------
>
> Key: OODT-147
> URL: https://issues.apache.org/jira/browse/OODT-147
> Project: OODT
> Issue Type: Improvement
> Components: file manager
> Affects Versions: 0.1-incubating, 0.2
> Environment: indep. of env.
> Reporter: Chris A. Mattmann
> Assignee: Chris A. Mattmann
> Priority: Critical
> Labels: file, handling, manager, oodt, type
> Fix For: 0.3
>
>
> The o.a.oodt.cas.filemgr.structs.type.* package contains code originally intended to strongly type Metadata elements within CAS file manager. IOW, it was originally conceived to make declaring a type for an Element easy. Consider the un-typed CAS file manager policy below:
> {code}
> <element id="urn:oodt:ProductReceivedTime" name="ProductReceivedTime">
> ..
> </element>
> {code}
> which currently doesn't specify its type as a {noformat}Date{noformat} when it clearly is a {noformat}Date{noformat} element.
> Type handling was supposed to take care of this. As it stands, there are a number of fundamental disconnects with type handling:
> # There are absolutely 0 examples of how to use it. The existing example is not tailored for the general audience and does little to inform a user of what Type handling is supposed to do.
> # Type handlers are attached to Product Type (repo manager) policy when instead they really should be a part of the Validation layer policy (i.e., elements.xml)
> # Type handlers aren't configurable.
> # There is no way to map a TypeHandler alias or name (e.g.., instead of having to declare the FQCN o.a.oodt.cas.filemgr.structs.type.DateTypeHandler, we should be able to specify DateType).
> # The TypeHandler interface is dependent on a ProductType.
> In order to address the above concerns I'm going to attach a patch that does the following:
> # Moves type handler declarations to Validation layer policy (elements.xml).
> # Refactors the TypeHandler interface to be configurable.
> # Refactors the TypeHandler interface to be independent of ProductType.
> # Allows for easy aliasing of TypeHandlers.
> # By default assigns all default CAS elements that ship with the CAS file manager a default type.
> # Adds a bunch more documentation.
> # Adds unit tests.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OODT-147) Completely refactor TypeHandling code
Posted by "Chris A. Mattmann (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OODT-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris A. Mattmann updated OODT-147:
-----------------------------------
Fix Version/s: (was: 0.4)
0.5
- push to 0.5
> Completely refactor TypeHandling code
> --------------------------------------
>
> Key: OODT-147
> URL: https://issues.apache.org/jira/browse/OODT-147
> Project: OODT
> Issue Type: Improvement
> Components: file manager
> Affects Versions: 0.1-incubating, 0.2
> Environment: indep. of env.
> Reporter: Chris A. Mattmann
> Assignee: Chris A. Mattmann
> Priority: Critical
> Labels: file, handling, manager, oodt, type
> Fix For: 0.5
>
>
> The o.a.oodt.cas.filemgr.structs.type.* package contains code originally intended to strongly type Metadata elements within CAS file manager. IOW, it was originally conceived to make declaring a type for an Element easy. Consider the un-typed CAS file manager policy below:
> {code}
> <element id="urn:oodt:ProductReceivedTime" name="ProductReceivedTime">
> ..
> </element>
> {code}
> which currently doesn't specify its type as a {noformat}Date{noformat} when it clearly is a {noformat}Date{noformat} element.
> Type handling was supposed to take care of this. As it stands, there are a number of fundamental disconnects with type handling:
> # There are absolutely 0 examples of how to use it. The existing example is not tailored for the general audience and does little to inform a user of what Type handling is supposed to do.
> # Type handlers are attached to Product Type (repo manager) policy when instead they really should be a part of the Validation layer policy (i.e., elements.xml)
> # Type handlers aren't configurable.
> # There is no way to map a TypeHandler alias or name (e.g.., instead of having to declare the FQCN o.a.oodt.cas.filemgr.structs.type.DateTypeHandler, we should be able to specify DateType).
> # The TypeHandler interface is dependent on a ProductType.
> In order to address the above concerns I'm going to attach a patch that does the following:
> # Moves type handler declarations to Validation layer policy (elements.xml).
> # Refactors the TypeHandler interface to be configurable.
> # Refactors the TypeHandler interface to be independent of ProductType.
> # Allows for easy aliasing of TypeHandlers.
> # By default assigns all default CAS elements that ship with the CAS file manager a default type.
> # Adds a bunch more documentation.
> # Adds unit tests.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OODT-147) Completely refactor TypeHandling code
Posted by "Chris A. Mattmann (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OODT-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris A. Mattmann updated OODT-147:
-----------------------------------
Priority: Major (was: Critical)
> Completely refactor TypeHandling code
> --------------------------------------
>
> Key: OODT-147
> URL: https://issues.apache.org/jira/browse/OODT-147
> Project: OODT
> Issue Type: Improvement
> Components: file manager
> Affects Versions: 0.1-incubating, 0.2
> Environment: indep. of env.
> Reporter: Chris A. Mattmann
> Assignee: Chris A. Mattmann
> Labels: file, handling, manager, oodt, type
> Fix For: 0.5
>
>
> The o.a.oodt.cas.filemgr.structs.type.* package contains code originally intended to strongly type Metadata elements within CAS file manager. IOW, it was originally conceived to make declaring a type for an Element easy. Consider the un-typed CAS file manager policy below:
> {code}
> <element id="urn:oodt:ProductReceivedTime" name="ProductReceivedTime">
> ..
> </element>
> {code}
> which currently doesn't specify its type as a {noformat}Date{noformat} when it clearly is a {noformat}Date{noformat} element.
> Type handling was supposed to take care of this. As it stands, there are a number of fundamental disconnects with type handling:
> # There are absolutely 0 examples of how to use it. The existing example is not tailored for the general audience and does little to inform a user of what Type handling is supposed to do.
> # Type handlers are attached to Product Type (repo manager) policy when instead they really should be a part of the Validation layer policy (i.e., elements.xml)
> # Type handlers aren't configurable.
> # There is no way to map a TypeHandler alias or name (e.g.., instead of having to declare the FQCN o.a.oodt.cas.filemgr.structs.type.DateTypeHandler, we should be able to specify DateType).
> # The TypeHandler interface is dependent on a ProductType.
> In order to address the above concerns I'm going to attach a patch that does the following:
> # Moves type handler declarations to Validation layer policy (elements.xml).
> # Refactors the TypeHandler interface to be configurable.
> # Refactors the TypeHandler interface to be independent of ProductType.
> # Allows for easy aliasing of TypeHandlers.
> # By default assigns all default CAS elements that ship with the CAS file manager a default type.
> # Adds a bunch more documentation.
> # Adds unit tests.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (OODT-147) Completely refactor
TypeHandling code
Posted by "Paul Ramirez (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OODT-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997857#comment-12997857 ]
Paul Ramirez edited comment on OODT-147 at 2/22/11 3:43 PM:
------------------------------------------------------------
+1, having types will be nice. It looks as the current TypeHandler was possibly trying to do this? Although it also seems to be a blend of value mapping and met extractor functionality. Although, I've never used it so I'd probably have to lean on Brian, since he wrote that code, to describe what use cases it was trying to satisfy.
Starting with the basic types such as Integer, Double, Date, etc. would be nice as I'm sure there is a lot of functionality that would satisfy many of the use cases that would come along. Some minimal implementation of these types plus an extension place for adding one's own type would be a big win.
If the current functionality of the TypeHandler code is to do value mapping for queries and metadata then that should likely be more thought out. For instance, is that done server side or client side? Is it transparent to the user? How and where is it configured? Is this something that can be used outside the filemgr framework?
was (Author: pramirez):
+1, having types will be nice. It looks as the current TypeHandler was possibly trying to do this? Although it also seems to be a blend of value mapping and met extractor functionality. Although, I've never used it so I'd probably have to lean on Brian, since he wrote that code, to describe what use cases it was trying to satisfy.
Starting with the basic types such as Integer, Double, Date, etc. would be nice as I'm sure there is a lot of functionality that would satisfy many of the use cases that would come along. Some minimal implementation of these types plus an extension place for adding one's own type would be a big win.
If the current functionality of the TypeHandler code is to do value mapping for queries and metadata then that should likely be more thought out.
> Completely refactor TypeHandling code
> --------------------------------------
>
> Key: OODT-147
> URL: https://issues.apache.org/jira/browse/OODT-147
> Project: OODT
> Issue Type: Improvement
> Components: file manager
> Affects Versions: 0.1-incubating, 0.2
> Environment: indep. of env.
> Reporter: Chris A. Mattmann
> Assignee: Chris A. Mattmann
> Priority: Critical
> Labels: file, handling, manager, oodt, type
> Fix For: 0.3
>
>
> The o.a.oodt.cas.filemgr.structs.type.* package contains code originally intended to strongly type Metadata elements within CAS file manager. IOW, it was originally conceived to make declaring a type for an Element easy. Consider the un-typed CAS file manager policy below:
> {code}
> <element id="urn:oodt:ProductReceivedTime" name="ProductReceivedTime">
> ..
> </element>
> {code}
> which currently doesn't specify its type as a {noformat}Date{noformat} when it clearly is a {noformat}Date{noformat} element.
> Type handling was supposed to take care of this. As it stands, there are a number of fundamental disconnects with type handling:
> # There are absolutely 0 examples of how to use it. The existing example is not tailored for the general audience and does little to inform a user of what Type handling is supposed to do.
> # Type handlers are attached to Product Type (repo manager) policy when instead they really should be a part of the Validation layer policy (i.e., elements.xml)
> # Type handlers aren't configurable.
> # There is no way to map a TypeHandler alias or name (e.g.., instead of having to declare the FQCN o.a.oodt.cas.filemgr.structs.type.DateTypeHandler, we should be able to specify DateType).
> # The TypeHandler interface is dependent on a ProductType.
> In order to address the above concerns I'm going to attach a patch that does the following:
> # Moves type handler declarations to Validation layer policy (elements.xml).
> # Refactors the TypeHandler interface to be configurable.
> # Refactors the TypeHandler interface to be independent of ProductType.
> # Allows for easy aliasing of TypeHandlers.
> # By default assigns all default CAS elements that ship with the CAS file manager a default type.
> # Adds a bunch more documentation.
> # Adds unit tests.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OODT-147) Completely refactor TypeHandling code
Posted by "Chris A. Mattmann (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OODT-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris A. Mattmann updated OODT-147:
-----------------------------------
Fix Version/s: (was: 0.3)
0.4
> Completely refactor TypeHandling code
> --------------------------------------
>
> Key: OODT-147
> URL: https://issues.apache.org/jira/browse/OODT-147
> Project: OODT
> Issue Type: Improvement
> Components: file manager
> Affects Versions: 0.1-incubating, 0.2
> Environment: indep. of env.
> Reporter: Chris A. Mattmann
> Assignee: Chris A. Mattmann
> Priority: Critical
> Labels: file, handling, manager, oodt, type
> Fix For: 0.4
>
>
> The o.a.oodt.cas.filemgr.structs.type.* package contains code originally intended to strongly type Metadata elements within CAS file manager. IOW, it was originally conceived to make declaring a type for an Element easy. Consider the un-typed CAS file manager policy below:
> {code}
> <element id="urn:oodt:ProductReceivedTime" name="ProductReceivedTime">
> ..
> </element>
> {code}
> which currently doesn't specify its type as a {noformat}Date{noformat} when it clearly is a {noformat}Date{noformat} element.
> Type handling was supposed to take care of this. As it stands, there are a number of fundamental disconnects with type handling:
> # There are absolutely 0 examples of how to use it. The existing example is not tailored for the general audience and does little to inform a user of what Type handling is supposed to do.
> # Type handlers are attached to Product Type (repo manager) policy when instead they really should be a part of the Validation layer policy (i.e., elements.xml)
> # Type handlers aren't configurable.
> # There is no way to map a TypeHandler alias or name (e.g.., instead of having to declare the FQCN o.a.oodt.cas.filemgr.structs.type.DateTypeHandler, we should be able to specify DateType).
> # The TypeHandler interface is dependent on a ProductType.
> In order to address the above concerns I'm going to attach a patch that does the following:
> # Moves type handler declarations to Validation layer policy (elements.xml).
> # Refactors the TypeHandler interface to be configurable.
> # Refactors the TypeHandler interface to be independent of ProductType.
> # Allows for easy aliasing of TypeHandlers.
> # By default assigns all default CAS elements that ship with the CAS file manager a default type.
> # Adds a bunch more documentation.
> # Adds unit tests.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OODT-147) Completely refactor TypeHandling code
Posted by "Chris A. Mattmann (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OODT-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998057#comment-12998057 ]
Chris A. Mattmann commented on OODT-147:
----------------------------------------
Hi Brian:
Can you elaborate on where exactly you changed code in the ValidationLayer interface? Why couldn't this be dealt with via subclassing? The ValidationLayer is hidden in a Catalog so why couldn't you just have a PEATEValidationLayer?
In addition DataSourceCatalog works fine like I said with getElementByName, so there's not really an issue....
> Completely refactor TypeHandling code
> --------------------------------------
>
> Key: OODT-147
> URL: https://issues.apache.org/jira/browse/OODT-147
> Project: OODT
> Issue Type: Improvement
> Components: file manager
> Affects Versions: 0.1-incubating, 0.2
> Environment: indep. of env.
> Reporter: Chris A. Mattmann
> Assignee: Chris A. Mattmann
> Priority: Critical
> Labels: file, handling, manager, oodt, type
> Fix For: 0.3
>
>
> The o.a.oodt.cas.filemgr.structs.type.* package contains code originally intended to strongly type Metadata elements within CAS file manager. IOW, it was originally conceived to make declaring a type for an Element easy. Consider the un-typed CAS file manager policy below:
> {code}
> <element id="urn:oodt:ProductReceivedTime" name="ProductReceivedTime">
> ..
> </element>
> {code}
> which currently doesn't specify its type as a {noformat}Date{noformat} when it clearly is a {noformat}Date{noformat} element.
> Type handling was supposed to take care of this. As it stands, there are a number of fundamental disconnects with type handling:
> # There are absolutely 0 examples of how to use it. The existing example is not tailored for the general audience and does little to inform a user of what Type handling is supposed to do.
> # Type handlers are attached to Product Type (repo manager) policy when instead they really should be a part of the Validation layer policy (i.e., elements.xml)
> # Type handlers aren't configurable.
> # There is no way to map a TypeHandler alias or name (e.g.., instead of having to declare the FQCN o.a.oodt.cas.filemgr.structs.type.DateTypeHandler, we should be able to specify DateType).
> # The TypeHandler interface is dependent on a ProductType.
> In order to address the above concerns I'm going to attach a patch that does the following:
> # Moves type handler declarations to Validation layer policy (elements.xml).
> # Refactors the TypeHandler interface to be configurable.
> # Refactors the TypeHandler interface to be independent of ProductType.
> # Allows for easy aliasing of TypeHandlers.
> # By default assigns all default CAS elements that ship with the CAS file manager a default type.
> # Adds a bunch more documentation.
> # Adds unit tests.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OODT-147) Completely refactor TypeHandling code
Posted by "Brian Foster (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OODT-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998056#comment-12998056 ]
Brian Foster commented on OODT-147:
-----------------------------------
i branched the component because i had to change the ValidationLayer interface and thus code in the XmlRpcFileManager (i.e. as core as they come) changed as well so that way it could utilize it . . . DataSourceCatalog was just an example of one place . . . there are others . . . also DataSourceCatalog is one of the core implementations of a FileManager Catalog, therefore it should be implemented in such a way that is clear to design implementations for the FileManager since most developers will be using that as a starting point for writing their own DataSourceCatalog implementation.
> Completely refactor TypeHandling code
> --------------------------------------
>
> Key: OODT-147
> URL: https://issues.apache.org/jira/browse/OODT-147
> Project: OODT
> Issue Type: Improvement
> Components: file manager
> Affects Versions: 0.1-incubating, 0.2
> Environment: indep. of env.
> Reporter: Chris A. Mattmann
> Assignee: Chris A. Mattmann
> Priority: Critical
> Labels: file, handling, manager, oodt, type
> Fix For: 0.3
>
>
> The o.a.oodt.cas.filemgr.structs.type.* package contains code originally intended to strongly type Metadata elements within CAS file manager. IOW, it was originally conceived to make declaring a type for an Element easy. Consider the un-typed CAS file manager policy below:
> {code}
> <element id="urn:oodt:ProductReceivedTime" name="ProductReceivedTime">
> ..
> </element>
> {code}
> which currently doesn't specify its type as a {noformat}Date{noformat} when it clearly is a {noformat}Date{noformat} element.
> Type handling was supposed to take care of this. As it stands, there are a number of fundamental disconnects with type handling:
> # There are absolutely 0 examples of how to use it. The existing example is not tailored for the general audience and does little to inform a user of what Type handling is supposed to do.
> # Type handlers are attached to Product Type (repo manager) policy when instead they really should be a part of the Validation layer policy (i.e., elements.xml)
> # Type handlers aren't configurable.
> # There is no way to map a TypeHandler alias or name (e.g.., instead of having to declare the FQCN o.a.oodt.cas.filemgr.structs.type.DateTypeHandler, we should be able to specify DateType).
> # The TypeHandler interface is dependent on a ProductType.
> In order to address the above concerns I'm going to attach a patch that does the following:
> # Moves type handler declarations to Validation layer policy (elements.xml).
> # Refactors the TypeHandler interface to be configurable.
> # Refactors the TypeHandler interface to be independent of ProductType.
> # Allows for easy aliasing of TypeHandlers.
> # By default assigns all default CAS elements that ship with the CAS file manager a default type.
> # Adds a bunch more documentation.
> # Adds unit tests.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OODT-147) Completely refactor TypeHandling code
Posted by "Brian Foster (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OODT-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997959#comment-12997959 ]
Brian Foster commented on OODT-147:
-----------------------------------
okay . . . then i would argue that ValidationLayer method:
{code}
public Element getElementByName(String elementName)
throws ValidationLayerException;
{code}
gets changed to:
{code}
public Element getElementByName(String elementName, ProductType productType)
throws ValidationLayerException;
{code}
because that method is ambiguous then, since the architecture is now that ElementName is not unique
> Completely refactor TypeHandling code
> --------------------------------------
>
> Key: OODT-147
> URL: https://issues.apache.org/jira/browse/OODT-147
> Project: OODT
> Issue Type: Improvement
> Components: file manager
> Affects Versions: 0.1-incubating, 0.2
> Environment: indep. of env.
> Reporter: Chris A. Mattmann
> Assignee: Chris A. Mattmann
> Priority: Critical
> Labels: file, handling, manager, oodt, type
> Fix For: 0.3
>
>
> The o.a.oodt.cas.filemgr.structs.type.* package contains code originally intended to strongly type Metadata elements within CAS file manager. IOW, it was originally conceived to make declaring a type for an Element easy. Consider the un-typed CAS file manager policy below:
> {code}
> <element id="urn:oodt:ProductReceivedTime" name="ProductReceivedTime">
> ..
> </element>
> {code}
> which currently doesn't specify its type as a {noformat}Date{noformat} when it clearly is a {noformat}Date{noformat} element.
> Type handling was supposed to take care of this. As it stands, there are a number of fundamental disconnects with type handling:
> # There are absolutely 0 examples of how to use it. The existing example is not tailored for the general audience and does little to inform a user of what Type handling is supposed to do.
> # Type handlers are attached to Product Type (repo manager) policy when instead they really should be a part of the Validation layer policy (i.e., elements.xml)
> # Type handlers aren't configurable.
> # There is no way to map a TypeHandler alias or name (e.g.., instead of having to declare the FQCN o.a.oodt.cas.filemgr.structs.type.DateTypeHandler, we should be able to specify DateType).
> # The TypeHandler interface is dependent on a ProductType.
> In order to address the above concerns I'm going to attach a patch that does the following:
> # Moves type handler declarations to Validation layer policy (elements.xml).
> # Refactors the TypeHandler interface to be configurable.
> # Refactors the TypeHandler interface to be independent of ProductType.
> # Allows for easy aliasing of TypeHandlers.
> # By default assigns all default CAS elements that ship with the CAS file manager a default type.
> # Adds a bunch more documentation.
> # Adds unit tests.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (OODT-147) Completely refactor
TypeHandling code
Posted by "Brian Foster (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OODT-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997933#comment-12997933 ]
Brian Foster edited comment on OODT-147 at 2/22/11 6:11 PM:
------------------------------------------------------------
haha . . . chris, it is attached to ProductTypes and not Elements because you wouldn't let me when i first implemented it . . . this is because different TypeHandlers many times have to be specified for the same ElementName depending on the ProductType. For example, DataVersion is a field usually shared across multiple ProductTypes, however usually this field is very different for each ProductType (i.e. one ProductType may have a version which is of the format v01.02 where others are just integers -- the former requires a TypeHandler which enforces v\d{2}\.\d{2} and the latter would probably have a type handler which enforces \d{3}. If this where to be attached to Elements, then ElementName could not be unique -- since i would need two Elements with the same name but different ids such that each of the Eleents could have their own TypeHandler and then attached to the appropriate ProductType and you where set on having ElementName unique (not just ElementId).
was (Author: bfoster):
haha . . . chris, it is attached to ProductTypes and not Elements because you wouldn't let me when i first implemented it . . . this is because different TypeHandlers many times have to be specified for the same ElementName depending on the ProductType. For example, DataVersion is a field usually shared across multiple ProductTypes, however usually this field is very different for each ProductType (i.e. one ProductType may have a version which is of the format v01.02 where others are just integers -- the former requires a TypeHandler which enforces v\d{2}\.\d{2} and the latter would probably have a type handler which enforces \d{3}. If this where to be attached to Elements, then ElementName could not be unique (since i would need two Elements which the same name but different ids such that each of the Eleents could have their own TypeHandler and then attached to the appropriate ProductType and you where set on having ElementName unique (not just ElementId).
> Completely refactor TypeHandling code
> --------------------------------------
>
> Key: OODT-147
> URL: https://issues.apache.org/jira/browse/OODT-147
> Project: OODT
> Issue Type: Improvement
> Components: file manager
> Affects Versions: 0.1-incubating, 0.2
> Environment: indep. of env.
> Reporter: Chris A. Mattmann
> Assignee: Chris A. Mattmann
> Priority: Critical
> Labels: file, handling, manager, oodt, type
> Fix For: 0.3
>
>
> The o.a.oodt.cas.filemgr.structs.type.* package contains code originally intended to strongly type Metadata elements within CAS file manager. IOW, it was originally conceived to make declaring a type for an Element easy. Consider the un-typed CAS file manager policy below:
> {code}
> <element id="urn:oodt:ProductReceivedTime" name="ProductReceivedTime">
> ..
> </element>
> {code}
> which currently doesn't specify its type as a {noformat}Date{noformat} when it clearly is a {noformat}Date{noformat} element.
> Type handling was supposed to take care of this. As it stands, there are a number of fundamental disconnects with type handling:
> # There are absolutely 0 examples of how to use it. The existing example is not tailored for the general audience and does little to inform a user of what Type handling is supposed to do.
> # Type handlers are attached to Product Type (repo manager) policy when instead they really should be a part of the Validation layer policy (i.e., elements.xml)
> # Type handlers aren't configurable.
> # There is no way to map a TypeHandler alias or name (e.g.., instead of having to declare the FQCN o.a.oodt.cas.filemgr.structs.type.DateTypeHandler, we should be able to specify DateType).
> # The TypeHandler interface is dependent on a ProductType.
> In order to address the above concerns I'm going to attach a patch that does the following:
> # Moves type handler declarations to Validation layer policy (elements.xml).
> # Refactors the TypeHandler interface to be configurable.
> # Refactors the TypeHandler interface to be independent of ProductType.
> # Allows for easy aliasing of TypeHandlers.
> # By default assigns all default CAS elements that ship with the CAS file manager a default type.
> # Adds a bunch more documentation.
> # Adds unit tests.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (OODT-147) Completely refactor
TypeHandling code
Posted by "Chris A. Mattmann (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OODT-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997965#comment-12997965 ]
Chris A. Mattmann edited comment on OODT-147 at 2/22/11 6:51 PM:
-----------------------------------------------------------------
Heh, the Element Name was *never* suppossed to be unique, hence the Element ID :)
I'm fine with adding a method to:
{code:java}
getElementByName(String elementName, ProductType productType)
{code}
But I'm not fine with removing the existing:
{code:java}
getElementByName(String elementName)
{code}
Function. That function should simply return the first (possibly only) occurrence of the Element with the given name per its original intended behavior.
I think we're in agreement though!
was (Author: chrismattmann):
Heh, the Element Name was *never* suppossed to be unique, hence the Element ID :)
I'm fine with adding a method to getElementByName(String elementName, ProductType productType), but I'm not fine with removing the existing getElementByName(String elementName) function. That function should simply return the first (possibly only) occurrence of the Element with the given name per its original intended behavior.
I think we're in agreement though!
> Completely refactor TypeHandling code
> --------------------------------------
>
> Key: OODT-147
> URL: https://issues.apache.org/jira/browse/OODT-147
> Project: OODT
> Issue Type: Improvement
> Components: file manager
> Affects Versions: 0.1-incubating, 0.2
> Environment: indep. of env.
> Reporter: Chris A. Mattmann
> Assignee: Chris A. Mattmann
> Priority: Critical
> Labels: file, handling, manager, oodt, type
> Fix For: 0.3
>
>
> The o.a.oodt.cas.filemgr.structs.type.* package contains code originally intended to strongly type Metadata elements within CAS file manager. IOW, it was originally conceived to make declaring a type for an Element easy. Consider the un-typed CAS file manager policy below:
> {code}
> <element id="urn:oodt:ProductReceivedTime" name="ProductReceivedTime">
> ..
> </element>
> {code}
> which currently doesn't specify its type as a {noformat}Date{noformat} when it clearly is a {noformat}Date{noformat} element.
> Type handling was supposed to take care of this. As it stands, there are a number of fundamental disconnects with type handling:
> # There are absolutely 0 examples of how to use it. The existing example is not tailored for the general audience and does little to inform a user of what Type handling is supposed to do.
> # Type handlers are attached to Product Type (repo manager) policy when instead they really should be a part of the Validation layer policy (i.e., elements.xml)
> # Type handlers aren't configurable.
> # There is no way to map a TypeHandler alias or name (e.g.., instead of having to declare the FQCN o.a.oodt.cas.filemgr.structs.type.DateTypeHandler, we should be able to specify DateType).
> # The TypeHandler interface is dependent on a ProductType.
> In order to address the above concerns I'm going to attach a patch that does the following:
> # Moves type handler declarations to Validation layer policy (elements.xml).
> # Refactors the TypeHandler interface to be configurable.
> # Refactors the TypeHandler interface to be independent of ProductType.
> # Allows for easy aliasing of TypeHandlers.
> # By default assigns all default CAS elements that ship with the CAS file manager a default type.
> # Adds a bunch more documentation.
> # Adds unit tests.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OODT-147) Completely refactor TypeHandling code
Posted by "Chris A. Mattmann (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OODT-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998041#comment-12998041 ]
Chris A. Mattmann commented on OODT-147:
----------------------------------------
Hi Brian:
bq. Not to start a he said you said, but you specifically total me that ElementId is computer ID and ElementName is human readable ID
And how specifically is what I'm saying in violation of that statement (that I did make, to leverage as an analogy to illustrate the concept)? The element ID *is* the only part of the Element that I've said *must* be unique.
bq. there is code in the filemgr which relies on such a concept . . . for example in DataSourceCatalog assumes ElementName is unique:
So? That's an implementation of an extension point for the Catalog. It's not a concrete, core classes. There are other Catalog implementations. Furthermore, the above code *does not* rely on the fact that the Element name is unique -- as I said -- the behavior of getElementByName is such that it should only return the first (and possibly only) matching Element with the given name. If there is only one element (or even many Elements) the Catalog implementation still functions as expected.
bq. i believe we should create an issue against the filemgr which adds the above method to ValidationLayer and ensures ElementName everywhere is treated as if it is not unique
I'm happy to add the above method, but there isn't anything else across the file manager that needs to be done.
bq. the reason i'm being persistant here is because this particular issue is one of the primary reasons i had to branched the filemgr in wengine for PEATE . . . so i could add such methods to the ValidationLayer.
So basically what you're saying is that you had to branch an entire major component of the system rather than simply extending the existing component and writing your own ValidationLayer, as was intended when the extension point was created? I'm not buying that, sorry. ValidationLayers are hidden in the catalog implementation and thus don't have any specific contract on their particular interface other than a few core methods. You could have arbitrarily added methods to *your ValidationLayer implementation* without changing *any of the core code* in the File Manager.
> Completely refactor TypeHandling code
> --------------------------------------
>
> Key: OODT-147
> URL: https://issues.apache.org/jira/browse/OODT-147
> Project: OODT
> Issue Type: Improvement
> Components: file manager
> Affects Versions: 0.1-incubating, 0.2
> Environment: indep. of env.
> Reporter: Chris A. Mattmann
> Assignee: Chris A. Mattmann
> Priority: Critical
> Labels: file, handling, manager, oodt, type
> Fix For: 0.3
>
>
> The o.a.oodt.cas.filemgr.structs.type.* package contains code originally intended to strongly type Metadata elements within CAS file manager. IOW, it was originally conceived to make declaring a type for an Element easy. Consider the un-typed CAS file manager policy below:
> {code}
> <element id="urn:oodt:ProductReceivedTime" name="ProductReceivedTime">
> ..
> </element>
> {code}
> which currently doesn't specify its type as a {noformat}Date{noformat} when it clearly is a {noformat}Date{noformat} element.
> Type handling was supposed to take care of this. As it stands, there are a number of fundamental disconnects with type handling:
> # There are absolutely 0 examples of how to use it. The existing example is not tailored for the general audience and does little to inform a user of what Type handling is supposed to do.
> # Type handlers are attached to Product Type (repo manager) policy when instead they really should be a part of the Validation layer policy (i.e., elements.xml)
> # Type handlers aren't configurable.
> # There is no way to map a TypeHandler alias or name (e.g.., instead of having to declare the FQCN o.a.oodt.cas.filemgr.structs.type.DateTypeHandler, we should be able to specify DateType).
> # The TypeHandler interface is dependent on a ProductType.
> In order to address the above concerns I'm going to attach a patch that does the following:
> # Moves type handler declarations to Validation layer policy (elements.xml).
> # Refactors the TypeHandler interface to be configurable.
> # Refactors the TypeHandler interface to be independent of ProductType.
> # Allows for easy aliasing of TypeHandlers.
> # By default assigns all default CAS elements that ship with the CAS file manager a default type.
> # Adds a bunch more documentation.
> # Adds unit tests.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (OODT-147) Completely refactor TypeHandling code
Posted by "Chris A. Mattmann (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OODT-147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997965#comment-12997965 ]
Chris A. Mattmann commented on OODT-147:
----------------------------------------
Heh, the Element Name was *never* suppossed to be unique, hence the Element ID :)
I'm fine with adding a method to getElementByName(String elementName, ProductType productType), but I'm not fine with removing the existing getElementByName(String elementName) function. That function should simply return the first (possibly only) occurrence of the Element with the given name per its original intended behavior.
I think we're in agreement though!
> Completely refactor TypeHandling code
> --------------------------------------
>
> Key: OODT-147
> URL: https://issues.apache.org/jira/browse/OODT-147
> Project: OODT
> Issue Type: Improvement
> Components: file manager
> Affects Versions: 0.1-incubating, 0.2
> Environment: indep. of env.
> Reporter: Chris A. Mattmann
> Assignee: Chris A. Mattmann
> Priority: Critical
> Labels: file, handling, manager, oodt, type
> Fix For: 0.3
>
>
> The o.a.oodt.cas.filemgr.structs.type.* package contains code originally intended to strongly type Metadata elements within CAS file manager. IOW, it was originally conceived to make declaring a type for an Element easy. Consider the un-typed CAS file manager policy below:
> {code}
> <element id="urn:oodt:ProductReceivedTime" name="ProductReceivedTime">
> ..
> </element>
> {code}
> which currently doesn't specify its type as a {noformat}Date{noformat} when it clearly is a {noformat}Date{noformat} element.
> Type handling was supposed to take care of this. As it stands, there are a number of fundamental disconnects with type handling:
> # There are absolutely 0 examples of how to use it. The existing example is not tailored for the general audience and does little to inform a user of what Type handling is supposed to do.
> # Type handlers are attached to Product Type (repo manager) policy when instead they really should be a part of the Validation layer policy (i.e., elements.xml)
> # Type handlers aren't configurable.
> # There is no way to map a TypeHandler alias or name (e.g.., instead of having to declare the FQCN o.a.oodt.cas.filemgr.structs.type.DateTypeHandler, we should be able to specify DateType).
> # The TypeHandler interface is dependent on a ProductType.
> In order to address the above concerns I'm going to attach a patch that does the following:
> # Moves type handler declarations to Validation layer policy (elements.xml).
> # Refactors the TypeHandler interface to be configurable.
> # Refactors the TypeHandler interface to be independent of ProductType.
> # Allows for easy aliasing of TypeHandlers.
> # By default assigns all default CAS elements that ship with the CAS file manager a default type.
> # Adds a bunch more documentation.
> # Adds unit tests.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira