antes de implantar “myapp.war” no glassfish 4 eu tenho que
jdbc-connection-pool
não funciona sozinho … bem de asadmin) jdbc-resource
igual ao anterior) property javax.persistence.schema-generation.create-database-schemas
, mas é falso) agora estou fazendo:
asadmin add-resources ...
asadmin create-auth-realm ...
asadmin deploy ...
asadmin disable myapp ...
nano /.../glassfish/applications/myapp/WEB-INF/classs/META-INF/persistence.xml
ctrl+o
, enter
, ctrl+x
, enter
asadmin enable myapp ...
rm -Rf /tmp/install
e sem outra sugestão estou planejando:
chmod +x deploy.sh
./deploy.sh
e o roteiro cuidará de tudo. mas eu gostaria de fazer upload de apenas um arquivo de guerra via console http glassfish e obter o mesmo resultado.
Existe uma maneira de ter uma class ou script chamado antes de contextInitialized
?
como você implantaria essa coisa?
Para completar, aqui estão algumas informações adicionais:
/myapp/WEB-INF/classs/META-INF/persistence.xml
org.eclipse.persistence.jpa.PersistenceProvider jdbc/myapp false NONE <!-- --> <!-- --> <!-- --> <!-- --> <!-- --> <!-- --> <!-- -->
/myapp/WEB-INF/glassfish-resources.xml
enquanto o glassfish entende /myapp/…/persistence.xml (às vezes executando também o comando CREATE SCHEMA myapp
, às vezes não, aparentemente random – mas tudo bem),
Eu definitivamente não posso fazer o glassfish ler /myapp/WEB-INF/glassfish-resources.xml. ele ignora esse arquivo.
UPDATE glassfish lê o arquivo, mas prefixa os nomes do jndi com java:app/
quebra outras referências. estando ciente disso, eu reescrevo as referências com prefixo e agora está funcionando bem. Por último, notei que se glassfish-resources.xml
estiver dentro de META-INF
(em vez de WEB-INF
) glassfish lê o arquivo e também está presente em http ui em “applications> myapp> descriptors”
finalmente encontrei uma solução:
database create / upgrade : em ServletContextListener.contextInitialized
eu uso o script ddl gerado em tempo de compilation para criar o database, se não existir, ou usar o liquibase para atualizar o database, se existir. não há mais uso persistence.xml para geração de database.
Implantação de região de autenticação : não implantar nem criar nenhuma região específica de contêiner. em ServletContextListener.contextInitialized
eu registro uma implementação JASPIC customizada, que é em si um wrapper de módulo de login do JAAS. obrigado a @ArjanTijms por este artigo e esta resposta
Você pode configurar resources com escopo de aplicativo para o jdbc-connection-pool e jdbc-resource dentro do glassfish-resources.xml e, quando você implantar seu arquivo WAR, eles serão criados. Quando você desdobra sua GUERRA, eles irão embora. Isso resolve o problema de adicioná-los manualmente com asadmin. O que geralmente faço é configurá-lo manualmente usando a GUI, em seguida, copie e cole os elementos
e
do domain.xml em glassfish-resources.xml, então eu mudo o jndi-name para ser aplicativo com escopo, por exemplo:
Então eu me certifico de que glassfish-resources.xml é empacotado no lugar apropriado no arquivo WAR, ou seja, na pasta WEB-INF .
De acordo com o que li na documentação do Oracle para o Glassfish 4, não parece que você possa empacotar a configuração do auth-realm com o aplicativo como você pode para o material do JDBC. Eu arquivei uma solicitação de aprimoramento para este aprimoramento de empacotamento auth-realm do glassfish . Aparentemente, é possível empacotar a associação para o domínio em vários descritores de implementação, consulte a seção “Como definir um território para um aplicativo ou módulo” deste guia para detalhes.
Alerta de HACK
Na verdade, eu só pensei em algo que é um pouco de truque, mas poderia contornar esse problema. Você pode criar um aplicativo da web simples que inclua o arquivo WAR de aplicativos reais nele (em um diretório de resources). Esse aplicativo de wrapper includeia um cliente REST (como o cliente Jersey) que faria chamadas REST para a API REST de administração do Glassfish para ver se o auth-realm está lá e configurado. Se for, usaria a API REST para implementar o arquivo WAR integrado. Se não fosse, usaria a API REST para criar o auth-realm e, em seguida, implementaria o WAR.
Eu não estou muito claro sobre os problemas que você está tendo com a geração de esquema, mas isso é tudo suportado através do persistence.xml e funciona bem. Se você quiser ainda mais funcionalidade no caminho da criação de scripts de migration automática, eu verificaria a integração de um pacote como o FlyAway
Aqui está um exemplo de um arquivo glassfish-resources.xml com resources de escopo de aplicativo que funciona para mim em Glassfish 3.1.2. Alguns dos atributos que você possui não o fazem e eu também não uso um estilo de nomenclatura JNBC JDBC para o nome do pool no recurso jdbc.