Primeiro, o trabalho de base. O GlassFish é um pouco estranho para mim na maneira como implementa o WAR. Pelo que entendi, os arquivos WAR são explodidos em algum lugar pelo agente do nó, mas você não obtém access para cutucar os arquivos depois que eles são implementados. Isso significa que você ajusta os arquivos de configuração (portal-ext.properties) que precisará reimplantar a cada vez – e o Liferay é muito grande, com ~ 73MB. Isso causará exceções de falta de espaço no PermGen periodicamente e exigirá a reboot do cluster. Portanto, seria sensato definir a opção JVM para aumentar o tamanho do espaço PermGen no glassfish. Há uma boa explicação do problema aqui:
Essa opção da JVM não resolverá o problema, mas aumentará o atraso entre as reinicializações do cluster (o console glassfish não funcionou para reinicializar, btw; tivemos que fazer isso por meio da linha de comando).
A próxima pergunta foi: onde vão os arquivos JAR de dependência? Estamos operando em um cluster compartilhado executando outros serviços, portanto, colocá-lo na pasta domains / domain1 / lib não funcionará. Colocamos os arquivos JAR de dependência no arquivo war do liferay, no WEB-INF / lib, e parece estar feliz com isso.
Próximo: onde o arquivo de substituição do portal-ext.properties vai? A resposta está novamente no arquivo war do liferay, em WEB-INF / classs. Esse também é um motivo que contribui para a necessidade de reimplantar toda vez que modificamos uma propriedade, conforme discutido acima.
Próximo: contexto. Por padrão, o liferay tenta implantar no contexto raiz “/”. Estamos em um ambiente compartilhado, então implantamos o WAR no contexto / lr1. Em portal-ext.properties, tivemos que definir a propriedade
Próximo: Não faz muito sentido usar o HSQL incorporado em um ambiente em cluster; nós configuramos um nome de JNDI para nosso pool de conexões de database usando o GlassFish. Existem instruções sobre como fazer isso nos guias de documentação do Liferay. No arquivo portal-ext.properties, fomos capazes de colocar