Bug 754556 - Deploying EAR/WAR to EAP 4.3 server fails with IE8
Summary: Deploying EAR/WAR to EAP 4.3 server fails with IE8
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RHQ Project
Classification: Other
Component: Core UI
Version: 4.2
Hardware: Unspecified
OS: Unspecified
urgent
high
Target Milestone: ---
: JON 3.0.0,RHQ 4.3.0
Assignee: John Mazzitelli
QA Contact: Mike Foley
URL:
Whiteboard:
Depends On:
Blocks: jon30-sprint9
TreeView+ depends on / blocked
 
Reported: 2011-11-16 20:19 UTC by John Sanda
Modified: 2018-11-14 09:40 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-07 19:24:05 UTC
Embargoed:


Attachments (Terms of Use)

Description John Sanda 2011-11-16 20:19:12 UTC
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 17:07:12 UTC
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 17:30:09 UTC
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 17:47:36 UTC
master commit: c9688a017c484af70bd731805ec5088deb2bf189
release_jon3.x commit: f204de0b5177073defba2f0add4fc0f70e2a4be6

Comment 4 Mike Foley 2011-11-18 18:53:04 UTC
issue is not specific to EAP 4.3.  related to file upload in general.

Comment 5 Sunil Kondkar 2011-11-22 12:52:22 UTC
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 19:24:05 UTC
changing status of VERIFIED BZs for JON 2.4.2 and JON 3.0 to CLOSED/CURRENTRELEASE

Comment 7 Mike Foley 2012-02-07 19:26:17 UTC
marking VERIFIED JON 3 bugs to CLOSED/CURRENTRELEASE


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