Details
-
Improvement
-
Status: Closed
-
Normal
-
Resolution: Fixed
-
None
-
None
-
None
-
Turing Team 183
Description
Currently, the HST component mngr starts up possibly before the repository is running: This depends on whether first the hst or first the cms webapp starts.
This means that all HST spring beans have to be constructed such that repository access is always lazy. A typical construct then is for example instead of that a Spring bean during initialization can direct get hold of, say, the repository LockManager, it does so by for example using a supplier, where the supplier might look something like:
@Override public LockManager get() { if (lockManager != null) { return lockManager; } synchronized (lock) { if (lockManager != null) { return lockManager; } while ((lockManager = HippoServiceRegistry.getService(LockManager.class)) == null) { log.debug("{} not available yet, waiting {} {} before reattempting to get it", LockManager.class.getSimpleName(), waitMillis, MILLISECONDS); try { MILLISECONDS.sleep(waitMillis); } catch (InterruptedException e) { log.info("Interrupted while waiting for {}", LockManager.class.getSimpleName()); Thread.currentThread().interrupt(); } } } return lockManager; }
This is very unhandy. Starting up the HST Spring component manager after the repository service has become available results in that we can get rid of these kind of supplier patterns or separate threads trying until something works (like registering a jcr observer)
The fix is simple AFAICS: Postpone the HST component manager creation until the repository is available.
Only tricky part might be integration tests, where the repository initialization is triggered by a spring bean. However I think this shouldn't be that hard to fix if it turns out to be a problem.
Attachments
Issue Links
- clones
-
HSTTWO-4191 Postpone initializing the HST Component Manager until the RepositoryService is available
- Closed
- relates to
-
HSTTWO-4333 Support flag to switch to new HST config nodes loading behavior
- Closed