Cluster should not expose its internal fields
Description
It is currently possible to access a Cluster's internal manager field, and that is done in several places in our code.
While this works in most cases, it is error-prone and will not work properly under at least one identified situation: when a DelegatingCluster is in use and one calls AbstractSession.checkNotInEventLoopGroup() on a Session returned by that cluster.
A simple and trivial fix would be to amend AbstractSession.checkNotInEventLoopGroup() so that it does not access the field directly, but a better solution would be to encapsulate that field.
Among other benefits, it would allow us to simplify a lot the implementation of DelegatingCluster.
Environment
Pull Requests
Activity
It is currently possible to access a DelegatingCluster's internal manager field
Could you give examples of how this can be done through the public API?
Sorry I was a bit too alarmist in my description. It turns out that the only really problematic place is AbstractSession.checkNotInEventLoopGroup(). All the other places could keep accessing the internal field.
However: by encapsulating this field, we not only make internal code more bullet-proof, but it also can simplify a lot the implementation of DelegatingCluster. It would basically boil down to the following:
This is now superseded by driver 4.0, closing.
