Request to define namespaces used in Matterhorn in a central or bundle scoped Config File

Description

Issue: It's hard to tell what namespaces are used in Matterhorn and its hard to tell when they change.
For example, the namespace "http://org.opencastproject.security" is defined 18 times in 9 classes across 2 bundles.
In this case, when that namespace changed from "org.opencastproject.security" to "http://org.opencastproject.security" between 1.4rc2 and 1.4rc7, the series REST API changed.

A possible solution for more namespace visibility is move the namespace definitions out of java and into configuration files.
For example,
opencast.mediapackage.namespace="http://mediapackage.opencastproject.org"
opencast.security.namespace="http://org.opencastproject.security"
opencast.acl.namespace=${opencast.security.namespace}
opencast.ace.namespace=${opencast.security.namespace}
opencast.organization.namespace=${opencast.security.namespace}
...

Activity

Show:
Greg Logan
February 28, 2013, 4:49 PM

Karen, I'm not sure how much work this would be, but can you bring this up on list please? CFRs tend to get missed in the general hubbub around JIRA and this strikes me as a really good suggestion to bring up to the committer body.

Christoph Driessen
March 5, 2013, 8:35 AM

Generally namespaces are well-known identifiers or literal entities that are not subject to configuration. Hence I think this is more of a documentation issue. I strongly agree that the used namespaces should be documented more prominently but not in the form of config file. I'd rather propose to add a "mh-namespaces.txt" documentation file to docs/.

Besides this formal argument a config file will just cause more confusion. Namespaces are not only used in Java code but also in Javascript and XML files. The latter cannot access the config so they have to use them literally. But since a config file exists one can get easily the impression that it's possible to alter namespace identifiers by editing the config.

Another point is that namespaces are not only used inside Matterhorn but also in communication with the outside world. A client of one of MH's XML structures cannot rely on a config. It just has to know. As namespaces are part of MH's communication protocols they have to be as stable as possible. Putting them in a config evokes that they can be configured which is not quite true.

Former user
March 5, 2013, 12:42 PM

Christoph,
I agree on the hazard of putting namespace identifiers into a configuration file. I should have called it a Properties file surrounded with big warnings not to touch the values. The benefit of the code using values from a single accessible source is that it's more truthful than a disconnected text document. It is easier to see if there is a disconnect between a namespace used in Matterhorn and one used by the outside world. A less dangerous alternative is to put common namespace constants into a single configuration class, referenced by the code, that can be exported as javadoc and viewed on one page.

Christoph Driessen
March 5, 2013, 12:49 PM

+1 for the constants class. Defining constants for well-known identifiers is a good practice and it does not look like a configuration. We can place it in matterhorn-commons and name it MatterhornNamespaces.

Assignee

Unassigned

Reporter

Former user

Criticality

None

Tags (folksonomy)

Components

Configure