Bug 104837 - Content Items with category give error on publishing
Content Items with category give error on publishing
Product: Red Hat Enterprise CMS
Classification: Retired
Component: other (Show other bugs)
All Linux
high Severity high
: ---
: ---
Assigned To: Vadim Nasardinov
Jon Orris
Depends On:
Blocks: 98410
  Show dependency treegraph
Reported: 2003-09-22 15:08 EDT by Jon Orris
Modified: 2005-10-31 17:00 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-10-07 18:21:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jon Orris 2003-09-22 15:08:13 EDT
Description of problem:

Content items assigned to categories give an AssertionError in publishing.

To reproduce:
Create an article
Assign it to a category
Publish it

com.arsdigita.util.AssertionError: Cannot copy
category=[com.arsdigita.categorization.Category:{id=1065}]}]; it is not
an ACSObject
	at com.arsdigita.util.Assert.fail(Assert.java:78)
	at com.arsdigita.cms.DomainCopier.copy(DomainCopier.java:114)
	at com.arsdigita.cms.VersionCopier.copy(VersionCopier.java:108)
	at com.arsdigita.cms.DomainCopier.copy(DomainCopier.java:414)
	at com.arsdigita.cms.VersionCopier.copy(VersionCopier.java:170)
	at com.arsdigita.cms.DomainCopier.copyCollection(DomainCopier.java:370)
	at com.arsdigita.cms.DomainCopier.copyRole(DomainCopier.java:300)
	at com.arsdigita.cms.DomainCopier.copyProperty(DomainCopier.java:227)
	at com.arsdigita.cms.ObjectCopier.copyProperty(ObjectCopier.java:110)
	at com.arsdigita.cms.DomainCopier.copy(DomainCopier.java:175)
	at com.arsdigita.cms.VersionCopier.copy(VersionCopier.java:108)
	at com.arsdigita.cms.VersionCopier.createVersion(VersionCopier.java:185)
	at com.arsdigita.cms.VersionCopier.copyItem(VersionCopier.java:76)
	at com.arsdigita.cms.ContentItem.createPendingVersion(ContentItem.java:1556)
	at com.arsdigita.cms.ContentItem.copyProperty(ContentItem.java:1748)
	at com.arsdigita.cms.ObjectCopier.copyProperty(ObjectCopier.java:99)
	at com.arsdigita.cms.DomainCopier.copy(DomainCopier.java:169)
	at com.arsdigita.cms.VersionCopier.copy(VersionCopier.java:108)
	at com.arsdigita.cms.VersionCopier.createVersion(VersionCopier.java:185)
	at com.arsdigita.cms.VersionCopier.copyItem(VersionCopier.java:76)
	at com.arsdigita.cms.ContentItem.createPendingVersion(ContentItem.java:1556)
	at com.arsdigita.cms.ContentItem.publish(ContentItem.java:1230)
Comment 1 Vadim Nasardinov 2003-09-22 17:13:28 EDT
I am not sure if I'm the right person to deal with this bug.  I think
what happens is, the VersionCopier tries to copy the "category"
attribute of the ContentBundle object.  (This attribute is inherited
by the "ContentBundle" object type from "ACSObject".)  In the new
categorization object type model, the value of this attribute is a
CategoryObjectLink. This new object type essentially reifies the
two-way association between Category and ACSObject that existed in the
old model, and gives the reified association an explicit name.

The VersionCopier expects the value of this attribute to be an
ACSObject.  This used to be true in the old model.  In the new model,
the value of this attribute is an object of type CategoryObjectLink,
which is not a subtype of ACSObject.  This hoses up the VersionCopier.

So, there are at least two ways to deal with this bug:

 1. Make the VersionCopier capable of dealing with non-ACSObjects.

 2. Fix the categorization object model to not introduce an
    intermediate object type.

