ramu11 commented on PR #25551:
URL: https://github.com/apache/camel/pull/25551#issuecomment-5339831605
1. Default HostAccess / Java interoperability
- camel-python3 uses a restricted GraalVM HostAccess configuration by
default.
- Python can access body, headers, properties, and exchangeId.
- exchange, message, and context are not exposed by default.
- Consequently, Java APIs such as exchange.getExchangeId() are not
available by default.
- This differs from camel-python, where Java interoperability is
inherently available through Jython.
Question: Is this restricted default HostAccess model appropriate for the
new camel-python3 component?
2. Trusted Java access
- Python3Language.createWithHostAccess() provides an explicit opt-in
using HostAccess.ALL.
- This mode exposes exchange, message, and context, allowing access to
their public Java APIs.
- HostAccess.ALL does not enable allowAllAccess(true), Java class lookup,
filesystem I/O, or process creation.
Question: Is createWithHostAccess() the preferred API for users requiring
Java/Camel object access, or would maintainers prefer a different approach?
3. Compatibility with camel-python
- camel-python3 is a new language component and does not replace
camel-python.
- The implementation therefore intentionally does not reproduce Jython's
unrestricted Java interoperability by default.
- Instead, it follows a more restrictive GraalVM-oriented model.
Question: Should camel-python3 prioritize behavioral compatibility with
camel-python for Java object access, or is a safer GraalVM-specific default
preferable?
4. Security model and terminology
- The default configuration is restricted, but it is not a GraalVM
SandboxPolicy.
- Similarly, HostAccess.ALL should not be considered a sandbox.
- SandboxPolicy.CONSTRAINED was investigated but is not currently enabled
because it introduces additional restrictions/requirements that are not
necessary for the intended Camel use case.
Question: Does this security model and terminology align with Camel's
expectations for scripting languages?
5. Live mutable Camel data
- headers is exposed as a live Java Map; for example:
python
headers['foo'] = 'bar'
directly modifies the Exchange.
- Java List bodies are also exposed as mutable foreign lists.
- properties is currently exposed as a snapshot.
Question: Is exposing mutable headers/body collections through the
restricted HostAccess model acceptable, or should these bindings be
read-only/copies?
6. Default bindings
The proposed default data model is:
body, headers, properties, exchangeId
while:
exchange, message, and context
are available only through the trusted configuration.
Question: Does this binding model make sense as the public camel-python3
API?
### Maintainer Feedback Requested
I would particularly appreciate maintainer feedback on the
HostAccess/default security model and its intentional difference from
camel-python.
The existing Jython component provides Java interoperability through the
Jython runtime, whereas camel-python3 uses GraalVM HostAccess to establish a
more restrictive default model.
Before finalizing the API and documentation, I would like to confirm whether
this is the preferred Camel approach, or whether camel-python3 should expose
Java/Camel objects by default for compatibility with camel-python.
--
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]
