[GitHub] [syncope] mmoayyed commented on pull request #315: Upgrading CAS to 6.5.x; moving wa-reference as https

[GitBox <gi...@apache.org>]

mmoayyed commented on pull request #315:
URL: https://github.com/apache/syncope/pull/315#issuecomment-1040075316


   I see; thanks for the details.
   
   This seems simple-enough to fix; unfortunately like most other seemingly-simple problems, it's quite complicated to work it out. Mainly because of this:
   https://github.com/spring-cloud/spring-cloud-config/issues/1645
   
   In summary, this is because attribute resolution registered by Syncope is only conditionally activated via:
   
   ```java
   @ConditionalOnProperty("cas.authn.attribute-repository.syncope.url")
   public class SyncopePersonDirectoryConfiguration { }
   ```
   
   This means, when you start up empty, the configuration class and all the other beans in it will get ignored and skipped. Then, when you refresh by adding a value (such as URL), Spring application context will fail to refresh beans, because there is nothing to refresh to begin with. Refresh requests and scope only work in scenarios in the application context hierarchy where there is a reference to a bean that can be refreshed; beans or configuration classes that were skipped during the startup and application context initialization will never be refreshable, because they are not re-created. IOW, refresh requests only work best when there is a setting whose existing value changes from A to B; if there was no A to begin with, or if A is being removed, refresh requests may fall short. 
   
   So it's very difficult to: keep things refreshable, and, make sure the context is not polluted with *noise* (i.e. beans that exists and do nothing).
   
   For now, we might have to accept noise; that is to remove `@ConditionalOnProperty("cas.authn.attribute-repository.syncope.url")` and let the context create empty beans, only to be refreshed later. This might be a good compromise for now in the 6.5.1 line.
   
   This is being worked on in 6.6 so that conditional beans on props continue to work correctly, though as you can imagine, this goes quite deep and will take a bit of time to get right. 
   


-- 
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: dev-unsubscribe@syncope.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org