Scott points out that (1) has to be implemented, if we want the
VersionCopier to deal with associations that have link attributes.
(Link attributes are supported by representing the two-way association
internally as a synthetic, anonymous object type, much like the
explicitly named CategoryObjectLink.)

It is possible, in theory, to avoid the introduction of
CategoryObjectLink and revert the categorization object type model to
what it used to look like.  However, doing so hinges on adding new
features to persistence, either by implementing the 'specialize'
method that Dan proposed in his Categorization RFC, or by adding
enhanced support for link attributes.

In any case, there is no simple fix for this bug that I am aware of.
I am adding Rafi, Justin, and Scott to the cc list.

The following diagrams must be viewed in a fixed-width font browser or

The old model

+----------+                             +-----------+
| Category |<-------------+------------->| ACSObject |
+----------+  0..n        |        0..n  +-----------+
|          |              |              |           |
+----------+              |              +-----------+
                          |                    .
                    ..............            /_\
                    . anon assoc .             |
                    ..............             |
                    .sortKey     .             |
                    .isIndex     .      +---------------+
                    .isDefault   .      | ContentBundle |
                    ..............      +---------------+
                                        |               |
                                         | ContentItem |
                                         |             |
                                           |  Event   |
                                           |startTime |

                   | CatObjLink |
      +----------->|sortKey     |<--------------+
      |       0..n |isIndex     | 0..n          |
      |            |isDefault   |               |
      |            +------------+               |
      |1..1                                     |1..1
      @                                         @
 +----------+                             +-----------+
 | Category |                             | ACSObject |
 +----------+                             +-----------+
 |          |                             |           |
 +----------+                             +-----------+
                                         | ContentBundle |
                                         |               |
                                          | ContentItem |
                                          |             |
                                            |  Event   |
                                            |startTime |
Comment 2 Jon Orris 2003-09-23 10:56:16 EDT
Changing priority to High, as it breaks most of the automated scripts. Most of
them categorize content items.

Sorry to add pressure to what I know is a complex bug :(

Comment 3 Daniel Berrange 2003-09-23 11:01:09 EDT
My preference is that we remove the intermediate object type that was added,
reverting to a standard association. The introduction of this type has broken
many other pieces of code aside from publishing. I /think/ if 'addPath' were to
be fixed, then we could probably use the standard association model, without
needing to invent the 'specialize' method either.


As previously discussed I'll be writing a mail discussing this category object
model conundrum in more detail
Comment 4 Vadim Nasardinov 2003-09-23 13:01:54 EDT

I don't see this as fixable anytime soon.  Not by me, anyway.
I can think of the following options.

1. Remove the intermediate object type "c.a.categorization.CategoryObjectLink"

   Pros: this would fix the particular bug that your reported.
   Cons: it would break a gazillion other things, because the addPath API
         doesn't currently allow filtering/ordering by link attributes.

2. Change the publishing code to deal with DomainObjects rather than

   Pros: this would fix this particular bug.
   Cons: it's a fundamental rewrite that will take many, many weeks.

3. Do #1 plus change the addPath implementation to allow filtering/
   ordering on/by link attributes.

   Pros: this would make #1 possible.
         this would close a couple of other existing tickets.
         this bring joy and happiness to the world.
   Cons: I have no idea how difficult it would be and am definitely
         the wrong person to try and implement this.

The bottom line is, I don't see a quick resolution of this ticket.

for further details.
Comment 5 Archit Shah 2003-09-24 13:31:36 EDT
I believe this bug can be fixed very easily by skipping the categories
association in ContentItem.copyProperty. Something like:

+        if ("categories".equals(attribute)) {
+            return true;
+        }

This works because there is already code in copyProperty which deals with
copying categorization information. This is necessary because bundles are
categorized instead of items. With this change, when bundles are published the
categories association is not copied. Instead, when any item in the bundle is
published, the bundle's categories association is copied.
Comment 6 Jon Orris 2003-09-24 15:24:17 EDT
Submitted Archit's fix @36318

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