I am looking for a way to start the tridion related stuff in the content delivery programatically or delayed instead of starting immediately when the app server starts the webapp.

I am not sure where the entrance point of starting tridion is situated, seeing as it does not use any filters/servlets, but my guess is that it starts in the StorageManagerFactory, which contains a field private static StorageManagerFactory instance = reloadInstance();. If I check the logs you can also see that this is the first instance to start.

Can anyone verify that this is the situation and that the storagemanagerfactory makes it so that the rest of the content delivery classes gets initialised? And would anyone know how to make it so that it only starts when I want it to start, seeing as the getInstance and reloadInstance are protected methods so I can not use them myself.

  • You are describing a solution and not a problem; could you tell us what the underlying problem is why you would want to do this at all? Aug 8, 2014 at 11:05
  • @BjørnvanDommelen sure. At the moment our build process for 3 environments with live and staging produces 6 war files (resources filtering with maven). I'd like to create a library with spring 3.1 using the WebApplicationInitializer to dynamically load the properties at runtime. These will be located outside of the war file and be reloadable. For this I have to make it so that tridion hasn't started yet so that I can load in the properties in the conf files. Now that I know that it is the SessionManagementContextListener I can load this after the property resolving Aug 9, 2014 at 12:01

2 Answers 2


Most web application frameworks (such as spring) provide loads of ways to trigger custom java code when your application starts. All you have to do is to trigger something tridionny - like resolving a 0 link - to start up the storage manager.

Alternatively, having a monitoring system that polls a URL that does a tridion call will have the same effect whilst also keeping track of your application.

  • Starting up the storage manager is not really the problem, keeping it from starting up until I want it to start up is. When I look at the log files I clearly see that the storagemanagerfactory is started before spring Aug 7, 2014 at 9:29
  • That is strange - in my case its usually the opposite. Since tridion itself is spring based, you might have some scan functionality that picks up on the tridion-internal contexts before it picks up on yours ... Aug 7, 2014 at 9:39
  • are Timestamp of Tridion logs earlier than spring?
    – Raj Kumar
    Aug 7, 2014 at 9:59
  • It might be that you have the cache channel listener running in your web app. The ThreadPoolExecutor will start straight away I think. The same is true for monitoring.
    – Raimond
    Aug 7, 2014 at 10:00
  • My first 2 lines when I start my webapp: 2014-08-07 12:03:16,102 INFO localhost-startStop-1 org.springframework.web.context.ContextLoader - Root WebApplicationContext: initialization started 2014-08-07 12:03:16,102 INFO Sessions cleaner thread com.tridion.storage.StorageManagerFactory - ******************************************************************************** Aug 7, 2014 at 10:05

The site I was testing has UI installed and I was checking the staging one.

When checking a different site with no UI installed, I saw that in the log files there was no tridion logging until I really browsed to a page. Just to be sure I tested a 3rd site which also has UI installed, this had the same logging on staging as the initial site, meaning the AmbientDataServletFilter or the SessionManagementContextListener of the UI is probably touching the cd_storage.


After browsing through the code, it most definitely seems to be the SessionManagementContextListener. When this starts up it will try to clean all the old preview sessions, hereby using the storagemanagerfactory.getDAOForStorageIdAndTransaction, which will of course start the instance.

  • if its Ambient framework, you should see "HttpModule - Ambient Framework initialization" in the logs as well
    – Raj Kumar
    Aug 7, 2014 at 10:52
  • It seems to be the SessionManagementContextListener in the cd_session. When Tridion starts up it first performs a cleanup of the old sessions. This happens on another thread, the reason why it states Sessions cleaner thread instead of localhost-start-stop Aug 7, 2014 at 11:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.