Spec-Zone .ru
спецификации, руководства, описания, API
Содержание документации

URLConnection кэширующийся API

HTTP обычно используется для распределенных информационных систем, где производительность может быть улучшена при помощи кэшей ответа. В то время как прокси-серверы HTTP обычно кэши недавно посещенные веб-ресурсы, это является иногда также требуемым, чтобы иметь локальный кэш. Примерами являются кэши браузера.

У Тигра новая платформа обеспечивает путь к обработчикам протокола, чтобы получить доступ к механизму кэширования ответа, реализованному платформой или третьей стороной.

Вот API:

Мы представили три абстрактных класса в java.net пакет. Они:

Конкретный подкласс ResponseCache представляет кэш URLConnection непосредственно. Экземпляр такого класса может быть зарегистрирован в системе, вызывая ResponseCache.setDefault (), и система вызовет этот объект чтобы к:

У ResponseCache есть два метода: доберитесь (), возвращает CacheResponse, основанный на заголовках запроса и URI; и помещенный () позволяет кэшу решать, должен ли ресурс кэшироваться, возвращает CacheRequest.

Конкретный подкласс CacheRequest используется, чтобы записать запись в ResponseCache. Экземпляры такого класса обеспечивают объект OutputStream, который вызывают обработчики протокола, чтобы сохранить данные ресурсов в кэш, и также аварийное прекращение работы () метод, который позволяет работе хранилища кэша быть прерванной и отказаться.

У класса CacheRequest есть два метода: getBody () возвращает поток для того, чтобы записать тело запроса в кэш; и аварийное прекращение работы () отказывается от записи кэша.

Конкретный подкласс CacheResponse возвращает запись из ResponseCache. Экземпляры такого класса предоставляют InputStream, который возвращает тело объекта, и также getHeaders () метод, который возвращает связанные заголовки ответа.

У класса CacheResponse есть два метода: getBody () возвращает поток для того, чтобы считать тело запроса из кэша; и getHeaders () возвращает сохраненные заголовки.

Кэширование логического потока

Следующий пример показывает, что простой файл базировал кэширование. Однако, это одинаково жизнеспособно, чтобы использовать другие механизмы, такие как база данных для того, чтобы кэшироваться.

Класс MyCacheResponse является реализацией CacheResponse. То, что это делает, должно взять имя файла и получить заголовки ответа HTTP и тело от этого.

class MyCacheResponse extends CacheResponse {
FileInputStream fis;
Map<String, List<String>> headers;
public MyCacheResponse(String filename) {
        try {
         fis = new FileInputStream(new File(filename));
         ObjectInputStream ois = new ObjectInputStream (fis);
         headers = (Map<String, List<String>>)  ois.readObject();
   } catch (IOException ex) {
        // handle exception
   }
}

public InputStream getBody() throws IOException {
   return fis;
}

 public Map getHeaders() throws IOException {
   return headers;
 }
}

MyCacheRequest является реализацией CacheRequest. Это берет имя файла и заголовки ответа и хранит заголовки в файле и также возвращает outputstream, направленный к тому же самому файлу так, чтобы любое тело ответа могло кэшироваться там.

class MyCacheRequest extends CacheRequest {
FileOutputStream fos;
public MyCacheRequest(String filename,
   Map<String, List<String>> rspHeaders) {
   try {
        File file = new File(filename);
        fos = new FileOutputStream(file);
        ObjectOutputStream oos = new ObjectOutputStream(fos);
        oos.writeObject(rspHeaders);
   } catch (Exception ex) {
        throw new RuntimeException(ex.getMessage());
   }
}
public OutputStream getBody() throws IOException {
   return fos;
}

public void abort() {
   // we abandon the cache by close the stream,
   // and delete the file
   fos.close();
   file.delete();
 }
}

Наконец, мы можем связать это в целом нашей реализацией ResponseCache, это проверяет URI на сетевой ресурс, который получается или кэшироваться и возвращает соответствующие инстанцирования наших реализаций CacheResponse или CacheRequest. В этом примере мы только обрабатываем случай, когда URI равен uri1 для того, чтобы получить от кэша, и для URI равняется uri2 для того, чтобы сохранить к кэшу. Но это легко расширяется, чтобы обработать более сложный файл базируемый кэш.

class MyResponseCache extends ResponseCache {
 public CacheResponse
 get(URI uri, String rqstMethod, Map rqstHeaders)
   throws IOException {
   // get the response from a cached file if available
   if (uri.equals(ParseUtil.toURI(uri1))) {
        return new MyCacheResponse(FNPrefix+"file1.cache");
   }
   return null;

public CacheRequest put(URI uri, URLConnection conn)
   throws IOException {
   // save cache to a file
   // 1. serialize headers into file2.cache
   // 2. write data to file2.cache
   if (uri.equals(ParseUtil.toURI(uri2))) {
       return new MyCacheRequest(OutFNPrefix+"file2.cache",
        conn.getHeaderFields());
   }
   return null;
 }
}

Как только мы разработали нашу собственную реализацию ResponseCache, все оставленные быть сделанными должны зарегистрировать ее, и JVM будет использовать ее.

public static void main(String args[]) throws Exception {
        ......
        ResponseCache.setDefault(new MyResponseCache());
        HttpURLConnection http = (HttpURLConnection)url1.openConnection();
        InputStream is = null;
        ......
}

Нет никакой реализации по умолчанию URLConnection, кэширующегося в Java 2 Standard Edition. Однако, Плагин Java и Java WebStart действительно обеспечивают один из поля.


Oracle и/или его филиалы Авторское право © 1993, 2011, Oracle и/или его филиалы. Все права защищены.
Свяжитесь с Нами