Forem: Query Filter

docker107

Query Filter — Thu, 07 May 2026 16:46:31 +0000

The reason you cannot find the file in the project's root directory is that quantum/pom.xml is a relative path. In Maven projects, this usually means the repository is a multi-module project.

Where is the file?

The pom.xml is located inside a subdirectory named quantum.

TeamCity Context: In your TeamCity screenshot, the "Path to POM file" is quantum/pom.xml. This tells the build agent to look inside the quantum folder of your checked-out source code.
Jenkins Context: If you are running the Jenkins job on the root level, but the settings are inside quantum/pom.xml, Jenkins might be defaulting to a different parent pom.xml or its own auto-generated settings, which explains why the artifacts are ending up in the "wrong group."

Why the "Wrong Group" in Jenkins?

If the TeamCity build was publishing to the correct group but Jenkins is not, the "Group ID" control is likely in one of two places:

1. The `<distributionManagement>` section (Inside `quantum/pom.xml`)

Open quantum/pom.xml and look for this block. It defines the Artifactory URL and the target repository.

<distributionManagement>
    <repository>
        <id>artifactory-releases</id>
        <url>https://artifactrepository.citigroup.net/artifactory/libs-release-local</url>
    </repository>
</distributionManagement>

The Problem: If Jenkins is not using the specific quantum/pom.xml as its entry point, it won't see these deployment coordinates.

2. The Jenkins Artifactory Plugin (Overriding the POM)

In Jenkins, check your Job Configuration. Many COMET jobs use the "Artifactory Plugin" which has a section called "Target Repository".

If this is filled out in Jenkins, it overrides whatever is written in your pom.xml.
The Fix: Ensure the "Target Repository" in Jenkins matches exactly what was used in TeamCity.

Action Plan for the "etsf" Migration

To fix the group/package issue:

Locate the file: Go to your terminal or IDE and run: find . -name "pom.xml" | grep quantum This will confirm the exact disk location of the file you saw in the TeamCity screenshot.
Point Jenkins to it: In your Jenkins "Build" step, change the Root POM field from pom.xml to quantum/pom.xml.
Check for "Profiles": In the TeamCity screenshot, look at the "Additional Maven command-line parameters". If there is a -P some-profile-name, you must include that in Jenkins too. Often, the deployment logic is hidden inside a Maven Profile.

Verdict for your Rebuild:
The "wrong group" is almost certainly caused by Jenkins targeting the root directory instead of the quantum subdirectory. Aligning the "Root POM" path in Jenkins to quantum/pom.xml should restore the correct inheritance and publishing coordinates.

Does your Jenkins job currently have "pom.xml" or "quantum/pom.xml" in the Root POM field?

docker106

Query Filter — Thu, 07 May 2026 15:44:31 +0000

Migration Findings Report: etsf Library (Java 6 to Java 8)

Category	Specific Findings
Missing Infrastructure	Core `com.citigroup.valengine` components (`ValidationContext`, `ValidationResult`) are missing. Found only as fragmented "shadow" re-implementations in other apps; likely orphaned in retired BitBucket archives.
Java 8 Compliance	Numerous `Map` and `Class` assignments failed compilation due to stricter type inference, requiring manual casting to resolve legacy raw-type ambiguities.
Test Suite Regression	594 tests are currently failing due to missing dependencies. These classes span EMMA server interfaces, regional business logic (Japan/Korea), and core CPLS persistence and caching layers.

Identified Missing Classes (Test Dependencies)

com.citigroup.get.emma.server.OpenTypeIF
BaseCacheChangeListener
CplsSupervisoryApprovalCacheToDbPersistentStore
JPNSupervisorProviderImpl
KRSupervisorProviderImpl
SupervisorDataProvider
CPLSBeanInitializer
ApprovalCacheChangeListener
ApprovalOrderPersister
MessageFilterImpl
ConvertAuditFields

Verdict

