One of our customers is using Tridion 2011 SP1, and they will upgrade it to SDL Web 8.

Now there are custom Java modules which are made by using Broker API(Tridion 2011 SP1), and it's necessary to migrate it to SDL Web 8.

So I made an Eclipse project, imported Java source code files of the custom module(Tridion 2011 SP1) and SDL Web 8's JAR files to the project. SDL Web's JAR files are copied from \Content Delivery\roles\api\rest\java\lib in install media.

Then some compilation errors occurred.

1.Package of "PageExistsHandle" class is modified.

com.tridion.web.jsp.tag.PageLinkHandler seems to be modified to com.sdl.web.content.tags.PageLinkHandler.

2. A class "JSPPage" is missing.

com.tridion.dynamiccontent.ComponentPresentationAssembler has following constructor in Tridion 2011 SP1.


But in SDL Web 8, there is no class named JSPPage.

In my implementation, some Dynamic Component Presentation contains Java code in it. I remember to excute Java code in DCP, it's required to create ComponentPresentationAssembler's instance by this constructor, and publish DCPs to file system.

3. A Class "ComponentLink" doesn't have "getLinkInfo" method.

On SDL Tridion 2011 SP1, com.tridion.linking.ComponentLink class has a method getLinkInfo, but SDL Web 8 doesn't have it. (But in SDL Web 8's Javadoc, there is "getLinkInfo" on "ComponentLink" class page)

I customized it by extending "ComponentLink" class and using "LinkInfo" to customize a logic to get URL linked to.


  • About 1 above, is it no problem just to modify package in Java?
  • About 2 and 3 above, how can I migrate my custom module to SDL Web 8? Or should I use "In process(legacy)" JAR files instead of "rest"?



On question1: Yes you can change the package to the new package 'com.sdl.web.content.tags.PageLinkHandler'. But please consider using the TLD's the tag handler class itself is not the public API, the public API is described in the tag library descriptor (TLD) file that is provided. The idea in an upgrade is that you simply swap out the 'tld' file and you have upgraded your tags.

on question2: In a webservice world it is no longer possible to execute JSP/Java code on the content webservice side. So in case you want to have dynamic functionality on the content webservice you need to make sure to use TCDL/REL for this purpose. Hence due to on the Content Service not being able to execute JSP/Java we removed the constructor with the JSPPage.

On question3: I am unsure why you used that method before as it was protected and non-public API, unsure how it was made to work besides extending the class? There is no alternative for it available at this moment, can you indicate why this method was used?

  • When same component is used in many pages, Component link (dynamic linking) resolves URL according to priority, but it caused problem that resolved URL is different from I wish. So I made a functionality that generates link to a page which have a component with a specific component template. To achieve that I used LinkInfo's properties "templateId" and so on. Aug 16 '16 at 8:52
  • By the way, I noticed that "ComponentMetaFactory" doesn't exist on SDL Web 8 neither. Is this class removed? This issue is asked in following post too.tridion.stackexchange.com/questions/15277/… Aug 16 '16 at 8:59
  • I found "ComponentMetaFactory", it's in "content-compatible-8.1.1-1012.jar". I' m using Deployer Extension and the JAR file was missing from my setting. Copied "content-compatible-8.1.1-1012.jar" and content-broker-8.1.1-1012.jar from "API" folder of installation media, then ComponentMetaFactory worked. Aug 17 '16 at 2:59
  • I correct about "ComponentMetaFactory". Put "cd_broker.jar" in "/services/deployer-service" directory is necessary. The JAR file is in "api/in-process/java/lib" of installation media. Aug 25 '16 at 6:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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