How to get a Jira Datasource?

[lesteso]

Hi there,

I'm trying to conect to Jira database ussing a datasource, but i didn't it...

In my Tomcat context.xml:

<Resource name="jiradb"

auth="Container" type="javax.sql.DataSource"

username="user"

password="pass"

driverClassName="com.mysql.jdbc.Driver"

url="jdbc:mysql://localhost:3307/jiradb"

/>

And, in my class:

InitialContext context = new InitialContext();

DataSource ds = (DataSource) context.lookup("java:comp/env/jdbc/jiradb");

I receive this message in the log file:

javax.naming.namenotfoundexception: el nombre jdbc no este asociado a este contexto

Thanks in advance!

[lesteso · Accepted solution]

Hi!

I could connect to JIRA database using a datasource with this code:

final OfBizConnectionFactory connectionFactory = new DefaultOfBizConnectionFactory();

conection = connectionFactory.getConnection();

You needn't to use in your Jira plugin code: DriverManager.registerDriver(new com.mysql.jdbc.Driver());...

I hope it is helpful.

Regards!

[Nic Brough -Adaptavist-]

May I ask why you want to get a datasource in a plugin?

Two reasons - first, I want to be sure that you do not want to use it to do any writes to the database, and secondly, if we know why you think you need the data source, there's a good chance we can point you at a better way to do whatever you're aiming for without the database.

(I'm also not sure that the context contains the datasource, and I'm pretty sure you can't just cast a string to a datasource like that. I'd also try just 'jiradb' instead of the whole thing, I but I'm really not sure)

[Konrad Garus]

For starters, it would be nice if the alternative (ActiveObjects) had sensible docs and API, and supported transactions. There are numerous ORMs far better than ActiveObjects.

[Nic Brough -Adaptavist-]

Transactions become irrelevant when you're using AO correctly - via the API.  I'd agree that the docs aren't great though.

[Konrad Garus]

How can I update two entities together then, with guaranteed atomicity? How do you ensure isolation and consistency?

[Nic Brough -Adaptavist-]

Let the API do it.  You should never be tooching a JIRA database directly.

[Konrad Garus]

It looks like in JIRA ActiveObjects do not support transactions: https://jira.atlassian.com/browse/JRA-25808 (from 2011, no less). Javadoc (https://docs.atlassian.com/jira/7.1.4/com/atlassian/jira/DefaultHostContextAccessor.html) says: "JDEV-32949: This has been reverted to a NO-OP until we figure out if we can do this in safe way."

So, if the API wasn't weak and discouraging enough, it looks like it's not even fully supported on JIRA.

[Konrad Garus]

I'm desperate to get away from ActiveObjects, even for bare JDBC. Asked a new question at https://answers.atlassian.com/questions/38744777.

If you know the answer, or can verify the one from @Luis Esteso on this page, could you please share it?

[Nic Brough -Adaptavist-]

Luis' answer looks correct to me, for reading a JIRA database.

You must never write to one though.

[Konrad Garus]

OK, what happens if I do write? I need it both ways.

I mean, I do not want to write to core JIRA tables. That's obviously a bad idea. But I want to create and write my own tables. What can go wrong with that?

[Nic Brough -Adaptavist-]

Ok, that's safe.  JIRA will ignore new tables completely.

But

• You could lose them when upgrading
• Make sure you are careful with table names - there's the JIRA core stuff and then all the other AO tables (pick an obvious prefix standard to avoid issues - kg_ or something)
• You are totally unsupported by Atlassian (if you raise a support call, they could easily answer "we can't help you until you've dropped all the extra tables")
• JIRA doesn't use the database a lot for several reasons, and you'll need to be very careful to keep the load low.  Things like starting to edit an issue, or even just view them in some places can cause fast multiple SQL hits, so direct access could be a problem if you're doing things like fields with them.