High Risk / Blocked. The current rebuild effort is operating on "incomplete intelligence." Compiling the code via manual casting is a cosmetic fix; however, the absence of the valengine source and the failure of nearly 600 tests suggests that the library’s functional core is compromised. Until the authoritative legacy libraries are retrieved from BitBucket archives or found in Artifactory, the library cannot be certified as stable for Java 8 production environments.

docker105

Query Filter — Wed, 06 May 2026 18:15:15 +0000

find ~/.gradle/caches/modules-2/files-2.1 -name "*.jar" -print0 \
| xargs -0 -P 8 -I {} sh -c 'jar tf "{}" | grep -q "com/company/MyClass.class" && echo "FOUND in {}"'

docker104

Query Filter — Wed, 06 May 2026 16:24:48 +0000

plugins {
    id 'java-library'
}

group = 'com.citi.158825.ETSFb'
version = '1.0-A20'

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(8) // Adjust to 11 or 21 if needed
    }
}

sourceSets {
    main {
        // This tells Gradle that 'src/main/config' is a resource folder
        resources {
            srcDirs = ['src/main/resources', 'src/main/config']
        }
    }
}

jar {
    archiveBaseName = 'etsf'
    manifest {
        attributes(
            'Implementation-Title': 'CPLS etsf Library',
            'Implementation-Version': archiveVersion,
            'Build-Time': new Date().format("yyyy-MM-dd'T'HH:mm:ssZ")
        )
    }
}

docker103

Query Filter — Wed, 06 May 2026 16:15:13 +0000

plugins {
    id 'java-library' // Essential for creating a library JAR
}

group = 'com.citi.158825.ETSFb'
version = '1.0-A20'

java {
    // Matches your CPLS target environment (Java 6/8/21)
    toolchain {
        languageVersion = JavaLanguageVersion.of(8) 
    }
}

repositories {
    mavenCentral()
    // If you need to pull existing jars from your Artifactory:
    maven {
        url "https://maven-icg-prod.com/artifactory/libs-release"
    }
}

dependencies {
    // Add any external jars here
    // implementation 'org.apache.commons:commons-lang3:3.12.0'
}

tasks.named('jar') {
    manifest {
        attributes(
            'Implementation-Title': 'ETSF Library',
            'Implementation-Version': archiveVersion,
            'Built-By': System.getProperty('user.name')
        )
    }
}

docker102

Query Filter — Wed, 06 May 2026 14:38:48 +0000

This proposal is structured for management to emphasize a structured, low-risk approach to recovering the etsf library while addressing the practicalities of cross-team collaboration.

Management Proposal: Recovery Strategy for Legacy CPLS Artifacts

Executive Summary

Recent audit of the CPLS (formerly COMET) application stack has identified the etsf library as a critical dependency that is currently present in Artifactory but missing from the GitHub source code repository. Given its 2025 activity, this is likely a migration "orphan." I propose a Reverse-Chronological Forensic Recovery (Divide-and-Conquer) to restore this asset from BitBucket backups.

Proposed Recovery Methodology

We will use a search-and-validate loop to minimize time spent on irrelevant legacy data:

Phase 1: The "High-Confidence" Window (Q3 2025)
- Action: Direct the BitBucket Infrastructure team to restore the Full Backup from Q3 2025 (aligned with the last Artifactory update on Aug 25, 2025).
- Validation: Compare restored code against the disassembled JAR from Artifactory using class-level checksums.
Phase 2: Narrowing (Weekly Incrementals)
- Action: If the Q3 backup matches, pull the subsequent weekly incrementals to find the absolute latest commit before the library was deleted or migrated.
Phase 3: Fallback (Quarterly Regression)
- Action: If Q3 2025 is empty, move back in quarterly increments (Q2 2025, Q1 2025, etc.) until the source is located.

Practicality & Resource Assessment

Working with the Central Hub/Infrastructure teams is practical, but success depends on precise documentation.

