I'm seeing a Java.Lang.RuntimeException when trying to call the GetLink() method, the Tridion instance has recently been upgraded from 2009 to 2011 SP1. Initially I suspected this might be an issue with the Java version or that the correct DLLs haven't been added to the bin folder. Java version is correct, Tridion Linking DLL is correct yet still I see this error.

The DLLs have been taken from another site under the same Tridion instance where component linking works perfectly fine.

I've had a look online but can't really narrow the problem down - has anyone seen this before?

Stack trace is below:

   Codemesh.JuggerNET.NTypeValue.Throw(Int64 inst) +351
   Codemesh.JuggerNET.JavaClass.ThrowTypedException(Int64 inst) +1278
   Codemesh.JuggerNET.JavaMethod.CallObject(JavaProxy jpo, JavaMethodArguments args) +551
   Com.Tridion.Linking.ComponentLink.GetLink(String sourcePageURI, String targetComponentURI, String excludeTemplateURI, String linkTagAttributes, String linkText, Boolean showTextOnFail, Boolean showAnchor) +205
   Tridion.ContentDelivery.Web.Linking.ComponentLink.GetLink(String sourcePageUri, String targetComponentUri, String excludeTemplateUri, String linkTagAttributes, String linkText, Boolean showTextOnFail, Boolean showAnchor) +38
   ASP.en_includes_controls_rss_items_ascx.Header_PreRender(Object sender, EventArgs e) in c:\inetpub\wwwroot\path_to_file\rss-items.ascx:18
   System.EventHandler.Invoke(Object sender, EventArgs e) +0
   System.Web.UI.Control.OnPreRender(EventArgs e) +8704614
   System.Web.UI.Control.PreRenderRecursiveInternal() +80
   System.Web.UI.Control.PreRenderRecursiveInternal() +171
   System.Web.UI.Control.PreRenderRecursiveInternal() +171
   System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +842


Just to explain a little about the setup of the websites, each site uses the config and lib from the Tridion Install directory under \Program Files\Tridion. There is no config/lib folder per website, just a bin folder.

  • If you are saying that java version is correct and dlls like xmogrt is correct, can you ensure by looking at the Event Logs (in the Windows OS) that the bin path of these DLLs and config has been picked up correctly? - For example: It should pick up from Tridion_Home environment variable but in case you also have config and lib folder copied at your local applications' bin folder, then it might picked up from this bin folder instead of the Tridion_Home location Sep 16, 2013 at 12:33
  • Hi Pankaj, there's nothing in event viewer that suggests there are missing dlls as far as I can see. Sep 16, 2013 at 13:40
  • the same stacktrace seems to appear in this question which is a 2009 question, so I'm wondering if all your JARs in the lib dir are also correctly upgraded from 2009 to 2011? See also @Mihai's answer there. Sep 16, 2013 at 14:21
  • Hi Bart, if this was the case wouldn't I see this problem across all sites under this Tridion instance? Other sites on the same server that use Component Linking work fine. Just saying :) Sep 16, 2013 at 15:51
  • Can you check if other sites which are having internal linking working, have the Tridion config and lib folders in the Web Application's bin directory. Alternatively, can you (for testing purpose) try by copying the Tridion config and lib folders in the those Web Applications' bin directory for which internal linking is not working. Sep 16, 2013 at 17:03

3 Answers 3


It's a long shot, but Tridion can throw misleading Java exceptions if you create a ComponentLink object with invalid constructor arguments (e.g. an invalid or malformed Publication ID).

Can you update your question with code to show how you're creating and using the ComponentLink class?

  • Thank you Rick! The Publication Id setting was missing in the web config. Quite annoying that a better exception isn't thrown to help narrow down the problem easier >:( Sep 30, 2013 at 14:59

There's clearly something going on with the java subsystem needed by Tridion. The fact it gets reported as a linking issue is probably just because that's the first Tridion API call your page contains.

Here's what I would do.

First, eliminate the "maybe I'm missing a jar" discussion by:

  • Copying all Tridion configuration files into /bin/config
  • Copying all Tridion jar files into /bin/lib
  • IISReset, test.

If this works, then you know that the problem is with loading the libs/config from the TRIDION_HOME location. Perhaps due to application pool identity permissions, perhaps due to other "random" stuff on your environment. But at least you'll have a way forward.

Second, make sure Tridion is logging something. Configure your logback.xml to properly log something in DEBUG, and try to decode what's happening.

Third, do check your Tridion / Tridion Content Manager windows event logs for messages, Juggernet will usually log something about finding/not finding a Tridion Home, java home, etc.

Last, and definitely not least, read this excellent post from Peter Kjaer on How Tridion Content Delivery loads Configuration Files (.NET)

  • Thanks Nuno, I will take a look at this and get back to you with my findings. Sep 17, 2013 at 13:40

I have observed this error mostly when either Tridion license file is missing or the path for tridion license file given in cd_storage_conf.xml file is not correct.

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.