Section 11.5.2 refers to an unknown class

[snicoll]

Section 11.5.2 defines what happens when more than one annotations are placed on the same method. In this case a CacheAnnotationConfigurationException should be thrown but this exception is not available anywhere.

[gregrluck]

This was unused in the code base so I removed it. Thanks for picking this up. Will bring this back in the first maintenance release.

[snicoll]

@gregrluck I was discussing this one with @jhoeller and we're wondering why this is part of the spec at all. If you've misused the annotation model, what does a standard exception bring concretely?

We'd rather remove that section or rephrase it so that an exception must be thrown but not specifying a concrete exception type.

[cruftex]

We'd rather remove that section or rephrase it so that an exception must be thrown but not specifying a concrete exception type.

Answering from a maintenance point of view:

Rewording from "should" to "must" calls for proper TCK tests. That can break existing implementations and causes work for an ambiguous situation, but that has no relevance for working application code.
Further more, it is too late to start discussion about consistent handling of configuration errors.

If the "should" stays, then at least the RI should have the behavior that we endorse in the spec.

Considering this, I am in favor for:

• Don't include the exception for 1.1, it was not there in 1.0 and nobody says it's needed
• Reword spec: Ambiguous configurations should cause implementation defined exceptions.

@snicoll : Since you are the initial and only requester, what is your preferred resolution?

[snicoll]

Don't include the exception for 1.1, it was not there in 1.0 and nobody says it's needed

The spec does but I see what you mean. Just to make sure I understand, your option is to do both of the items in the bullet list, right? That's what I'd do: remove the exception and any reference in the spec and reword it to states that implementations must throw defined exceptions.

Thanks!

[cruftex]

your option is to do both of the items in the bullet list, right?

Yes!

... reword it to states that implementations must throw defined exceptions.

Careful. That formulation is to strict. It says that an implementation must throw an exception but maybe it has enough information to continue and only log a warning. Personally, I like the "fail fast and hard" approach but implementations can have different preference. Strict formulations also require tests. I am going with RFC-like wording: normative/strict => must, recommendation => should.

Let's see whether somebody else has another opinion on it, otherwise I think we can go forward.

[cruftex]

On page 121 the standard says:

11.5.2. Multiple Annotations

Only one method level caching annotation can be specified on a method and only one parameter level
caching annotation can be specified on a parameter. If more than one annotation is specified on a
method or on a parameter then a CacheAnnotationConfigurationException must be thrown
either at application initialization time or on method invocation.

Proposed change:

• revert commit e7b9606
• Change the last sentence to: If more than one annotation is specified on a method, annotation processors are recommended to throw an implementation specific exception or log a warning.

Rationale:

• No annotation processor is implementing this, since the exception is missing in 1.0
• It is not likely that implementations will change for 1.1 and comply to the standard
• We had the discussion about configuration errors at other points as well and decided not to enforce additional behavior in an MR