New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CacheEntryEvent.getValue and getOldValue #391
Comments
I prepared a pull request for RI's implementation of |
For the sake of backwards compatibility, I can see why one would map oldValue to getValue() for EXPIRED and REMOVED CacheEntryEvent. Minimal correction to javadoc that removes the erroneous reference to CacheEntryCreatedListener. From:
To: |
@jfialli Thanks Joe for bringing this up. Here is indeed some unfinished business.
Since it is in the concept that one listener implementation can serve for all events, e.g. for create, updated and removed, it would make sense to send the old value consistently via Clarifications: The clarifications above all make sense. There is one more in
The spec wording follows rfc2119, so: should -> must Unsopported Operation
I am not totally convinced that "just" removing it from the RI is the best choice (as in jsr107/RI#61). Since there is no TCK test, implementations will still do anything.
Thoughts? |
On the topic of
If the interpretation is (a), then any implementation-specific behavior is acceptable when Additionally, the method's javadoc above indicates |
I see it practical. The spec has room for interpretation, for example
That's a wrong conclusion of the form (I just looked it up....) described here: Nothing in the Spec says that an implementation is not allowed to send the old value in an event if |
To be fair I add another option to the list above:
In terms of good API design I am still in favor of 2, because:
|
I agree, I offered an interpretation attempting to define what is not already defined, not proof. I agree that solution 2 is cleaner API but have some reservations about introducing the exception throwing behavior in a maintenance release. |
Sometimes I like to be more perfect but it isn't possible. In this case implementations diverge because the Spec isn't clear and there is no TCK test. Checking the implementations everyone that implemented some logic around "old value" needs to change as soon as the spec and the tests get stricter, no matter whether we decide for option 2 or 3. I browsed trough all implementations I monitor via the test zoo project. There are three variants:
I think we need/should to do a step back here, because I am not sure whether we really have consensus what
To make things easier we should try first whether we can agree on semantics for the case |
I am getting lost in the prose descriptions. Here is an attempt at a systematic treatment. For the tables below, value represents a value that is in the cache while the Listener is Here is a table when CacheEntryListenerConfiguration#isOldValueRequired() is true that summarizes
Note the use of past tense for CacheEntryExpiredListener and CacheEntryRemovedListener. Here is table when CacheEntryListenerConfiguration#isOldValueRequired is false:
Only the value that is still in the cache is accessible via getValue(). To be backwards compatible with 1.0, the following could be a compromise when
For the sake of backwards compatibility, getValue() in Removed/ExpiredListener can be documented |
Thanks Joe. Your tables are a relief.
Good compromise!
Not so fast. That is not in the wording nor the meaning of the Spec yet. If it is not required it means: Updated table when CacheEntryListenerConfiguration#isOldValueRequired is false:
W.R.T.:
I have two different notions of "configure". The first is enable and optimize a specific cache implementation in a specific environment, the second is that an application is requesting specific semantics that it needs to function properly. The second one we need on the API level. The first one is intentionally not addressed by JSR107. |
I agree with the updated table when isOldValueRequired is false. |
Thanks Joe & Jens, I also think the tables you agreed on make sense. |
Proposal for updated javadoc on
@jfialli @cruftex comments? Once we finalize this I'll prepare pull requests for spec, RI and TCK as all have to be updated. |
Pull requests:
|
Add @OverRide annotation to getValue(). (Its is defined initially in Cache.Entry). getOldValue documentation update. Change: |
consequently, getValue() documentation update. Change:
True, but irritating. Better remove the rationale, since the "why" is usually not addressed in the JavaDoc.
Add:
Or remove it and refer to |
👍
Agreed. I did some minor editing to the text you proposed, here is the result:
And here is
What do you think? |
I just merged the PR. It includes all what we discussed above. Now the Spec document should be updated. |
… returning oldValue when isOldValue is false.
This should be closed. Merges were done back in October. |
Observations from Joe Fialli on
CacheEntryEvent
following the resolution of #362 :Comments on current changes:
Since
getValue
method is overriding a method defined inCache.Entry
, an@Override
annotation is missing.getValue()
is defined for{@link CacheEntryUpdateListener}
, but that is not listed. Is the intent that getValue() always has a value for allCacheEntryUpdateListener
, but its value being set for all other Listeners is based onCacheEntryListenerConfiguration#isOldValueRequired()
being true?(2a). If answer to 2 is yes, I definitely agree that previous value for entry is not returned in
CacheEntryExpiredListener
andCacheEntryRemovedListener
whenisOldValueRequired
is false. However,getValue()
should always return entry's current value forCacheEntryCreatedListener
regardless ofCacheEntryListenerConfiguration.isOldValueRequired()
Current solution contradicts terminology for an existing Cache API remove method
/**
....
*/
boolean javax.cache.Cache.remove(K key, V oldValue).
In this existing method, the documentation refers to the value as
oldValue
(when it should for all intents be just "value"). This is a condition for the operation to occur. So the above parameter definitely should be "value" just as in a "Removed" or "Expired" Listener, the value should be considered the previous or "oldValue" prior to the entry no longer being associated with the cache.The undocumented exception UnsupportedOperationExceotion that is thrown by the RI but not documented in spec or javadoc. This issue was raised in issue and not addressed before it was closed.
The text was updated successfully, but these errors were encountered: