Details
-
Bug
-
Status: Closed
-
Normal
-
Resolution: Fixed
-
None
-
None
-
None
-
0.5
-
Platform 192 - Messy HST 2, Platform 193 - HST Almost
Description
This has been a very tiny bug in the past of the HST, and while refactoring the HST, we should address it.
The problem is that registries like componentRegistry and siteMapItemHandlerRegistry are objects that are not tied to the VirtualHosts object. When the hst configuration changes, these registries are cleared. However existing running requests keep using the immutable stale VirtualHosts object still! Those requests should be handled by the old componentRegistry and siteMapItemHandlerRegistry as well!
Hence perhaps we should tie componentRegistry and siteMapItemHandlerRegistry instances to the VirtualHosts implementation object (do not expose them over an api since they are really internal objects), so they piggyback on the lifecycle of the VirtualHosts
Also note that the registry objects might/should live in the hst platform webapp instead of in the hst website webapps. This only might be quite invasive since the HstComponent instantiation then also might have to be done in the hst platform webapp (since I don't want to expose the registries to the hst website webapps)...in the end, the hst platform should 'own' all this, but I am not sure if we can gradually move these registries into the hst platform webapp or that a lot has to be moved in 1 go once we start with this
Attachments
Issue Links
- is cloned by
-
HSTTWO-4472 Make sure that the siteMapItemHandlerRegistry is tied to the VirtualHosts object lifecycle
- Closed
- relates to
-
HSTTWO-4378 Support Hst Model invalidation, rebuilding and concurrency
- Closed
-
HSTTWO-4472 Make sure that the siteMapItemHandlerRegistry is tied to the VirtualHosts object lifecycle
- Closed