flyingImer commented on code in PR #4061: URL: https://github.com/apache/polaris/pull/4061#discussion_r3002649522
########## runtime/service/src/main/java/org/apache/polaris/service/task/RealmContextPropagator.java: ########## @@ -0,0 +1,82 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ +package org.apache.polaris.service.task; + +import jakarta.annotation.Nullable; +import jakarta.enterprise.context.ApplicationScoped; +import jakarta.enterprise.context.ContextNotActiveException; +import jakarta.inject.Inject; +import org.apache.polaris.core.context.RealmContext; +import org.apache.polaris.service.context.catalog.RealmContextHolder; +import org.slf4j.Logger; +import org.slf4j.LoggerFactory; + +/** + * Propagates the realm context across the async task boundary via {@link RealmContextHolder}. + * + * <p>The full {@link RealmContext} object is captured — not just the realm identifier string — so + * that vendor-specific {@code RealmContext} implementations (which may carry additional routing + * information) survive the async boundary intact. + * + * <p>At capture time {@link RealmContextHolder} is request-scoped; its CDI proxy resolves to the + * holder in the currently active request scope. On a normal HTTP request thread that scope holds the + * realm set by the request filter. When an async task handler schedules a follow-up task (no active + * JAX-RS request), {@code RealmContextHolder} in that task's scope already contains the realm + * restored by this propagator's {@link #restore} path, so capture continues to work correctly for + * nested task submission. + */ +@ApplicationScoped +public class RealmContextPropagator implements AsyncContextPropagator { + + private static final Logger LOGGER = LoggerFactory.getLogger(RealmContextPropagator.class); + + private final RealmContextHolder realmContextHolder; + + @SuppressWarnings("unused") // Required by CDI + protected RealmContextPropagator() { + this(null); + } + + @Inject + public RealmContextPropagator(RealmContextHolder realmContextHolder) { + this.realmContextHolder = realmContextHolder; + } + + @Nullable + @Override + public Object capture() { Review Comment: @dimas-b Fair point. I plan to do the State pattern refactor as an immediate follow-up PR. My rationale is that the interface lives in `runtime/service` with no downstream consumers, so evolving it across two PRs has zero migration cost. This one stays focused on the propagation mechanism + CDI discovery; the follow-up is a pure shape refactor (`capture() → Object` becomes `capture() → RestoreAction`) with no behavioral change. I'll open it right after this lands. But if you'd rather bundle it here, I can do that too. Just want to keep the review surface manageable. WDYT? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
