Is there ever need to attach more than one body Encoder implementation to particular Codec annotation

[igorbeslic]

Hi all, one more tech question related to talend component runtime and api implementation. Take for example particular Encoder implementation that encodes body payload into intended format (x-www-form-urlencoded).

Q1) Why @Codec annotation attribute encoder expects array of encoders?

If may payload has type CustomType and I attach CustomeTypeToXWWFormURLEncoder what is purpose of array?

I see that RequestParser should resolve proper encoder for given content, but by reading the code I don't see the way for request parser to filter other than first Encoder given in encoder attribute.

Q2) What is purpose of @ContentType annotation?

I thought (as it is not documented) that Decoder or Encoder implementations should be annotated with it so the component-runtime knows out of the box which Encoder is applicable for particular body content type and payload or returned response body.

It would be nice to understand Talend API. If any of Talend sw engineers could give more insight into HttpClient and @Codec I would be really thankful.

Thank you very much!

[Anonymous]

Hi @igorbeslic,

Thanks for your question. Can I ask which application you are referring to? Is it the API Services or are you talking about a data integration component? It seems like you are talking about W3 standards and in regard to Content-Type, this will hopefully explain that question https://www.w3.org/Protocols/rfc1341/4_Content-Type.html.

If you can elaborate on what your question regards to (the Talend product), I may be able to offer some more help

Regards

Richard

[igorbeslic]

Hi @rhall I developed custom input component. I test that component in Talend Open Studio for ESB 7.2.1.

Component connects to Liferay portal REST services and reads data from particular end point.

For the purpose of OAuth2 authorization, my component needs to obtain oauth2 access_token to proceed further data exchange with Bearer token.

To achieve mentioned I had to implement my own Encoder implementation:

import com.liferay.talend.datastore.OAuthDataStore;
import com.liferay.talend.http.client.exception.EncoderException;

import org.talend.sdk.component.api.service.http.Encoder;

/**
 * @author Igor Beslic
 */
public class XWWWFormURLEncoder implements Encoder {

	@Override
	public byte[] encode(Object o) throws EncoderException {
		if (o instanceof OAuthDataStore) {
			return _encode((OAuthDataStore)o);
		}

		throw new EncoderException(
			"Unable to encode payload of type " + o.getClass());
	}
        private byte[] _encode(OAuthDataStore oAuthDataStore) {....}
}

and attach it to httpClient extension:

import com.liferay.talend.datastore.OAuthDataStore;
import com.liferay.talend.http.client.codec.XWWWFormURLEncoder;

import javax.json.JsonObject;

import org.talend.sdk.component.api.service.http.Codec;
import org.talend.sdk.component.api.service.http.Header;
import org.talend.sdk.component.api.service.http.HttpClient;
import org.talend.sdk.component.api.service.http.Path;
import org.talend.sdk.component.api.service.http.Request;
import org.talend.sdk.component.api.service.http.Response;

/**
 * @author Igor Beslic
 */
public interface LiferayHttpClient extends HttpClient {

	@Codec(encoder = XWWWFormURLEncoder.class)
	@Request(method = "POST", path = "/o/oauth2/token")
	public Response<JsonObject> getAccessToken(
		@Header("Content-Type") String contentType,
		OAuthDataStore oAuthDataStore);

	@Request
	public Response<JsonObject> getData(
		@Header("Authorization") String authorizationHeader,
		@Header("Accept") String acceptHeader, @Path("") String path);

}

From perspective of my getAccessToken method, only one Encoder will do the magic: XWWWFormUrlEncoder. I'm only curious if there is really use case that would require component developer to provide more than one Encoder implementation.

@rhall one additional question: I mentioned HttpClient interface, and I wonder is it possible to provide end point path to @Request annotated method in a flexible way (to avoid hardcoding endpoint in @Request annotation). I ask it, because Liferay portal has only core endpoints known during component development time. Many of endpoint depend on final portal implementation done by customer.

Please see my getData method... I added parameter annotated with @Path to show you what is my idea.

For now I provided workaround: I do not specify Path at all, but provide full REST endpoint URL to LiferayHttpClient.base() method.

Thank you very much for your assistance!

[Anonymous · Accepted solution]

Hi @igorbeslic,

Sorry about my previous post. I neglected to look at which board it was in. I was working from a basis of looking for posts which had not been answered, rather than looking through the boards. Also, thanks for your posts in the Component Development board. These will help others when they are facing the same issues as you.

First of all, in answer to multiple codecs I would offer the situation displayed in this documentation http://repo.apache.maven.org/maven2/org/talend/sdk/component/documentation/1.1.8/documentation-1.1.8.... If you search for HttpClient, there is an example of a POST service with an Encode and Decoder codec. One for the message entering and one for the response. 

With regard to the endpoint, I will first admit that this is not a speciality of mine. However I have understood that this is used in this context to identify the method being called. Having something dynamic here would defeat the purpose of that

Regards

Richard

[igorbeslic]

@rhall example at page 155 answers my second question.. So @Path annotated argument would replace param in path template in @Request annotation... OK. It gives enough flexibility