Problemas comuns no Deploy de Aplicações Java

De Wiki Integrator do Brasil
Ir para: navegação, pesquisa

A lista abaixo foi elaborada para ajudar ao desenvolvedor iniciante, assim como usuário iniciante, sobre problemas comuns encontrados em um deploy.

1. Use sempre um servidor Java que tenha conhecimentos mínimos. Se não tem experiência básica com servidores Java, recomendamos sempre o Tomcat.
2. Tenha em mente que cada servidor Java tem um procedimento diferente para deploy, configuração do ambiente como pool de conexões, bibliotecas e etc. O desenvolvedor que utiliza, por exemplo, localmente um GlassFish, automatizado completamente pelo NetBeans, poderá e terá dificuldades online na sua operação. A recomendação do item 1 é válida em situações como esta.
3. Os tutoriais que a Integrator fornece não podem ser considerados a única fonte de documentação do servidor Java que escolheu usar. O desenvolvedor é obrigado a recorrer a documentação caso precise de instruções mais específicas.
4. Erros em aplicativos exigem que o desenvolvedor recorra aos logs. Caso o desenvolvedor tenha dúvidas, ele deve recorrer a própria interpretação para perguntar ao suporte de forma clara o que está necessitando resolver.
5. Erros de formatação em aplicativos exigem que o desenvolvedor analise o caminho que foi adicionado aos seus componentes. É importante também analisar a diferença do deploy que usa local para o online. Não use caminhos físicos para formatações .
6. Problemas com fontes em relatórios como o JasperReports temos o link clicando aqui como dica.
7. Problemas com bancos de dados podem ser resolvidos vendo as dicas que fornecemos clicando aqui.
8. Erros com acentuações tem nossa explicação básica clicando aqui.
9. O encoding do PostgreSQL, assim como do servidor Linux não se altera. Sempre será UTF-8.
10. O encoding do Tomcat, por exemplo, é por padrão ISO-8859-1. O desenvolvedor tendo acesso 100% ao servidor, poderá alterar esse padrão por sua conta. Para alterar, veja o tópico Encoding padrão do Tomcat.
11. Problemas com envios de email podem ser facilmente resolvidos analisando nosso exemplo clicando aqui.
12. O pool de conexões é obrigatório para evitar abertura de conexões persistentes sem fechamento. Clique aqui para ver um exemplo que fornecemos. Isso vale também para O Erro Broken Pipe ou Communications link failure.



IMPORTANTE: É fundamental ao desenvolvedor compreender que o serviço contratado é uma hospedagem de aplicações e, como tal, o suporte está limitado ao uso dos painéis de controle. Exigir do suporte análise de erros ou falhas em aplicativos foge ao serviço contratado.