Instalação

A instalação do SGBD PostgreSQL é extremamente mutável, a depender do sistema operacional. Uma vez que não é nosso escopo abranger todas as possibilidades de instalação, descreveremos a configuração de um banco de dados já instalado no sistema operacional. Uma vez instalado o PostgreSQL no sistema operacional hospedeiro, é necessário realizar algumas configurações mínimas para seu adequado funcionamento com o PJe.

Usuário básico

Ao ser instalado, o PostgreSQL define um usuário básico responsável pela administração do banco de dados. Ordinariamente, esse usuário tem o login “postgres” e sua senha é definida durante o processo de instalação do SGBD. Se essa senha não foi definida durante a instalação, é necessário que o administrador do sistema operacional hospedeiro o faça em seguida. Para isso, considerando um SO do padrão POSIX, devem ser executados alguns comandos na linha de comando do SO hospedeiro. São os seguintes:

usuario@sohost:~$ sudo su – postgres -c 'psql' [sudo] password for usuario: psql (9.x) Type “help”for help.	(1)


postgres=# \password Enter new password: Enter it again:	(2)


postgres=# \quit	(3)

O comando (1) permite que o administrador assuma a identidade do usuário “postgresql”, ao mesmo tempo em que executa, como este usuário, o cliente de banco de dados psql na base padrão. Dependendo da configuração do sistema operacional, será exigida do usuário administrador a entrada de sua senha de usuário para a execução desse comando.
O comando (2) indica que o usuário “postgres” pretende definir ou modificar sua senha. A senha deve ser definida por meio de sua inserção seguida da tecla enter e a repetição do procedimento. Após, basta executar o comando (3) para sair do sistema.

Liberação para acesso em rede

Por padrão, a instalação do PostgreSQL não permite que clientes de outros computadores da mesma rede possam acessar o banco de dados. Em razão disso, é necessário modificar dois arquivos de configuração do PostgreSQL para permitir tais acessos.
O primeiro arquivo a ser modificado é o arquivo postgresql.conf, localizado na pasta main da tablespace do sistema (/etc/postgresql/9.x, /var/local/postgresql/9.x, etc.). Nesse arquivo, é necessário editar a linha com o parâmetro listen_addresses, que originalmente contém “localhost”. Deve ser substituído o conteúdo “localhost” pelos números IPs, separados por vírgulas, dos equipamentos autorizados a acessar o banco de dados. Embora não seja recomendável, caso a estrutura e a política de segurança do tribunal permita, a lista de IPs, pode ser substituída por asterisco (*), caso em que o servidor de banco de dados poderá receber conexões de qualquer origem.
No mesmo arquivo, é recomendável ativar o parâmetro password_encryption, atribuindo a ele o valor “on”.
Finalmente, é necessário editar o arquivo pg_hba.conf, localizado na mesma pasta. Esse arquivo tem uma longa documentação explicativa. Em síntese, o objetivo desse arquivo é fazer o ajuste fino a respeito de como e o que pode ser acessado remotamente. Para uma configuração simples é necessário acrescentar, após a última linha, linhas contendo a configuração de acesso às bases do PJe. No caso de criação dos bancos de dados “pje_descanso” e “pje_descanso_bin” com o controle pelo usuário padrão “postgres” e acesso à uma subrede 10.0.0.*, as linhas acrescentadas poderiam ser:

host		pje_descanso		postgres	10.0.0.0/24		md5
host		pje_descanso_bin		postgres	10.0.0.0/24		md5

Essas duas linhas significam que o usuário “postgres” poderá acessar os bancos de dados “pje_descanso” e “pje_descanso_bin” se seu acesso for realizado com o uso de senha encriptada a partir de máquinas cujo IP estejam entre 10.0.0.1 e 10.0.0.255.
Para mais informações a respeito dessas configurações de acesso, consulte http://www.postgresql.org/docs/9.1/interactive/client-authentication.html.

Configuração específica

O sistema PJe utiliza dois bancos de dados para suas operações usuais. Isso por vezes demanda a preparação de mais de uma transação em um mesmo momento. Para suportar esse tipo de operação, é necessário modificar uma configuração específica do SGBD. Essa configuração é feita no mesmo arquivo postgresql.conf anteriormente mencionado. Após abri-lo, deve ser modificado o parâmetro max_prepared_transactions para que esse tipo de operação seja ativado, configurando-se o valor para, no mínimo, 10, conforme a capacidade do equipamento servidor disponibilizado para o SGDB.
Favor verificar a documentação do SGBD a respeito.

Carga inicial dos dados do PJe no SGBD

O sistema PJe – Processo Judicial Eletrônico foi concebido para funcionamento em cenários muito diversos de instalações, especialmente considerando a multiplicidade de segmentos do Judiciário e suas especificidades. Em razão disso, ele encerra uma quantidade significativa de configurações que, feitas manualmente, tornaria difícil, senão impossível chegar a um cenário utilizável em um prazo razoável. Em razão disso, são disponibilizadas, com a versão binária do sistema, cópias de bases de dados com uma configuração mínima a partir da qual os tribunais podem começar a configurar o sistema conforme suas características próprias. As cópias são disponibilizadas, ordinariamente, em formato SQL, que permitem o uso entre versões diferentes do PostgreSQL. Eventualmente, podem ser disponibilizadas em formato binário.

Criação dos bancos de dados

Os bancos de dados do PJe devem ser criados utilizando algumas características essenciais, quais sejam:

encoding: LATIN1
template: template0
collation: C
character type: C

A criação do banco pode ser feita diretamente do sistema operacional utilizando o comando createdb. Eis um exemplo:

usuario@sohost:~$ createdb -E LATIN1 –-lc-collate=C –lc-ctype=C -O postgres -T template0 -h 123.45.67.8 -W -U postgres pje_descanso

ou

   CREATE DATABASE pje
   WITH 
   OWNER = postgres
   ENCODING = 'LATIN1'
   LC_COLLATE = 'C'
   LC_CTYPE = 'C'
   TEMPLATE=template0
   CONNECTION LIMIT = -1;

O comando acima criou um banco de dados chamado “pje_descanso” pertencente ao usuário “postgre” no banco de dados localizado na máquina “123.45.67.8” com as características essenciais do PJe. O mesmo deveria ser feito para o banco binário, que deve, por óbvio, ter outro nome, por exemplo: “pje_descanso_bin”.

Carga de banco de dados em script SQL

A carga do banco de dados a partir de scripts SQL deve também ser feita por meio da linha de comando, agora utilizando o cliente de terminal do PostgreSQL, psql:

psql -U USUARIO -h SERVIDOR -d DATABASE -W < ARQUIVO, onde:

USUARIO - usuário de banco de dados com acesso a base criada
SERVIDOR - IP ou DNS do servidor que responde ao PostgreSQL
DATABASE - banco de dados criado para restauração do dump
ARQUIVO - caminho completo ou relativo para o arquivo SQL que contém a restauração

usuario@sohost:~$ psql -U postgres -h 123.45.67.8 -d pje_descanso –W < ./ pje_descanso_1.4.3_limpa.sql

O exemplo acima carrega o banco “pje_descanso” com os dados do backup SQL contido no arquivo “pje_descanso_1.4.3_limpa.sql”. O mesmo deve ser feito com o backup SQL do banco binário.
Após a carga de dados, é necessário executar o comando SQL de INSERT listado abaixo na base “pje_descanso” para definição do CPF e nome do usuário administrador do sistema. Isso é necessário para que seja possível ao admin cadastrar os usuários da aplicação a partir do serviço de consulta de pessoas físicas e jurídicas da Receita Federal. Atente para a necessidade de substituir os parâmetros <CPF> e <NOME> pelo número do CPF (com máscara) e nome do detentor do documento.

