Problems about migrating Java(Broker API) from Tridion 2011 SP1 to SDL Web 8

Question

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.

ComponentPresentationAssembler(com.tridion.web.jsp.JSPPage)

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.

Questions

• 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"?

Regards,

Answer 1

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?