Serious tRESTRequest bug

One Star

Serious tRESTRequest bug

I have found a serious bug that afflicts tRESTRequest (and possibly other components) when a job is exported as an OSGI bundle to the Talend runtime. I am running TOS for ESB 5.3. I have created a JIRA issue, https://jira.talendforge.org/browse/TESB-10014, that demonstrates the problem using a slightly modified version of the DemoREST job (included as part of the ESB_DEMOS project that comes with TOS ESB). The only thing I added to the sample is the trivial code in tJava_1.
The essence of the problem is simply stated: For the ?REST endpoint? field (and possibly other tRESTRequest fields), Talend does not evaluate the field. This means that you can?t use context variables, the global map, or any Java code in this field! This is a very serious problem for systems (such as ours) in which configuration (such as endpoints) is controlled by external config files.
In more technical terms, the problem is easily understood by viewing the generated code. The class Thread4RestServiceProviderEndpoint, which is generated by Talend, has the following
...
private final String defaultEndpointUrl = "http://127.0.0.1:8090/";
private String endpointUrl = context.REST_ENDPOINT;
...
When run in studio (or exported as an autonomous job), context.REST_ENDPOINT is evaluated but, when exported to the runtime, it is not. This is easy to see by browsing to http://localhost:8040/services/. The endpoint is listed as context.REST_ENDPOINT.
Hopefully, this is an issue that can be solved quickly.
One Star

Re: Serious tRESTRequest bug

I am too facing same issue in Talend 6.1. Any updates on this?
One Star

Re: Serious tRESTRequest bug

EndpointURL value used in generated Blueptint after export as OSGi bundle; but context variables initialized later when job is going to start. Therefore no additional work for  EndpointURL as context variable; its by design.