Revert "Fix #4561 (revert #4430)" -- i.e. go back to modified #4430.

[cowtowncoder]

Reverts #4562, as per discussion #4430 the fix we have (minor change to lock scoping) that confirms fix seems safe. So we should be good to go in patch (2.17.2), not waiting for next minor release (2.18.0).

Apologies for the whiplash to anyone following discussions. :)

[iProdigy]

note: technically reactor users can still encounter a problem (if they enable blockhound) but now the error will be shown, which is easier to know how to respond (blockhound allowlist)

oh i missed that the release notes doesn't say reactor issues are fixed, you can disregard^

[cowtowncoder]

@iProdigy Probably worth emphasizing: could you add a comment on ... #4561

[iProdigy]

@cowtowncoder done!

Currently my workaround comment uses _createAndCacheValueDeserializer (which could be problematic if the method name ever changes).

Should the workaround instead allowlist findValueDeserializer and hasValueDeserializerFor? (technically this could also lead to problems if another method was added that directly calls _createAndCacheValueDeserializer)

[pjfanning]

@cowtowncoder done!

Currently my workaround comment uses _createAndCacheValueDeserializer (which could be problematic if the method name ever changes).

Should the workaround instead allowlist findValueDeserializer and hasValueDeserializerFor? (technically this could also lead to problems if another method was added that directly calls _createAndCacheValueDeserializer)

I don't think we should worry too much about this. Let reactor-core blockhound users do their own testing. The key thing is that we fix the code so that we don't try to release a lock that we never acquired - then the blockhound users will get the right exception message and they can worry about how to fix it.

[cowtowncoder]

+1 to @pjfanning but also because we are unlikely to change the structure or naming for 2.x.

@iProdigy You are right to be wary of internal methods, naming (we do change them over time). But in this it probably as the best choice.

As aside, hasValueSerializer()/hasValueDeserializer() methods will --if I remember correctly -- be removed from 3.0 because they don't... really work the way most users think they do (or should). Only a very small fraction of classes will return false, because default POJO ("Bean") (de)serializer construction is attempted, and even if that fails, information obtained is of limited value.
But despite this, there's real cost in calling methods, only to be usually followed by matching read or write. So frameworks probably shouldn't really call these methods at all.
Might be worth deprecating these methods (well, ObjectMapper.canSerialize() / .canDeserialize()) actually

Ah yes: removal is wrt #1917 will file an issue for adding deprecation in 2.18.