Serialized Form

  • Package org.chenile.base.exception

  • Package org.chenile.cache.interceptor

  • Package org.chenile.cache.model

  • Package org.chenile.core.context

    • Class org.chenile.core.context.ChenileExchange

      class ChenileExchange extends Object implements Serializable
      serialVersionUID:
      -8886041051244601433L

      • Serialized Fields

        • apiInvocation
          List<Object> apiInvocation
          An object internally used by ServiceInvoker to invoke the API.
        • body
          Object body
          The converted body of the incoming message. This will be set to the actual payload expected by the service. It may be a JSON string to begin with before the transformation framework converts it to the desired payload type
        • bodyType
          com.fasterxml.jackson.core.type.TypeReference<?> bodyType
          bodyType is populated by the Chenile Transformation framework. The bodyType might vary depending on the URL of the incoming request and also some headers. A body type selector is a special Command<ChenileExchange> that determines the body type depending on the context of the request. (like headers, URL , locale etc.) All incoming JSONs (and other type of strings) are converted into the body type specified here
        • chainContext
          ChainContext<ChenileExchange> chainContext
          Internal field for the purpose of continuing the interceptor chain. The interceptors can use this to pass control to the next in the line by calling the ChainContext.doContinue() method. Interceptors can also use the ChainContext.savePoint() to save the current point and using ChainContext.resumeFromSavedPoint(ChainContext.SavePoint) to continue the chain from the saved point. This is useful if the rest of the interceptor chain needs to be called multiple times as part of some retry logic.
        • exception
          ErrorNumException exception
          The exception thrown by the service or any of the interceptors
        • headers
          Map<String,Object> headers
          Incoming request headers. Some headers can be added as we navigate through the interception chain
        • httpResponseStatusCode
          int httpResponseStatusCode
          contains the http response status code
        • invokeMock
          boolean invokeMock
          This is useful if this request is determined to be a mock request. Hence a mock service may have to be invoked instead of the actual service. In case of HTTP a special header (x-chenile-mock) will be passed for mock requests.
        • locale
          Locale locale
          Calculated locale. This should be populated from the incoming request as per the headers passed to it.
        • localInvocation
          boolean localInvocation
        • logWriter
          LogWriter logWriter
        • method
          Method method
          This field just uses a cached method object for optimization purposes. This needs to be recalculated if the serviceReference is changed by an interceptor.
        • multiPartMap
          Map<String,MultipartFile> multiPartMap
          This is used to handle multipart messages from HTTP.
        • operationDefinition
          OperationDefinition operationDefinition
          This is a very important metadata to handle the request. It contains the definition of the Service and the Operation within it. All operations are performed using these data structures. For example this metadata will be used to determine the service that needs to be invoked and the method within the service. This metadata is also used to determine the interceptors that are applicable etc. ChenileServiceDefinition and OperationDefinition are expected to be set by the protocol specific end point. Example: in chenile-http the URL called will be mapped to the ChenileServiceDefinition and OperationDefinition.
        • originalSourceReference
          String originalSourceReference
          This (optional) field allows traceability to the original request. This is populated when the entry point is invoked in a batch mode from a file watcher or a reader from a queue or topic. In this situation, no response is emitted. Hence, we need to know how this request got created in the first place.
          Typical values can be:
        • file1:line1:ref ID -> to indicate that this message was constructed from the file in question etc.
        • mqtt:topic1:id -> to indicate that this messages was created by MQTT by reading the topic in question etc.