Custom Rules - SonarQube 5.2

[Daniel Castro]

I am trying to standardize the coding quality rules where I work. One of our greatest offenders if the persistence.xml used by JPA. So, my intention is to find a way on our SonarQube 5.2 to not allow:

persistence.xml outside /src/main/resources;
check if the persistence.xml has transaction-type="RESOURCE_LOCAL" and points as error;
check if property name="hibernate.hbm2ddl.auto" value="update" or "create-drop" or "create" and points as error;
check if the persistence.xml has transaction-type="JTA" HAS A jta-data-source tag bellow (as its son).
Does SonarQube 5.2 has JPA rules to criticize it? Is it possible? How?

[matad...@googlemail.com]

Hi Daniel, check out the XML plug in which could be perfect for this. You can express custom XML rules through xpath expressions which most of these fit.

[G. Ann Campbell]

Hi Daniel,

I've specified a couple rules based on this:

1. RSPEC-3823
"RESOURCE_LOCAL" transaction type should not be used

1. RSPEC-3822
Hibernate should not update database schemas

and I'm wondering about a 3rd rule. What happens if a JTA persistence-unit doesn't have a jta-data-source?

Ann

[Daniel Ferreira Castro]

My intention is to enforce the use of jta-data-source instead of the non-jta-data-source, both tags that are allowed but since I am enforcing the use of JTA I must not allow non jta configurations.

--


You received this message because you are subscribed to a topic in the Google Groups "SonarQube" group.


To unsubscribe from this topic, visit https://groups.google.com/d/topic/sonarqube/DEUALanUIu4/unsubscribe.


To unsubscribe from this group and all its topics, send an email to sonarqube+...@googlegroups.com.


To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/a1d69c89-ad9e-4e95-a895-b7d5c528feab%40googlegroups.com.


For more options, visit https://groups.google.com/d/optout.

--

Sent from Gmail Mobile

[G. Ann Campbell]

Hi Daniel,

I get that. But what goes wrong if I don't specify a jta-data-source for a JTA persistence unit? Data saves fail silently? The app doesn't start up? Garbage is written to the log? Nasal demons?

Ann

---

G. Ann CAMPBELL | SonarSource

Product Manager

http://sonarsource.com

On Thu, Jan 5, 2017 at 1:39 PM, Daniel Ferreira Castro <dfca...@gmail.com> wrote:

My intention is to enforce the use of jta-data-source instead of the non-jta-data-source, both tags that are allowed but since I am enforcing the use of JTA I must not allow non jta configurations.

Em ter, 3 de jan de 2017 às 17:49, G. Ann Campbell <ann.ca...@sonarsource.com> escreveu:

Hi Daniel,

I've specified a couple rules based on this:

1. RSPEC-3823
"RESOURCE_LOCAL" transaction type should not be used

1. RSPEC-3822
Hibernate should not update database schemas

and I'm wondering about a 3rd rule. What happens if a JTA persistence-unit doesn't have a jta-data-source?

Ann

On Thursday, 22 December 2016 18:08:25 UTC-5, Daniel Castro wrote:

I am trying to standardize the coding quality rules where I work. One of our greatest offenders if the persistence.xml used by JPA. So, my intention is to find a way on our SonarQube 5.2 to not allow:

persistence.xml outside /src/main/resources;
check if the persistence.xml has transaction-type="RESOURCE_LOCAL" and points as error;
check if property name="hibernate.hbm2ddl.auto" value="update" or "create-drop" or "create" and points as error;
check if the persistence.xml has transaction-type="JTA" HAS A jta-data-source tag bellow (as its son).
Does SonarQube 5.2 has JPA rules to criticize it? Is it possible? How?

--


You received this message because you are subscribed to a topic in the Google Groups "SonarQube" group.


To unsubscribe from this topic, visit https://groups.google.com/d/topic/sonarqube/DEUALanUIu4/unsubscribe.

To unsubscribe from this group and all its topics, send an email to sonarqube+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/a1d69c89-ad9e-4e95-a895-b7d5c528feab%40googlegroups.com.


For more options, visit https://groups.google.com/d/optout.

[Daniel Ferreira Castro]

Hi Ann, I was on my vacations.

I will try to address your question as below.

JTA-DATA-SOURCE

- All the transaction management will be handled by the container;

NON-JTA-DATA-SOURCE

- All the transaction management will NOT be handled by the container;

A JTA Persistence Unit has all the mechanisms to handle a JTA DATA SOURCE and is possible to have a NON JTA DATA SOURCE that does not need those mechanisms.

A NON JTA Persistence Unit (RESOURCE LOCAL) lacks the handling mechanisms of JTA and so can not handle a JTA DATA SOURCE, only NON JTA DATA SOURCE.

Having briefly said that it is possible to have 2 data sources inside a persistence-unit, one JTA and other NON-JTA IF the Persistence Unit is JTA, but this is not true inside a RESOURCE_LOCAL persistence-unit.

[G. Ann Campbell]

Hi Daniel,

Thanks for getting back to me. I still don't understand what bad thing happens if a JTA persistence-unit doesn't have a jta-data-source.

Ann

---

G. Ann CAMPBELL | SonarSource

Product Manager

http://sonarsource.com

[G. Ann Campbell]

Hi Daniel,

Sorry to be slow on the uptake, but I'm still not understanding why this is a bad idea. I understand what you think is a bad idea (mixing jta with non-jta) but what I don't understand is why. I have suspicions, but my Google-fu is weak, and I'm not finding anything to either confirm or deny them.

Why is understanding the why such a big deal? Because I don't want to write a rule that says (essentially) "because I said so". No one liked hearing that as a kid, and I'm pretty sure that as adults folks like it even less.

So please pretend I'm a junior dev who thinks this kind of mixing is a super idea, and explain to me why it's not.

Thanks for your patience,

Ann

---

G. Ann CAMPBELL | SonarSource

Product Manager

http://sonarsource.com

On Mon, Jan 30, 2017 at 12:02 PM, Daniel Ferreira Castro <dfca...@gmail.com> wrote:

The real deal is not if you have or not a jta-data-source inside a persistence-unit.  It is possible to use it.

The problem seems to be when you have a RESOURCE_LOCAL persistence-unit and a jta-data-source inside it.

Quoting myself

[Daniel Ferreira Castro]

Hi G, how are you?

I have not used any argument about "God said so and we must proceed that way" :)  But ok, we have not find yet strong info to defend my suggestion. :)

It seems reasonable for me, only that.  I also agree that this is no strong reason to go ahead with a rule unless this rule is a particular custom rule to fit some needs (in that case how it should be done?).

Still trying to find more info about that.  Either way, if my studies proves that my idea is good or not good it will be a learning that will help us all.

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/CAEi9rULTLHOWtxOocvM6CBBcat9_yHVQN05mygocCfKgApVmqw%40mail.gmail.com.