Qual implementação OSGi você usa?

Voltando um pouco no assunto, pq eu escolheria OSGi sobre qualquer outro bom e velho framework de injecao de dependencias?

Em resumo, porque é um sistema baseado em plugins, à la Eclipse (embora não seja um rich-client), e é preciso de “alguma coisa” que lide com o ciclo de vida e versionamento dos plugins. Até onde me lembre, o Spring IoC ou o Pico não oferecem este tipo de serviço, embora, inicialmente, eu tenha considerado utilizá-lo (pico), até o momento em que eu notei que eu teria que determinar o ciclo de vida dos meus plugins na raça. Acho que seria uma idéia bem interessante construir sobre o pico/nano um gerenciador de ciclo de vida de componentes, mas, por enquanto, acho que vai ficar na minha TODO list.

Enfim, opiniões?

Carlos, um container OSGi e de DI são coisas bem diferentes. Cada um trabalha com artefatos/componentes de granulosidade distintas.

Um container de DI/IoC trabalha em cima de instancias de objetos e o wiring das suas dependencias. Só isso.

Já o container OSGi, ele lida com deployment e gerenciamento de dependencia de bundles, que são conjuntos de classes e recursos. OSGi não fornece DI.

Em ambos os casos estamos falando em gerenciar dependencias, mas Spring, por exemplo, e OSGi trabalham em escopos diferentes, o primeiro focado em objetos e instancias deles, e o segundo em APIs e o deployment delas.

Eu já tentei usar o OSGi com o Oscar, foi um fracasso. Somente OSGi não resolve muita coisa, o grande BOOM vem de usar o framework de plugins do Eclipse. Não experimentei usar Equinox com o esquema de plugins do Eclipse, mas já desenvolvi plugins e sei do poder da plataforma.

Mas isso só funciona quando você esta trabalhando em um nível muito, muito alto de separação entre times. OSGi e plugins eclipse funcionam muito bem com equipes separas por continentes, já que isola muito bem o desenvolvimento e padroniza a comunicação entre os componentes de um sistema. Uma analogia razoavel é pensar que são as benéfices de SOA aplicadas aos pedaços de um software.

O problema é que DI vicia mais que heroina e culto evangélico juntos. O grau de liberdade, desacoplamento e agilidade que se ganha é incrivel. Funciona muito bem quando o time trabalha todo em cima do mesmo código. Mas imagino que não escala muito bem para o cenário que eu sugeri para usar OSGi.

Então o grande lance seria juntar Spring e OSGi? Seria… quase. Os dois não se bicam muito bem devido ao modelo que cada um trabalha. OSGi abusa de lazy loading e classloaders a rodo; coisas que não funcionam muito bem no Spring. A cirurgia para integrar os dois seria bem grande.

Eu tive necessidade de usar algo conceitualmente semelhante a OSGi e adotei o hivemind, que possui um esquema semelhante ao de plugins para extensão e tem um suporte a DI muito legal. Ahhh, e o xml dele é beem menor que do Spring 1.x.

Minha dica fica sendo essa, de uma olhada no hivemind. Provavelmente vai atender teu problema de forma bem melhor que OSGi.

A sim, esqueci de falar algo importante. OSGi é util pacas se teus requisitos incluirem trabalhar com múltiplas versões dos mesmos bundles e fazer deploy online de novas versões.

Liberdade sem poder fazer nada sem precisar redigir 5 páginas de XML? Como isso é possível? Setters que jamais deveriam existir? O usuário se adapta as necessidade da ferramenta e não o oposto?

Não é necessário desacoplar cada classe da aplicação. Desacoplamento não é “quanto mais, melhor” e sim quando faz sentido dentro de um contexto, caso contrário acaba-se naufragando em abstrações.

Realmente, os veneradores do Spring passarão a vida inteira se comparando ao EJB 2.x como motivo de sua existência. E os veneradores de Ruby passarão a vida inteira se comparando ao Java (na verdade ao Spring) e suas toneladas de XML.

Liberdade sem poder fazer nada sem precisar redigir 5 páginas de XML? Como isso é possível? Setters que jamais deveriam existir? O usuário se adapta as necessidade da ferramenta e não o oposto?

Não é necessário desacoplar cada classe da aplicação. Desacoplamento não é “quanto mais, melhor” e sim quando faz sentido dentro de um contexto, caso contrário acaba-se naufragando em abstrações.

Realmente, os veneradores do Spring passarão a vida inteira se comparando ao EJB 2.x como motivo de sua existência. E os veneradores de Ruby passarão a vida inteira se comparando ao Java (na verdade ao Spring) e suas toneladas de XML.

