• Bug
  • Status: Closed
  • 0 Showstopper
  • Resolution: Fixed
  • Configuration
  • hhuynh
  • Reporter: teck
  • June 13, 2008
  • 0
  • Watchers: 0
  • September 11, 2008
  • August 15, 2008

Attachments

Description

The docs here: http://www.terracotta.org/confluence/display/docs1/Configuration+Guide+and+Reference#ConfigurationGuideandReference-%2Ftc%3Atcconfig%2Fapplication%2Fdso%2Finstrumentedclasses

Say this: The include and exclude stanzas are evaluated bottom up according to the order in the Terracotta configuration file. The first pattern that matches will determine whether the class will or will not be instrumented. If no patterns match, the class will not be instrumented”

In reality this is not true. Consider this config:

foo.Type* foo.Type2

With the above config, foo.Type2 should be included but it is not. Interestingly enough, the eclipse plugin processes things correctly and decorates Type2 as included.

I think the product should be updated to match the documentation and the eclipse plugin. If we’re going to make the documentation fit the product then we’re going to have to update the eclipse plugin as well.

ADD A TEST FOR THIS! This needs to be a test that uses a real tc-config.xml file (as opposed to programtic config access like a system test)

The problematic code is in com.tc.object.config.ConfigLoader.loadInstrumentedClasses()

Comments

Tim Eck 2008-06-13

not the first time this has been broken (http://jira.terracotta.org/jira/browse/LKC-1582)

Walter Harley 2008-08-14

The code in ConfigLoader.loadInstrumentedClasses is indeed wrong; rather than breaking includes and excludes into separate arrays and processing them separately (thus losing any relative ordering information), it needs to use XmlObject.selectPath(“*”) to get all the includes and excludes in a single array.

That said, I’m not sure I understand the documentation, either. “Bottom up according to the order in the Terracotta configuration file” seems confusing: aren’t these exclusive?

Here’s the behavior I expect:

include A* exclude AB* include ABC* -> A and ABC should be included; AB should not.

include A* include ABC* exclude AB* -> A should be included; AB and ABC should not.

exclude AB* include A* -> A, AB, and ABC should all be included.

Does that seem right?

Tim Eck 2008-08-14

Your examples look correct the way I recall how it is supposed to work. That said, the way I read the examples the second and third ones contain useless directives (“include ABC*” in the 2nd example, and “exclude AB*’ in the 3rd). They are useless since they completely masked by the rules below them (ie. removing them will not effect the outcome)

Walter Harley 2008-08-14

I’ve entered a separate Jira for docs clarification: “bottom up” here just means “starting at the end of the file.”

It is correct that these examples contain useless rules (it might actually be nice for the Eclipse plugin to warn about that).

Walter Harley 2008-08-14

Proposed patch. This fixes the problem, in manual testing. Still working on writing an automated test.

Walter Harley 2008-08-14

Slightly modified version of previous patch, with null check for return of XmlObject.selectPath(). It’s not documented whether this can return null so I figured better safe than sorry.

Walter Harley 2008-08-15

Patch containing fix and unit tests.

Walter Harley 2008-08-15

Fixed in trunk by revision 9751. Fixed in 2.7 branch by revision 9754.

Fix is to use XmlObject.selectPath(“*”) rather than InstrumentedClasses.getIncludeArray and …ExcludeArray() to preserve relative order while iterating children of the tag in ConfigLoader.