Bug 703206

Summary: When uploading bundle recipes don't display the uploaded results
Product: [Other] RHQ Project Reporter: Charles Crouch <ccrouch>
Component: ProvisioningAssignee: RHQ Project Maintainer <rhq-maint>
Status: NEW --- QA Contact: Mike Foley <mfoley>
Severity: unspecified Docs Contact:
Priority: high    
Version: 4.0.0CC: hbrock, hrupp, mazz
Target Milestone: ---Keywords: FutureFeature, Improvement
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
test bundle recipe none

Description Charles Crouch 2011-05-09 12:22:19 EDT
So as mazz says below the problem is not in the recipe upload but the fact that once uploaded we try to display the contents of the file back in the text area, and in doing so the xml gets screwed up. 
The answer here is just not to display the xml after a file upload :-). We just need something like a check mark next to the upload to indicate it succeeded, just as we have for the subsequent content upload.

(11:15:00 AM) ccrouch: so is it a known bug that when uploading a recipe when creating a bundle, the upload process strips out the closing / on single xml elements '/>' goes to '>', resulting in invalid xml
(11:15:53 AM) pilhuhn: ccrouch you mean when uploading the whole bundle via the upload box?
(11:17:06 AM) pilhuhn: ccrouch I am not sure if it is known, but I've seen issues in the past with the upload of the whole zip, where pasting in the recipe worked,
(11:18:15 AM) ccrouch: pilhuhn: no this is the difference between pasting the recipe and uploading the recipe, I'm not using container bundles
(11:18:33 AM) ccrouch: iirc there was something screwed up with this in IE a while back
(11:18:38 AM) ccrouch: but this is in FF
(11:30:41 AM) mazz: ccrouch: known issue
(11:30:43 AM) mazz: there is a bz on this
(11:30:51 AM) mazz: you have to close all tags with </tag>
(11:33:06 AM) mazz: 'course I can't find the BZ but this has been a known issue for a long time. has to do with the way the browser or gwt or something processes HTTP response that has xml in it
(11:33:27 AM) mazz: I remember debugging this a long time ago and couldn't figure out why the xml was getting hosed exactly
(11:36:22 AM) ccrouch: thanks mazz
(11:36:33 AM) mazz: ccrouch: there is an FAQ on this
(11:36:34 AM) mazz: http://rhq-project.org/display/JOPR2/FAQ#FAQ-WhenItrytocreateabundlebyuploadingaAntrecipeXMLdirectly%2CtheXMLcontentseemstogetcorruptedandtagsareplacedoutoforder.
(11:37:07 AM) ccrouch: at worst we're going to need to put something in the error message to explain to people they need to copy/paste or change their xml
(11:37:18 AM) ccrouch: i cant believe there is no way to upload valid xml :-/
(11:37:24 AM) mazz: its not uploading
(11:37:30 AM) mazz: its the processing of the response
(11:37:43 AM) mazz: we upload the XML file, which we then immediately return in the response
(11:37:58 AM) ccrouch: well let not return it in the response :-)
(11:38:00 AM) mazz: the response XML is failing to get processed and placed into the GWT text component for some reason
(11:38:24 AM) ccrouch: just have a check mark, saying uploaded successfully :-)
(11:38:25 AM) mazz: I debugged this for a long time and could never figure out why it was happening
Comment 1 Charles Crouch 2011-05-09 12:29:22 EDT
Setting this to high priority because when using the tool there is no indication of what the workaround is (i.e. copy and paste from the file to the text area, instead of uploading the file) you just get an exception complaining about invalid xml. We have a FAQ entry but I'm not sure people''s first reaction is to go look in there.
Comment 2 John Mazzitelli 2011-05-16 15:12:26 EDT
"The answer here is just not to display the xml after a file upload"

That's not fully the solution because we don't store the XML anywhere on the server - all we do it turn right around and stream it back over the response so the client can populate it in the text field (in other words, this is a way for a user to "load the content" of a file that is local to the browser and show it in the browser. We just use the server and HTTP protocol as a intermediary or proxy to do this.

What we can do is on the server, parse the XML and remove the <tag/> type tags and replace them with <tag></tag> type tags, if that's possible. Or we fix the browser code to not screw this up (I'm not sure where the problem was, but I do remember debugging this and discovering it was a problem that wasn't obvious in our code)
Comment 3 John Mazzitelli 2011-05-17 17:16:40 EDT
The problem is not server side - using a tcp-tracer, I captured the HTTP response coming back after the recipe is uploaded and you'll see the XML comes back OK - this is the last portion of the HTTP response:

Content-Disposition: form-data; name="textFile"; filename="deploy.xml"
Content-Type: text/xml

<?xml version="1.0"?>

<project name="small-bundle" default="main" xmlns:rhq="antlib:org.rhq.bundle">

    <rhq:bundle name="Small Bundle"
                description="a small bundle with a small.properties file">

        <rhq:deployment-unit name="jar">
            <rhq:file name="small-v1.properties" destinationFile="small.properties" replace="false" />


    <target name="main"/>



That XML is identical to the XML that was sent up in the HTTP request, and that XML is valid.
Comment 4 John Mazzitelli 2011-05-17 17:24:50 EDT
It appears once the data gets here:

org.rhq.enterprise.gui.coregui.client.bundle.create.BundleUploadDistroFileStep.createRecipeForm().new DynamicFormHandler() {...}.onSubmitComplete(DynamicFormSubmitCompleteEvent)

the XML is corrupted.
Comment 5 John Mazzitelli 2011-05-18 11:07:41 EDT
Created attachment 499618 [details]
test bundle recipe

Note: it appears this is a problem only on SOME browsers, but not all.

See the attached recipe to test with. using that, I see the error in FireFox but NOT Chrome. It appears there is a bug in FF's parsing of the XML. I think it has to do with its JavaScript implementation of innerHTML.
Comment 6 Charles Crouch 2011-09-30 13:38:05 EDT
(In reply to comment #2)
> "The answer here is just not to display the xml after a file upload"
> That's not fully the solution because we don't store the XML anywhere on the
> server - all we do it turn right around and stream it back over the response so
> the client can populate it in the text field

This is exactly the problem. We should not be relying on the browser to store the contents of the recipe file that was uploaded. Instead when the user chooses to upload a recipe file it should be stored on the server and not displayed to the user.

The fact that the user can, as an alternative, paste in a recipe into the wizard should be completely unrelated to the uploading of a recipe file.

I understand that this is not how the wizard is architected right now, and that this problem only occurs on certain browsers. So given that, and according to comment1 we have this issue doc'd in the FAQ, I'm pushing this out of JON3 and marking it as a future improvement