TC Version Check of TIM

Type: New Feature
Status: Closed
Priority: 2 Major
Resolution: Fixed
Component/s:
Labels:

Assignee: hhuynh
Reporter: tgautier
Created: March 05, 2008
Votes: 0
Watchers: 0
Updated:
May 02, 2008
Resolved:
March 13, 2008

Description

Implement version check in the TC product to emit warnings/info/error based on TIM manifest entry for required TC version.

Requirement:

identify and specify the meta data field for TC version requirement
Upon TIM load, TC should evaluate this meta data field
if missing, should emit a warning that indicates the TIM is missing TC version requirement info
if present, check version against TC. If version is not matched precisely, emit a WARN to console and logs

Optional:

implement a strict mode version of this feature, which will emit an ERROR and exit the process at the point of load
strict mode could be controlled by the tc.properties

Comments

Fiona OShea 2008-03-06

Add the WARN stuff for pacheco

Juris Galang 2008-03-10

Here’s two ways on how we could add an entry into a bundle’s manifest to identify the TC version requirement and other meta-data:

AS AN ATTRIBUTE OUTSIDE THE MAIN SECTION So we’ll have the following entry in the manifest:

[… OSGi attributes here …] Bundle-Version: 1.0.0.SNAPSHOT Require-Bundle: …blah…

Name: Terracotta Require-Version: 2.x.x

This lets us add as many TC specific meta-data as we want and it’s all grouped together under the Terracotta attribute. However attributes outside of the main section is not accessible via the OSGi API; ie. from the Bundle class, the method getHeaders() will only return the attributes from the main section (or the MainAttributes) - which is both good and bad: OSGi should not know about Terracotta specific attributes, but that means when we write code that reads this attribute it’s outside of the OSGi context (ie: we treat TIM bundles as regular JAR files) - for our purpose this does not really hurt us - since we’ll want to do the version check the Resolver level…

AS ATTRIBUTE IN THE MAIN SECTION BTW, this is how we specify alternative config files that should be loaded by the TIM (when the default terracotta.xml will not suffice, for example VM or OS specific configs)

[… OSGi attributes here …] Bundle-Version: 1.0.0.SNAPSHOT Require-Bundle: …blah… Terracotta-RequireVersion: 2.x.x

Which makes it accessible via the OSGi API. But we’ll want to prefix all of our attributes with ‘Terracotta-‘ — we’re stretching out the manifests file spec, here (sort-of) but unrecognized attributes are simply ignored and assumed as application specific (according to the spec)

Either path works fine for us. Maybe we should just use both.

Juris Galang 2008-03-10

Actually, I’d vote for implementing this new meta-data as an entry in the main section of a bundle’s manifest. It’s simple and it goes with the way we’ve implemented the alternate terracotta config extension for TIM’s. We should as much as possible NOT add anymore extensions into a TIM’s manifest and rely more on OSGi conventions (at least until or if we move our implementation of TIMs from OSGi)

So, this extension’s grammar would be:

Terracotta-RequireVersion: (version

any)

Where version of the form:

x.x.x[.q]

Note that I’m using the OSGi convention for version qualifiers, so as not to introduce yet another syntax for specifying version qualifiers when working under the context of TIMs.

And the rules are:

Omitting this attribute, will emit a warning.
Using the word ‘any’ will essentially be like setting the strict-version-check to off.
Supplying a version number would generate a warning if it does not match the exact version of TC client that is loading the TIM.
The supplied version number must be absolute (we will not support version ranges - yet)

Juris Galang 2008-03-10

From Taylor: I agree with the latest comment, can you also specify how the strict version check setting behaves, and is controlled.

From Juris: An entry in the tc.properties file named l1.modules.tc-version-check controls the TC version checking. If this property does not exists, then it is assumed to have been declared with it’s default value.

The default value is off. The allowed values are: off, warn, enforce, strict. Here’s how we could interpret these values:

off: - Behave as if this new feature does not exist.

warn: - If TIM does not have the Terracota-RequireVesion attribute, then inform user that the TIM has no Terracotta-RequireVersion - If Terracotta-RequireVersion attribute value does not match TC version then emit mismatched version warning, otherwise keep quiet.

enforce: - If TIM does not have the Terracota-RequireVesion attribute, then inform user that the TIM has no Terracotta-RequireVersion - If Terracotta-RequireVersion attribute value does not match TC version then abort with fatal error (or whatever enforce means to in our context - this could behave just like warn)

strict: - If Terracotta-RequireVersion is not present or the value does not match the TC version, then abort with fatal error message.

One thing I’d like to know is how we should behave for when there is a bad value specified in the Teracotta-RequireVersion attribute (eg: the version specified does not conform to the expected format) - should we abort (I think we should if the switch is set to any value other than off) or just warn.

Taylor Gautier 2008-03-10

My comments, be more specific in the enforce case, and add for each setting how we should behave when the value is incorrectly formatted.

So, for enforce:

enforce: - If TIM does not have the Terracota-RequireVesion attribute, then emit a warning that the TIM has no Terracotta-RequireVersion - If Terracotta-RequireVersion attribute value does not match TC version then abort with fatal error (or whatever enforce means to in our context - this could behave just like warn) - If Terracotta-RequireVersion is incorrectly formatted, abort with fatal error

Juris Galang 2008-03-10

Since you’ve already covered the enforce setting.

off: - Behave as if this new feature does not exist. - If Terracotta-RequireVersion is incorrectly formatted, then there is no effect.

strict: - If Terracotta-RequireVersion is not present or the value does not match the TC version, then abort with fatal error message. - If Terracotta-RequireVersion is incorrectly formatted, abort with fatal error

Juris Galang 2008-03-13

CDV-636: TC Version Check of TIM CDV-167: Add ability to check for dso version in config modules. DEV-1128: TIMs need manifest attribute specifying supported Terracotta version

Code and tests to check for required TC version for TIM’s. A new attribute named Terracotta-RequireVersion is added into the manifest of all TIM’s that comes packaged with the kit. When TC installs a TIM at runtime, this attribute’s vvalue is compared against TC’s version number and appropriate action is taken (see CDV-636 for details)

Fiona OShea 2008-03-21

We may need to wait for new TIMs versions to verify this fix

Hung Huynh 2008-05-02

verified with 2.6 r8445