Продвигаемся дальше

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

Пример, приведенный здесь, является реально работающим. Исходный код примера можно найти в пакете класса хранилища локальной файловой системы модуля org.eclipse.team.examples.filesystem. Проект можно извлечь из хранилища CVS и при изучении этого материала пользоваться им как справочником.

Реализация Подписчика с нуля

В первом примере предполагается, что для обслуживания состояния синхронизации локальной рабочей области нет готовой инфраструктуры. При реализации подписчика с нуля можно воспользоваться некоторыми дополнительными API, предусмотренными в модуле org.eclipse.team.core. В пакете org.eclipse.team.core.variants есть два производного класса Subscriber, которыми можно воспользоваться как основой. Первый - это ResourceVariantTreeSubscriber . О нем мы поговорим во втором примере (см. ниже). Второй - это производный класс первого: ThreeWaySubscriber. Такая реализация подписчика предоставляет несколько полезных классов для управления состоянием синхронизации локальной рабочей области. При отсутствии инфраструктуры это будет неплохой стартовой площадкой.

Реализация подписчика с нуля проиллюстрирована примером файловой системы в модуле org.eclipse.team.examples.filesystem. Здесь код приведен по минимуму, так его можно взять в хранилище Eclipse CVS. Хотя технически это не трехсторонний подписчик, но пример файловой системы построен именно на такой инфраструктуре. Модули FTP и WebDAV также строятся на ее основе.

ThreeWaySubscriber

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

Кроме реализации подписчика, изменены также операции get и put для класса хранилища файловой системы, чтобы обновить состояние синхронизации в ThreeWaySynchronizer. Операции реализованы в классе org.eclipse.team.examples.filesystem.FileSystemOperations.

ThreeWaySynchronizer

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

Для обеспечения безопасности нитей и возможности группирования оповещений об изменениях в классе ThreeWaySynchronizer используются базовые правила планирования и блокировки.

ThreeWayRemoteTree

Класс ThreeWayRemoteTree является производным классом ResourceVariantTree, специально созданного для ThreeWaySubscriber. Для обеспечения возможности выборки удаленного состояния с сервера этот класс должен переопределяться клиентами. Более подробно класс ResourceVariantTree обсуждается в следующем примере.

CachedResourceVariant

Класс CachedResourceVariant - это частичная реализация IResourceVariant, которая кэширует все содержимое, выбранное за определенный период времени (обычно 1 час). Эта функция иногда бывает полезной, так как к обращений к содержимому может быть несколько за короткое время (например, для определения состояния синхронизации и отображения содержимого в Редакторе сравнения). Производный класс по-прежнему должен задавать уникальный ИД содержимого в виде массива байтов, по которому можно восстановить описатель варианта ресурса.

Надстройка над существующей синхронизацией рабочей области

Во многих типах хранилищ уже предусмотрен механизм управления их состоянием синхронизации (например, если есть существующие модули). Класс ResourceVariantTreeSubscriber и связанные с ним классы позволяют надстраивать существующую инфраструктуру синхронизации. Например, к таким классам относятся базовые классы всех подписчиков CVS.

ResourceVariantTreeSubscriber

Как уже говорилось в предыдущем примере, класс ThreeWaySubscriber - это производный класс ResourceVariantTreeSubscriber, обеспечивающий синхронизацию локальной рабочей области с помощью ThreeWaySynchronizer. Производные классы ResourceVariantTreeSubscriber должны предусматривать:

Остальные функции подписчика можно реализовать с помощью этих указанных.

ResourceVariantTree

ResourceVariantTree - это точная реализация интерфейса IResourceVariantTree, возможности которого следующие:

В производных классах должно быть реализовано следующее:

Конкретные реализации класса ResourceVariantByteStore, которые сохраняют байты для всей рабочей среды (PersistantResourceVariantByteStore) или кэшируют байты только для текущего сеанса (SessionResourceVariantByteStore). Однако, для формирования подписчика на основе готовой инфраструктуры синхронизации рабочей области обычно требуется реализация производных классов ResourceVariantByteStore, взаимодействующих с этой инфраструктурой. Например, ThreeWayRemoteTree использует реализацию хранилища байт для хранения удаленных байт в ThreeWaySynchronizer.

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