What would be the best way to write checks for pom.xml and ejb-jar.xml files content ?

[Michel Pawlak]

Hi SQ team,

I currently have a Maven enforcer plugin that runs a set of checks on ejb-jar.xml files of ejb projects. I would like to convert some of these checks that are non-blocking to SQ checks in order to have violations within SQ (and in order not to stop builds, and thus make sure that SQ analyses are always run). What would be the best way to write such a plugin ?

The plugin should be able to : 

- detect the presence of an ejb-jar.xml file if there is a pom.xml file and the packaging's tag value is "ejb"

- do some checks on the content of ejb-jar.xml

Do I have to start from scratch or can I reuse something (xml plugin ?)

Thanks in advance for your help

Michel

[Freddy Mallet]

Sorry for this late answer @Michel. 

As we're talking about rules targeting a java project, for me those rules should be part of the SonarQube Java plugin. Indeed, from a technical point of view nothing prevents anymore a language plugin to log an issue on a source file analysed by another language plugin and so here to have the Java plugin logging an issue on an XML configuration file. @Nicolas, do you share the same feeling ?

Could you share some examples of rules you're thinking about @Michel ?

Thanks

Freddy MALLET | SonarSource

Product Director & Co-Founder
http://sonarsource.com

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/feb4210a-d8a7-49d8-908f-352a8a2c5aa0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michel Pawlak]

Hi Freddy,

I think that "java" should be understood as a technology and not only as a language. I thus agree with you, java plugin should make possible the analysis of non "*.java" files, such as java-related xml files. In our case we have ejb-jar.xml, but we could imagine also checking persistence.xml files, spring configuration files, etc.

Here are some examples concerning ejb-jar.xml : 

• if the project is not whitelisted, ejb-jar.xml descriptor file must exist
• a specific interceptor must be declared in ejb-jar.xml
• ejb-jar.xml cannot contain interception exclusions (exclusions must be done through annotations)

[Nicolas Peru]

Hi Freddy and Michel, 

I am totally on the same line with you here. @Michel you put that really nicely by saying java in sonar-java-plugin is to be understood more as the java ecosystem than solely the java language. 

One thing to precise : We depend a lot on platform team for this features to index all files so for this to work it will most probably requires at least a 5.1+ version of SQ. 

We would be really interested to have ideas of rules on those topics as we are no EJB experts. Would you be able to details a bit more your examples ? Some of them sound specific but others might be broad enough to make their way into RSPEC and then the plugin. 

Cheers,

Nicolas PERU | SonarSource

Senior Developer
http://sonarsource.com

https://twitter.com/benzonico

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/577f9128-2ec6-43ee-9c3a-9980a7b03b6e%40googlegroups.com.

[Michel Pawlak]

Hi Nicolas,

Here are some details about the three rules I listed. Other checks I have are really specific to our context or can only be done on produced deliverables (war / ear).