Is it "Monthly"? No. If we provide the specific Artifact ID (etsf) and Group ID (com.citi.158825.ETSFb), a search of a specific backup volume usually takes 24–48 hours for the team to run. The "months" of delay usually come from vague requests; specific IDs and dates bypass this.
The "Ticket" Requirement: Yes, an official ticket is mandatory. In most enterprise environments, Infrastructure teams cannot access backup vaults without a tracked request for audit and compliance purposes.

Action Plan & Internal Instructions

Required Ticket Details

To avoid back-and-forth, the ticket should include:

Service: Source Control Recovery (BitBucket Legacy)
Target Repo/Path: com/citi/158825/etsf
Specific GroupID: com.citi.158825.ETSFb
Priority Date: August 25, 2025 (Last known deployment)
Request: "Restore the repository state from the last full backup prior to Sept 1, 2025."

Collaborative Instructions for Hub Teams

To BitBucket Admins: "Identify the last active 'Project Key' associated with the etsf artifact. If the repo was deleted, provide the deletion log entry to identify the decommissioning owner."
To GitHub Migration Team: "Audit the 'Migration Exclusion List' for the 2025-2026 cycle to see if 158825 was intentionally scoped out due to its Java 6 status."

Risk Mitigation

By comparing any found source code against the disassembled code from Artifactory, we eliminate the risk of "version mismatch." We are not just looking for any code; we are looking for the code that matches the binary currently running in our environment.

Recommendation: Proceed with a High-Priority Infrastructure ticket today to initiate the Q3 2025 search.

Does the CPLS migration timeline allow for a 48-hour buffer to wait for these backup results?

docker101

Query Filter — Wed, 06 May 2026 14:05:46 +0000

Based on disassembled code from Artifactory: maven-icg-prod/com/citi/158825

This report consolidates the library metrics, focusing on the Java versioning transition and the specific file distribution within the /opt/CPLS environment.

Artifact Name	Version	Java Release Year	Java Version	Major Version	Java Files (Total)
`dds`	2.0 B3	2006	Java 6	50	40
`configserverJMXClient`	1.0 A1	2006	Java 6	50	49
`emmacommon`	1.0 A0	2004	Java 5	49	8
`emmacommon`	1.2 C0	2004	Java 5	49	4
`emmacommon`	2.0 D0	2006	Java 6	50	5
`emmaserver`	1.0 A0	2004	Java 5	49	18
`emmaserver`	1.2 C0	2004	Java 5	49	19
`emmaserver`	2.0 D0	2006	Java 6	50	25
`etsf`	1.0 A20	2006	Java 6	50	119
`etsf`	1.0 A6	2006	Java 6	50	98

Key Takeaways for Deployment

Runtime Requirements: Since the majority of these artifacts (including the largest, etsf) are Major Version 50, the target environment must run JRE 6 or higher.
Version Discrepancy: Note that emmacommon and emmaserver have legacy versions (1.0 and 1.2) compiled in Java 5. While these will run on a newer JVM, the 2.0 versions represent the current standard for the 2006 baseline.
CPLS Application Structure: The high file count in etsf suggests it is the primary functional component of the CPLS suite, while emmacommon remains a lightweight dependency.

docker100

Query Filter — Mon, 04 May 2026 13:54:07 +0000

Update: RPM Versioning & Strategy for CPLS

Hi Team,

Our LightSpeed support ticket confirmed that high-level user-defined variables are not currently passed into build technologies like Tekton. As a result, we are adopting a version.properties file (adjacent to build.gradle) as our primary, Rank #1 configuration method.

Note: While version.properties is our standard, it can be superseded by Tekton variables if an override is deemed necessary.

Example `version.properties` File:

# Primary build configuration (Rank #1)
pkgVersion=9.1.94
pkgRelease=6

Key Implementation Details:

