Class IpfFhirConfigurationProperties.StreamingUpload
- Enclosing class:
IpfFhirConfigurationProperties
Base64SplittingFilter. The split itself knows nothing about Spring or about this starter;
everything it needs is handed to it as StreamingUploadOptions.- See Also:
-
Field Summary
FieldsModifier and TypeFieldDescriptionstatic final intSpring Security's default filter order plus a little, seefilterOrder. -
Constructor Summary
Constructors -
Method Summary
Modifier and TypeMethodDescriptionintOnly request bodies larger than this are split; smaller ones are passed through byte for byte, so that ordinary requests behave exactly as they do without this filter.intOrder of the filter in the servlet filter chain.Types of the resources whose create interaction carries a document inline.longMaximum size of a single extracted document.intExtracted document content up to this size is kept in memory instead of being written to a temporary file.Directory for temporary document files.booleanWhether large document uploads shall be split before they reach the FHIR parser.voidsetEnabled(boolean enabled) Whether large document uploads shall be split before they reach the FHIR parser.voidsetEngageAboveBytes(int engageAboveBytes) Only request bodies larger than this are split; smaller ones are passed through byte for byte, so that ordinary requests behave exactly as they do without this filter.voidsetFilterOrder(int filterOrder) Order of the filter in the servlet filter chain.voidsetInlineDocumentResources(Set<String> inlineDocumentResources) Types of the resources whose create interaction carries a document inline.voidsetMaxDocumentSizeBytes(long maxDocumentSizeBytes) Maximum size of a single extracted document.voidsetMemoryThresholdBytes(int memoryThresholdBytes) Extracted document content up to this size is kept in memory instead of being written to a temporary file.voidsetTempDirectory(Path tempDirectory) Directory for temporary document files.
-
Field Details
-
DEFAULT_FILTER_ORDER
public static final int DEFAULT_FILTER_ORDERSpring Security's default filter order plus a little, seefilterOrder.- See Also:
-
-
Constructor Details
-
StreamingUpload
public StreamingUpload()
-
-
Method Details
-
toOptions
- Returns:
- these settings as the split's own, framework-independent options
-
isEnabled
public boolean isEnabled()Whether large document uploads shall be split before they reach the FHIR parser. -
setEnabled
public void setEnabled(boolean enabled) Whether large document uploads shall be split before they reach the FHIR parser. -
getEngageAboveBytes
public int getEngageAboveBytes()Only request bodies larger than this are split; smaller ones are passed through byte for byte, so that ordinary requests behave exactly as they do without this filter.This is measured on the whole request body, i.e. metadata plus the base64 of all documents in it.
-
setEngageAboveBytes
public void setEngageAboveBytes(int engageAboveBytes) Only request bodies larger than this are split; smaller ones are passed through byte for byte, so that ordinary requests behave exactly as they do without this filter.This is measured on the whole request body, i.e. metadata plus the base64 of all documents in it.
-
getMemoryThresholdBytes
public int getMemoryThresholdBytes()Extracted document content up to this size is kept in memory instead of being written to a temporary file.This is measured on a single decoded document and is therefore deliberately independent of
engageAboveBytes; it is quite normal for it to be the larger of the two. Splitting the body is what avoids the expensive part - the base64 text and the decoded array that the FHIR parser would otherwise materialize - whereas a temporary file is only needed to also avoid a large contiguous heap allocation. Small documents therefore stay in memory and cause no disk I/O at all. -
setMemoryThresholdBytes
public void setMemoryThresholdBytes(int memoryThresholdBytes) Extracted document content up to this size is kept in memory instead of being written to a temporary file.This is measured on a single decoded document and is therefore deliberately independent of
engageAboveBytes; it is quite normal for it to be the larger of the two. Splitting the body is what avoids the expensive part - the base64 text and the decoded array that the FHIR parser would otherwise materialize - whereas a temporary file is only needed to also avoid a large contiguous heap allocation. Small documents therefore stay in memory and cause no disk I/O at all. -
getMaxDocumentSizeBytes
public long getMaxDocumentSizeBytes()Maximum size of a single extracted document. Bounds how much temporary disk space one request can use. -
setMaxDocumentSizeBytes
public void setMaxDocumentSizeBytes(long maxDocumentSizeBytes) Maximum size of a single extracted document. Bounds how much temporary disk space one request can use. -
getTempDirectory
Directory for temporary document files. Defaults to the JVM temporary directory. -
setTempDirectory
Directory for temporary document files. Defaults to the JVM temporary directory. -
getInlineDocumentResources
Types of the resources whose create interaction carries a document inline. Defaults to what MHD needs, i.e. the ITI-105 create of a DocumentReference; a POST to the FHIR base itself, such as the ITI-65 transaction bundle, is always considered regardless of this setting. -
setInlineDocumentResources
Types of the resources whose create interaction carries a document inline. Defaults to what MHD needs, i.e. the ITI-105 create of a DocumentReference; a POST to the FHIR base itself, such as the ITI-65 transaction bundle, is always considered regardless of this setting. -
getFilterOrder
public int getFilterOrder()Order of the filter in the servlet filter chain. The default places it directly after the Spring Security filter chain, whose own default order is -100: unauthenticated requests must never be spooled to disk, and any request logging registered further down then sees the slimmed-down body rather than buffering the full upload a second time. The value is spelled out rather than derived from Spring Boot'sSecurityProperties.DEFAULT_FILTER_ORDER, which this starter does not depend on. -
setFilterOrder
public void setFilterOrder(int filterOrder) Order of the filter in the servlet filter chain. The default places it directly after the Spring Security filter chain, whose own default order is -100: unauthenticated requests must never be spooled to disk, and any request logging registered further down then sees the slimmed-down body rather than buffering the full upload a second time. The value is spelled out rather than derived from Spring Boot'sSecurityProperties.DEFAULT_FILTER_ORDER, which this starter does not depend on.
-