Skip to content

Conversation

@lachlan-roberts
Copy link

This is based on the work from #235.

Port the invoker to upgrade to Eclipse Jetty-12 version 12. Specifically using the new core APIs of Eclipse Jetty-12 that allow the overhead of a Servlet container to be avoided.

BREAKING CHANGE: use Java 17 or above, as required by Eclipse Jetty-12.

Replaces

Port the invoker to upgrade to Eclipse Jetty-12 version 12.  Specifically using the new core APIs of Eclipse Jetty-12 that allow the overhead of a Servlet container to be avoided.

BREAKING CHANGE: use Java 17 or above, as required by Eclipse Jetty-12.

Signed-off-by: Lachlan Roberts <[email protected]>
Port the invoker to upgrade to Eclipse Jetty-12 version 12.  Specifically using the new core APIs of Eclipse Jetty-12 that allow the overhead of a Servlet container to be avoided.

BREAKING CHANGE: use Java 17 or above, as required by Eclipse Jetty-12.

Signed-off-by: Lachlan Roberts <[email protected]>
@lachlan-roberts lachlan-roberts changed the title use Jetty-12.1 core without servlets chore(implementation): use Jetty-12 core without servlets Sep 30, 2025
@lachlan-roberts lachlan-roberts changed the title chore(implementation): use Jetty-12 core without servlets chore(implementation): use Jetty-12.1 core without servlets Sep 30, 2025
@ludoch
Copy link
Collaborator

ludoch commented Oct 3, 2025

Thanks!
We need to remove jdk11 constraints in builds. I guess only a Googler can understand and change the kokoro files to jdk17

Also all references with maven.compiler.source>11</maven.compiler.source> need to change to 17

@ludoch ludoch requested a review from akerekes October 3, 2025 18:02
@ludoch
Copy link
Collaborator

ludoch commented Oct 3, 2025

@akerekes please help on google internal kokoro workflows.
The entire new code now has to only work with java17,21 and 25, so drop 11 and add new configs.

@ludoch ludoch self-requested a review October 3, 2025 18:04
@akerekes
Copy link
Contributor

akerekes commented Oct 3, 2025

Hi @lachlan-roberts , thank you for the PR! I'll work on the Google internal side. One note on the timeline is that Cloud Function deprecates java11 at the end of the month: https://cloud.google.com/functions/docs/runtime-support#java so my preference is to have this PR ready to merge, but wait until the end of the month with the merge, then do it in early November and release a new version of the FF-java library.

Copy link
Contributor

@akerekes akerekes left a comment

Choose a reason for hiding this comment

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

Thank you @lachlan-roberts for the PR! I did the first round of review.

Please rebase the PR to HEAD one more time, I'm not planning to merge any other PRs until this one is done to avoid further rebasing and merge conflicts.

res.setStatus(HttpServletResponse.SC_INTERNAL_SERVER_ERROR);
logger.log(Level.SEVERE, "Failed to execute " + functionExecutor.functionName(), t);
res.setStatus(HttpStatus.INTERNAL_SERVER_ERROR_500);
callback.succeeded();
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this be callback.failed()?

Copy link
Author

Choose a reason for hiding this comment

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

I think it is best to use Response.writeError here. Which will complete the callback itself.

Fixed.

public boolean handle(Request request, Response response, Callback callback) {
try {
testReference.get().test(new HttpRequestImpl(req));
if (!HttpMethod.POST.is(request.getMethod())) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you add a comment to mention that this restriction is just the result of the migration from servlets and if a test case required this handler could be extended to accept GET requests.

Copy link
Author

Choose a reason for hiding this comment

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

This was just a straight adaption of the servlet because it only overrided doPost(), but none of the tests are trying other HTTP methods and expecting a 405.

So I think its best I just remove this block of code.

Port the invoker to upgrade to Eclipse Jetty-12 version 12.  Specifically using the new core APIs of Eclipse Jetty-12 that allow the overhead of a Servlet container to be avoided.

BREAKING CHANGE: use Java 17 or above, as required by Eclipse Jetty-12.

Signed-off-by: Lachlan Roberts <[email protected]>
} finally {
executionIdUtil.removeExecutionId();
}
return true;
Copy link
Member

Choose a reason for hiding this comment

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

Can you add a comment here or at the top of the method explaining the return value? It seems confusing to me at face value

FunctionExecutor<CloudEventT> executor = (FunctionExecutor<CloudEventT>) functionExecutor;
byte[] body = req.getInputStream().readAllBytes();

byte[] body = Content.Source.asByteArrayAsync(req, -1).get();
Copy link
Member

Choose a reason for hiding this comment

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

Can you explain this array manipulation in a comment? why the '-1'?

new TimerTask() {
@Override
public void run() {
// TODO: there is a race between the handler writing response and timeout firing.
Copy link
Member

Choose a reason for hiding this comment

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

Can you add the action item to this TODO? what needs to be done to address this race condition?

@akerekes
Copy link
Contributor

@lachlan-roberts Thank you for the follow-up. Can you reformat the code to make the linter check pass?

The PR looks good to me, I'm waiting on @maemayve 's comments to be resolved and happy to approve it then.

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