rangareddy commented on issue #497:
URL:
https://github.com/apache/incubator-xtable/issues/497#issuecomment-5759426591
Opened #945 with an RFC and a runnable draft for this.
The UI proposal I attached above ends on a question that was never answered,
so the RFC settles it
and explains why. The February 2025 comments here agreed on Spring MVC, but
that was before
`xtable-service` existed; it landed in May 2025 on Quarkus with JAX-RS.
Serving the UI from
Spring now would add a second web framework, a second DI container and a
second server to the
build, to front endpoints that have to be added to the Quarkus service
anyway. RFC-4 therefore
serves the UI from `xtable-service`. If Spring is still preferred that is a
fair call, but worth
making deliberately.
Two things worth knowing without reading the whole PR:
**The async API this needs is already specified and never got built.**
`spec/rest-service-open-api.yaml` declares `Prefer: respond-async` returning
`202` with a
`conversion-id`, plus `GET /v1/conversion/table/{conversion-id}`. Nothing in
`xtable-service/src/main/java` implements either. The draft implements that
published contract
instead of inventing a separate `/jobs` API, so phase 1 is worth doing on
its own even without a
UI.
**`xtable-service` currently cannot run any conversion at all.** Calling the
released synchronous
endpoint on unmodified `main` returns HTTP 500:
```
java.util.ServiceConfigurationError:
org.apache.xtable.spi.sync.ConversionTarget:
org.apache.xtable.kernel.DeltaKernelConversionTarget Unable to get public
no-arg constructor
Caused by: java.lang.ClassNotFoundException: io.delta.kernel.engine.Engine
```
`DeltaKernelConversionTarget` needs `delta-kernel-defaults`, which
`xtable-service` does not
declare; `delta-core` and `delta-kernel-api` are declared at `test` scope.
Because `ServiceLoader`
instantiates every registered target eagerly, one bad provider aborts the
iteration and even an
Iceberg-only conversion fails. The integration test misses it because
test-scope artifacts are on
the classpath there. This affects the released 0.4.0 line too. There is a
one-commit fix in the PR,
kept separate so it can be split out and considered for backport.
@vinishjail97 @the-other-tim-brown the question I would most like a view on
is in the RFC's
Security section: the service ships with no authentication or authorization,
and a browser UI
makes exposing the port more likely. The draft serves the UI only when
`xtable.ui.enabled` is set,
defaulting to off. Is that enough for something documented as a local
developer utility, or should
the UI require authentication before it ships?
--
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]