INSERT INTO client.tb_pess_doc_identificacao
(  
  id_pessoa_doc_identificacao, 
  cd_tp_documento_identificacao, 
  nr_documento_identificacao, 
  dt_expedicao, 
  ds_nome_pessoa, 
  in_usado_falsamente, 
  in_ativo, 
  ds_orgao_expedidor, 
  id_estado_expedidor, 
  id_pessoa, 
  in_principal, 
  dt_usado_falsamente, 
  id_pais, 
  id_usuario_cadastrador
)
VALUES 
(
  nextval('client.sq_tb_pess_doc_identificacao'), 
  'CPF', 
  '<CPF>', 
  NULL, 
  '<NOME>', 
  'FALSE', 
  'TRUE',
  'Secretaria da Receita Federal', 
  NULL, 
  1, 
  'TRUE',
  NULL, 
  NULL, 
  NULL
);

Replicação e Cluster

Sobre a implementação de replicação no PostgreSQL do banco do PJe, acesse Replicação no PostgreSQL.

Para a implementação de Clusters no PostgreSQL, acesse Criar um Cluster no PostgreSQL.

Instalação e configuração do servidor de aplicação

O sistema PJe – Processo Judicial Eletrônico é uma aplicação Web escrita na linguagem de programação Java. Assim sendo, ela é executada em um servidor de aplicação específico, o JBoss Application Server 5.1.0. Para garantir o correto funcionamento do sistema, certifique-se que os passos abaixo foram executados com sucesso.

Uma das premissas do sistema é que esteja instalada no sistema operacional uma máquina virtual Java JDK com versão 1.6.0_45. Recomendamos o uso do java JDK 1.7.0_51, porém para este JDK funcionar com o JBoss Server 5.1.0, deve ser aplicado um patch que corrige um classloader no bootstrap.xml ou usar a versão EAP 5.2.0. Atualmente o CNJ utiliza o JBOSS EAP 5.2.0 junto com o Java SDK 1.7.0_51. Para verificar se o sistema operacional possui uma versão JDK devidamente instalada, execute o comando a seguir.
```
usuario@sohost:~$ java -version
```
Baixe e instale o JBoss Application Server 5.1.0 para JDK 1.6, para isso siga os passos seguintes:
1. Baixe o JBoss disponível na URL http://downloads.sourceforge.net/project/jboss/JBoss/JBoss-5.1.0.GA/jboss-5.1.0.GA-jdk6.zip?r=&ts=1386707755&use_mirror=ufpr. Certifique-se que o pacote baixado é o jboss-5.1.0.GA-jdk6.zip e não o pacote jboss-5.1.0.GA.zip, pois a versão para JDK 1.6 já vem com as bibliotecas do Jboss que implementam o padrão jaxws instaladas. Essas bibliotecas são condição para o perfeito funcionamento das comunicações via web service.
2. Descompacte o arquivo jboss-5.1.0.GA-jdk6.zip para o local desejado na estrutura de arquivos (Ex: /opt/jboss-5.1.0.GA). Deve-se atentar que alguns sistemas operacionais permitem a instalação desses servidores por meio de pacotes de instalação que já configuram a inicialização e parada do servidor.
Reconfigure os limites de memória disponibilizados para o servidor de aplicação. Isso pode ser feito no script de inicialização do servidor, pela linha de comando ou diretamente no arquivo run.conf, localizado na pasta descompactada JBOSS_DIR/bin. Em quaisquer dos cenários, o que se faz é modificar a variável de ambiente JAVA_OPTS para disponibilizar mais memória para a aplicação Java. Essencialmente, devem ser aumentadas a memória total de pilha – parâmetro -Xmx – e o tamanho máximo da memória permanente – parâmetro -XX:MaxPermSize. O tamanho máximo disponível da memória total de pilha é severamente limitado pelo sistema operacional quando ele é de 32 bits, motivo por que é recomendável utilizar sistemas operacionais de 64 bits, caso em que a barreira de 3GB de memória disponível é facilmente superada. O ideal é dispor do máximo possível da memória disponível no servidor de aplicação para a máquina virtual Java, assegurando um mínimo de 1024MB. Para a memória permanente (MaxPermSize), recomenda-se um mínimo de 256MB. Desse modo, os parâmetros acima devem ser modificados no arquivo JBOSS_DIR/bin/run.conf ou nas variáveis de ambiente ou script para o seguinte:
```
JAVA_OPTS=”$JAVA_OPTS –Xms1024m -Xmx1024m -XX:MaxPermSize=256m”
```
Modifique o arquivo JBOSS_DIR/server/default/deployers/seam.deployer/META-INF/seam-deployers-jboss-beans.xml, apagando ou comentando a linha que define o bean SeamMTMatcher, conforme recomendado em registro de falha específico [1]. Note-se que a afirmação retro parte da premissa de que a configuração do servidor escolhida para execução do PJe é a default, devendo esse nome ser substituído pelo do servidor efetivamente escolhido.
Modifique o arquivo JBOSS_DIR/server/default/deployers/jbossws.deployer/META-INF/standard-jaxws-client-config.xml, alterando o valor da propriedade chunksize de “2048” para “0”. Isso é necessário para permitir consultas a webservices que exigem autenticação via SOAP Header, caso do serviço de consultas a advogados da OAB.
Acrescente a biblioteca JAR do driver JDBC do PostgreSQL à pasta JBOSS_DIR/server/default/lib.
Para servidores de aplicação configurados em rede interna e disponibilizados na Internet através de proxy, o arquivo JBOSS_DIR/server/default/deployers/jbossws.deployer/META-INF/jboss-beans.xml deve ser alterado conforme a seguir:
- comentar a linha "property name="webServiceHost..."
- alterar o valor da propriedade "modifySOAPAddress" para "false"
Abaixo, trecho do arquivo conforme alteração:
```

<property name="modifySOAPAddress">false</property>
```
Essa alteração corrige a informação exibida na lista de serviços do PJe disponibilizada através de <urlpje>/intercomunicacao?wsdl

Para o correto funcionamento dos webservices é necessário atualizar as bibliotecas jaxb do JBoss para a versão 2.2.7. Para isso siga os passos abaixo:

Baixe o JAXWS 2.2.7 da URL https://jax-ws.java.net/2.2.7/JAXWS2.2.7-20120813.zip;
Copie e substitua os arquivos JAXWS2.2.7-20120813.zip/jaxws-ri/lib/jaxb-impl.jar e JAXWS2.2.7-20120813.zip/jaxws-ri/lib/jaxb-xjc.jar para a pasta JBOSS_DIR/lib;
Copie e substitua o aquivo JAXWS2.2.7-20120813.zip/jaxws-ri/lib/jaxb-api.jar a para a pasta JBOSS_DIR/lib/endorsed.

Caso a biblioteca em questão não esteja devidamente instalada, na fase de deploy do war acontecerá o seguinte erro:

       Caused by: java.lang.IllegalStateException: Cannot build JAXB context
       at org.jboss.ws.metadata.builder.jaxws.JAXWSMetaDataBuilder.createJAXBContext(JAXWSMetaDataBuilder.java:994)
       at org.jboss.ws.metadata.builder.jaxws.JAXWSWebServiceMetaDataBuilder.buildWebServiceMetaData(JAXWSWebServiceMetaDataBuilder.java:163)
       at org.jboss.ws.metadata.builder.jaxws.JAXWSServerMetaDataBuilder.setupProviderOrWebService(JAXWSServerMetaDataBuilder.java:52)
       at org.jboss.ws.metadata.builder.jaxws.JAXWSMetaDataBuilderJSE.buildMetaData(JAXWSMetaDataBuilderJSE.java:62)
       at org.jboss.wsf.stack.jbws.UnifiedMetaDataDeploymentAspect.start(UnifiedMetaDataDeploymentAspect.java:64)
       at org.jboss.wsf.framework.deployment.DeploymentAspectManagerImpl.deploy(DeploymentAspectManagerImpl.java:129)
       at org.jboss.wsf.container.jboss50.deployer.ArchiveDeployerHook.deploy(ArchiveDeployerHook.java:76)
       at org.jboss.wsf.container.jboss50.deployer.AbstractWebServiceDeployer.internalDeploy(AbstractWebServiceDeployer.java:60)
       at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55)
       at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179)
       ... 31 more

