[COOK-3853] Application java fails to deploy if a remote war file has no change

[ghost]

https://tickets.opscode.com/browse/COOK-3853

1. Fixed the name of the destination war to <application.name>.war instead of the basename for the URL. This is required because the URLs we have pretty non readable basenames.

e.g. https://abc.com/nexus/service/local/artifact/maven/redirect?r=snapshots&g=dummy&a=dummy&v=LATEST&e=war

tomcat fails to deply this because the URL does not have a basename ending with .war

1. fix to provider_remote_file_deploy.rb which gave exceptions with current chef's remote_file and file providers.
2. If the war file has not changed the target revision for the remote file would be an empty string resulting in deploy_revision clearing up the releases and current folders!
   Fixed by setting the revision number to checksum if not explictly specified.
3. The application's unpacked folder wasn't cleared from webapps meaning new war deployment did not take effect. Fixed.

[sethvargo]

Ohai! Thank you for supporting the Opscode Cookbooks! There are a few couple prerequisites before we can merge your contribution. We need to ensure you've completed a Contributor License Agreement (CLA) and a ticket in our JIRA tracker for the release workflow.

1. Create a COOK ticket in Opscode Open Source JIRA
2. Sign the Opscode CLA (you only need to do this once)
3. Mark the JIRA ticket as "Fix Provided" (please note, it can take up to 48 hours to process)
4. Join us for COOK Code Review (optional)

For more detailed steps and information, please see How to Contribute on the Opscode Wiki.

In this case, it appears someone else created the ticket already. However, we will need you to add a link to this Pull Request to the ticket and then mark the ticket as "Fix Provided". You will not be able to mark the ticket as "Fix Provided" until you have signed the CLA.

Feel free to ping me (@sethvargo) if you have any questions 😄. Thanks!

[ghost]

Hi Seth,

Have signed the CLA. However Jira still doesn't allow me to mark the ticket as fix provided. I guess there is lag between signing the CLA and jira seeing the CLA.

Also added the link to the ticket in the pull request.

Thanks

[sethvargo]

Hey @omkarashish thank you for taking the time to do that. Unfortunately it's still a manually process to add you to JIRA. Would you mind checking back tomorrow please? I'm sorry about the delay, and keep in mind this is a one-time process. You won't need to do this for every ticket.

[ghost]

Hi Seth,

Have updated the status of the ticket (https://tickets.opscode.com/browse/COOK-3853) as fix provided.

Thanks,
Ashish

[btm]

I'm not familiar enough with deploying Java applications, but I wonder if this is too presumptuous to expect the war file to have the same name as the resource but with this extension (always). There was no hardcoded reference to this extension previously. When you create the RemoteFile resource again below, you're now using "#{deploy_resource.name}.war" but before it was just deploy_resource.name. This seems like a breaking change, and also a hardcoded expectation that will be confusing.

[ghost]

The name of the file file refereed to by '@war' is the name of the file created locally. Tomcat requires the .war extension to be able to deploy the application. This assumption does not apply to the source file which coulod have any name.

In fact the older code made this assumption. It used the url of the war file instead, which in my case was cryptic and did not have the .war. With this tomcat never deployed the application.

[miry]

@omkarashish can you provide the simple work example