<xsd:element name="cache">
<xsd:annotation>
<xsd:documentation><h3><b>Topic:</b></h3> 4.
Interceptors/Features<br/><h3><b>Description:</b></h3>
<p> Don't use, this does NOT implement valid HTTP caching.
</p> <p> We currently just use this class to cache a
bunch of Debian and Ubuntu Repositories as well as the Docker
Registry for offline use. The cache does not revalidate any
responses, so machines querying the cache for Debian package updates
will be stuck in the past until the cache (on disk) is cleared
manually. - This is - simply put - the only use case, where using
this class makes any sense. </p><br/>
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="beans:identifiedType">
<xsd:sequence>
<xsd:choice minOccurs="1">
<xsd:annotation>
<xsd:documentation><h3><b>Topic:</b></h3>
4.
Interceptors/Features<br/><h3><b>Description:</b></h3>
<p> Don't use, this does NOT implement valid HTTP
caching. </p> <p> We currently just use this class
to cache a bunch of Debian and Ubuntu Repositories as well as
the Docker Registry for offline use. The cache does not
revalidate any responses, so machines querying the cache for
Debian package updates will be stuck in the past until the
cache (on disk) is cleared manually. - This is - simply put -
the only use case, where using this class makes any sense.
</p><br/></xsd:documentation>
</xsd:annotation>
<xsd:element ref="fileStore">
</xsd:element>
<xsd:element ref="inMemoryStore">
</xsd:element>
</xsd:choice>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
|