Obs.: Na instalação padrão do red-hat enterprise linux 6.5, os arquivos .jar dos diretórios JBOSS_DIR/lib e JBOSS_DIR/lib/endorsed são links simbólicos. Assim, convém alterar os arquivos apontados por estes links. Desta forma, bastar copiar os arquivos acima para o diretório /usr/share/java-signed/glassfish-jaxb.

Instale a biblioteca Apache Portable Runtime (libtcnative), que faz com que algumas chamadas Java sejam delegadas para bibliotecas nativas do sistema operacional, melhorando o desempenho do sistema em produção. Para isso siga os passoa abaixo:
1. Baixe o JBOSS NATIVE 2.0.10 disponível na URL http://downloads.jboss.org/jbossnative//2.0.10.GA/jboss-native-2.0.10-linux2-x64-ssl.tar.gz;
2. Copie o arquivo jboss-native-2.0.10-linux2-x64-ssl.tar.gz/bin/native/openssl para a pasta JBOSS_DIR/bin/;
3. Copie os arquivos jboss-native-2.0.10-linux2-x64-ssl.tar.gz/bin/native/* para a pasta JBOSS_DIR/bin/META-INF/lib/linux2/x64/.

Observação: Para que o APR seja inicializado com sucesso pelo Eclipse é necessário colocar a linha abaixo no início dos parâmetros da VM do launch do servidor. -Djava.net.preferIPv4Stack=true -Djava.library.path=JBOSS_DIR/bin/META-INF/lib/linux2/x64

Para habilitar o SSL do JBoss altere o arquivo JBOSS_DIR/server/default/deploy/jbossweb.sar/server.xml, descomentando e alterando o connector SSL para ficar conforme exemplo abaixo.
A configuração a seguir refere-se ao cenário onde o JBoss faz o papel de Container Web e Servidor de Aplicações, muitos tribunais usam o Apache como Container Web, neste caso a habilitação do SSL é feita no próprio Apache.

<Connector 
    protocol="org.apache.coyote.http11.Http11Protocol" 
    SSLEnabled="true" 
    port="8443" 
    address="${jboss.bind.address}"
    scheme="https" 
    secure="true" 
    clientAuth="want" 
    keystoreFile="{CAMINHO DO KEYSTORE}"
    keystorePass="{SENHA DO KEYSTORE}" 
    truststoreFile="{CAMINHO DO TRUSTSTORE}" 
    truststorePass="{SENHA DO TRUSTSTORE}"
    sslProtocol = "TLS" />

Exemplo:

<Connector 
    protocol="org.apache.coyote.http11.Http11Protocol" 
    SSLEnabled="true" 
    port="8443" 
    address="${jboss.bind.address}"
    scheme="https" 
    secure="true" 
    clientAuth="want" 
    keystoreFile="/desenvolvimento/documento/certificado-digital/pje-documentacao/cnj-jboss.keystore"
    keystorePass="123456" 
    truststoreFile="/desenvolvimento/documento/certificado-digital/pje-documentacao/cnj-jboss.truststore" 
    truststorePass="123456"
    sslProtocol = "TLS" />

Segue a rotina para geração de keystore e truststore de exemplo.

usuario@sohost:~$ keytool -genkey -alias jbosskey -keyalg RSA -keystore cnj-jboss.keystore -storepass 123456 -keypass 123456 -dname "CN=jboss, OU=PJe, O=Conselho Nacional de Justica, L=Brasilia, ST=DF, C=BR"
usuario@sohost:~$ keytool -export -alias jbosskey -keystore cnj-jboss.keystore -storepass 123456 -file cnj-jboss.cer
usuario@sohost:~$ keytool -genkey -alias clientekey  -keyalg RSA -keystore cnj-cliente.keystore -storepass 123456 -keypass 123456 -dname "CN=cliente, OU=PJe, O=Conselho Nacional de Justica, L=Brasilia, S=DF, C=BR" 
usuario@sohost:~$ keytool -export -alias clientekey -keystore cnj-cliente.keystore -storepass 123456 -file cnj-cliente.cer
usuario@sohost:~$ keytool -import -v -keystore cnj-cliente.truststore  -storepass 123456 -file cnj-jboss.cer -alias jbosskey
usuario@sohost:~$ keytool -import -v -keystore cnj-jboss.truststore  -storepass 123456 -file cnj-cliente.cer -alias clientekey

O framework de chamada de WebServices do JBoss 5.1.0 GA deve ser atualizado para a versão jbossws-native-3.4.0. Para isso siga os passoa abaixo:
- ATENÇÃO: Antes de executar os passos abaixo faça um backup do Servidor de Aplicações;
- Baixe o arquivo jbossws-native-3.4.0.GA do endereço eletrônico http://download.jboss.org/jbossws/jbossws-native-3.4.0.GA.zip. Esta é a versão do JBossWS mais recente suportada pelo JBoss 5.1.0, conforme informado no link https://developer.jboss.org/wiki/JBossWS-SupportedTargetContainers;
- Descompacte o arquivo jbossws-native-3.4.0.GA.zip em uma pasta qualquer;
- Copie o arquivo ant.properties.exemples para ant.properties;
- Altere as propriedades 'jboss510.home' e 'jbossws.integration.target' do arquivo ant.properties, conforme exemplo abaixo:
```
jboss501.home=/
jboss510.home=/desenvolvimento/ferramenta/jboss-5.1.0.GA
jboss600.home=/
jboss601.home=/

jbossws.integration.target=jboss510
```
- Execute o ant conforme exemplo abaixo:
```
ant deploy-jboss510
```

Observações gerais:

Deve-se lembrar que, pretendendo-se disponibilizar o sistema para uso em produção, o servidor de aplicação deve ser configurado para responder pela porta 80 com reencaminhamento para a porta segura 443, com disponibilização da aplicação apenas por meio do protocolo HTTPS.
Certifique-se que o LOCALE do servidor de aplicações esteja corretamente configurado para PT_BR. Em servidores Linux RedHat, essa configuração é feita no atributo LANG do arquivo /etc/sysconfig/i18n.

LANG=”pt_BR.UTF-8”

Instalação e configuração do servidor de aplicação WILDFLY 9.0.2 para o Pje 2.0

Instale a versão 9.0.2 do wildfly. Normalmente, o diretório padrão para instalação deste container é /opt/wildfly no linux. É altamente recomendável que se crie os serviços para iniciar e parar o wildfly, quer seja com init.d ou systemctl. Para este tutorial será seguido o systemctl por ser a versão mais recente. As distribuições de linux deixarão de apoiar o init.d com o tempo.

A maioria das configurações do wildfly estão no arquivo standalone.xml que fica no diretório <WILDFLY_HOME>/standalone/configuration/standalone.xml Devemos usar o perfil completo do wildfly que está no arquivo standalone-full.xml. Em nossa instalação apenas copiamos o arquivo standalone-full.xml para standalone.xml

Por padrão usaremos <WILDFLY_HOME> apontando para /opt/wildfly

Recursos de VM (Virtual Machines)

Linux (qualquer versão)
Wildfly 9.0.2
Memória: 8GB (mínimo)
Processadores (vCores): 4
Java 1.8 (qualquer pacote – openjdk ou oracle oficial)
Partição /tmp com 30 GB
Partição /var separada da partição raiz – ‘/’ - para o log – com a finalidade de quando e se houver 100 de uso da partição não cause indisponibilidade do sevidor.

Configurando o Jboss EAP 7 ou Wildfly 9.0.2 usando jboss-cli

Com o intuito de facilitar a configuração do servidor wildfly ou Jboss EAP a partir do zero para o PJe 2.0, copie o arquivo config_pje_wildfly_jboss.zip para um diretório, descompacte-o e execute o interface da linha de comando do jboss/wildfly (jboss-cli.sh) a partir do diretório descompactado criado. O motivo para executar dentro do diretório criado se deve ao fato que dentro do arquivo compactado existem 2(duas) adições ao subsystem module do wildfly/jboss a saber: 1) o driver jdbc do postgres e 2) mojarra 1.2. Desta forma, esses dois arquivos devem estar no mesmo diretório do arquivo pje-wildfly.cli!

Os servidores de aplicação não devem ter nenhuma alteração.
Sempre usar a configuração full do wildfly/jboss

Execute o comando:

<JBOSS_HOME>/bin/jboss-cli.bat -c --file=pje-wildfly.cli

Se o comando executou com sucesso, deverá aparecer a seguinte mensagem do jboss-cli:

The batch executed successfully
process-state: reload-required

Reinicialize o wildfly/jboss.

Apenas mais dois pontos para observar:

Configurar a memória da VM do java para o servidor wildfly/jboss pois a configuração padrão é insuficiente para o PJe
Alterar manualmente o datasource para o banco de dados desejado.

Abaixo está o passo a passo do que foi executado.

Instalação driver jdbc do Postgresql

Até o presente momento, não encontramos uma forma automatizada de fazer um deploy de drivers jdbc no wildfly, assim, esse procedimento será manual. Não existem mais diretórios lib no wildfly. Todos os arquivos jar são, de certa forma, implantados no module subsystem. O padrão usado no PJe para o nome do módulo do jdbc do postgres será org.postgresql. Também não há contra-indicação quanto a uma versão específica do jdbc do postgres. Nós usamos sempre a mais atual possível. Já testamos versões mais recentes do jdbc conectando em versões mais antigas do servidor postgres com sucesso.

Criar o diretório para instalação do jar do jdbc:

mkdir -p <WILDFLY_HOME>/modules/system/layers/base/org/postgresql/main

No diretório criado - <WILDFLY_HOME>/modules/system/layers/base/org/postgresql/main - copiar o driver jdbc e criar um arquivo module.xml, conforme exemplo abaixo:

<?xml version="1.0" encoding="UTF-8"?>

<module xmlns="urn:jboss:module:1.0" name="org.postgresql">
  <resources>
    <resource-root path="postgresql-9.4.1207.jar"/>
        <!-- Insert resources here -->
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>

Portanto, deveremos ter 2(dois) arquivos neste diretório. *Algumas considerações importantes*: 1) O nome do arquivo jdbc deve ser igual ao indicado no parâmetro path do resource-root, 2) Evitar espaços em branco no inicio do arquivo module.xml, 3) O nome do módulo name="org.postgresql deve seguir a estrutura do diretório <WILDFLY_HOME>/modules/system/layers/base/org/postgresql/main e será referenciado no arquivo standalone.xml

-rw-r--r--. 1 wildfly   1392 Jun 16 18:12 module.xml
-rw-r--r--. 1 wildfly 607093 Jun 16 18:12 postgresql-9.4.1207.jar

chown -R wildfly:wildfly <WILDFLY_HOME>/modules/system/layers/base/org/postgresql

Instalação do mojarra 1.2

O PJE ainda necessita de uma versão específica do JSF - a versão 1.2 - que não está mais disponível na instalação padrão do Wildfly 9. Desta forma temos que instalar manualmente. Para fazer isso basta realizar o deploy deste pacote mojarra-1.2 utilizando o console do wildfly. Uma vez que o wildfly esteja ativo, no diretório bin da instalação do wildfly encontra-se o executável jboss-cli.sh.

::/opt/wildfly/bin/jboss-cli.sh

Será apresentado a seguinte informação:

You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
[disconnected /]

Digite o comando 'connect'

[disconnected /] connect

Se tudo ocorrer certo, o prompt será alterado para:

[standalone@localhost:9990 /]

digite, deploy <PATH_TO_CLI>/install-mojarra-1.2_15.cli

[standalone@localhost:9990 /] deploy install-mojarra-1.2_15.cli

Nenhuma informação será mostrada neste momento. Saia da console do wildfly com o comando exit e restarte o servidor.

[standalone@localhost:9990 /] exit

Veja o link (aqui) para informações de como criar um serviço para o wildfly. No debian, trocar o comando: chkconfig --add <servico>, por update-rc.d <servico> defaults

# systemctl restart wildfly-standalone  #Obs.: o nome do serviço pode ser diferente.

Vamos conferir novamente na console se o deploy foi bem sucedido. O nome mojarra-1.2_15 deve aparecer na lista de implementações ativas.

[standalone@localhost:9990 /]  /subsystem=jsf/:list-active-jsf-impls
{
    "outcome" => "success",
    "result" => [
        "mojarra-1.2_15",
        "main"
    ]
}

Alterações no arquivo standalone.xml

Habilitar o wildfly para aceitar conexões externas (equivalente ao -b 0.0.0.0 do jboss 5.1). Incluir entre o final da seção </extensions> e o início da seção <management> - linhas 33 a 36 aproximadamente.

    <system-properties>
        <property name="jboss.bind.address" value="0.0.0.0"/>
        <property name="jboss.bind.address.management" value="0.0.0.0"/>
    </system-properties>

Alterar o subsystem weld para incluir a cláusula require-bean-descriptor.

Antes:

<subsystem xmlns="urn:jboss:domain:weld:2.0"/>

Depois:

<subsystem xmlns="urn:jboss:domain:weld:2.0" require-bean-descriptor="true"/>

Criação das entradas dos drivers jdbc para o jboss Dentro do arquivo standalone.xml, existe uma seção chamada <drivers>, que fica dentro da seção <datasources>, que pertence ao subsystem <subsystem xmlns="urn:jboss:domain:datasources:3.0"> e deve ser configurada em dois passos. O primeiro é a configuração do driver e o segundo, o datasource

<driver name="postgres_XA" module="org.postgresql">
    <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
</driver>
<driver name="postgres" module="org.postgresql">
    <datasource-class>org.postgresql.Driver</datasource-class>
</driver>

Importante notar que o nome do módulo module="org.postgresql" deve ser rigorosamente o nome criado no arquivo module.xml quando implantado o driver jdbc do postgres. Segue um exemplo como ficaria a seção drivers completa:

<drivers>
    <driver name="h2" module="com.h2database.h2">
        <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
    </driver>
    <driver name="postgres_XA" module="org.postgresql">
        <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
    </driver>
    <driver name="postgres" module="org.postgresql">
        <datasource-class>org.postgresql.Driver</datasource-class>
    </driver>
</drivers>

Para testar se tudo está correto, ao iniciar o wildfly, no arquivo de log, deverão aparecer as entradas para os dois drivers criados no arquivo standalone.xml:

INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0005: Deploying non-JDBC-compliant driver class org.postgresql.Driver (version 9.4)
INFO  [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 36) WFLYJCA0005: Deploying non-JDBC-compliant driver class org.postgresql.Driver (version 9.4)
INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-8) WFLYJCA0018: Started Driver service with driver-name = postgres
INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-2) WFLYJCA0018: Started Driver service with driver-name = postgres_XA

Criação dos Datasources

Logo acima da seção <drivers> está a seção <datasources>. Assim como o pje da família 1.x, poderemos usar até 3 datasources a saber: pjeDS, pjeLogDS e pjeBinDS, sendo este último opcional para quem optar pelo jcr-storage. Atualmente o CNJ recomenda a utilização do jcr-storage. A criação do datasource aqui não diferencia muito do jboss 5.1, bastando acrescentar as entradas. Os valores aqui não são valores de referencia, são apenas exemplos. Cada instalação deve verificar os valores ideias do pool de conexões podendo ser maior conforme a necessidade.

<xa-datasource jndi-name="java:/pjeDS" pool-name="pje_pool" enabled="true" use-java-context="true" use-ccm="true">
    <xa-datasource-property name="DatabaseName">
        pje2
    </xa-datasource-property>
    <xa-datasource-property name="ServerName">
        10.0.0.1
    </xa-datasource-property>
    <xa-datasource-property name="prepareThreshold">0</xa-datasource-property>
    <statement>
        <prepared-statements-cache-size>0</prepared-statements-cache-size>
        <share-prepared-statements>false</share-prepared-statements>
    </statement>
    <driver>postgres_XA</driver>
    <new-connection-sql>set search_path=client,core,jt,criminal,public,acl</new-connection-sql>
    <xa-pool>
        <min-pool-size>1</min-pool-size>
        <max-pool-size>10</max-pool-size>
        <prefill>true</prefill>
    </xa-pool>
    <security>
        <user-name>USER</user-name>
        <password>PASSWORD</password>
    </security>
    <validation>
        <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/>
        <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/>
    </validation>
</xa-datasource>
<xa-datasource jndi-name="java:/pjeLogDS" pool-name="pje_log_pool" enabled="true" use-java-context="true" use-ccm="true">
    <xa-datasource-property name="DatabaseName">
        pje_log
    </xa-datasource-property>
    <xa-datasource-property name="ServerName">
        10.0.0.1
    </xa-datasource-property>
    <xa-datasource-property name="prepareThreshold">0</xa-datasource-property>
    <statement>
        <prepared-statement-cache-size>0</prepared-statement-cache-size>
        <share-prepared-statements>false</share-prepared-statements>
    </statement>
    <driver>postgres_XA</driver>
    <xa-pool>
        <min-pool-size>1</min-pool-size>
        <max-pool-size>10</max-pool-size>
       <prefill>true</prefill>
    </xa-pool>
    <security>
        <user-name>USER</user-name>
        <password>PASSWD</password>
    </security>
    <validation>
        <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/>
        <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/>
    </validation>
</xa-datasource>

Como dito antes, opcionalmente pode-se criar o datasource para o bin

<xa-datasource jndi-name="java:/pjeBinDS" pool-name="pje_bin_pool" enabled="true" use-java-context="true" use-ccm="true">
    <xa-datasource-property name="DatabaseName">
        pje_bin
    </xa-datasource-property>
    <xa-datasource-property name="ServerName">
        10.0.0.1
    </xa-datasource-property>
    <xa-datasource-property name="prepareThreshold">0</xa-datasource-property>
    <statement>
        <prepared-statement-cache-size>0</prepared-statement-cache-size>
        <share-prepared-statements>false</share-prepared-statements>
    </statement>
    <driver>postgres_XA</driver>
    <xa-pool>
        <min-pool-size>1</min-pool-size>
        <max-pool-size>10</max-pool-size>
       <prefill>true</prefill>
    </xa-pool>
    <security>
        <user-name>USER</user-name>
        <password>PASSWD</password>
    </security>
    <validation>
        <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/>
        <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/>
    </validation>
</xa-datasource>

Um detalhe a ser acrescido é a possibilidade de usar o pgBouncer e, para isso, foram adicionados os seguintes parâmetros de configuração:

    <xa-datasource-property name="prepareThreshold">0</xa-datasource-property>
    <statement>
        <prepared-statement-cache-size>0</prepared-statement-cache-size>
        <share-prepared-statements>false</share-prepared-statements>
    </statement>

Estes parâmetros são opcionais, mas recomendados.

Ao inciar o wildfly, se tudo estiver correto, serão mostradas as seguintes linhas no log do servidor

INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-7) WFLYJCA0001: Bound data source [java:/pjeLogDS]
INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-5) WFLYJCA0001: Bound data source [java:/pjeDS]

Caso contrário, um erro será gerado.

MNI e Proxy Apache ou outros

Caso o servidor do wildfly esteja atrás de um proxy (Apache ou outros), talvez exista a necessidade de alterar o endereço de envio do <soap:address> do MNI, segue um exemplo:

    <subsystem xmlns="urn:jboss:domain:webservices:2.0">
        <modify-wsdl-address>true</modify-wsdl-address>

        <wsdl-host>www.cnj.jus.br</wsdl-host>
        <wsdl-port>80</wsdl-port>
        <wsdl-secure-port>443</wsdl-secure-port>
        <wsdl-uri-scheme>https</wsdl-uri-scheme>

        <endpoint-config name="Standard-Endpoint-Config"/>
        <endpoint-config name="Recording-Endpoint-Config">
            <pre-handler-chain name="recording-handlers" protocol-bindings="##SOAP11_HTTP ##SOAP11_HTTP_MTOM ##SOAP12_HTTP ##SOAP12_HTTP_MTOM">
                <handler name="RecordingHandler" class="org.jboss.ws.common.invocation.RecordingServerHandler"/>
            </pre-handler-chain>
        </endpoint-config>
        <client-config name="Standard-Client-Config"/>
    </subsystem>

Isto fará com que o endereço de retorno do WSDL seja reescrito e não seja enviado o endereço interno do servidor de aplicação

    <soap:address location="https://www.cnj.jus.br/pjecnj/intercomunicacao"/>

O próximo passo é apenas realizar a implantação (deploy) do pje.

Configuração do número máximo de arquivos abertos - unity - systemd

Especial atenção ao número máximo de arquivos que o usuário wildfly pode abrir. Para isso temos que configurar a unit do systemd para não limitar o usuário wildfly quando ao número máximo de arquivos abertos.

Editar a unity do wildfly - Neste exemplo usaremos a unit exemplo /etc/systemd/system/wildfly-standalone.service. Deveremos incluir a diretiva LimitNOFILE=infinity

[Unit]
Description=WildFly application server
After=network.target

[Service]
Type=simple
User=wildfly
Group=wildfly
ExecStart=/opt/wildfly/bin/standalone.sh
TimeoutSec=3min
LimitNOFILE=infinity

[Install]
Alias=wildfly.service
WantedBy=multi-user.target

Recarregar as definições do systemd

systemctl daemon-reload

Reinicar o wildfly

Configuração de parâmetros para modo de testes/homologação

Por padrão a aplicação do PJe (a partir da versão 2.0.0.1) sobe em modo de produção ativa. Caso o ambiente configurado seja em contexto de testes ou homologação, deve-se adicionar o parâmetro "-Dpje.producao=false" no arquivo run.conf do wildfly.

Comentários e críticas sempre serão bem-vindos para melhorar este tutorial de configuração.

Instalação do PJe no servidor de aplicação

A instalação do PJe no servidor de aplicação é feita em duas etapas: a configuração dos bancos de dados no servidor de aplicação e a efetiva implantação do sistema.

Configuração dos esquemas

Na utilização de postgres, para que a manipulação do banco de dados do PJe possa ser feita sem utilização dos esquemas na referência às tabelas, é necessário incluir no parâmetro search_path os esquemas existentes no banco.

O search_path é um parâmetro que está presente no arquivo "postgresql.conf". Por padrão, a linha estará assim:

#search_path = '"$user",public' # schema names

Deverá ficar assim:

search_path = '"$user",public,client,core,jt,criminal,acl' # schema names

Se, por ventura em um outro momento, for criado um novo esquema no banco, deverá ser incluído no search_path. É importante retirar o símbolo "#" da frente do nome search_path, caso contrário, as alterações não serão reconhecidas pelo servidor de Banco de Dados.

Após as alterações é necessário rodar este comando com o usuário "postgres" na base "postgres":

SELECT pg_reload_conf();

O comando acima deverá ser executado uma vez em cada servidor que foi alterado. Por exemplo: suponhamos que há um servidor "172.172.0.170" e nesse servidor há dez bases de dados. É suficiente rodar o comando pg_reload apenas uma vez na base "postgres" desse servidor. As configurações já servirão para todas as outras bases do servidor. Se por ventura for criada uma nova base depois, a mesma já reconhecerá as configurações também. Caso tenha um outro servidor de banco de dados, o mesmo procedimento deverá ser feito para ele também.

Obs: Não será necessário reiniciar o servidor de Banco de Dados, pois esse parâmetro é dinâmico e a execução do pg_reload é suficiente para o servidor reconhecer as novas configurações.

Configuração dos mocks

Para uso em ambiente de teste, o PJe permite a utilização de simulação no acesso a serviços externos, em particular à validação de CPF e CNPJ na Receita Federal do Brasil e à validação da OAB no Conselho Federal da OAB. Para utilizar os simuladores, deve-se configurar, no arquivo components.xml, disponível no pacote war da aplicação, os seguintes parâmetros como "true".

<component name="consultaClienteReceitaPFCNJ" class="br.jus.cnj.pje.nucleo.service.ConsultaClienteReceitaPFMock" 
    precedence="100" installed="true"/>
<component name="consultaClienteReceitaPJCNJ" class="br.jus.cnj.pje.nucleo.service.ConsultaClienteReceitaPJMock" 
    precedence="100" installed="true"/>
<component name="consultaClienteOAB" class="br.jus.cnj.pje.nucleo.service.ConsultaClienteOABMock" precedence="100" installed="true"/>

Configuração de parâmetros para upload de arquivos

A partir da versão 1.6.0, nas funcionalidades de protocolo inicial, de anexação de documentos nos detalhes do processo e na resposta de expediente, o PJE permite que se faça upload de documentos múltiplos anexados ao documento principal. A configuração padrão de instalação do PJe utiliza os seguintes parâmetros como base:

application/pdf:1572864 
audio/mpeg:5242880
audio/ogg:5242880
audio/vorbis:5242880 
image/png:1572864
video/ogg:10485760
video/mp4:10485760

Ou seja, permite os mimetypes listados acima com os respectivos tamanhos em bytes.

Pode-se alterar esse parâmetros acrescentando uma linha no arquivo components.xml, que adicione os tipos que se deseja permitir associados aos respectivos tamanhos. Como exemplo, pode-se utilizar a linha abaixo:

<factory name="mimeData" scope="application" value="application/pdf:1572864;audio/mpeg:5242880;audio/ogg:5242880;audio/vorbis:5242880;
  image/png:1572864;video/ogg:10485760;video/mp4:10485760" auto-create="true"/>

É válido ressaltar que no web.xml deve estar permitido o tamanho configurado, ou seja, o parâmetro maxRequestSize deve ser maior ou igual ao maior tamanho configurado no components.xml.

<param-name>maxRequestSize</param-name>
<param-value>10485760</param-value>

Configuração dos bancos de dados no servidor de aplicação

O PJe utiliza, atualmente, duas fontes de dados para armazenamento das informações. Uma das fontes é o banco de metadados do sistema, onde ficam armazenadas todas as informações das partes, processos e documentos. A segunda fonte de dados é um banco onde ficam armazenados apenas os documentos binários, ou seja, o efetivo conteúdo daqueles documentos que foram enviados pelas partes ao sistema, e não produzidos no próprio sistema. Há a possibilidade de se utilizar uma terceira fonte de dados, responsável por armazenar os dados de log do sistema (tb_log e tb_log_detalhe). Recomendamos essa possibilidade para melhoria de performance.
Essas fontes de dados recebem nomes específicos nos arquivos de configuração do próprio PJe, que devem ser referenciados quando da criação do arquivo de fontes de dados, no JBoss AS. Independente de se utilizar uma fonte de dados separada para o armazenamento de logs, a referência aos logs é feita separadamente no arquivos de fontes de dados. Em nossos testes, configuramos a quantidade mínima de conexões da base de log com a metade da máxima da base da aplicação e a quantidade máxima com os mesmos valores da base de aplicação. Mas os tribunais devem configurar da forma que acharem mais adequado.
A definição de fontes de dados no JBoss AS é feita por meio de arquivos XML terminados em “-ds.xml” localizados no diretório /deploy da configuração do servidor escolhido. Para uma configuração padrão, seria o arquivo JBOSS_DIR/server/default/deploy/PJE-ds.xml.
Junto com o pacote de instalação do sistema, é disponibilizado o arquivo PJE-ds.xml, que precisa ser alterado com as configurações locais. O conteúdo desse arquivo deve seguir o padrão da definição de fontes de dados. Abaixo, transcreve-se um arquivo de exemplo cujos IPs dos servidores de bancos de dados, nomes de bancos de dados e usuários e senhas devem ser modificados apropriadamente.

<?xml version="1.0" encoding="UTF-8"?> 

<!-- $Id: PJE2-dev-ds.xml 10915 2010-08-17 21:14:53Z daniel_cnj $ --> 

<!DOCTYPE datasources 
   PUBLIC "-//JBoss//DTD JBOSS JCA Config 1.5//EN" 
   "http://www.jboss.org/j2ee/dtd/jboss-ds_1_5.dtd"> 
<datasources> 
 <xa-datasource> 
   <jndi-name>PJE_DESCANSO_DS</jndi-name> 
   <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class> 
   <xa-datasource-property name="ServerName">192.168.122.55</xa-datasource-property> 
   <xa-datasource-property name="PortNumber">5432</xa-datasource-property> 
   <xa-datasource-property name="DatabaseName">pje_descanso</xa-datasource-property> 
   <user-name>postgres</user-name> 
   <password>senha</password> 
   <track-connection-by-tx /> 
   <metadata> 
     <type-mapping>PostgreSQL 8.0</type-mapping> 
   </metadata> 
 </xa-datasource> 
 <xa-datasource> 
   <jndi-name>PJE_DESCANSO_BIN_DS</jndi-name> 
   <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class> 
   <xa-datasource-property name="ServerName">192.168.122.55</xa-datasource-property> 
   <xa-datasource-property name="PortNumber">5432</xa-datasource-property> 
   <xa-datasource-property name="DatabaseName">pje_descanso_bin</xa-datasource-property> 
   <user-name>postgres</user-name> 
   <password>senha</password> 
   <track-connection-by-tx /> 
   <metadata>
     <type-mapping>PostgreSQL 8.0</type-mapping>
   </metadata>
 </xa-datasource>
 <xa-datasource>
   <jndi-name>PJE_DESCANSO_LOG_DS</jndi-name>
   <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
   <xa-datasource-property name="ServerName">192.168.122.55</xa-datasource-property>
   <xa-datasource-property name="PortNumber">5432</xa-datasource-property>
   <xa-datasource-property name="DatabaseName">pje_log</xa-datasource-property>
   <user-name>postgres</user-name>
   <password>senha</password>
   <track-connection-by-tx/>
   <metadata> 
     <type-mapping>PostgreSQL 8.0</type-mapping> 
   </metadata> 
 </xa-datasource> 
</datasources>

Implantação do PJe

A implantação do PJe no servidor de aplicação, mantidas as informações padronizadas, limita-se a colocar o arquivo WAR do sistema na pasta /deploy da configuração de servidor escolhida para a instalação.
Uma vez efetivada essa cópia na pasta e inicializado o servidor de aplicação (comando run.sh), o próprio servidor de aplicação se responsabilizará por complementar a instalação. O sistema estará disponível para acesso no endereço em que foi disponibilizado o servidor, com o nome sem a extensão. Assim, se o arquivo WAR tinha nome “pje.war” e o servidor estiver disponibilizando o acesso seguro HTTPS no endereço “123.45.67.89”, o sistema será acessível apontando o navegador para https://123.45.67.89/pje.
Como ato final da instalação, ainda utilizando o exemplo acima, acesse o endereço https://123.45.67.89/pje/pages/admin/reindex.seam (utilizando o mesmo servidor do exemplo acima) para gerar os índices necessários à aplicação. O procedimento força a atualização dos índices do hibernate-search, utilizado, entre outras funcionalidades, na identificação de processos preventos.

Acesso ao serviço da Receita Federal

Finalizada a instalação do servidor de aplicação, deve-se instalar o certificado digital do CNJ. Somente assim o sistema será capaz de se comunicar com o serviço de consulta a dados da Receita Federal do Brasil. O serviço de validação de CPF da receita federal é um serviço contratado pelos órgãos, públicos ou não, para consulta de CPF. Dessa forma, a receita exige que o órgão forneça sua identificação para que ela responda à consulta só aos órgãos com os quais ela tem contrato. A forma automática que a receita tem de validar quem está fazendo a consulta é através do certificado digital do órgão contratante, que é fornecido quando o site que realiza a consulta o envia para a receita. Ao se utilizar métodos java, o certificado a ser enviado deve estar configurado na máquina java utilizada pelo servidor de aplicação que faz a consulta do CPF. Os passos descritos aqui se destinam a esse fim, ou seja, configurar o java utilizado pelo Jboss de forma que ele armazene o certificado que será utilizado para que a receita valide se a consulta está sendo realizada através de um órgão contratante do seu serviço. Para o caso de tribunais que não têm contrato próprio, pode-se utilizar o certificado do CNJ. O certificado do CNJ pode ser obtido através de transações seguras realizadas com o CNJ. Através do site https://www.cnj.jus.br/ecnj é um exemplo. Ao acessar esse endereço, você terá acesso a um cadeado do lado esquerdo da barra de endereços que, sendo acionado, permitirá a exibição e guarda do certificado. Ao exibir o certificado, haverá uma aba Detalhes contendo um botão para exportação do certificado, que deve ser salvo em uma pasta do servidor para posterior importação para o java. Esse arquivo é importado para o Java através das instruções a seguir:

salve o arquivo do certificado em algum diretório
abra uma janela onde você possa executar comandos via linha de comando
na pasta lib/security do java, renomeie o arquivo cacerts para um outro nome qualquer, por exemplo, cacerts_old
execute o comando keytool -import -alias <alias> -file <certificado> -keystore <truststore>, onde <alias> é o apelido do certificado, <certificado> é o caminho onde o certificado foi salvo no passo 1 e <truststore> é o caminho de armazenamento dos certificados no java. Exemplo: keytool -import -alias cnj -file \tmp\www.cnj.jus.br.crt -keystore /usr/lib/jvm/java-6-openjdk-amd64/jre/lib/security/cacerts
ao executar o comando, o sistema solicitará a senha de acesso ao banco de certificados (<trutstore>) que, se não tiver sido alterada na instalação do Java, será changeit
Concluído o procedimento de instalação do certificado digital do CNJ, envie e-mail para g-assistencia.qualidade.pje@cnj.jus.br, informando os endereços IPs de saída dos servidores de aplicação para acesso ao serviço de consulta da Receita Federal do Brasil. Após a confirmação de cadastro, certifique-se de que os IPs de saída estão de fato cadastrados no CNJ, acessando o endereço https://www.cnj.jus.br/testeReceitaFederal/wsdl/proxyReceita.wsdl, por meio da execução do comando WGET diretamente na máquina servidora da aplicação

Ao atualizar o seu certificado, o CNJ notificará os tribunais usuários do PJe através de lista de contatos para que eles realizem a atualização conforme procedimento acima. Após a atualização, o servidor deverá ser reiniciado.

Para instalações de teste, o acesso ao serviço pode ser interceptado por um serviço interno do PJe, que retornará dados aleatórias para os CPFs e CNPJs consultados. Para utilizar o simulador (Mock), deve-se configurar, no arquivo components.xml, disponível no pacote war da aplicação, os seguintes parâmetros:

<component name="consultaClienteReceitaPFCNJ" class="br.jus.cnj.pje.nucleo.service.ConsultaClienteReceitaPFMock" precedence="100" installed="true"/>
<component name="consultaClienteReceitaPJCNJ" class="br.jus.cnj.pje.nucleo.service.ConsultaClienteReceitaPJMock" precedence="100" installed="true"/>

Procedimentos para evolução de versão

Em um cenário de evolução de versão em situação de produção, os passos para reinstalação são os mesmos acima, devendo-se atentar especialmente no que é posto nas notas de liberação de versão. Nelas são destacados os procedimentos especiais de modificação e atualização dos bancos de dados e o meio de preservação de dados já existentes não armazenados em bancos de dados.
Deve-se sempre lembrar que a evolução de versão em situação de produção deve ser sempre precedida de realização de cópia de segurança dos dados e de testes de evolução em ambientes de homologação.

Guia rápido de instalação

Softwares requeridos

PostgreSQL 9.1 – http://www.postgresql.org
Oracle Java Development Kit 1.6.0_33 – http://java.sun.com (pode ser utilizada também a OpenJDK, que tem apresentado melhor performance em alguns estudos de caso)
Driver JDBC PostgreSQL 9.1 – http://jdbc.postgresql.org
JBoss Application Server 5.1.0GA-JDK6 – http://www.jboss.org
PJe – ftp://ftp.cnj.jus.br/

Pacote de instalação do PJe

O pacote de instalação do PJe é composto dos seguintes arquivos:

pje.war: arquivo de deploy da aplicação
instalacao_pje_1_4_x.pdf: manual de instalação do sistema
release_notes_pje_[versão].doc: lista das melhorias e correções incluídas na versão
PJE-ds.xml: arquivo de configuração de acesso às bases de dados do sistema
pje_[versão]_limpa.sql e pje_[versão]_limpa_bin.sql: scripts para criação das bases de dados minimamente configuradas
/scripts: diretório onde são incluídos scripts para migração da versão imediatamente anterior para a versão atual
/scripts/imports: diretório onde são incluídos scripts de carga de dados
/outros/InstallCert.java: arquivo utilitário para inclusão do certificado do CNJ na lista de certificados confiáveis da JVM

Para baixar o pacote de instalação do PJe, é necessário acessar a área de versões do sistema, disponibilizada no FTP do CNJ.
1. Conecte-se ao FTP do CNJ (via prompt de comando ou ferramenta): ftp.cnj.jus.br
2. Informe o usuário e a senha disponibilizados aos tribunais para acesso ao FTP do CNJ
3. Certifique-se que a configuração de transferência do FTP esteja setada para binário ou automático a fim de realizar a transferência do pacote de instalação corretamente
4. navegue até o diretório “pje_descanso”
5. baixe o arquivo compactado da versão mais recente

Sistema gerenciador do banco de dados

1. Instale a versão 9.1 do PostgreSQL e configure os arquivos postgresql.conf e pg_hba.conf
2. Crie as bases de dados “pje_versao” e “pje_versao_bin”, onde “versao” referencia o número da versão macro do sistema. Por exemplo: “pje_1_4” e “pje_1_4_bin”
3. Certifique-se que as bases de dados sejam criadas com as configurações exigidas para o correto funcionamento do sistema:

encoding: LATIN1
template: template0
collation: C
character type: C

4. Utilizando o comando psql, restaure as bases de dados “pje_versao_limpa.sql” e “pje_versao_limpa_bin.sql”, onde “versão” referencia o número da versão micro do sistema. Por exemplo: “pje_1_4_3_limpa.sql” e “pje_1_4_3_limpa_bin.sql”:

psql -U USUARIO -h SERVIDOR -d DATABASE -W < ARQUIVO, onde:

USUARIO - usuário de banco de dados com acesso a base criada
SERVIDOR - IP ou DNS do servidor que responde ao PostgreSQL
DATABASE - banco de dados criado para restauração do dump
ARQUIVO - caminho completo ou relativo para o arquivo SQL que contém a restauração

5. Execute o comando SQL de INSERT listado abaixo para especificar o CPF e o nome usuário administrador (admin). Atente para a necessidade de substituir os parâmetros <CPF> e <NOME> pelo número do CPF (com máscara) e o nome do detentor do documento.

INSERT INTO client.tb_pess_doc_identificacao
(  
  id_pessoa_doc_identificacao, 
  cd_tp_documento_identificacao, 
  nr_documento_identificacao, 
  dt_expedicao, 
  ds_nome_pessoa, 
  in_usado_falsamente, 
  in_ativo, 
  ds_orgao_expedidor, 
  id_estado_expedidor, 
  id_pessoa, 
  in_principal, 
  dt_usado_falsamente, 
  id_pais, 
  id_usuario_cadastrador
)
VALUES 
(
  nextval('client.sq_tb_pessoa_doc_identificacao'), 
  'CPF', 
  '<CPF>', 
  NULL, 
  '<NOME>', 
  'N', 
  'S',
  'Secretaria da Receita Federal', 
  NULL, 
  1, 
  'S',
  NULL, 
  NULL, 
  NULL
);

Servidor de aplicação

1. Instale o servidor JBoss Application Server 5.1.0, descompactando o arquivo de instalação jboss-5.1.0.GA-jdk6, que se encontra disponível http://sourceforge.net/projects/jboss/files/JBoss/JBoss-5.1.0.GA/
2. Modifique o arquivo JBOSS_DIR/server/default/deployers/seam.deployer/META-INF/seam-deployers-jboss-beans.xml, apagando ou comentando a linha que define o bean SeamMTMatcher
3. Modifique o arquivo JBOSS_DIR/server/default/deployers/jbossws.deployer/META-INF/standard-jaxws-client-config.xml, alterando o valor da propriedade chunksize de “2048” para “0”
4. Acrescente a biblioteca JAR do driver JDBC do PostgreSQL à pasta JBOSS_DIR/Server/default/lib
5. Certifique-se que o LOCALE do servidor de aplicações esteja corretamente configurado para PT_BR. Em servidores Linux RedHat, essa configuração é feita no atributo LANG do arquivo /etc/sysconfig/i18n (LANG=”pt_BR.UTF-8”)
6. Copie o arquivo PJE-ds.xml para a pasta JBOSS_DIR/Server/default/deploy e altere seu conteúdo para refletir as configurações de acesso às bases de dados instaladas
7. Descompacte o conteúdo do arquivo “pje.war” na pasta JBOSS_DIR/Server/default/deploy
8. O sistema estará disponível para acesso no endereço em que foi disponibilizado o servidor. Por exemplo: https://host/pje, onde “host” é o endereço do servidor.
9. Como ato final da instalação, acesse o endereço http://host/pje/pages/admin/reindex.seam para gerar os índices necessários à aplicação

Acesso ao serviço da Receita Federal

Importar o certificado digital para acesso à Receita através das instruções a seguir:

salve o arquivo do certificado em algum diretório
abra uma janela onde você possa executar comandos via linha de comando
na pasta lib/security do java, renomeie o arquivo cacerts para um outro nome qualquer, por exemplo, cacerts_old
execute o comando keytool -import -alias <alias> -file <certificado> -keystore <truststore>, onde <alias> é o apelido do certificado, <certificado> é o caminho onde o certificado foi salvo no passo 1 e <truststore> é o caminho de armazenamento dos certificados no java. Exemplo: keytool -import -alias cnj -file \tmp\www.cnj.jus.br.crt -keystore /usr/lib/jvm/java-6-openjdk-amd64/jre/lib/security/cacerts

Concluído o procedimento de instalação do certificado digital do CNJ, envie e-mail ao grupo g-assistencia.qualidade.pje@cnj.jus.br, informando os endereços IPs de saída 
 dos servidores de aplicação para acesso ao serviço de consulta da Receita Federal do Brasil. Após a confirmação de cadastro, certifique-se de que os IPs de saída estão 
 de fato cadastrados no CNJ, acessando o endereço https://www.cnj.jus.br/testeReceitaFederal/wsdl/proxyReceita.wsdl, por meio da execução do comando WGET 
 diretamente na máquina servidora da aplicação.

Configuração JCR-Storage

1) Baixar os arquivos do link abaixo

       http://ftp.cnj.jus.br/pje/programs/jcr-storage-server.war
       ou
       http://ftp.cnj.jus.br/pje/programs/jcr-storage-server-exec.jar

2) Entrar na pasta "server" para iniciar o serviço (jar).

Mudar as propriedades "jcr.server.tempDir" e "jcr.server.repoDir" do arquivo "server.properties" para apontar onde o repositório deve ser criado.
Iniciar o serviço conforme comando.
1. java -jar jcr-storage-server-exec.jar -httpPort 9000 -Dbr.jus.cnj.jcr.serverProperties=<CAMINHO_DO_ARQUIVO>/server.properties

3) Tomcat deployment (war)

incluir diretiva java -Dbr.jus.cnj.jcr.serverProperties=/etc/tomcat7/jcr-storage-server.properties no startup do tomcat
Iniciar o serviço tomcat

Exemplo de um arquivo jcr.properties:

   jcr.server.tempDir=/tmp/jackrabbit
   jcr.server.repoDir=/var/local/lib/jackrabbit
   jcr.server.maxFiles=500

4) Incluir na tabela de parâmetros do PJe os seguintes parâmetros:

Variável	Descrição	Valor
jcr.url	Url de conexão	http://localhost:9000/storage/documents(jar) ou http://<SERVIDOR_TOMCAT>:8080/jcr-storage-server/documents para o war
jcr.username	Usuario de conexão	Usuario
jcr.password	Senha de conexão	Senha

Opcionalmente pode-se utilizar o arquivo jcr-storage.properties para passar estes dados ao PJe:
- Copiar o arquivo jcr-storage.properties da pasta "lib-jboss" (arquivo baixado no link acima) para a pasta lib do JBoss

Instalação

Conteúdo

Público-alvo

Conhecimento prévio

Softwares requeridos

Pacote de instalação do PJe

Sistema gerenciador de banco de dados

Instalação

Usuário básico

Liberação para acesso em rede

Configuração específica

Carga inicial dos dados do PJe no SGBD

Criação dos bancos de dados

Carga de banco de dados em script SQL

Replicação e Cluster

Instalação e configuração do servidor de aplicação

Instalação e configuração do servidor de aplicação WILDFLY 9.0.2 para o Pje 2.0

Recursos de VM (Virtual Machines)

Configurando o Jboss EAP 7 ou Wildfly 9.0.2 usando jboss-cli

Instalação driver jdbc do Postgresql

Instalação do mojarra 1.2

Alterações no arquivo standalone.xml

Criação dos Datasources

MNI e Proxy Apache ou outros

Configuração do número máximo de arquivos abertos - unity - systemd

Configuração de parâmetros para modo de testes/homologação

Instalação do PJe no servidor de aplicação

Configuração dos esquemas

Configuração dos mocks

Configuração de parâmetros para upload de arquivos

Configuração dos bancos de dados no servidor de aplicação

Implantação do PJe

Acesso ao serviço da Receita Federal

Procedimentos para evolução de versão

Guia rápido de instalação

Softwares requeridos

Pacote de instalação do PJe

Sistema gerenciador do banco de dados

Servidor de aplicação

Acesso ao serviço da Receita Federal

Configuração JCR-Storage

Ferramentas pessoais

Espaços nominais

Variantes

Visualizações

Ações

Pesquisar

Navegação

Informações Gerais

Aplicativos PJe

Manuais

Suporte

Ferramentas