CDV ❯ <field-expression> for <root> in tc-config.xml results in exception

• Type: Bug
• Status: Closed
• Priority: 2 Major
• Resolution: Fixed
• Component/s: Configuration
• Labels:

• Assignee: teck
• Reporter: costescuandrei
• Created: November 30, 2011
• Votes: 0
• Watchers: 1
• Updated:

  October 22, 2012
• Resolved:

  July 10, 2012

Description

When testing compatibility with 3.6.0: I have roots defined in tc-config.xml just like this (of course with my annotation class instead of the one below taken from config reference file): Code: @com.example.MyRootAnnotation * *

Running the terracotta client fails with exception:

Code: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.createGlobalContext(ClassProcessorHelper.java:473) at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.initialize(ClassProcessorHelper.java:347) at com.tc.object.bytecode.hook.impl.ClassProcessorHelper.defineClass0Pre(ClassProcessorHelper.java:512) at java.lang.ClassLoader.defineClassCond(Unknown Source) at java.lang.ClassLoader.defineClass(Unknown Source) at java.security.SecureClassLoader.defineClass(Unknown Source) at java.net.URLClassLoader.defineClass(Unknown Source) at java.net.URLClassLoader.access$000(Unknown Source) at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at sun.misc.Launcher$AppClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.misc.Launcher$AppClassLoader.__tc_loadClass(Unknown Source) at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) Caused by: java.lang.NullPointerException: string is null at com.tc.util.Assert.assertNotNull(Assert.java:149) at com.tc.util.Assert.assertNotEmpty(Assert.java:195) at com.tc.util.Assert.assertNotBlank(Assert.java:216) at com.tc.util.Assert.assertNotBlank(Assert.java:227) at com.tc.object.config.schema.Root.(Root.java:18) at com.tc.object.config.schema.DSOApplicationConfigObject.translateRoots(DSOApplicationConfigObject.java:108) at com.tc.object.config.schema.DSOApplicationConfigObject.(DSOApplicationConfigObject.java:50) at com.tc.config.schema.setup.BaseConfigurationSetupManager.createNewDSOApplicationConfig(BaseConfigurationSetupManager.java:155) at com.tc.config.schema.setup.BaseConfigurationSetupManager.dsoApplicationConfigFor(BaseConfigurationSetupManager.java:147) at com.tc.object.config.StandardDSOClientConfigHelperImpl.(StandardDSOClientConfigHelperImpl.java:224) at com.tc.object.config.StandardDSOClientConfigHelperImpl.(StandardDSOClientConfigHelperImpl.java:182) at com.tc.object.bytecode.hook.impl.DSOContextImpl.getGlobalConfigHelper(DSOContextImpl.java:322) at com.tc.object.bytecode.hook.impl.DSOContextImpl.createGlobalContext(DSOContextImpl.java:98) ... 20 more

From what I can find in the docs/schema this should still work as expected. Last time I tested with 3.4.0 it worked… I need this as some roots can be obfuscated… so listing them 1 by 1 using is not an option right now.

From what I can tell from looking into terracotta code, MUST be used which is wrong if you look at docs/schema. Please make work again.

Comments

Andrei Costescu 2012-01-30

Any estimates on when this issue will be fixed?

Andrei Costescu 2012-04-12

I tested it on all versions between 3.4.1 and 3.6.1. 3.4.1 works ok, all higher versions (starting with 3.5.0) show this bug. So it was probably introduced in 3.5.0

Tim Eck 2012-07-10

this will be fixed in 3.6.3

As an alternative I think one could use the @Root annotations available in terracotta-toolkit.

Andrei Costescu 2012-07-12

Thank you Tim.