[ActiveMQ] Align Package With 6.2.x Testing And Versioned Pipeline Fixtures

[giorgi-imerlishvili-elastic]

Proposed commit message

This PR updates the Apache ActiveMQ Classic integration so deploy assets and documentation match 6.2.x (Java 17, Jetty 11 / Jolokia 2.x) while keeping a 5.17.1 service variant for regression.

Docker / elastic-package deploy: Java 17 base image, default broker 6.2.2, paths under /opt/activemq, and an entrypoint that picks the matching jetty / jolokia-access templates for 5.x vs 6.x before starting the broker.
Variants: v6.2.2 (default) and v5.17.1 in _dev/deploy/variants.yml.
Docs: _dev/build/docs/README.md — supported/tested versions, JVM requirements, and Jolokia collection notes.
Pipeline tests: split log samples into test-activemq-5-15 and test-activemq-6-2, and audit into test-audit-5-17 and test-audit-6-2, so legacy and 6.2-style lines are exercised separately.

Checklist

• I have reviewed tips for building integrations and this pull request is aligned with them.
• I have verified that all data streams collect metrics or logs.
• I have added an entry to my package's changelog.yml file.
• I have verified that Kibana version constraints are current according to guidelines.
• I have verified that any added dashboard complies with Kibana's Dashboard good practices

Author's Checklist

• [ ]

How to test this PR locally

Related issues

• Closes https://github.com/elastic/obs-integration-team/issues/987

Screenshots

[github-actions]

Vale Linting Results

Summary: 2 suggestions found

💡 Suggestions (2)

File	Line	Rule	Message
packages/activemq/_dev/build/docs/README.md	33	Elastic.Versions	Use 'or later' instead of 'or newer' when referring to versions.
packages/activemq/docs/README.md	33	Elastic.Versions	Use 'or later' instead of 'or newer' when referring to versions.

---

The Vale linter checks documentation changes against the Elastic Docs style guide.

To use Vale locally or report issues, refer to Elastic style guide for Vale.

[elastic-vault-github-plugin-prod]

🚀 Benchmarks report

To see the full report comment with /test benchmark fullreport

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 3f1aa60

cc @giorgi-imerlishvili-elastic

[muthu-mps]

The system tests notes can be added to the test script. Add mentions about the tested and supported version here.

Suggested change

	This integration targets **Apache ActiveMQ Classic**. Elastic package system tests can run against **ActiveMQ Classic 6.2.2** (default) or **5.17.1** (see `_dev/deploy/variants.yml`). Use a **Java 17 or newer** JVM in the test image; ActiveMQ Classic 6.2.x requires Java 17+ on the broker, and 5.17.x runs on Java 17 for these tests.
	This integration targets **Apache ActiveMQ Classic**. ActiveMQ Classic 6.2.x requires Java 17+ on the broker, and 5.17.x runs on Java 17 for these tests.

[Copilot]

Pull request overview

Updates the ActiveMQ integration’s dev deployment assets, docs, and pipeline fixtures to align system testing with Apache ActiveMQ Classic 6.2.2 (Java 17, Jetty 11 / Jolokia 2.x) while keeping a 5.17.1 variant for regression.

Changes:

• Bump package version to 1.10.0 and add changelog entry describing 6.2.x alignment.
• Switch _dev deploy default variant to 6.2.2, update Docker image to Java 17, and add version-specific Jetty/Jolokia templates selected by entrypoint.
• Split/introduce pipeline test fixtures for 5.15-era logs vs 6.2-style logs, and for 5.17 vs 6.2 audit formats.

Reviewed changes

Copilot reviewed 12 out of 20 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
packages/activemq/manifest.yml	Version bump to 1.10.0.
packages/activemq/changelog.yml	Add 1.10.0 enhancement entry for 6.2.x alignment.
packages/activemq/docs/README.md	Update compatibility/docs for 6.2.2 + Java 17 and Jolokia path notes.
packages/activemq/_dev/build/docs/README.md	Mirror docs updates for build docs.
packages/activemq/_dev/deploy/variants.yml	Add v6.2.2 variant and set as default.
packages/activemq/_dev/deploy/docker/Dockerfile	Move base image to Java 17 and default service version to 6.2.2; run entrypoint as CMD.
packages/activemq/_dev/deploy/docker/docker-compose.yml	Mount versioned Jetty/Jolokia templates; update logs mount to /opt/activemq/logs.
packages/activemq/_dev/deploy/docker/entrypoint.d/entrypoint.sh	Select appropriate Jetty/Jolokia templates based on major version; normalize logs handling.
packages/activemq/_dev/deploy/docker/files/jetty-5.17.xml	Add Jetty override for 5.17.x line.
packages/activemq/_dev/deploy/docker/files/jetty-6.2.xml	Add Jetty override for 6.2.x line.
packages/activemq/_dev/deploy/docker/files/jolokia-5.17.xml	Add Jolokia access policy for 5.17.x line.
packages/activemq/_dev/deploy/docker/files/jolokia-6.2.xml	Add Jolokia access policy for 6.2.x line.
packages/activemq/data_stream/log/_dev/test/pipeline/test-activemq-5-15.log	New log fixture for 5.15-style lines (incl. stack traces).
packages/activemq/data_stream/log/_dev/test/pipeline/test-activemq-5-15.log-expected.json	Expected parsed output for 5.15 log fixture.
packages/activemq/data_stream/log/_dev/test/pipeline/test-activemq-6-2.log	New log fixture for 6.2-style lines.
packages/activemq/data_stream/log/_dev/test/pipeline/test-activemq-6-2.log-expected.json	Expected parsed output for 6.2 log fixture.
packages/activemq/data_stream/audit/_dev/test/pipeline/test-audit-5-17.log	New audit fixture for 5.17-style audit lines.
packages/activemq/data_stream/audit/_dev/test/pipeline/test-audit-5-17.log-expected.json	Expected parsed output for 5.17 audit fixture.
packages/activemq/data_stream/audit/_dev/test/pipeline/test-audit-6-2.log	New audit fixture for 6.2-style audit lines.
packages/activemq/data_stream/audit/_dev/test/pipeline/test-audit-6-2.log-expected.json	Expected parsed output for 6.2 audit fixture.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

