Bug 109963 - Unable to create an instance of the ContentItemPortlet
Summary: Unable to create an instance of the ContentItemPortlet
Alias: None
Product: Red Hat Enterprise CMS
Classification: Retired
Component: other   
(Show other bugs)
Version: nightly
Hardware: All Linux
Target Milestone: ---
Assignee: Richard Li
QA Contact: Jon Orris
Depends On:
Blocks: 106481
TreeView+ depends on / blocked
Reported: 2003-11-13 14:42 UTC by Daniel Berrange
Modified: 2007-04-18 16:59 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-01-26 21:34:03 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Daniel Berrange 2003-11-13 14:42:39 UTC
Description of problem:
When trying to add a 'Content Item' to a portal, an NPE is thrown when
submitting the form. If i remove the '/ccm' prefix on the path to the
item, the NPE goes away, but it simply says 'cannot find contnet item'

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Create an item 'foo' in /content/
2. Publsh the item
3. Add a content item portlet, entering /ccm/content/foo.en as the
item url
Actual results:

Expected results:
The portlet is added.

Additional info:

Comment 1 Jon Orris 2003-11-25 21:53:47 UTC
Relevant stack trace:

Looks like the underlying impl of ContentSection.getSectionFromNode
has changed, and no longer throws a DataObjectNotFoundException;
instead the section is returned null, leading to the NPE.

Comment 2 Richard Li 2004-01-07 19:58:44 UTC
I implemented a partial fix @39176. All this does is check if the
dispatcher prefix exists, and, if so, removes it.

The other issue that needs to be resolved is support for multilingual
content items/URLs -- I just noticed your example above, and that case
isn't handled right now.

Comment 3 Richard Li 2004-01-07 20:08:16 UTC
@39177 switches to using the MultilingualItemResolver.

Dan, does this fix the problems?

Comment 4 Daniel Berrange 2004-01-08 09:54:51 UTC
In the short term yes. Ideally we should be calling
ContentSection#getItemResolver IIRC to return the currently configured
item resolver for the section.

Note You need to log in before you can comment on or make changes to this bug.