Estendendo aplicativos da Web Java com plugins

Question

Eu tenho este aplicativo da web que cresceu para uma bagunça incontrolável.

Quero dividi -lo em uma parte comum da "estrutura" (que ainda inclui coisas da Web, como páginas e imagens) e vários módulos que adicionam funcionalidade e telas extras. Eu quero que essa refatoração também seja útil como um sistema de plug-in para extensões de terceiros.

Todos os módulos precisam ser unidades de implantações separadas, idealmente um arquivo de guerra ou jar.

Tentei apenas fazer vários arquivos de guerra regulares, mas o Tomcat mantém (de acordo com a especificação do servlet), esses arquivos de guerra se separam completamente de cada um, para que eles não possam compartilhar suas classes, por exemplo.

Eu preciso plugins para poder ver o caminho de classe "principal".

Preciso o aplicativo principal para ter algum controle sobre os plugins, como poder listá -los e definir sua configuração.

Gostaria de manter a separação completa entre os próprios plugins (a menos que eles especifiquem dependências) e quaisquer outros aplicativos da Web não relacionados que possam estar em execução no mesmo tomcat.

Eu gostaria que eles estivessem enraizados no prefixo da URL do aplicativo "principal", mas isso não é necessário.

Eu gostaria de usar o Tomcat (grandes mudanças arquitetônicas precisam ser coordenadas com muitas pessoas), mas também para ouvir sobre uma solução limpa no mundo EJB ou OSGI, se houver.

Answer 1

Eu tenho mexido com a idéia de usar o OSGI para resolver o mesmo problema que você está descrevendo. Em particular, estou olhando para usar Módulos dinâmicos da primavera.

Answer 2

Dê uma olhada em Java Portlets - http://developers.sun.com/portalserver/reference/techart/jsr168/ - Em poucas palavras, uma especificação que permite a interoperabilidade entre o que são aplicativos da Web J2EE independentes

EditarEsqueci de mencionar que os portlets são praticamente agnósticos da estrutura - para que você possa usar o Spring para o aplicativo pai e os desenvolvedores individuais podem usar o que quiserem em seus portlets.

Answer 3

Você já olhou usando o Maven para separar seus projetos e, em seguida, resolveu as dependências entre as guerras e potes? Você acabará com a duplicação de bibliotecas entre as guerras, mas apenas onde é necessário (e isso não deve ser um problema, a menos que você entre em uma diversão funky de carregador de classe).

O Tomcat também permite configurar aplicativos cruzados de contexto, se você precisar ir de uma guerra para outra de uma maneira relativamente transparente ...

Se você deseja manter as coisas no mesmo aplicativo da Web único (por exemplo, root), poderá criar um WebApp proxy que encaminhe para o outro aplicativo relevante nos bastidores para o usuário torná -lo relativamente transparente?

Answer 4

Seu principal problema vai se concentrar nos ativos físicos e estáticos do sistema - o restante é de maneira simples, efetivamente, frascos.

As guerras são separadas, no Tomcat, com carregadores de classe separados, mas também são separados no nível da sessão (cada guerra é um aplicativo da Web Indvidual e tem seu próprio estado de sessão).

Em Glassfish, se as guerras fossem empacotadas em um ouvido, elas compartilhariam carregadores de classe (a GF usa um espaço de carregador de classe plana nas orelhas), mas ainda teria estado de sessão separado.

Além disso, não tenho certeza se você pode fazer um "avanço" para outra guerra no servidor. O problema existe que os avançados usam um URL relativo à raiz do aplicativo da web, e cada webApp tem sua própria raiz, para que você simplesmente "não pode chegar lá daqui". Você pode redirecionar, mas isso não é a mesma coisa que um atacante.

Portanto, esses recursos do aplicativo da web conspiram contra você, tentando implantá -los homogeneamente dentro do contêiner.

Em vez disso, acho que a dica quente é criar um utilitário "assembler" que pega seus módulos individuais e os "mescla" para um único aplicativo da web. Ele pode mesclar sua web.xml, seu conteúdo, normalizar os frascos e aulas, etc.

