Bug 973223 - CSProcessor assemble now appears to use IDs for all file names?
Summary: CSProcessor assemble now appears to use IDs for all file names?
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: PressGang CCMS
Classification: Community
Component: REST-API
Version: 1.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: Lee Newson
QA Contact: Stephen Gordon
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-11 13:41 UTC by Stephen Gordon
Modified: 2013-10-09 05:23 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-10-09 05:23:50 UTC
Embargoed:


Attachments (Terms of Use)

Description Stephen Gordon 2013-06-11 13:41:19 UTC
Description of problem:

When using csprocessor assemble on 0.32.3 the fixed URL pass appears to fail. As a result all file names fall back to the IDs instead. As a result links we sent to QE in previous builds are now incorrect even though we have for the most part only modified topics in between.

Content spec ID is 15807, relevant output is:

sgordon@zugzug:~/Documents/cspecs/Installation_and_Configuration_Guide> csprocessor assemble
CSProcessor client version: 0.32.3
Loading configuration from /home/sgordon/.config/csprocessor.ini
Loading project configuration from csprocessor.cfg
Connecting to PressGang server: http://skynet.usersys.redhat.com:8080/TopicIndex/

Starting to parse...
Starting first validation pass...
Attempting to download all the latest topics...
Attempting to download all the revision topics...
	Downloading revision topics 50% Done
	Downloading revision topics 100% Done
Starting second validation pass...
INFO:  The Content Specification is valid.

Starting to build...
Doing en-US Populate Database Pass
Doing Fixed URL Pass
org.jboss.resteasy.client.ClientResponseFailure: Error status 400 Bad Request returned
	at org.jboss.resteasy.client.core.BaseClientResponse.createResponseFailure(BaseClientResponse.java:523)
	at org.jboss.resteasy.client.core.BaseClientResponse.createResponseFailure(BaseClientResponse.java:514)
	at org.jboss.resteasy.client.core.BaseClientResponse.checkFailureStatus(BaseClientResponse.java:508)
	at org.jboss.resteasy.client.core.extractors.BodyEntityExtractor.extractEntity(BodyEntityExtractor.java:38)
	at org.jboss.resteasy.client.core.ClientInvoker.invoke(ClientInvoker.java:120)
	at org.jboss.resteasy.client.core.ClientProxy.invoke(ClientProxy.java:88)
	at com.sun.proxy.$Proxy27.updateJSONTopics(Unknown Source)
	at com.redhat.contentspec.builder.DocbookBuilder.setFixedURLsPass(DocbookBuilder.java:3808)
	at com.redhat.contentspec.builder.DocbookBuilder.doPopulateDatabasePass(DocbookBuilder.java:661)
	at com.redhat.contentspec.builder.DocbookBuilder.buildBook(DocbookBuilder.java:433)
	at com.redhat.contentspec.builder.DocbookBuilder.buildBook(DocbookBuilder.java:307)
	at com.redhat.contentspec.builder.ContentSpecBuilder.buildBook(ContentSpecBuilder.java:86)
	at com.redhat.contentspec.client.commands.BuildCommand.process(BuildCommand.java:542)
	at com.redhat.contentspec.client.commands.AssembleCommand.process(AssembleCommand.java:73)
	at com.redhat.contentspec.client.Client.processArgs(Client.java:259)
	at com.redhat.contentspec.client.Client.main(Client.java:109)

Doing en-US First topic pass
...

Comment 1 Stephen Gordon 2013-06-11 14:23:51 UTC
(In reply to Stephen Gordon from comment #0)
> Content spec ID is 15807, relevant output is:

I got ekopalova to assemble another spec for me and she didn't get this issue, she did however encounter it when assembling 15807. So it appears to be something specific to this spec, thought it might be the custom legal notice but commenting that out didn't seem to help.

Comment 2 Lee Newson 2013-06-11 23:03:20 UTC
The problem is actually a server side issue in the REST API that I've actually already fixed, but it hasn't been released yet. The cause is that when concurrent builds occur two Fixed URL property tags get set with the same value. The csprocessor will fix this on the next build by removing the latter property tag, however the server doesn't use the mapping id to delete the property tag and instead just uses the main id and value.

The workaround is to manually find the topics that have the duplicated property tags and delete both of them.

Comment 3 Lee Newson 2013-07-01 22:44:39 UTC
Fixed in build 20130701-0911 and deployed during the maintenance yesterday.

Comment 4 Lee Newson 2013-10-09 05:23:50 UTC
Moving this bug to CLOSED CURRENT_RELEASE to clean up old bugs that were QA'd
by the PressGang team but not by the original reporter. If the bug is still present then please re-open the bug.


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