<allow-origin>*</allow-origin> makes the Jolokia endpoint permissive to any Origin. Even for system tests, it’s safer to avoid the wildcard and allow only the origins you need (localhost/127.0.0.1) or explicitly document that this file must only be used in local/CI test environments and never in production-like deployments.

Suggested change

	without browser Origin headers during integration tests.
	-->
	<restrict>
	<cors>
	<allow-origin>http://localhost:*</allow-origin>
	<allow-origin>http://127.0.0.1:*</allow-origin>
	<allow-origin>*</allow-origin>
	without browser Origin headers during integration tests. This file is for
	local/CI test environments only and restricts browser origins to localhost
	and 127.0.0.1 instead of allowing arbitrary origins.
	-->
	<restrict>
	<cors>
	<allow-origin>http://localhost:*</allow-origin>
	<allow-origin>http://127.0.0.1:*</allow-origin>

[Copilot]

These HeaderPatternRule beans are all declared with the same bean id ("header"). In Spring XML, bean ids are expected to be unique; duplicates can either fail parsing or silently override earlier definitions depending on the bean factory settings. Drop the id attributes (since they are not referenced) or make them unique to avoid unpredictable behavior.

Suggested change

	<bean id="header" class="org.eclipse.jetty.rewrite.handler.HeaderPatternRule">
	<property name="pattern" value="*"/>
	<property name="name" value="X-FRAME-OPTIONS"/>
	<property name="value" value="SAMEORIGIN"/>
	</bean>
	<bean id="header" class="org.eclipse.jetty.rewrite.handler.HeaderPatternRule">
	<property name="pattern" value="*"/>
	<property name="name" value="X-XSS-Protection"/>
	<property name="value" value="1; mode=block"/>
	</bean>
	<bean id="header" class="org.eclipse.jetty.rewrite.handler.HeaderPatternRule">
	<property name="pattern" value="*"/>
	<property name="name" value="X-Content-Type-Options"/>
	<property name="value" value="nosniff"/>
	</bean>
	<bean id="header" class="org.eclipse.jetty.rewrite.handler.HeaderPatternRule">
	<property name="pattern" value="*"/>
	<property name="name" value="Cache-Control"/>
	<property name="value" value="no-store"/>
	</bean>
	<bean id="header" class="org.eclipse.jetty.rewrite.handler.HeaderPatternRule">
	<property name="pattern" value="*"/>
	<property name="name" value="Content-Security-Policy"/>
	<property name="value" value="style-src-elem 'self'; style-src 'self'; img-src 'self'; script-src-elem 'self'; default-src 'none'; object-src 'none'; frame-ancestors 'none'; base-uri 'none';" />
	</bean>
	<!-- More relaxed rules to allow browsers to properly render XML -->
	<bean id="header" class="org.eclipse.jetty.rewrite.handler.HeaderPatternRule">
	<bean class="org.eclipse.jetty.rewrite.handler.HeaderPatternRule">
	<property name="pattern" value="*"/>
	<property name="name" value="X-FRAME-OPTIONS"/>
	<property name="value" value="SAMEORIGIN"/>
	</bean>
	<bean class="org.eclipse.jetty.rewrite.handler.HeaderPatternRule">
	<property name="pattern" value="*"/>
	<property name="name" value="X-XSS-Protection"/>
	<property name="value" value="1; mode=block"/>
	</bean>
	<bean class="org.eclipse.jetty.rewrite.handler.HeaderPatternRule">
	<property name="pattern" value="*"/>
	<property name="name" value="X-Content-Type-Options"/>
	<property name="value" value="nosniff"/>
	</bean>
	<bean class="org.eclipse.jetty.rewrite.handler.HeaderPatternRule">
	<property name="pattern" value="*"/>
	<property name="name" value="Cache-Control"/>
	<property name="value" value="no-store"/>
	</bean>
	<bean class="org.eclipse.jetty.rewrite.handler.HeaderPatternRule">
	<property name="pattern" value="*"/>
	<property name="name" value="Content-Security-Policy"/>
	<property name="value" value="style-src-elem 'self'; style-src 'self'; img-src 'self'; script-src-elem 'self'; default-src 'none'; object-src 'none'; frame-ancestors 'none'; base-uri 'none';" />
	</bean>
	<!-- More relaxed rules to allow browsers to properly render XML -->
	<bean class="org.eclipse.jetty.rewrite.handler.HeaderPatternRule">