MVCPortlet delegates the task to obtain the right MVCCommand to the MVCCommandCache class. This class should obtain the right MVCCommand from the OSGi registry, because MVCCommands are OSGi components.
MVCCommandCache stores the MVCCommands in a map based on the mvcCommandName. However, it doesn't care about the service.ranking property, so a recently deployed MVCCommand OSGi component with a small service ranking would override an already deployed MVCCommand OSGi component with a higher service ranking. This shouldn't happen.
If we deploy a new MVCCommand to override the behaviour of an existing MVCComand and then we undeploy, the map inside MVCCommandCache will remove the reference to the MVCCommand, even though there might be other active components that should replace that one. This is a limitation of the way the MVCCommands are stored, since the map inside MVCCommandCache only keeps track of one MVCCommand, and as soon as the component is stop, the map will remove the reference without looking for already existing components.
In order to test this issue we need some custom code:
1. Create a custom MVCCommand that overrides an already existing MVCCommand. The new MVCCommand should have a negative service.ranking (to ensure that it shouldn't have any impact). However, you will see that the custom MVCCommand will be invoked instead of the original one. This proves the first issue.
2. Create a custom MVCCommand that overrides an already existing MVCCommand. The new MVCCommand should have a very high service ranking (to ensure that is always executed). After deploying the module and test that it's executed, undeploy it. Then, try to invoke the MVCCommand and you'll see that an error is thrown on the console.