Class InlineBytes

java.lang.Object
org.apache.tika.pipes.core.fetcher.InlineBytes
All Implemented Interfaces:
Serializable

public class InlineBytes extends Object implements Serializable
Document bytes carried in the ParseContext instead of fetched from a source, for callers that already hold the content and would otherwise have to spool it to disk just to hand it to the forked worker.

Read by BytesFetcher, which the tuple selects with fetcher id BytesFetcher.FETCHER_ID. In-process only: deliberately not a registered component, so no serialized form of it exists and serialization refuses loudly. On the IPC wire the payload travels beside the tuple in PipesRequest (which lifts it out on the parent and plants it back into the worker's context on the child); it counts against maxIpcPayloadBytes like any other part of the request. A request can supply it in no form at all.

See Also:
  • Constructor Details

    • InlineBytes

      public InlineBytes()
    • InlineBytes

      public InlineBytes(byte[] bytes)
  • Method Details

    • getBytes

      public byte[] getBytes()
    • setBytes

      public void setBytes(byte[] bytes)
    • length

      public int length()
    • equals

      public boolean equals(Object o)
      Value equality on the payload. Objects.equals would compare array identity here, which would silently make two tuples carrying identical content unequal.
      Overrides:
      equals in class Object
    • hashCode

      public int hashCode()
      Length only. FetchEmitTuple.hashCode() hashes its ParseContext, so hashing the payload itself would walk megabytes on every map insert; unequal-hash-implies-unequal still holds, and collisions fall through to equals(java.lang.Object).
      Overrides:
      hashCode in class Object
    • toString

      public String toString()
      Length only -- FetchEmitTuple.toString() prints its ParseContext, and a debug log of a multi-megabyte payload is a real operational hazard.
      Overrides:
      toString in class Object