Skip to content

Conversation

@rombert
Copy link

@rombert rombert commented Sep 14, 2023

The new Apache Sling instrumentation ensures that top-level routes reflect the Sling Servlet (or script) handling the script and also that nested spans created by including components point to the right handler.

I've done extensive testing locally but since this is my first contribution there might be some rough edges. I'll add some screenshots to clarify what this looks like in practice.

Rendering with nested components

image

Rendering with top-level servlet

image

@rombert rombert requested a review from a team September 14, 2023 14:42
@laurit
Copy link
Contributor

laurit commented Sep 15, 2023

@rombert could you also add tests for your instrumentation

@rombert
Copy link
Author

rombert commented Sep 15, 2023

@laurit , sure I'll look into that. I will probably go for container-based tests as it's not trival to set up a Sling instance with the full Engine and it will also make testing against various versions easier. I was looking at https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation/cassandra/cassandra-4.4/library/src/test/java/io/opentelemetry/instrumentation/cassandra/v4_4/CassandraTest.java ( and https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation/cassandra/cassandra-4.4/testing/src/main/java/io/opentelemetry/testing/cassandra/v4_4/AbstractCassandra44Test.java / https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/instrumentation/cassandra/cassandra-4-common/testing/src/main/java/io/opentelemetry/cassandra/v4/common/AbstractCassandraTest.java ). Are those good examples of doing such tests?

What is not clear to me is how the agent is injected in the container running the system under test, do you have an idea about that?

@laurit
Copy link
Contributor

laurit commented Sep 15, 2023

@rombert with cassandra there is no need to inject the agent into the image as we are testing cassandra client not the server.
Tests that inject agent into an image are in https://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/smoke-tests Tests that accompany the instrumentation automatically run with the agent, currently all of them use the tested framework inside the test. Consider if it is possible to start an embedded version of the sling inside the test, if it needs other services then perhaps these can be run in container with testcontainers. If this is not suitable for you then it will be a bit tricky as it would deviate from what all other tests do.

Copy link
Contributor

@breedx-splk breedx-splk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implementation looks good to me. I agree with @laurit tho and would like to see tests.

name = servlet.getServletConfig().getServletName();
}
if (name == null || name.isEmpty()) {
name = servlet.getServletInfo();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could see this as potentially surprising if it shows up as the "name", but I think it's fine. Hopefully more informative than just the class name when the name is missing from the config.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could've sworn that I found this pattern in the repository, but I can't find it anymore.

@rombert
Copy link
Author

rombert commented Feb 6, 2024

Thanks for the reviews @laurit and @breedx-splk . This is still on my to-do list but I did not manage to get back to it. Hopefully soon :-)

@jaydeluca
Copy link
Member

@rombert are you still working on this?

@rombert
Copy link
Author

rombert commented Feb 4, 2025

@jaydeluca - it's on my list, yes, but it gets pushed back by other priorities. I don't have a timeline for resuming work on it.

@rombert rombert requested a review from a team as a code owner February 5, 2025 14:44
@rombert
Copy link
Author

rombert commented Feb 5, 2025

I just rebased to the latest main branch. Still plan to look into adding tests.

rombert and others added 3 commits July 2, 2025 13:47
Add a new http-based test for Apache Sling based on the latest released Sling Started demo
application.

This commit shows how testing should work but it has a number of issues:
- ignores advice failures
- ignores muzzle failures
- does not clean up the existing Sling instance
- the code that starts up the Sling instance is fragile
@otelbot-java-instrumentation
Copy link
Contributor

🔧 The result from spotlessApply was committed to the PR branch.

@rombert
Copy link
Author

rombert commented Jul 2, 2025

@breedx-splk @jaydeluca @laurit - I implemented an initial test, it has lots of hiccups though. Would be great to have some feedback before diving deeper:

On my side, the code to startup Sling needs to be improved and the code to shutdown needed to be added :-) We don't really have an 'embedding' use case so the APIs are lacking for now.

Thanks!

@rombert
Copy link
Author

rombert commented Jul 2, 2025

Oh, and a follow-up question: our next release will be based on Jakarta Servlet instead so the instrumentation will no longer work with it. Should I already move the current instrumentation to a different folder in preparation for two co-existing instrumentations ?

I expect the logic to be the same and the tests identical but the APIs will be different so I don't see this working easily inside a single project.

I would call the folder instrumentation/sling/sling-javax/javaagent and a potential future contribution would be instrumentation/sling/sling-jakarta/javaagent. I chose names instead of versions because we don't really have 'product' releases in Sling, we produce a framework that downstream applications package. We can also based this off the Sling API library which triggered this chanage so we can have sling-api-2.0 (javax.servlet) and sling-api-3.0 (jakarta.servlet).

@laurit
Copy link
Contributor

laurit commented Aug 27, 2025

I implemented an initial test, it has lots of hiccups though. Would be great to have some feedback before diving deeper

It is hard to say anything because the tests don't really work as they are. I think the problem is that the DefaultArtifactHandler finds jars only from the local maven repository. Which in my case, and also in the ci, does not contain the required jars. If I could run the test then I could try figuring out what causes the advice and muzzle failures.

Oh, and a follow-up question: our next release will be based on Jakarta Servlet instead so the instrumentation will no longer work with it. Should I already move the current instrumentation to a different folder in preparation for two co-existing instrumentations ?

I think that currently this isn't too important as I'd expect it to be not too hard to get it working with jakarta when you have it already working with javax. You can start with implementing it for javax or jakarta whichever is more comfortable for you and add the other later.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants