Service provider что это за программа

Использование SPI механизма для создания расширений

Архитектура большинства Java(и не только) приложений сегодня предусматривает возможность расширения функционала посредством различного рода магических воздействий на код. В последнее время это также стало возможно, если использовать какой-нибудь модный фреймворк или IoC-контейнер. Но что делать, если приложение долгоживущее и слишком сложное для того, чтобы переводить его на использование какого либо фреймворка?

В последнем приложении, с которым я работал, был реализован на тот момент неизвестный мне велосипед SPI механизм, который искал в джарках текстовые файлы вида и брал оттуда название нужного класса, реализующего этот интерфейс, далее этот класс использовался как расширение. Поискав в интернете, узнал, что Service Provider Interface(SPI) представляет собой программный механизм для поддержки сменных компонентов и что этот механизм уже довольно давно используется в Java Runtime Environment(JRE), например в Java Database Connectivity(JDBC):

Фасад — Сервис провайдер — Сервис контейнер – как это работает. Фреймворк Laravel

ps = Service.providers(java.sql.Driver.class); try < while (ps.hasNext()) < ps.next(); >> catch (Throwable t) < // Do nothing >

Благодаря этому коду приложения больше не нуждаются в конструкции Class.forName() (хотя и с ней будут работать), JDBC драйверы будут подгружены автоматически при первом обращении к методам класса DriverManager.

Как это работает?

Весь смысл в разделении логики на сервис(Service) и провайдеры(Service Providers). Ссылки на провайдеры сохраняются в джарках расширений в текстовом файле(UTF-8) , в каждой строке полное имя класса провайдера. Пустые строки и комментарии(начинающиеся с символа #) игнорируются. Ограничения на провайдеры: они должны реализовывать интерфейс либо наследоваться от класса сервиса и иметь конструктор по умолчанию(zero-argument public constructor).

Основное приложение для получения списка провайдеров может воспользоваться входящей в состав Java SE 6 API утилитой java.util.ServiceLoader, которая работает по следующему принципу:

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

В более ранних версиях Java SE есть аналогичная утилита sun.misc.Service, работает по тому же принципу, но является частью проприетарного ПО Sun Oracle и может быть удалена в следующих релизах Java SE.

Пример использования

Например, у нас есть программа, которая ищет музыку на компе и выводит отсортированный по имени результат на экран.

public class MusicFinder < public static ListgetMusic() < //some code >> public class ReportRenderer < public void generateReport() < final Listmusic = findMusic(); for (String composition : music) < System.out.println(composition); >> public List findMusic() < final Listmusic = MusicFinder.getMusic(); Collections.sort(music); return music; > public static ReportRenderer getInstance() < return new ReportRenderer(); >public static void main(final String[] args) < final ReportRenderer renderer = ReportRenderer.getInstance(); renderer.generateReport(); >>

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

УДАЛИТЬ! Это приложение постоянно работает в фоне и разряжает заряд батареи телефона.

Друзья попользовались сервисом и решили, что чего-то не хватает. Может выводить в отдельный файл? Но тогда придется переписывать весь этот клевый код. Не придется, можно воспользоваться SPI механизмом.

Например, создадим плагин для нашей супер-программы:

Поместим в META-INF/services/com.example.ReportRenderer следующее:

com.example.FileReportRenderer

Сделаем исходную программу расширяемой:
public class ReportRenderer < //. public static ReportRenderer getInstance() < final Iteratorproviders = ServiceLoader.load(ReportRenderer.class).iterator(); if (providers.hasNext()) < return providers.next(); >return new ReportRenderer(); > //. >

При запуске приложение, как и прежде, будет выводить всю найденную музыку на экран. Но если мы поместим только что созданную джарку расширения в classpath, то мы получим в результате файлик music.txt, содержащий результаты поиска.

Теперь пришло время поиграться с MusicFinder-ом. Сделаем его тоже расширяемым. Для этого поменяем класс на интерфейс:

public interface MusicFinder < ListgetMusic(); >

Добавим в основном модуле реализацию:
public class DummyMusicFinder implements MusicFinder < public ListgetMusic() < return Collections.singletonList(«From DummyMusicFinder. «); >>

Поддержка расширений в ReportRenderer:
public class ReportRenderer < //. public ListfindMusic() < final Listmusic = new ArrayList(); for (final MusicFinder finder : ServiceLoader.load(MusicFinder.class)) < music.addAll(finder.getMusic()); >Collections.sort(music); return music; > //. >

Как и в случае с ReportRenderer добавим текстовый файл META-INF/services/com.example.MusicFinder, содержащий:

com.example.DummyMusicFinder

Опять же результат выполнения первой программы не поменялся. Теперь расширение. Здесь сделаем две реализации MusicFinder-а:

public class ExtendedMusicFinder implements MusicFinder < public ListgetMusic() < return Collections.singletonList(«From ExtendedMusicFinder. «); >> public class MyMusicFinder implements MusicFinder < public ListgetMusic() < return Collections.singletonList(«From MyMusicFinder. «); >>

META-INF/service/com.example.MusicFinder:
com.example.MyMusicFinder com.example.ExtendedMusicFinder

Ну, вот и все, программа поддерживающая расширения готова, теперь с расширением в classpath, она выдаст список:

From DummyMusicFinder. From ExtendedMusicFinder. From MyMusicFinder.

Исходники примера можно найти здесь.

Заключение

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

Источник: habr.com

Сервис-провайдеры

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

Но, что мы подразумеваем под «начальной загрузкой»? В общем, мы имеем в виду регистрацию элементов, включая регистрацию связываний контейнера служб (service container), слушателей событий (event listener), посредников (middleware) и даже маршрутов (route). Сервис-провайдеры являются центральным местом для конфигурирования приложения.

Если вы откроете файл config/app.php , включенный в Laravel, вы увидите массив ‘providers’ . Это все классы сервис-провайдеров, которые будут загружены вашим приложением. По умолчанию в этом массиве перечислены основные сервис-провайдеры Laravel. Они загружают основные компоненты Laravel, такие, как подсистема отправки почты, очередь, кеш и другие. Многие из этих провайдеров являются «отложенными», что означает, что они не будут загружаться при каждом запросе, а только тогда, когда предоставляемые ими службы действительно необходимы.

В этой документации вы узнаете, как писать собственные сервис-провайдеры и регистрировать их в приложении Laravel.

Если вы хотите узнать больше о том, как Laravel обрабатывает запросы и работает изнутри, ознакомьтесь с нашей документацией по жизненному циклу запроса Laravel.

Написание сервис-провайдеров

Все сервис-провайдеры расширяют класс IlluminateSupportServiceProvider . Большинство сервис-провайдеров содержат метод register и boot . В рамках метода register следует только связывать (bind) сущности в контейнере служб. Никогда не следует пытаться зарегистрировать каких-либо слушателей событий, маршруты или что-то другое в методе register .

Чтобы сгенерировать новый сервис-провайдер, используйте команду make:provider Artisan:

php artisan make:provider RiakServiceProvider

Метод register

Как упоминалось ранее, в рамках метода register следует только связывать сущности в контейнере служб. Никогда не следует пытаться зарегистрировать слушателей событий, маршруты или что-то другое в методе register . В противном случае вы можете случайно воспользоваться подсистемой, чей сервис-провайдер еще не загружен.

Давайте взглянем на рядовой сервис-провайдер приложения. В любом из методов сервис-провайдера у вас всегда есть доступ к свойству $app , которое обеспечивает доступ к контейнеру служб:

Этот сервис-провайдер определяет только метод register и использует этот метод для указания, какая именно реализация AppServicesRiakConnection будет применена в нашем приложении — при помощи контейнера служб. Если вы еще не знакомы с контейнером служб Laravel, ознакомьтесь с его документацией.

Свойства bindings и singletons

Если ваш сервис-провайдер регистрирует много простых связываний, вы можете использовать свойства bindings и singletons вместо ручной регистрации каждого связывания контейнера. Когда сервис-провайдер загружается фреймворком, он автоматически проверяет эти свойства и регистрирует их связывания:

Метод boot

Итак, что, если нам нужно зарегистрировать компоновщик шаблонов в нашем сервис-провайдере? Это должно быть сделано в рамках метода boot . Этот метод вызывается после регистрации всех остальных сервис-провайдеров, что означает, что в этом месте у вас уже есть доступ ко всем другим службам, которые были зарегистрированы фреймворком:

Внедрение зависимости в методе boot

Вы можете указывать тип зависимостей в методе boot сервис-провайдера. Контейнер служб автоматически внедрит любые необходимые зависимости:

Регистрация сервис-провайдеров

Все сервис-провайдеры регистрируются в файле конфигурации config/app.php . Этот файл содержит массив providers , в котором можно перечислить имена классов. По умолчанию в этом массиве перечислены основные сервис-провайдеры Laravel. Эти поставщики загружают основные компоненты Laravel, такие, как почтовая подсистема, очереди, кеш и другие.

Чтобы зарегистрировать сервис-провайдер, добавьте его в массив:

‘providers’ => [ // Другие сервис-провайдеры AppProvidersComposerServiceProvider::class, ],

Отложенные сервис-провайдеры

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

Laravel составляет и сохраняет список всех служб, предоставляемых отложенными сервис-провайдерами, а также имя класса сервис-провайдера. Laravel загрузит сервис-провайдер только при необходимости в одной из этих служб.

Чтобы отложить загрузку сервис-провайдера, реализуйте интерфейс IlluminateContractsSupportDeferrableProvider , описав метод provides . Метод provides должен вернуть связывания контейнера службы, регистрируемые данным классом:

Русскоязычное комьюнити

• Группа в VK
• Телеграм LaravelRUS
• Телеграм Laravel для новичков
• Телеграм LaravelPro

Обучающие ресурсы

• Laracasts
• Codecourse
• Курс Дмитрия Елисеева
• Adam Wathan

Блоги разработчиков

• Laravel News
• Freek Van der Herten
• Brent Roose
• Marcel Pociot

Источник: laravel.su

ServiceProvider.exe что это за процесс и как его отключить?

Всем привет Поговорим немного о таком процессе как ServiceProvider.exe, который может быть у вас в диспетчере задач, если вы… устанавливали раньше Nero. Дело в том, что программа Nero, которая предназначена для работы с дисками, то вот она еще ставит и Nero TuneItUp. Это такая типа фирменная прога для оптимизации компа, но лично мне она не нравится. Ну не так хорошо она чистит комп, как например CCleaner.

Помимо Nero TuneItUp, после установки Nero, у меня еще появилась и какая-то прога Music Recorder. Но я честно говоря не знаю, были ли где-то при установке Nero галочки, которые отвечают за установку дополнительных прог, я просто на это не обратил внимание. Но вы внимание обращайте, иначе у вас со временем может стать много ненужных вам прог. А можете внимание и не обращать, если установите автоматический сниматель галочек, я о нем писал здесь, он сам снимает все левые галочки при установке прог! Советую посмотреть

Ну так вот, что же я самого главного то не написал, процесс ServiceProvider.exe то идет от проги Nero TuneItUp! Вот он в диспетчере задач:

Как видите процессор он никак не грузит да и оперативы кушает совсем немного, так что тут проблем нет. Запускается ServiceProvider.exe вот из этой папки:

C:Program Files (x86)NeroNero TuneItUp

А вот зачем и нужен процесс, вот для этой иконки в трее:

Если по ней нажать правой кнопкой, то появится меню, там есть пункт Закрыть, если его нажать то эта иконка пропадет и процесс ServiceProvider.exe тоже исчезнет!

Ну то есть в принципе, как отключить ServiceProvider.exe, я вам уже показал. То есть можно и этим обойтись. Но может быть вы хотите полностью избавится от ServiceProvider.exe? Если да, то вам придется удалить прогу Nero TuneItUp. Ну что значит придется, как я уже писал, мне лично она не нравится, ничего такого там особенного нет, часть функционала там вообще платная, ну то есть хотят впарить вам платную версию!

Как по мне, то намного лучше уж использовать CCleaner, она куда круче в плане функционала!

Вот смотрите, вот как выглядит Nero TuneItUp:

Ну вы там думайте, нужна вам эта программа или нет, а я тем временем покажу как ее удалить.

Если вы немного продвинутый юзер, то предлагаю вам воспользоваться таким удалятором как Revo Uninstaller, он и прогу удалит и винду от ее следов почистит. В общем удалятор годный, советую, пользуется им очень много народу

Ну а теперь как удалить Nero TuneItUp так бы сказать по-простяковски. Значит зажимаете кнопки Win + R и пишите туда такую команду как:

Теперь находим значок Программы и компоненты, ну и запускаем его:

В списке установленных программ ищем Nero TuneItUp, нажимаем по ней правой кнопкой и выбираем Удалить:

Появится окошко, в нем будет написано, ну мол вы уверены что справитесь без Nero TuneItUp? Ну короче такой прикол или что они там себе думают.. А вот то что нужно нажать, то есть Деинсталлировать сейчас, то это написано мелким шрифтом внизу:

Ну и все, потом за секундочек пять Nero TuneItUp удалится с компьютера и вы увидите только такое вот сообщение:

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

Источник: virtmachine.ru

Service Provider Interface (SPI)

Теги: java, java se, service provider interface (spi), jar-архив, meta-infservices, интерфейс для группы модулей, стратегия упаковки классов-реализаций в jar-архивы, classloader, загрузка классов-реализаций из jar-архива

Вот представьте: повысили вас до ведущего разработчика! Не номинально, а по-настоящему – будете отвечать за техническое развитие продукта. И вот заходите вы в почту, естественно, чтобы должность в подписи поменять, а там.

Вместе с полномочиями пришла и ответственность: – пользователи не хотят больше устанавливать дистрибутив приложения целиком, они хотят устанавливать только то, что планируют использовать; – техническая поддержка просит реализовать наконец возможность автоматического обновления приложения; – разработчики тоже ругают долгий цикл доставки обновлений пользователям; – отдел продаж требует технически поддержать новую модель гибкого ценообразования — теперь пользователь покупает только нужный ему функционал; – партнёры хотят создавать собственные расширения к продукту; – юристы перестраховываются и требуют убрать из состава дистрибутива коммерческого продукта ту часть функционала, которая использует некоторые open source библиотеки, чтобы избежать необходимости публикации исходников.

Как разрубить этот «гордиев узел»?

Разделить монолитное приложение на модули! Модули могут загружаться по требованию и обновляться при необходимости в процессе работы основного приложения.

А как это сделать? Выбор велик. Можно просидеть все выходные, изобретая собственный «велосипед». Можно вооружиться кофе-машиной и погрузиться в изучение вселенной OSGi.

А можно вспомнить, чему учат на курсе OTUS: в состав Java SE входит технология Service Provider Interface (SPI).

О ней и пойдёт речь далее

Технология SPI позволяет разделить сервисы (бизнес-логику) приложения на интерфейс и его реализации. Таким образом, реализация сервиса может распространяться в виде отдельного jar-архива и включаться в работу уже в процессе работы основного приложения.

Эта технология, например, применяется в хорошо известной вам JDBC для загрузки драйвера конкретной СУБД.

На практике это выглядит так:

1) Создаёте общий интерфейс для группы ваших модулей Сигнатуры методов интерфейса могут быть абсолютно любыми. Например:

public interface Plugin

2) Создаёте необходимое количество классов-реализаций ваших модулей Например:

public class EchoPlugin implements Plugin < public Object execute(Object input) < // Делаем что-то полезное return input; >>

3) Определяете стратегию упаковки классов-реализаций в jar-архивы В один jar-архив может быть упакован один или несколько классов-реализаций. Как правило, один архив содержит реализацию одного логически целостного модуля приложения. Внутри каждого jar-архива в каталоге META-INFservices должен находится текстовый файл в кодировке UTF-8, название которого совпадает с полным именем интерфейса, созданного в п.1, например, ru.otus.Plugin. В тексте файла должны быть указаны полные имена классов-реализаций, содержащихся в jar-архиве, например:

ru.otus.EchoPlugin ru.otus.CopyPlugin

4) В программном коде основного приложения создаёте ClassLoader для загрузки классов-реализаций из jar-архива

URL[] moduleUrls = new URL[]; URLClassLoader urlClassLoader = new URLClassLoader(moduleUrls);

5) А затем, получаете и используете реализации необходимых вам модулей

for (final Plugin plugin : ServiceLoader.load(Plugin.class, urlClassLoader))

Всё, пользуйтесь!

Есть вопрос? Напишите в комментариях!

Источник: otus.ru