Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cleanup ee9 DefaultServletTest #11927

Merged
merged 1 commit into from
Jun 19, 2024

Conversation

joakime
Copy link
Contributor

@joakime joakime commented Jun 17, 2024

A cleanup of the test setup in the ee9 DefaultServletTest.

This includes re-enabling various disabled tests.

This is needed for testing alternate Base Resource configurations for the upcoming PR to address issue #11925 which will utilize this refactor of the DefaultServletTest.

defholder.setInitParameter("dirAllowed", "true");
defholder.setInitParameter("redirectWelcome", "false");
defholder.setInitParameter("gzip", "false");
Path docRoot = workDir.getEmptyPathDir().resolve("docroot");
Copy link
Contributor

Choose a reason for hiding this comment

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

These 2 lines seem to be repeated by every test, move into @BeforeEach?

Copy link
Contributor Author

@joakime joakime Jun 18, 2024

Choose a reason for hiding this comment

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

No, as this logic is not consistent across the test cases, only about 70% of them use the docroot.

Also, the new testcases coming after this PR is merged (see the comment at the top of this PR) from Issue #11925 will not use this docroot as well (that PR will use many alternate docroot concepts that have been shown to cause issues)


Path extraJarResources = MavenPaths.findTestResourceFile(ODD_JAR);
assertTrue(Files.exists(extraJarResources), "Unable to find " + ODD_JAR);
URL[] urls = new URL[]{extraJarResources.toUri().toURL()};
Copy link
Contributor

Choose a reason for hiding this comment

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

Why do we need the extra classloader? The test resource will already be on the current classpath won't it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This jar comes from src/test/resources/odd_jar.jar and isn't "live".
These test cases are specifically handling reported behaviors with odd/unusual jars.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Since a JAR can have entries that are difficult (and in some cases impossible) on real File System (unix, mac, and windows are all included in this statement), this test case ensures that we can support these kinds of files.

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't really understand your answer, as all things in src/test/resources are always on the test classpath, but if you want to create a special classloader for it, ok.

@@ -471,7 +529,7 @@ public static Stream<Arguments> contextBreakoutScenarios()
);

// A Raw Question mark in the prefix can be interpreted as a query section
if (prefix.contains("?"))
if (prefix.contains("?") || prefix.contains(";"))
Copy link
Contributor

Choose a reason for hiding this comment

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

The comment above now doesn't match the code - why are we now including semicolon?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The tests using this methodSource were disabled in ee9.

In ee10, this same testcase is enabled.
The changes in HttpURI make some paths interpret differently here.

In ee10, we have ...

// A Raw Question mark in the prefix can be interpreted as a query section
if (prefix.contains("?") || prefix.contains(";"))

Basically, paths like /context/dir;/../index.html are interpreted in Jetty 12 as /context/dir/../index.html
The change in the ee10 DefaultServletTest addresses this new reality of HttpURI, so that same change is now applied to the recently enabled tests in ee9 as well.

Copy link
Contributor

Choose a reason for hiding this comment

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

OK well maybe we should put a javadoc comment in there to that effect?

{
context.setBaseResource(ResourceFactory.of(context).newResource(docRoot));

ServletHolder defholder = context.addServlet(DefaultServlet.class, "/*");
Copy link
Contributor

Choose a reason for hiding this comment

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

I know it's this way in the original file, however the DefaultServlet is normally mapped at /, not /*

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Looking back historically, this seems intentional.
This servlet isn't declared with the "default" name either.
It seems to want to replicate a end user use-case.

Keep in mind that the new test cases coming after this PR is merged will introduce even more horrible DefaultServlet usages.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This (and subsequent tests with same quirk) are from the issue marked JETTY-980 from release jetty-7.0.0.M2.

It looks like the automatic adding of DefaultServlet to / if a servlet is not present on that url-pattern was one of the behaviors that triggered the original issue.
Because users would add another DefaultServlet to /* and that extra DefaultServlet on the /* pattern was causing issues with directory listings.

Copy link
Contributor

Choose a reason for hiding this comment

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

OK, maybe a javadoc comment then to ensure that in future we know this is intentional for the test.

{
context.setBaseResource(ResourceFactory.of(context).newResource(docRoot));

ServletHolder defholder = context.addServlet(DefaultServlet.class, "/*");
Copy link
Contributor

Choose a reason for hiding this comment

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

I know it's this way in the original file, however the DefaultServlet is normally mapped at /, not /*

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Same as above, this is intentional, and historical, to match end user use cases.

{
context.setBaseResource(ResourceFactory.of(context).newResource(docRoot));

ServletHolder defholder = context.addServlet(DefaultServlet.class, "/*");
Copy link
Contributor

Choose a reason for hiding this comment

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

I know it's this way in the original file, however the DefaultServlet is normally mapped at /, not /*

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Same as above, this is intentional, and historical, to match end user use cases.

{
context.setBaseResource(ResourceFactory.of(context).newResource(docRoot));

ServletHolder defholder = context.addServlet(DefaultServlet.class, "/*");
Copy link
Contributor

Choose a reason for hiding this comment

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

I know it's this way in the original file, however the DefaultServlet is normally mapped at /, not /*

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Same as above, this is intentional, and historical, to match end user use cases.

Copy link
Contributor

@janbartel janbartel left a comment

Choose a reason for hiding this comment

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

Does ee10 DefaultServlet need the same changes applied?

@joakime
Copy link
Contributor Author

joakime commented Jun 18, 2024

Does ee10 DefaultServlet need the same changes applied?

Possibly, but that can happen in a different PR, as the ee10 DefaultServletTest has some other differences.
I'm trying to avoid massive PRs to review.

@joakime joakime requested a review from janbartel June 18, 2024 12:59
janbartel
janbartel previously approved these changes Jun 19, 2024
Copy link
Contributor

@janbartel janbartel left a comment

Choose a reason for hiding this comment

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

OK, but see comments about javadocs.

{
context.setBaseResource(ResourceFactory.of(context).newResource(docRoot));

ServletHolder defholder = context.addServlet(DefaultServlet.class, "/*");
Copy link
Contributor

Choose a reason for hiding this comment

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

OK, maybe a javadoc comment then to ensure that in future we know this is intentional for the test.

+ Fix various warnings
+ Disable ODD_JAR / extraClassPath (temporarily)
+ Reenable disabled test Test
+ Reenable disabled test testListingContextBreakout
@joakime joakime force-pushed the fix/12.0.x/ee9-defaultservlettest-update branch from e036a44 to 4f72b84 Compare June 19, 2024 15:22
@joakime joakime merged commit 9db54aa into jetty-12.0.x Jun 19, 2024
10 checks passed
@joakime joakime deleted the fix/12.0.x/ee9-defaultservlettest-update branch June 19, 2024 16:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
No open projects
Status: ✅ Done
Development

Successfully merging this pull request may close these issues.

2 participants