oodt-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris A. Mattmann (JIRA)" <j...@apache.org>
Subject [jira] Commented: (OODT-147) Completely refactor TypeHandling code
Date Tue, 22 Feb 2011 21:13:39 GMT

    [ 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

        

Mime
View raw message