Description of problem: @36230/postgres 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 [com.arsdigita.categorization.CategoryObjectLink:{childObject=[com.arsdigita.cms.ContentBundle:{id=26001}], 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) at com.arsdigita.cms.ui.lifecycle.ItemLifecycleSelectForm$ProcessListener.process(ItemLifecycleSelectForm.java:412)
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 editor. 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 | +----------+
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 :(
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. http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=104889 As previously discussed I'll be writing a mail discussing this category object model conundrum in more detail
Jon, 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 ACSObjects. 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. See http://porter.boston.redhat.com/acs6/doc/categorization/categorization-api-RFC.html for further details.
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.
Submitted Archit's fix @36318