3

I'm in the process of moving an old Tridion 2013 SP1 portal webapp over to SDL Web 8 on new infrastructure. We have decided that for old portals, we will use the legacy in-process API.

Publishing works. I'm able to render embedded component presentations and resolve binaries. But I'm not able to render dynamic component presentations.

In cd_core.log on the portal that fails, I'm getting the following message:

"ERROR JSPProcessor - JSPProcessor.run(...) The JSP ComponentPresentation is not located in the documentroot of your website; /progs/portals/staging/tnprivat/web;/progs/portals/staging/tnprivat"

I believe this is the culprit, but I don't understand why it's happening.

In cd_storage_conf.xml for both the deployer and the webapp I have set the default item type mapping to defaultdb, with the exception of pages and binaries (those are going to DefaultFile). Therefore I don't understand why JSPProcessor is looking for the CP in the document root. Shouldn't it be looking for the DCP in the database - because I've checked, and it's present there.

Environment details:

  • OS: RHEL 7.1
  • Java: 1.8.0_102-b14
  • SDL Web: 8.1.1
  • Webapp container: Jetty-runner 9.3.11

I'm sure I have done something wrong in the configuration, but I don't know where. Hope you'll be able to help.

Improve this question
8
  • When you say you're unable to render the DCPs - are you using the ComponentPresentationAssembler class to assemble them - or are you using the ComponentPresentationFactory class?
    – Dylan .. Mark Saunders
    Sep 29, 2016 at 10:15
  • Well, I'm using the ComponentPresentation tag. I'm not sure what class this refers to. Here's an example: <div id="menuContainer" role="navigation" class="hide-on-load"><tridion:ComponentPresentation pageURI="tcm:52-139850-64" componentURI="tcm:52-213682" templateURI="tcm:52-213630-32"/></div> On our current Tridion 2013 environment, this will render a block of menu elements. On SDL Web 8, we just get a few blank lines. I'm certain that the component is published, as I can see it in the broker database
    – Morten Ryum
    Sep 29, 2016 at 12:04
  • I remember having issues with this, because the app server wouldn't execute code "outside" its webroot. Tridion will identify that the file is in location X (whatever you configured in the storage), pass it on to the app server, and the app server will determine that it cannot execute the code stored in that location. Not sure if Jetty supports this.
    – Nuno Linhares ♦
    Sep 29, 2016 at 12:43
  • @NunoLinhares I've specified the location to be defaultDb, so the location in the file system should be irrelevant, right? Anyway, I'll give Tomcat a shot tomorrow and let you know the results.
    – Morten Ryum
    Sep 29, 2016 at 13:10
  • JSP Component Presentations cannot execute from DB - they need to be in File System
    – Nuno Linhares ♦
    Sep 29, 2016 at 13:40

1 Answer 1

Reset to default
1

The issue is resolved.

To sum up:

  • It's not possible to store dynamic JSP component presentations in the database. It has to be stored in the file system.
  • If a JSP DCP is stored outside of the webapp root, it will not render on the page. ERROR JSPProcessor - JSPProcessor.run(...) The JSP ComponentPresentation is not located in the documentroot of your website will be logged to cd_core.log in the webapp. This problem applies to webapps running in Tomcat and Jetty, but might work in other app servers such as JBoss
  • The solution for us was to create one storage definition per webapp in cd_storage_conf and map this to the corresponding publication(s).

Side note: This solution is not ideal as it requires CD-side configuration when creating new publications (which in our case will require a release through our operations partner). I'm happy to hear suggestions on other solutions if you have any.

Improve this answer
2
  • 1
    I guess my first question (well, should have been) is if you need JSP DCPs in the first place. If you're only using standard Tridion tags like linking, you could use REL instead of JSP - these will be executed even when coming from a database. Another approach is the DD4T/DXA approach, where the DCP is stored as text (JSON) and the application parses the text to render whatever needs rendering.
    – Nuno Linhares ♦
    Oct 3, 2016 at 11:18
  • 1
    I've asked myself the same question. This publication is quite old and I have not been involved with development of most of the component templates, so I don't know how many components needs to be updated, and what the consequences would be of changing it to REL. We are in the process of replacing this portal with a brand new one, which is being built using DXA, so we won't have this issue in the future.
    – Morten Ryum
    Oct 3, 2016 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.