Suas observações não foram nada pertinentes para este tópico, mesmo porque ninguém mencionou nada sobre Ruby aqui. Se quiser, puder ou conseguir opinar sobre OSGi, sinta-se convidado a participar do tópico, senão guarde sua raiva para si próprio.

Liberdade sem poder fazer nada sem precisar redigir 5 páginas de XML? Como isso é possível? Setters que jamais deveriam existir? O usuário se adapta as necessidade da ferramenta e não o oposto?

Nesse caso eu vejo xml como uma vantagem, pq quero externalizar o assembly da aplicação. E o setter, bom, o setter precisa existir p/ eu ter como injetar a dependencia manualmente quando estou testando o código. Eu vejo os containers de DI como um diferencial competitivo do Java, a parte de configuração vem melhorado bastante no caso do Spring 2.0, o Hivemind já é muito mais esperto nesse quesito.

Thiagosc:

Não é necessário desacoplar cada classe da aplicação. Desacoplamento não é “quanto mais, melhor” e sim quando faz sentido dentro de um contexto, caso contrário acaba-se naufragando em abstrações.

Concordo com você, mas qual seu ponto?

Cara, você prefere desenvolver sem um container de DI? Você prefere fazer manualmente todo assembly e wiring dos objetos da tua aplicação?

louds:

Cara, você prefere desenvolver sem um container de DI? Você prefere fazer manualmente todo assembly e wiring dos objetos da tua aplicação?

Em primeiro lugar, você não está pensando POO e sim POS (programação orientada à Spring). Mas que “wiring”, que assembly?

Eu entendo que DI seja útil por exemplo para substituir determinadas implementações de classes quando se faz Unit testing entre outras coisas. Mas quando que o custo passa a ser mais alto que o benefício?

Para uma aplicação basta saber OO e elaborar uma estrutura de classes coerente, que “wiring” há nisso? Mas não atirem ovos ainda, pois não terminei…

Tá certo, possíveis contestações do que eu disse que acredito estarem corretas:

• criar toda uma infraestrutura para cada tipo aplicação seria dispendioso, que tal aproveitar algo comum e trabalhar com coisas mais genéricas?

Sim, e isso é o que Java EE faz.

• mas Java EE é intrusivo, preciso implementar interfaces ou extender classes…

Considero isso MENOS intrusivo que redigir 5 páginas de XML para fazer um Hello World. Além do mais, um modelo de componentes como por exemplo Servlets te livra de ter que inventar como funcionará tal coisa.

Spring pode ser tudo, menos “lightweight”.

• mas com XML eu posso mudar o funcionamento de determinadas coisas sem precisar mudar o código.

Para quê, se quem vai mexer com essas coisas são obrigatoriamente desenvolvedores? Se leigos precisassem lidar com isso, eu concordaria que mantê-los longe do código é essencial.

Já li gente dizendo DSL como alternativa ao XML, mas XML não é opção para nada além de formato de intercâmbio de dados entre sistemas distintos, funcionando como um protocolo, uma língua que todos entendem. XML em configuração PRECISA ser bem ecônomico, senão as nossas vidas se tornam menos felizes.

Mas pensando em termos de DI-mania a la Spring, DSLs até que fazem sentido. Realmente é MUITO melhor que XML nesse caso específico.

Enfim, isso é só a minha opinião. E opinião cada um tem a sua.

Tanto o pico e o Spring fazem controle do ciclo de vida da instância.

O Spring é mais engessado nessa parte (embora parece que a versão 2.0 vai suportar isso de uma maneira mais legal).

Agora o Pico faz isso muito bem, cadas contexto vira um container e você tem na verdade sempre uma arvore de conteiner. Você ainda tem como escrever o seu próprio ComponentAdapter que pode fazer uma gerência mais especifica da instância. Vide de exemplo o HotSwapComponentAdapter.

Seria algo além disso? Eu não conheço muito bem OSGI, mas até hoje o Pico atendeu a minha necessidade no quesito gerência do ciclo de vida do objeto.

De uma olhada no Monitor, ComponentAdapter e no conceito de arvores de containers do Pico e veja se eu estou falando o mesmo que você, se eu não estiver dê um exêmplo ai para que eu possa entender o OSGI melhor.

Está programado para o Spring 2.1 incluir integração com OSGi:

Feature request.

Ja tem uns protótipos.

EDIT: Com relação à pergunta do tópico, eu ouvi falar que o WebSphere 6.1 usa Equinox.