Resolution Priority:
1. Properties File: (Primary/Standard)
2. CLI Parameters: (Optional overrides, e.g., -PpkgVersion)
3. Defaults: (0.0.0)
Side-by-Side Installation: Artifacts are identified as CPLS-<AppVersion>-<AppRelease>. This ensures builds are distinct packages and previous installs remain intact.
Status: Verified on branch exper_leonid_comet_lse_mig_apr20. Please merge when ready.

Optional CLI Override Example:
./gradlew buildRpm -PpkgVersion="9.1.94" -PpkgRelease="6"

docker99

Query Filter — Thu, 30 Apr 2026 22:33:58 +0000

Subject: Regarding Persistent Test Messages in the CTI_QA Environment

Dear Customers,

Please accept my sincere apologies for the "LEONID CITI DEMO" messages that have been appearing within the system. I understand that these persistent messages have caused frustration and confusion, and I want to provide a clear explanation of why this occurred and how we are resolving it.

What Happened

During testing, I utilized two Persistent Queues—my_persistent_queue and my_persistent_queue123—which I bound to several topics, including US/COMET/INC/ORDER/CASH/COES/SLSI. In the Solace ecosystem, a Persistent Queue acts as a physical "mailbox" on the broker's disk. Unlike a standard topic, which is ephemeral, a message delivered to a persistent queue will remain there indefinitely until it is manually purged or successfully acknowledged by a consuming application.

Because these queues were linked to multiple topics, they captured and stored every "LEONID" test injection across several routing paths. These messages have remained "surfacing" because they were never consumed and removed from the broker’s storage.

The Resolution Plan

To permanently stop these messages from appearing, the "mailboxes" must be cleared and their links to the production-style topics must be severed. I have provided a guide below for the necessary actions within the Solace PubSub+ Manager.

Step	Action	Purpose
1. Locate Queues	Find `my_persistent_queue` and `my_persistent_queue123`.	Identifies the specific test containers.
2. Remove Bindings	Open the Subscriptions tab and delete all topic bindings.	Stops the queues from "attracting" any future messages.
3. Purge Messages	Select Action > Purge.	Wipes the existing demo messages from the disk.
4. Delete Queues	Select Action > Delete.	Permanently removes the test infrastructure to prevent recurrence.

I am currently auditing our source code and deployment scripts to ensure these test queues are not recreated in future builds. Thank you for your patience as we clean up these artifacts.

Best regards,

Leonid
Software & DevOps Engineer

docker98

Query Filter — Thu, 30 Apr 2026 22:25:19 +0000

Step,Action,Description

Access VPN,Open Solace Manager,Log into the 156783_COMET_US_CTI_QA Message VPN.
Locate Queues,Navigate to Messaging > Queues,Search for my_persistent_queue and my_persistent_queue123.
Remove All Bindings,Open Subscriptions Tab,Click the queue name and go to the Subscriptions tab. Delete the binding for US/COMET/INC/ORDER/CASH/COES/SLSI and any other related topics like US/CPLS/> or wildcard variants.
Clear Content,Select Action > Purge,"This wipes the ""Sept 2025"" demo messages currently on disk without deleting the queue itself."
Final Delete,Select Action > Delete,Recommended. Permanently remove these test queues to prevent them from capturing future traffic.

docker97

Query Filter — Thu, 30 Apr 2026 20:02:10 +0000

Based on the screenshot you provided, you have successfully located the Topic Endpoint (Queue) where these messages are residing. The queue name is DTE_156783_US_ExtInc_cash_coes_sls1_Q_0.

Since you have already selected the checkboxes for several messages, you are very close to deleting them. Here is how to finish the process:

1. Identify the "LEONID" Message

In the list under Messages Queued, click the small right-facing arrow (>) next to the checkbox for a Message ID.
This will expand the message details. Look at the Payload or Content section to find the "LEONID CITI DEMO" text.
Note: The messages in your screenshot are from September 15 & 16, 2025. If the "LEONID" message was sent "last fall," you may need to scroll down or use the filter to find older messages.

