Exceptions incorrectly logged when operator NOT is used in a statement

• Type: Bug
• Status: Closed
• Resolution: Fixed
• Affects Version/s: 7.0.X, 7.1.X, Master
• Fix Version/s: 7.0.0 DXP FP86, 7.0.10.12 DXP SP12, 7.0.X, 7.1.10 DXP FP14, 7.1.X, 7.2.10 DXP FP2, 7.2.10.1 DXP SP1, 7.2.X, 7.2.1 CE GA2, 7.3.0 CE GA1, 7.3.10 DXP GA1, Master
• Component/s: Core Infrastructure > Service Builder
• Labels:
  • ee-ts
  • liferay-dxp-70-sp12
  • liferay-dxp-72-sp1
  • liferay-fixpack-de-86-7010
  • liferay-fixpack-dxp-14-7110
  • liferay-fixpack-dxp-2-7210
• Branch Version/s:
  7.2.x, 7.1.x, 7.0.x
• Backported to Branch:
  Committed
• Fix Priority: 1
• Git Pull Request: https://github.com/brianchandotcom/liferay-portal/pull/77751

Exception messages are incorrectly built in persistence_impl_finder_find.ftl methods using the negation operator. For example the following method is generated in JournalArticlePersistenceImpl:

 

/**
 * Returns the first journal article in the ordered set where companyId = ? and status ≠ ?.
 *
 * @param companyId the company ID
 * @param status the status
 * @param orderByComparator the comparator to order the set by (optionally <code>null</code>)
 * @return the first matching journal article
 * @throws NoSuchArticleException if a matching journal article could not be found
 */
 @Override
 public JournalArticle findByC_NotST_First(long companyId, int status,
 OrderByComparator<JournalArticle> orderByComparator)
 throws NoSuchArticleException {

    JournalArticle journalArticle = fetchByC_NotST_First(companyId, status,
       orderByComparator);

    if (journalArticle != null) {
      return journalArticle;
    }

    StringBundler msg = new StringBundler(6);
    msg.append(_NO_SUCH_ENTITY_WITH_KEY);
    msg.append("companyId=");
    msg.append(companyId);
    msg.append(", status=");
    msg.append(status);
    msg.append("}");
 
    throw new NoSuchArticleException(msg.toString());
 }

 

(Current behaviour):

Resulting in a exception message like this when there is not an article with a status different than the specified one:

No JournalArticle exists with the key {groupId=23952, articleId=/1067002, status=8}

  

Expected behaviour: Messages generated by these kind of methods should look like:

No JournalArticle exists with the key {groupId=23952, articleId=/1067002, status!=8}