AshharAhmadKhan commented on PR #6217:
URL: https://github.com/apache/fineract/pull/6217#issuecomment-5181032283

   Hi @galovics , thanks for taking a close look at this, but I think the diff 
is being misread here.
   
   `FineractEntityAccessWriteService.java` isn't deleted. It only lost two 
methods: `createEntityAccess` and `addNewEntityAccess`, plus the commented out 
stub block. `createEntityToEntityMapping`, `updateEntityToEntityMapping`, and 
`deleteEntityToEntityMapping` are all still declared in the interface, 
untouched.
   
   `FineractEntityAccessUtil.java` isn't touched by this PR at all, zero diff. 
So the `fineractEntityAccessWriteService` field you highlighted is exactly the 
same before and after. Since the interface still exists, Spring still has a 
concrete type to inject there. Nothing in that constructor breaks.
   
   I also checked whether `FineractEntityAccessUtil` actually calls anything on 
that field. It doesn't. It's declared, injected, and assigned, but never 
invoked anywhere in the class. So even setting the deletion question aside, 
this dependency was already dead weight before the PR.
   
   That also lines up with the CI results on this PR. `build-core` and all the 
integration shards spin up the full Spring context, and they're passing. If the 
constructor were actually broken, that wouldn't be possible.
   
   Let me know if I'm missing something on your end though, always good to 
double check before merging something like this.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to