Please enable JavaScript.

Coggle requires JavaScript to display documents.

alternatives - Figure Out How To Handle The Monolith Beans That Cannot Be…

- - - - Why?
        
        There's code in the Components Library that scans for beans prefixed with "thymeleafApi.". For each one it finds, the library adds that bean to the apiBeanMap.
      - How fast will this take?
        
        Ask Rex.
  - - - How can we prevent this but still keep the bean in the Monolith?
        
        Mark the beans as deprecated in order to prevent other Monolith developers to create a new bean or implement more methods inside the existing beans
        
        Add somewhere (i.e., README, Javadocs at the top of each bean class) that this class is deprecated and they should be encouraged to use the Dynamic Data feature instead.
- - - - risks/roadblocks?
        
        After initial investigation, this alternative requires exposing services that weren't normally exposed via WebService. This route potentially requires teams that own those ecosystems to either do the work for us or at the least be in the PR as we work on it
        
        If we force the teams that provide services for the 3 beans to implement the changes, this could potentially take a while.
        
        why?
        
        The team has to put work in their backlog
        
        this work might not be a priority for the teams to work on them
        
        Can we try to work on it ourselves, and submit a PR to the teams invovled? The changes might not be dramatic since all we need to do is expose a WebService