Referências de serviço no OSGI

Question

Depois que uma instância de um serviço OSGI é recuperada do contexto do pacote, ele fica invalidado quando o serviço é interrompido?

Meus testes iniciais mostram que a instância de serviço pode ser usada mesmo após a parada do pacote de serviços, o que contradiz minha compreensão da natureza dinâmica do OSGI.

Suponho que isso se resume ao que recuperar um serviço (via ServiceTracker) de outro pacote do contêiner OSGI realmente faz, ele cria uma nova instância ou fornece um ponteiro para a instância registrada no contêiner?

Existem perigos no uso da instância do serviço depois que o serviço foi interrompido?

Answer 1

Esta é uma pergunta muito boa, então eu me aproveitei na especificação em busca de uma resposta definitiva. Acontece que há uma seção inteira falando sobre esse problema - consulte a seção 5.4 Referências obsoletas começando na página 132 de Especificação principal da plataforma de serviço OSGI, versão 4, versão 4.2.

Para responder sua pergunta de acordo com a especificação:

O comportamento de um serviço que não se torna registrado é indefinido. Esses serviços podem continuar a trabalhar corretamente ou lançar uma exceção a seu critério.

E para evitar problemas em potencial:

Os pacotes devem ouvir os eventos gerados pela estrutura para limpar e remover referências obsoletas.

A especificação também fornece algumas dicas sobre como minimizar as consequências de referências obsoletas.

Answer 2

Você está certo, pois é contraditório à natureza dinâmica do OSGI. Acredito que não há garantia de que o serviço esteja disponível, embora diferentes implementações de contêineres e serviços da OSGI possam se comportar de maneira diferente.

Por exemplo, se o serviço foi criado e registrado no Spring DM, o serviço recuperado é na verdade um proxy baseado em primavera para a implementação subjacente, e a implementação ainda poderá desaparecer. Assim, uma referência de serviço que se refere diretamente a uma implementação pode impedir que esse objeto seja removido, enquanto a referência baseada em proxy não.

Answer 3

A especificação OSGI diz:

Pacotes são entidades visíveis na programação normal de aplicação. Por exemplo, quando um pacote é interrompido, todos os seus serviços não serão registrados.

Portanto, você não deve conseguir um serviço de um pacote parado. Mas tecnicamente, pode ser possível usá -lo, pelo menos enquanto você mantém uma referência ao objeto de serviço (ninguém pode tirá -lo de você e não será gc). Mas não acho que seja um exceto para usar o serviço. Pode depender de outros recursos do pacote, que não estão disponíveis depois que o pacote foi interrompido.

Answer 4

Depois que uma instância de um serviço OSGI é recuperada do contexto do pacote, ele fica invalidado quando o serviço é interrompido?

Não, a própria referência não se torna invalidada. Enquanto algo dentro do contêiner estiver segurando, ele também não poderá ser GC'ed.

No entanto, se ainda será útil ou não, depende apenas da própria implementação do serviço, não do contêiner.

Meus testes iniciais mostram que a instância de serviço pode ser usada mesmo após a parada do pacote de serviços, o que contradiz minha compreensão da natureza dinâmica do OSGI.

As próprias especificações indicam que essas referências não devem ser mantidas, mas cabe ao implementador cuidar corretamente das especificações; Significa que não há contradição, existe apenas o fato de que você pode implementar e implantar pacotes que não se comportam corretamente de acordo com as especificações.

Suponho que isso se resume ao que recuperar um serviço (via ServiceTracker) de outro pacote do contêiner OSGI realmente faz, ele cria uma nova instância ou fornece um ponteiro para a instância registrada no contêiner?

O contêiner não cria novas instâncias de serviços, exceto se houver um serviço de serviço envolvido (consulte as especificações). Procurar um serviço deve sempre fornecer um ponteiro para a instância registrada no contêiner.

Existem perigos no uso da instância do serviço depois que o serviço foi interrompido?

Isso depende apenas da implementação do serviço; No entanto, ao fazer isso em um pacote, você cria automaticamente um pacote que não está em conformidade com as especificações.

Na prática, muitos serviços são implementados para liberar recursos e referências e não responderão mais corretamente.

Answer 5

Em relação à sua pergunta se é perigoso usar uma instância de serviço após a parada do serviço. Para citar a partir das especificações do núcleo 4.2 (5,4 referências obsoletas):

O comportamento de um serviço que não se torna registrado é indefinido. Esses serviços podem continuar a trabalhar corretamente ou lançar uma exceção a seu critério.

Não quero citar toda a seção da especificação aqui, mas as frases a seguir são uma boa discussão sobre o perigo de usar referências obsoletas:

Uma referência obsoleta é uma referência a um objeto Java que pertence ao carregador de classe de um pacote que é interrompido ou associado a um objeto de serviço que não é registrado. O Java Standard não fornece nenhum meio genérico para limpar referências obsoletas, e os desenvolvedores de pacote devem analisar seu código com cuidado para garantir que referências obsoletas sejam excluídas.

As referências obsoletas são potencialmente prejudiciais porque impedem o coletor de lixo Java da colheita das classes e, possivelmente, as instâncias de pacotes parados. Isso pode resultar em aumento significativo do uso da memória e pode fazer com que a atualização das bibliotecas de código nativo falhe. Os pacotes que usam serviços são fortemente recomendados para usar o rastreador de serviço ou os serviços declarativos.

Answer 6

Uma referência de serviço nunca deve ser mantida como referência. Você deve sempre procurar um serviço em tempo de execução. Isso o vincula à API OSGI, no entanto, o que nem sempre é desejado.

Dê uma olhada em - Osgi ServiceTracker - OSGI Declarativo Serviços - OSGI Blueprint - Spring DM - Peaberry - Ipojo

que todos cuidam do dinamismo para você, a maioria deles sem a API OSGI para usar.

Cumprimentos,

Leen Toelen