Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 109963

Summary:	Unable to create an instance of the ContentItemPortlet
Product:	[Retired] Red Hat Enterprise CMS	Reporter:	Daniel Berrangé <berrange>
Component:	other	Assignee:	Richard Li <richardl>
Status:	CLOSED RAWHIDE	QA Contact:	Jon Orris <jorris>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	nightly	CC:	jparsons
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-01-26 21:34:03 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	106481

Description Daniel Berrangé 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'
instead.

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:
NPE

Expected results:
The portlet is added.

Additional info:

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

Relevant stack trace:
java.lang.NullPointerException
	at
com.arsdigita.cms.dispatcher.SimpleItemResolver.getItem(SimpleItemResolver.java:105)
	at
com.arsdigita.cms.ui.portlet.ContentItemPortletEditor$1.initialValue(ContentItemPortletEditor.java:73)

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 Berrangé 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.