Metadata Valid
No translation
<!--
Thank you for contributing to this project!
-->
This adapts the templates for java-check, server.xml and setenv to the state of the 8.7.1 tarball, while keeping required modifications in place.
I thought about setting stuff depending on the installed java version, however not everyone installs java also via puppet and if ones does it, it must not necessarily be via the java puppet module.
Maybe we need an additional parameter to the module stating the java version?
Fixes #300
<!--
Thank you for contributing to this project!
-->
<!--
Replace this comment with a description of your pull request.
-->
<!--
Replace this comment with the list of issues or n/a.
Use format:
Fixes #123
Fixes #124
-->
We run Jira in a cluster setup (pacemaker). For that we need to have the homedir of Jira (which is also the "data" directory) on a NFS share. The NFS mount is done to another directory and the data dir is a symlink, which is managed outside of this jira module. To be able to do that, i needed to fix the jira module to not handle the homedir, if done from outside. I think it will be useful for others, who are building similar setups, hence this pull request.
n/a
With the recent addition of proxy support, I found it was missing proxy support for the mysql-connector. It also was missing puppet-archive support.
I opened this pull request to start the discussion.
At the moment, I set redirect https only if:
you set the version variable to 7.1.0 and up
and
if you set both tomcatredirecthttpsport and tomcatnative_ssl
It's safe to say that 7.1.0 accept this config and I dont' want to mess the web.xml file if you don't want to redirect. But I would like to know how we determine we need to redirect. I'm pretty sure that you might want to redirect even without $tomcatredirecthttps_port?
Is only tomcatnativessl is enough?
@ffrank I wasn't aware of the voxpupuli/puppet-extlib#63 at the time I wrote this patch. But it seems to describe a similar issue.
<!--
Thank you for contributing to this project!
-->
<!--
Replace this comment with a description of your pull request.
-->
<!--
Replace this comment with the list of issues or n/a.
Use format:
Fixes #123
Fixes #124
-->
<!--
Thank you for contributing to this project!
-->
<!--
Updated the tomcat connectors based on Atlassians Jira Software Upgrade notes.
More information under: https://confluence.atlassian.com/jirasoftware/jira-software-7-13-x-upgrade-notes-957135908.html
-->
<!--
Use format:
Fixes #269
-->
Add a new, optional class parameter jira::tomcat_additional_connectors
whose value is a well-formed, complex hash as described by the new type
aliases Jira::Tomcat_connectors and Jira::Tomcat_attributes. Each
hash key represents a port number, and the key's value is a hash that
describes the connector's attributes and their values.
Useful for defining additional HTTP ports through which to access Jira.
A typical use case is when Jira and Confluence run behind a reverse
proxy and application links between Jira and Confluence must be set up.
Then it is often better to allow Jira and Confluence to communicate
directly instead of through the reverse proxy, but this requires a
Tomcat connector that is configured for direct access instead of reverse
proxy access (proxyName, proxyPort, etc). Described here:
https://confluence.atlassian.com/kb/how-to-create-an-unproxied-application-link-719095740.html
Contains spec tests, documentation and examples.