Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add option to install Oracle Java Connector #50

Open
mkrakowitzer opened this issue Jan 20, 2015 · 8 comments
Open

Add option to install Oracle Java Connector #50

mkrakowitzer opened this issue Jan 20, 2015 · 8 comments
Milestone

Comments

@mkrakowitzer
Copy link
Contributor

@adamcrews
Copy link
Member

I'm thinking I'll take a stab at this, but Oracle makes it difficult to automatically download their files. You must accept a license agreement on the Oracle webpage which then sets a cookie that allows the download to happen. I can do this in the module, but the easiest way is to use the nanliu/archive module instead of staging or deploy to fetch and place the various downloaded bits.

So the avenues I can take are:

  1. add support for archive, so the module supports deploy, and staging, and archive.
    • easy, but seems silly to support so many overlapping tools.
  2. replace staging with archive.
    • pretty easy, but a much bigger PR and likely a major version bump.
  3. drop support for deploy and staging in favor of archive only.
    • more difficult, but I think it simplifies the code in the long run

Is there a reason that staging and deploy are both supported in the module?
Is there an objection to removing staging and deploy and going with only archive?

@mkrakowitzer
Copy link
Contributor Author

I kept support for deploy to remain backwards compatible as it was the original module used. I think lets drop support for both deploy and staging in favour of archive, it would require a major version bump though.

re downloading files from oracle, I do this with the deploy module, I am sure its possible with staging/archive. See example here: https://github.com/puppet-community/puppet-jira/blob/master/spec/acceptance/default_parameters_spec.rb

@igalic
Copy link
Contributor

igalic commented Sep 21, 2015

👍

@adamcrews
Copy link
Member

In case anyone else happens on this ticket, I've got this mostly done and expect to have all the tests passing in the next couple days.

@adamcrews
Copy link
Member

The ojdbc drivers are behind a login wall. I was figuring I could step around the license accept checkbox with a cookie just like you can with the java downloads, but that is not the case for the ojdbc drivers. You need both the cookie and auth credentials. So.... I'll do a PR shortly that will let you specify your own download url for the drivers, and add a note to the docs on why you can't auto download it direct from the source at Oracle.

@adamcrews
Copy link
Member

Haha, the jokes on me (and everyone else). The tar version of Jira that this module installs includes a ojdbc driver. A user only needs to add the driver if they are using the WAR file distribution. Since this module does not support setting jira up via war file, I think this ticket can just be closed.

Step 2 of this page documents this. https://confluence.atlassian.com/jira/connecting-jira-to-oracle-185729461.html

@TJM
Copy link
Contributor

TJM commented Jul 3, 2018

For what its worth they no longer include the ojdbc driver, even in the tar version. It's really too bad it can't automatically look in like $JIRA_HOME/lib for jars :-/

This one should at least support fetching the jar from a "local" source (puppet/https/etc), even if it can't emulate agreeing to the license agreement on oracle.com.

@TJM
Copy link
Contributor

TJM commented Oct 3, 2018

@adamcrews Do you still have any of this code? The ojdbc8.jar is not (no longer) distributed with JIRA, even in the "tar" distribution. It might be nice to have some existing "working" code to start with. My current customer will, of course, need to be able to set an "internal" URL (Artifactory) to retrieve the file from, because our servers cannot directly reach the Internet.

Additionally, as this is required for multiple tools, perhaps it would make sense to have ojdbc be its own puppet module, that could be reused in confluence, jira, crucible, etc?

Right now, I have a workaround like the following in my profile:

class profile::jira7 (
  Boolean $manage_ojdbc = true,
  String $ojdbc_source = 'https://artifactory.domain.com/artifactory/atlassian-tools/ojdbc8.jar',
) {

  include java
  include jira
  include jira::facts

  # Workaround for OJDBC
  if $manage_ojdbc {
    $ojdbc_file = split($ojdbc_source, '/')[-1]
    $ojdbc_path = "${jira::webappdir}/lib/${ojdbc_file}"
    file { $ojdbc_path:
      ensure => file,
      source => $ojdbc_source,
      mode   => '0644',
      owner  => $jira::uid,
      group  => $jira::gid,
    }
    File[$ojdbc_path] ~> Class[Jira::Service]
  }
}

I think using the archive module would be better. I think I remember there being some reason why using a http path for source was 'bad', like maybe it would make a web request for each puppet run?

Anyhow, I have very similar code for confluence, and that was when I thought maybe this should be its own module ;)

~tommy

@oranenj oranenj added this to the Wishlist milestone Apr 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants