@udo, if one needs to use a strong word like 'offender', then the offender is the one using an internal API. Geode is under no obligation to maintain or "fix" these for any project.
Is there a Jira, github issue, or pull-request to promote the internal class to the public space? Is there a feature request to uncouple this class you want to use in Spring? Is Spring the tail wagging the dog for Geode releases? On Wed, Dec 4, 2019, 17:59 Udo Kohlmeyer <u...@apache.com> wrote: > @Dan, > > I will add my -1 to this. > > I understand your argument of "let's solve the problem by removing the > offender". > > But in reality who is the offender? Is it the one class that is using an > "internal" api OR is it the implementation itself that is to tightly > coupled that extending it is impossible? > > STDG right now is trying to create a test, to test functionality that > requires it to inject/mock a Pool. The smallest piece of the code, not > the WHOLE PoolManager. But the system does not allow for the injection > of a `Pool` (which btw all the methods on the `PoolManagerImpl` has as > arguments). It casts every generic `Pool` to its implementation. This is > a very limiting factor. > > I understand that delaying a release is not optimal, but how much effort > to we believe it to be to clean up the code that so tightly couples > implementations together. > > I think we also must not forget that John, like many of us, is a > committer and PMC member on Geode. He also happens to be the main > committer on SDG, SBDG, SSDG, STDG. But if he feels that a release > should not go out without fixing a limiting feature to the Geode > project, then he may do so. > > I also feel that this is a limiting factor. > > The only difference is that I am not the main committer on the Spring > data projects for Geode. John is merely trying to get the best outcome > for both projects. > > --Udo > > On 12/4/19 4:39 PM, Dan Smith wrote: > >> Quite frankly the reasons STDG (or dependent projects downstream like > SDG, > >> SBDG, SSDG) are doing what it is (they are) doing is irrelevant to point > >> articulated in the description of GEODE-753. > >> > > What bothers me here is not your suggestions in GEODE-1753, but the fact > > that you are vetoing a Geode release because STDG is using an internal > > Geode method and had a problem. > > > > How hard is it to remove the use of PoolManagerImpl from STDG? If we can > > fix the issue there, that seems better than putting bandaids into the > > release branch so STDG can continue to use internal APIs. > > > > -Dan > > >
