What causes "injectField error field: value: " in pinpoint-apm/pinpoint?

Read the 'cause' chained exception to see the real failure (parse error vs access error)

pinpoint-apm/pinpoint · error · RuntimeException

injectField error field:<field> value:<value>

Error message

injectField error field:<field> value:<value>

What it means

injectField() wraps its entire body (parse + field.set) in a catch-all that rethrows RuntimeException('injectField error field:<field> value:<value>', cause). So any failure during value parsing (NumberFormatException, the Unsupported type ConfigurationException from parse(), the single-char check) or injection surfaces with this message, preserving the field name and raw value for diagnosis.

Source

Thrown at commons-config/src/main/java/com/navercorp/pinpoint/common/config/util/ValueAnnotationProcessor.java:194

        }
        return value.charAt(0);
    }

    private void injectField(Field field, Object target, String value) {
        final Class<?> fieldType = field.getType();

        try {
            final Object parsedValue = parse(fieldType, value);
            if (parsedValue != null) {
                try {
                    setAccessible(field);
                    field.set(target, parsedValue);
                } catch (ReflectiveOperationException e) {
                    throw new ConfigurationException(getFieldName(target, field) + " access error", e);
                }
            }
        } catch (Exception ex) {
            throw new RuntimeException("injectField error field:" + field + " value:" + value, ex);
        }
    }

    private String getFieldName(Object instance, Member field) {
        return instance.getClass().getSimpleName() + "." + field.getName();
    }

}

View on GitHub (pinned to 744c3d3075)

Solutions

Read the 'cause' chained exception to see the real failure (parse error vs access error)
Correct the property value in the config file to match the field type (numeric, valid enum constant name, etc.)
If the type changed in an upgrade, migrate the config key/value to the new expected type
Avoid static/final annotated fields so injection does not fail

Example fix

// before (config)
server.port=abc
// after (config)
server.port=18080

Defensive patterns

Strategy: try-catch

Try / catch

try {
    processor.process(configInstance, resolver);
} catch (RuntimeException e) {
    if (e.getMessage().startsWith("injectField error")) {
        log.error("Config field injection failed: {} | cause: {}", e.getMessage(), e.getCause());
    }
}

Prevention

Always inspect the cause chain — the real reason (NumberFormatException, invalid enum name) is wrapped
Validate config values (numeric ranges, enum names) before loading them into config objects
Write startup smoke tests that load all config classes from a sample properties file
Keep field types stable across releases or document config migrations

When it happens

Trigger: Any parse/inject failure inside injectField: non-numeric string for an int/long field, number out of range (e.g. value 99999 for byte), invalid enum constant name, unsupported field type, or reflection access failure — all get this wrapper message.

Common situations: Typo in a config value ('tuer' for boolean works, but 'port=abc' for int does not); enum constant renamed so old config value no longer matches; property value out of the numeric type's range; field type changed in a release while the config file still holds the old value format.

Understand the failure class

Background: "Invalid value" and "allowed values are" config errors: what your library rejected and how to fix it — this error's family across 41 libraries.

Related errors

AI-assisted analysis of pinpoint-apm/pinpoint@744c3d3075 (2026-09-07). Data as JSON: /api/errors/2d7dbe78eb9034ae. Report an issue: GitHub.