Bug 754556 - Deploying EAR/WAR to EAP 4.3 server fails with IE8
Deploying EAR/WAR to EAP 4.3 server fails with IE8
Product: RHQ Project
Classification: Other
Component: Core UI (Show other bugs)
Unspecified Unspecified
urgent Severity high (vote)
: ---
: JON 3.0.0,RHQ 4.3.0
Assigned To: John Mazzitelli
Mike Foley
Depends On:
Blocks: jon30-sprint9
  Show dependency treegraph
Reported: 2011-11-16 15:19 EST by John Sanda
Modified: 2012-02-07 14:26 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-02-07 14:24:05 EST
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 John Sanda 2011-11-16 15:19:12 EST
Description of problem:
I am unable to create an deploy a WAR child resource for a EAP 4.3 server when I upload the WAR file from IE8. The client-side path gets included in the file path.
I get the following error in my agent log,

MainDeployer$DeployerException: Failed to deploy /home/jsanda/Development/tools/jboss-eap-4.3/jboss-as/server/production/deploy/C:\fakepath\testBundle.war - Enable DEBUG logging to see the stack trace.

Note that the file upload and deployment works fine in FireFox

Version-Release number of selected component (if applicable):

How reproducible:
Always with IE8

Steps to Reproduce:
1. Import an EAP 4.x server into inventory
2. Using IE8 go to the Child Resources subtab for the EAP server
3. Click the Create Child button in the footer and select WAR. Note that the problem is not specific to WAR files, but that is what I used.
4. Go through the wizard and you should see an error similar to mine in your agent log
Actual results:

Expected results:

Additional info:
Comment 1 John Mazzitelli 2011-11-17 12:07:12 EST
the problem is that:

            packageName = new File(packageName).getName();

runs on the server. If the server is running on Linux (though the file upload came from Windows and packageName is somethign like "C:\path\foo.txt") we can't assume that it will parse windows paths correctly. On linux, this returns "C:\path\foo.txt" if that is the value of packageName.
Comment 2 John Mazzitelli 2011-11-17 12:30:09 EST
I tested uploading bundle files to see if the same problem happens - it doesn't. That works fine.

The issue is the form item "name" when uploading a package version is passed in with the IE filename (which includes the bogus fakepath).

So it looks like we need to be careful with all classes that subclass FileUploadServlet. Of the 4 that exist today, only PackageVersionFileUploadServlet appears to have this bug.

It uses:

   String packageName = getFormField(formFields, "name", file.getName());
   packageName = new File(packageName).getName();

This is code running in the server. If this is running on Linux, but we get a Windows path in the "name" form item (which happens if I upload via IE), then it won't do what you think it will - the File.getName() returns the full windows path (like "C:\fakepath\foo.txt").

We need to take out the new File() call and replace with a more generic method to strip the path to obtain the filename:

   String packageName = getFormField(formFields, "name", file.getName());
   packageName = FileUtil.getFileName(FileUtil.useForwardSlash(packageName), "/");
Comment 3 John Mazzitelli 2011-11-17 12:47:36 EST
master commit: c9688a017c484af70bd731805ec5088deb2bf189
release_jon3.x commit: f204de0b5177073defba2f0add4fc0f70e2a4be6
Comment 4 Mike Foley 2011-11-18 13:53:04 EST
issue is not specific to EAP 4.3.  related to file upload in general.
Comment 5 Sunil Kondkar 2011-11-22 07:52:22 EST
Verified on build#18 in rhq-release-gwt-locales branch.

Using IE8, successfully deployed a war file to the EAP 4.3 server. No errors are observed in agent log.
Comment 6 Mike Foley 2012-02-07 14:24:05 EST
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE
Comment 7 Mike Foley 2012-02-07 14:26:17 EST

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