2. Delete the Selected Messages

Once you have checked the boxes for the specific messages you want to remove (as you have started doing in the image):
Click the "Action" button located at the top right of the message list (next to the filter/settings icons).
Select Delete from the dropdown menu.
Confirm the deletion in the pop-up prompt.

3. Using the Filter (Faster)

Since there are 81 messages queued and the "LEONID" message is driving people crazy, it might be easier to filter for it:

Click the Filter icon (three horizontal lines/sliders) on the far right, above the message list.
Search for LEONID.
If the message appears, select it and use the Action > Delete flow.

Important Observation

Your screenshot shows that these messages have 0 Redeliveries. This means the "annoying" message isn't actually being sent to an application and failing; it is simply sitting in the queue. If people are seeing it "surface," it's likely because an application is performing a "Browse" of the queue rather than "Consuming" it, or they are looking at the same Solace Manager screen you are.

Caution: Ensure that you only check the boxes for the specific "DEMO" messages. Any messages with larger attachment sizes (like the ~1850B ones) might be actual production orders that you do not want to delete.

docker95

Query Filter — Thu, 30 Apr 2026 19:56:08 +0000

Dealing with a "ghost" message that keeps surfacing on a Solace broker usually implies it is trapped in a Queue with a high "Maximum Redelivery" count or it's sitting in a Dead Letter Queue (DLQ) that is being re-polled.

Since you have the topic string US/COMET/INC/ORDER/CASH/COES/SLSI, you need to identify which Queue is subscribed to that topic and then purge the specific message.

Here is the step-by-step guide to deleting it using the Solace PubSub+ Manager (GUI).

1. Identify the Queue

In Solace, messages aren't usually "deleted" from a topic; they are deleted from the Queues that attract those topics.

Log into your Solace PubSub+ Manager.
Go to Queues in the left-hand sidebar.
Look for a queue that has a Subscription matching your topic: US/COMET/INC/ORDER/CASH/COES/SLSI.
- Tip: If you aren't sure which queue it is, look for the one with a non-zero "Messages Queued" count or "Redelivered" stats.

2. Browse the Messages

Once you find the likely queue:

Click on the Queue Name.
Click the Messages tab at the top.
Click Query Messages (this will show you a list of messages currently sitting in that queue).
Look for the message containing "LEONID CITI DEMO". You can usually see a preview of the payload.

3. Delete the Specific Message

If you find the specific annoying message:

Select the checkbox next to that specific message.
Click Delete (usually a trash can icon or a button at the top of the list).
Confirm the deletion.

Alternative: Selective Purge via "Selector"

If the queue has thousands of messages and you can't find it manually, you can use a Queue Purge with a Selector. Note: Be very careful here not to purge the whole queue.

If your Solace version supports it in the UI:

Go to the Queue > Messages.
Use the Filter/Search box.
Enter a string like text LIKE '%LEONID CITI DEMO%'.
Once filtered, delete only those results.

If you are using CLI (SolAdmin / SEMP)

If you prefer the command line, you can use the following logic (replace <queue-name> with your actual queue name):

# To clear the ENTIRE queue (Nuclear option - only if all Sept 2025 msgs are junk)
admin
  message-spool message-vpn <your-vpn-name>
    delete-messages queue <queue-name>

Why does it keep "surfacing"?

If the message reappears after you delete it, one of two things is happening:

Redelivery Loop: An application is consuming it, failing to acknowledge (ACK) it because the data is "bad," and Solace is putting it back on the queue.
External Re-publisher: Some automated test script or "replay" tool in your UKPROD environment might be re-sending this "CITI DEMO" message periodically. If you delete it and it comes back with a new timestamp, you need to find the Producer (the app sending it) and stop it there.

Warning: If those "Sept 2025" messages are valid business orders, do not use the "Purge Queue" button, as that will wipe out all messages. Only delete the specific Message ID associated with the "LEONID" text.