Is your feature request related to a problem? Please describe.
Since the August version of ACB, it is now possible to specify encryption properties as arguments for the Mule runtime. This works well when deploying applications (including domains), but these arguments are not passed to the internal tooling runtime.
This causes exceptions and it seems to cause issues in DataWeave analysis (like in Anypoint Studio, functions like ++ or Mule::p() are not resolved if the app isn't properly deployed by the internal runtime).
Example of exception from Mule DX logs:
2023-08-16 16:11:47 [datasense-job-0] ERROR org.mule.contribution.datasense.resolvers.DataSenseJob - datasense-log : Error while resolving data sense
org.mule.tooling.client.api.exception.ToolingException: Error while creating application model
org.mule.runtime.config.internal.dsl.model.config.PropertyNotFoundException: Couldn't find configuration property value for key ${mule.encryptionKey} from properties provider environment properties provider - within resolver Deployment properties trying to process key mule.encryptionKey - within resolver global-properties configuration attributes trying to process key mule.encryptionKey - within resolver environment properties provider trying to process key mule.encryptionKey
at org.mule.tooling.client.internal.DefaultApplicationModelFactory.createApplicationModel(DefaultApplicationModelFactory.java:71) ~[?:?]
at org.mule.tooling.client.internal.application.DefaultApplication.lambda$newToolingApplicationModelLazyValue$7(DefaultApplication.java:169) ~[?:?]
at org.mule.runtime.api.util.LazyValue.get(LazyValue.java:75) ~[?:?]
at org.mule.tooling.client.internal.application.AbstractArtifact.getApplicationModel(AbstractArtifact.java:232) ~[?:?]
at org.mule.tooling.client.internal.DefaultToolingArtifact.getAst(DefaultToolingArtifact.java:500) ~[?:?]
at org.mule.runtime.api.util.LazyValue.get(LazyValue.java:75) ~[?:?]
at org.mule.tooling.client.internal.DefaultComponentLocationService.lambda$new$1(DefaultComponentLocationService.java:34) ~[?:?]
at org.mule.runtime.api.util.LazyValue.get(LazyValue.java:75) ~[?:?]
at org.mule.tooling.client.internal.DefaultComponentLocationService.getComponentLocations(DefaultComponentLocationService.java:46) ~[?:?]
at org.mule.tooling.client.internal.DefaultComponentLocationService.invokeMethod(DefaultComponentLocationService.java:59) ~[?:?]
at jdk.internal.reflect.GeneratedMethodAccessor99.invoke(Unknown Source) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.mule.tooling.client.bootstrap.internal.reflection.Dispatcher$ToolingCallable.call(Dispatcher.java:243) ~[mule-dx-mule-dev-plugin-3.8.2-all.jar:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:829) [?:?]
août 16, 2023 4:11:47 PM org.mule.weave.lsp.services.DataWeaveToolingService $anonfun$triggerValidation$1
Describe what you are ultimately trying to do
In our environment, the environment (mule.env) and encryption key are passed as properties of the runtime, not for each app. I would expect a way to specify these so the internal tooling runtime does not fail to analyze our applications.
Describe how you think Anypoint Code Builder can help solve your problem or improve your work
I would expect a setting or a configuration field that would allow me to specify the arguments to pass to the internal tooling runtime.
Currently, we are forced to hardcode these props in our app / domain, which is insecure and we risk committing the encryption key.
The domain should also be manually copied in each instances of the tooling runtime as the published asset does not include the hardcoded properties.
Additional context
This issue is also present in Anypoint Studio. The work around is to create an env.xml file in our app that contains the global props needed. When using a domain, we have to hardcode them in the domain file and deploy this version in the tooling runtime manually.
What priority would you give to this feature request?
Is your feature request related to a problem? Please describe.
Since the August version of ACB, it is now possible to specify encryption properties as arguments for the Mule runtime. This works well when deploying applications (including domains), but these arguments are not passed to the internal tooling runtime.
This causes exceptions and it seems to cause issues in DataWeave analysis (like in Anypoint Studio, functions like
++orMule::p()are not resolved if the app isn't properly deployed by the internal runtime). Example of exception from Mule DX logs:Describe what you are ultimately trying to do
In our environment, the environment (mule.env) and encryption key are passed as properties of the runtime, not for each app. I would expect a way to specify these so the internal tooling runtime does not fail to analyze our applications.
Describe how you think Anypoint Code Builder can help solve your problem or improve your work
I would expect a setting or a configuration field that would allow me to specify the arguments to pass to the internal tooling runtime.
Currently, we are forced to hardcode these props in our app / domain, which is insecure and we risk committing the encryption key. The domain should also be manually copied in each instances of the tooling runtime as the published asset does not include the hardcoded properties.
Additional context
This issue is also present in Anypoint Studio. The work around is to create an env.xml file in our app that contains the global props needed. When using a domain, we have to hardcode them in the domain file and deploy this version in the tooling runtime manually.
What priority would you give to this feature request?