Skip to Content
Author's profile photo Troy Cronin

EP: KM & Hot Deployment – A Brief Overview


A common occurrence with KM (Knowledge Management) problematic based scenarios can often be traced to Hot-Deployment occurrences especially when we are dealing with configuration setups. Hot Deployment references can be encountered in the form of exception highlights within default trace files or also lead to on-screen graphically represented errors. Such occurrences are often associated with recent upgrades, migrations and system restarts involving component configuration changes.

What is Hot-Deployment?

As the name hot-deployment might suggest this process refers to an abrupt & quick means of transferring underlying KM/KMC Code within a KM Service Landscape. The catch with Hot-Deployment is that such a process involving the code does not require the end-user or system admin to perform a restart of the corresponding container base. To elaborate further on this point if we take the Enterprise Portal as the backdrop we know that such an environment consists of multiple core component areas. From solely the perspective of KMC, hot-deployment means you are able to redeploy KMC Components freely without touching the corresponding Portal Components which provide the platform base on which KM runs.


In the image above we depict the process basis of how KM interacts with the Portal through run-time technology conduit channels. All KMC Components interact with the Enterprise Portal’s classloader elements i.e. the Portal Runtime Technology (PRT) which is supported through delegated communication from the CRT (Component Runtime).

Hot-Deployment – Concerns ?

The major point of highlight surrounding Hot-Deployment is that such an action is NOT supported, encouraged or recommended as it can lead to a wide array of different issues. If you come across hot-deployment references within the default trace files you’re findings will be identical or similar to the sample exception outlined below:

  • #0-500#Error#com.sapportals.wcm.crt.CrtClassLoaderRegistry#[HT T P Worker ,5,Dedicated_Application_Thread]#Plain.Stacktrace of classloader registration attempt. [EXCEPTION] java.lang.Exception #0-500#Error#com.sapportals.wcm.crt.CrtClassLoaderRegistry#

These exceptions can come into play with visual representation errors


  •[HTTP Worker [@842428700],5,Dedicated_Application_Thread]Plain Registration of classloader with id ignored, as hot-deployment is not supported (see OSS Note 894884). Please restart the server to enable newly deployed components.##2.0#2015 09 02 11:09:31:935#0-500#Error#com.sapportals.wcm.crt.CrtClassLoaderRegistry#

In the Hot-Deployment sample exceptions  outlined above we see the references to the Component Runtime & Portal Classloaders. The significance of such exceptions is that component discrepancies and functional issues may appears as a result.

Correcting Hot-Deployment

The exception above we see a reference being made to hot deployment. An overview on this particular exception along with its root source and means of resolution is covered in the following SAP documentation:

– SAP Note: 894884 – Hot-deployment of KMC components – Clarification

In order to resolve hot-deployment you will need to proceed to restart the J2EE engine in order to clear the hot deployment and then subsequently check if KM is accessible.

  • This restart requirement is outlinedas a hint in the exception itself and will appear as “Please restart the server to enable newly deployed components”.

In addition to the note documentation outlined above kindly review the guideline WIKI’s below which offer a more comprehensive overview:

Hot Deployment in the Enterprise Portal:

KMC – Hot Deployment Checker:

If you see exceptions pertaining to the “Registration of classloader with id” the reasoning behind this is sourced to incomplete deployment. A restart should in theory resolve this occurrence and resulting exception (as this restart subsequently redeploys the component).

So the bottom line here is that Hot Deployment is not supported and the J2EE should be restarted if it occurs. From a preventive standpoint you can use the Hot Deployment checker tool to see if your application is Hot deployment safe, see the note as well.

Points Of Consideration

If you find a restart does not resolve the issue there are various troubleshooting notes and resolution documentation available. However in true essence as this is a non-supported action there is not much we (SAP) can do in terms of offering consultation. SAP Note: 894884 should be used as the primary source of reference here. As per this note SAP Delivered components have not been Hot-Deployment “aware” since SP12+ onward.

If then you come across Hot-Deployment this means that the likely cause is a manual trigger or by Custom Developed Components. If it is the former i.e. (Custom) I need to emphasize that Hot-Deployment in any way, shape or form is not supported and therefore we advise such an action is never conducted ESPECIALLY in Production based Environments.

  • Custom Developed Components also fall outside the scope of the Support Channels therefore from our side consultation is not available.

If Hot-Deployment was caused by the Deployment of a custom service, this can be resolved by performing a full system restart. If however, it is being called by the actual coding of this custom application, then it will reoccur even after the system restart has been performed.

  • In this case, you will need to discuss this with the associated code developer responsible for the application in order to redesign it so that it is not causing an init or triggering a classLoader at runtime.

Basically, anything causing a restart of the CRT (component run-time) without a corresponding PRT (portal run-time) restart will result in Hot-Deployment being caused.


If hot deployment has occurred it will ordinarily be the cause of discrepancies and subsequent loss of functionality.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Nice one. My 2 cents on this: this issue occurs mostly e.g. on custom KM reports development or generally on stuff affecting RF frameowrk and is annoying as hell, since you need a restart after every deployment you are doing. There is a simple solution to avoid it: build spikes


      Author's profile photo Troy Cronin
      Troy Cronin
      Blog Post Author

      Hi Lawrence

      I hope you are keeping well and many thanks for the feedback. Regarding you're observations I agree completely and on some occasions it can prove to be mind boggling along with frustrating 😆 . I'll be continuing to cover all topics across the Portal to help aid customers and prevent issues from surfacing, who knows perhaps one day (in an ideal world) we will never encounter another software related error 😆 .

      Kind Regards & Talk Soon


      Author's profile photo Hemanth Kumar
      Hemanth Kumar

      Troy you seem to be taking about a self healing software system 🙂

      Author's profile photo Troy Cronin
      Troy Cronin
      Blog Post Author

      😆 Nothing in this world is impossible my friend 😉

      Author's profile photo Former Member
      Former Member

      Troy is simply young and still has the right attitude, Hemanth 😉

      However, Troy your documentation effort is very welcome, this is a perfect article for an AS Java BASIS consultant e.g., I fear most of our colleagues dont realize exactly what a hot deployment is and what the consequences are