[operator] consider extending the visibility of fields in base implementations

[kittaakos]

Is your feature request related to a problem? Please describe.

Please extend the visibility of the fields in the default implementations. Thank you

From the docs:

theia-cloud/documentation/Architecture.md

Lines 10 to 12 in 55813e2

	We provide a library (`org.eclipse.theia.cloud.operator`), as well as a default implementation (`org.eclipse.theia.cloud.defaultoperator`) for the operator.
	The library can be used to create an operator customized to your use cases.
	The default implementation is a production-ready operator that handles most use cases on most cloud providers out of the box and is used in our demos.

There is a nice way to customize the Guice module, but all fields are private, making it inconvenient to customize in a downstream project:

theia-cloud/java/operator/org.eclipse.theia.cloud.operator/src/main/java/org/eclipse/theia/cloud/operator/BasicTheiaCloudOperator.java

Lines 60 to 81 in 55813e2

	@Inject
	private TheiaCloudClient resourceClient;
	@Inject
	protected Set<OperatorPlugin> operatorPlugins;
	@Inject
	private AppDefinitionHandler appDefinitionAddedHandler;
	@Inject
	private WorkspaceHandler workspaceHandler;
	@Inject
	private SessionHandler sessionHandler;
	@Inject
	private TheiaCloudOperatorArguments arguments;
	private final Map<String, AppDefinition> appDefinitionCache = new ConcurrentHashMap<>();
	private final Map<String, Workspace> workspaceCache = new ConcurrentHashMap<>();
	private final Map<String, Session> sessionCache = new ConcurrentHashMap<>();
	private final Set<SpecWatch<?>> watches = new LinkedHashSet<>();

Describe the solution you'd like

Fields are protected, making it easier to customize the default implementation.

Describe alternatives you've considered

Use Java reflection for the framework customization

Cluster provider

No response

Additional information

No response

[jfaltermeier]

Thanks for the report, the request makes sense. We try to open things up as we identify the use cases.
We are also happy to accept contributions if you’d like to open a PR.

[kittaakos]

Thanks for taking care of the fixes and implementing the necessary changes.

We are also happy to accept contributions if you’d like to open a PR.

I'm happy to push back my changes — I'll check internally about our contribution policy first.

While customizing the operator and Theia contributions, I ran into a few areas where I think the framework could be improved. Just sharing a few here for visibility (feel free to spin them off into separate issues, or I can do that later when you have closed this issue):

• Operator test setup: The operator currently lacks tests. It can be confusing for newcomers to navigate the hybrid use of Guice and Jakarta DI across the Java projects. It’s also unclear what the preferred approach is for testing with proper injection.
• Message extensibility: Customizing messages between operator, backend, and frontend is tricky. Since many APIs and classes are not POJOs or JSON-like, extending behavior (e.g. modifying string-based parameters) often means copying entire implementations.
• Theia activity tracker API: The common Theia backend/frontend protocol exposes an express Router, which might not be the cleanest abstraction. It could benefit from a more structured API.
• Monitor request robustness: When the operator sends a monitor request and the response fails (e.g. non-2xx), the failure is silently swallowed. This makes it difficult to trust the operator for critical lifecycle flows.
• startServer should resolve with a Promise:
  

  theia-cloud/node/monitor/src/extension.ts

  Line 24 in 55813e2

  export function startServer(port: number): void {

• Use express from shared Theia:
  

  theia-cloud/node/monitor/src/modules/messaging-module.ts

  Line 1 in 55813e2

  import { json, Router } from 'express';

Related issues:

• [monitor, theia] ActivityTrackerFrontendContribution is not bound to self, therefore not customizable #427
• [monitor, theia] Consider not pulling in the @theia/plugin-ext dependency for the modal dialog #428
• [operator, monitor] Correctly close response when posting to the sessions' backend #430

[kittaakos]

We are also happy to accept contributions if you’d like to open a PR.

I'm happy to push back my changes — I'll check internally about our contribution policy first.

It's OK.

@jfaltermeier, would you be open to reviewing the proposals and, if they look good, helping to get them into a new release?

[jfaltermeier]

Sure, happy to review the PRs. Just @ me once they are opened.

[github-actions]

This issue is stale because it has been open for 180 days with no activity.