As guerras são uma característica e um bug no mundo Java. Eu os amo porque eles realmente fazem da implantação de aplicativos compilados "arrastar e soltar" em termos de instalá -los, e esse recurso é usado muito mais do que você está encontrando. Mas sinto sua dor. Temos uma estrutura "núcleo" comum que compartilhamos em todos os aplicativos e basicamente precisamos mesclá -la continuamente para mantê -la. Nós o roteirizamos, mas ainda é um pouco de dor.

Answer 5

"Além disso, não tenho certeza se você pode fazer um" avanço "para outra guerra no servidor. O problema existe que os avançados usam um URL relativo à raiz do aplicativo da web, e cada webApp tem sua própria raiz, então Você simplesmente "não pode chegar lá daqui". Você pode redirecionar, mas isso não é a mesma coisa que um avanço. "

Você pode encaminhar para outra guerra enquanto essa guerra permitir que alguém faça isso.

Glasshish e várias guerras de um ouvido: isso faz sentido.

Se você colocar as classes principais no caminho de classe compartilhado do Tomcat, poderá colocar seus plugins individuais em arquivos de guerra separados.

O aplicativo principal também pode fazer parte do servlet Tomcat que você define no Server.xml. Este pode ser o mestre servlet e todas as outras guerras podem ser controladas por este servlet mestre.

Isso faz sentido ?

Br,
~ A

Answer 6

Dependendo da complexidade da funcionalidade do plug -in, eu também estaria considerando um serviço da Web, por exemplo, implementado com o eixo.

Sua principal Appplication é configurada com o URL para o aplicativo da Web (plug -in), que fornece o serviço.

A vantagem, como eu vejo, é dupla:

• Você obtém uma API agradável, limpa e debatível entre as duas guerras, a saber, as mensagens SOAP/XML
• Você pode atualizar um único plug-in sem ter que testar todo o seu aplicativo

As desvantagens são que você precisa configurar alguns projetos de eixo e que você precisa ter algum tipo de configuração de plug -in. Além disso, pode ser necessário limitar o acesso aos seus aplicativos da Web de serviços, para que um pouco de configuração possa ser necessário.

Se os plugins funcionarem no mesmo banco de dados, limpe-se em limitar o tempo do cache ou configurar uma camada de cache de salto de guerra.

Answer 7

Também tenho tentado desenvolver uma estrutura comum ou abstrata, onde posso adicionar plugins (ou módulos) em tempo de execução e aprimorar o WebApp em execução existente.

Agora, como você disse, preferiu a maneira de fazer isso usando o arquivo de guerra ou jar. O problema do arquivo de guerra é que você não pode implantar como plugin no aplicativo existente. O Tomcat o implantará como um contexto da Web separado. Não é desejável.

Outra opção é jarro e escrever algum código personalizado para copiar esse arquivo JAR para a pasta Web-Inf/Lib e carregar as classes no carregador de classe existente. O problema é como implantar arquivos não Java, como JSP ou arquivos de configuração. Para isso, existem duas soluções, a. Use modelos de velocidade em vez de JSP (b.) Escreva algum código personalizado para ler o JSP do ClassPath em vez do caminho do contexto.

Os módulos dinâmicos Osgi ou primavera são bons, mas neste momento eles parecem excessivamente complexos para mim. Vou olhar para isso novamente, se sentir isso.

Estou procurando uma API simples, que pode cuidar do ciclo de vida do plug -in e ainda capaz de usar JSPs no meu arquivo JAR embalado.

Pode ser que você possa usar o ONU jar o plug -in na implantação e copiar arquivos para diretórios corretos.

Answer 8

Na verdade, não há nada melhor do que osgi se você estiver pensando em dividir a aplicação em módulos separados. Dê uma olhada no exemplo do GreenPages. Você pode criar um módulo pai (núcleo), onde inclua frascos que seu aplicativo precisa.

Se você souber algo sobre programação de componentes, em breve descobrirá que os módulos OSGI se comportam como interfaces, onde você deve expor o que usará em outros módulos. É bastante simples quando você entende. De qualquer forma, também pode ser muito doloroso quando você aprende a usar osgi. Tivemos problemas para usar o JSON, como uma versão de Jackson que adicionamos como JAR ao módulo, foi substituída por outro frasco que estava contido nos módulos do núcleo da primavera. Você sempre precisa verificar qual versão do JAR está carregada para suas necessidades.

Infelizmente, mesmo a abordagem OSGI não resolve o que estamos procurando. Como estender um modelo persistente e formas existentes no tempo de execução.