- src/main/resources/META-INF/ejb-jar.xml must exist if project is an ejb project -> Rationale : EJB3 default interceptors must be declared in this file (https://docs.jboss.org/ejb3/app-server/tutorial/interceptor/interceptor.html) So if you plan to use them you must have an ejb-jar.xml file (if you have no custom default interceptor you need no ejb-jar.xml)

- Default interceptor XYZ must be declared in ejb-jar.xml (EJB name pattern, default interceptor class) -> Rationale : allows to check all default interceptors that must be activated for the ejb project. This check has a cardinality = Cardinality.MULTIPLE

- interceptor exclusions must be declared as Java annotations -> Rationale : exclusions for the default interceptor can be declared as annotations or directly in ejb-jar.xml file. In order to simplify code review, avoid issues due to refactoring, and make sure that code behavior is not modified through configuration, we forbid XML-based exclusions

Currently I do these checks in a maven enforcer plugin during ear construction. If any of these checks fails, then the ear cannot be built (short explanation : no interceptor == no security). However I don't want to fail QA builds of ejb projects due to this reason, I prefer to raise blocker issues instead and let teams correct them asap.

By the way, here is an EJB related check I wrote that may be of interest to the community :

- Non serializable type in remote service method check -> Rationale : @Remote services interfaces must be callable from a remote VM, therefore parameters and return types of methods declared in a @Remote interface must implement java.io.Serializable or be primitive types.

Michel

[G. Ann Campbell]

Hi Michel,

You might take a look at the XML plugin's XPath rule: it allows you to specify a pattern for applicable files, the XPath to detect violations and the issue message.

HTH,

Ann

[G. Ann Campbell]

Doh!

This is what I get for skimming a thread.

I'd like to write up your rules as preparation for implementation but I have some questions (below):

On Wednesday, 8 July 2015 12:10:02 UTC+2, Michel Pawlak wrote:

Hi Nicolas,

Here are some details about the three rules I listed. Other checks I have are really specific to our context or can only be done on produced deliverables (war / ear).

- src/main/resources/META-INF/ejb-jar.xml must exist if project is an ejb project -> Rationale : EJB3 default interceptors must be declared in this file (https://docs.jboss.org/ejb3/app-server/tutorial/interceptor/interceptor.html) So if you plan to use them you must have an ejb-jar.xml file (if you have no custom default interceptor you need no ejb-jar.xml)

We don't have a lot of (any!) experience with EJB apps. What marks an app as EJB other than the existence of ejb-jar.xml?

And is this rule meant primarily to catch mis-named ejb-jar.xml files or ones that are missing?

 

- Default interceptor XYZ must be declared in ejb-jar.xml (EJB name pattern, default interceptor class) -> Rationale : allows to check all default interceptors that must be activated for the ejb project. This check has a cardinality = Cardinality.MULTIPLE

A couple questions here:

* what makes an interceptor default?

* I guess you're looking for interceptors defined in other xml files? Defined via annotations & not included in the xml file?

 

- interceptor exclusions must be declared as Java annotations -> Rationale : exclusions for the default interceptor can be declared as annotations or directly in ejb-jar.xml file. In order to simplify code review, avoid issues due to refactoring, and make sure that code behavior is not modified through configuration, we forbid XML-based exclusions

This seems pretty straightforward. Would you mind supplying a noncompliant (xml) sample and a compliant (annotations) sample?

 

- Non serializable type in remote service method check -> Rationale : @Remote services interfaces must be callable from a remote VM, therefore parameters and return types of methods declared in a @Remote interface must implement java.io.Serializable or be primitive types.

Here's the rule specification for this one: http://jira.sonarsource.com/browse/RSPEC-3276. Let me know if anything's off.

Ann

[Michel Pawlak]

Hi Ann,

My answers are below your questions

On Wednesday, July 22, 2015 at 9:41:16 AM UTC+2, G. Ann Campbell wrote:

I'd like to write up your rules as preparation for implementation but I have some questions (below):

We don't have a lot of (any!) experience with EJB apps. What marks an app as EJB other than the existence of ejb-jar.xml?

"ejb" packaging of pom.xml (we use Maven)

 

And is this rule meant primarily to catch mis-named ejb-jar.xml files or ones that are missing?

missing ones (we consider a mis-named one as a missing one)

 

A couple questions here:

* what makes an interceptor default?

The answer to this question, can be found in the "default interceptors" section of the following page : https://docs.jboss.org/ejb3/docs/tutorial/1.0.7/html/EJB3_Interceptors.html

Compliant example :

<assembly-descriptor>
 <!-- Default interceptor that will apply to all methods for all beans in deployment -->
 <interceptor-binding> (1) this may be multiple
      <ejb-name>*</ejb-name> (2) this should be configurable
      <interceptor-class>org.jboss.tutorial.interceptor.bean.DefaultInterceptor</interceptor-class> (3) this should be configurable as well + can be multiple
   </interceptor-binding>
   ...
</assembly-descriptor>

Non compliant example : interceptor binding is missing, of an awaited interceptor s not declared.

 

* I guess you're looking for interceptors defined in other xml files? Defined via annotations & not included in the xml file?

No, default interceptors can only be defined in the ejb-jar.xml file. We want to make sure that a specific interceptor (i.e. fully qualified class name) is declared in the 

interceptor-binding

section of the ejb-jar.xml file. For instance in the web page above we may want to make sure that 

<interceptor-class>org.jboss.tutorial.interceptor.bean.DefaultInterceptor</interceptor-class>

 is declared for 

<ejb-name>*</ejb-name>

 (i.e. DefaultInterceptor class wil be executed for all (*) JEE beans. 

This seems pretty straightforward. Would you mind supplying a noncompliant (xml) sample and a compliant (annotations) sample?

Same page as above, section "Exclusion of default and class interceptors" compliant code will have the following :

@ExcludeDefaultInterceptors
public class EmailMDB implements MessageListener
{
   ...
}

Non compliant code will have the following in ejb-jar.xml :

<assembly-descriptor>
      ...
      <interceptor-binding>
         <ejb-name>EmailSystemBean</ejb-name>
         <exclude-default-interceptors>true</exclude-default-interceptors> (1) This line is forbidden
      </interceptor-binding>
      ...
</assembly-descriptor>

 

 

- Non serializable type in remote service method check -> Rationale : @Remote services interfaces must be callable from a remote VM, therefore parameters and return types of methods declared in a @Remote interface must implement java.io.Serializable or be primitive types.

Here's the rule specification for this one: http://jira.sonarsource.com/browse/RSPEC-3276. Let me know if anything's off.

I wrote this rule and have now a working version. Having tested it on a representative code base of 350+remote interfaces, here are the cases I had to handle :

• primitive types are allowed
• Enums are allowed
• Serializable itself is not allowed (bad practice)
• subType of java.io.Serializable are allowed
• arrays of allowed types are allowed
• parameterized types must be checked
• parameter types of parameterized types must be checked (recursively)
• handle the case of java Collections and Maps (we consider them as Serializable as only 2-3 Collections Interfaces implementations are not serializable, and as those implementations are only used for developping caches (and therefore it makes no sense to transmit them through remote services calls)... this is as a corner case, but it may raise lots of false positives 
• both parameters and return types of method signatures must be checked
• we check only remote interfaces (not types)

Ann

Hope it helps, 

Michel 

[Michel Pawlak]

One more thing : 

 

We don't have a lot of (any!) experience with EJB apps. What marks an app as EJB other than the existence of ejb-jar.xml?

"ejb" packaging of pom.xml (we use Maven)

 

If you want to be Maven-agnostic, you can try to detect first if the project has JEE Beans (any one of javax.ejb.Singleton, MessageDrive, Stateless or Stateful) (as @Local/@Remote interfaces are not mandatory, do not base your check on it)

Michel

[G. Ann Campbell]

Hi Michel,

Thanks for your answers.

I've written these two new rules. Let me know if you see anything off about them: 

http://jira.sonarsource.com/browse/RSPEC-3281

http://jira.sonarsource.com/browse/RSPEC-3282 (Note that I generalized this one slightly from the case you presented)

I know you were expecting 3 rules, but in thinking about the first two it went like this:

1. there must be an ejb-jar.xml
2. but only if there are default interceptors
3. default interceptors must be in ejb-jar.xml

This means that

1. a default interceptor in the wrong file will cause issues to be raised for #1 and #3
2. a project with no default interceptors won't raise any issues at all (#2)

So it seemed best to limit the check to just finding default interceptors in the wrong file.

Let me know if I'm not looking at this in the right way.

Thx,

Ann

---

G. Ann CAMPBELL | SonarSource

Product Owner

http://sonarsource.com

--
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/cYQdBhf00eo/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/26028a77-0001-4474-a0a2-85bb4dbf59c7%40googlegroups.com.