© Copyright International Business Machines Corporation 2006. Todos direitos reservados. Direitos Restritos para Usuários do Governo dos Estados Unidos - Uso, duplicação e divulgação restritos pelo documento GSA ADP Schedule Contract com a IBM® Corporation.
A opção Minimizar arquivos de aplicativos copiados para o servidor é suportada pelo WebSphere® Application Server 6.0.2.5 e posterior. No editor do servidor do WebSphere Application Server V6.0, há uma caixa de opções para a opção; a opção será ignorada se for selecionada para um servidor anterior à versão 6.0.2.5.
Se um módulo EJB (Enterprise JavaBean) for compartilhado entre vários projetos EAR compartilhados em execução em um WebSphere Application Server e um dos projetos EAR for removido do servidor, outros projetos EAR deverão ser reiniciados antes que possam acessar os recursos, como beans EJB, no projeto EJB.
Se você não fizer essa ação, poderá ver mensagens de erro semelhantes às mostradas a seguir. Esses erros ocorrem porque o nome de JNDI (Java Naming and Directory Interface) no projeto EJB é removido do servidor quando o EAR é removido.
Aqui está uma amostra de mensagem de erro:
00000028 SystemOut O javax.naming.NameNotFoundException: Contexto: myCell/nodes/myNode/servers/server1, nome: ejb/ejbs/Session20Home: Primeiro componente no nome Session20Home não localizado. [A exceção raiz é org.omg.CosNaming.NamingContextPackage.NotFound: IDL:omg.org/CosNaming/NamingContext/NotFound:1.0]
em com.ibm.ws.naming.jndicos.CNContextImpl.processNotFoundException(CNContextImpl.java:4730)
em com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1907)
em com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1862)
em com.ibm.ws.naming.jndicos.CNContextImpl.lookupExt(CNContextImpl.java:1552)
em com.ibm.ws.naming.jndicos.CNContextImpl.lookup(CNContextImpl.java:1354)
em com.ibm.ws.naming.util.WsnInitCtx.lookup(WsnInitCtx.java:172)
em javax.naming.InitialContext.lookup(InitialContext.java:363)
em com.ibm.ivj.ejb.runtime.AbstractAccessBean.lookupAndCacheHome(AbstractAccessBean.java:224)
em com.ibm.ivj.ejb.runtime.AbstractAccessBean.getGlobalHome(AbstractAccessBean.java:216)
em com.ibm.ivj.ejb.runtime.AbstractAccessBean.getHome(AbstractAccessBean.java:249)
em ejbs.Session20AccessBean.ejbHome(Session20AccessBean.java:50)
em ejbs.Session20AccessBean.instantiateEJB(Session20AccessBean.java:80)
em ejbs.Session20AccessBean.foo(Session20AccessBean.java:91)
Devido a diversos comportamentos e interações entre os ambientes de tempo de execução do Eclipse e do WebSphere, há etapas adicionais necessárias ao executar WebSphere Application Clients multiencadeados por meio da caixa de diálogo Configurações de Ativação do Cliente Aplicativo. A caixa de diálogo Configurações de Ativação do Cliente Aplicativo está disponível na perspectiva J2EE ao selecionar Executar > Executar... na barra de ferramentas do produto. Se o cliente utilizar vários encadeamentos ou utilizar estruturas que podem utilizar encadeamentos adicionais, como o Swing, você deverá concluir as seguintes etapas adicionais:
- Na caixa de diálogo Configurações de Ativação do Cliente Aplicativo, selecione a guia Argumentos. Na caixa de texto Argumentos da VM, especifique o seguinte parâmetro:
-Dosgi.noShutdown=true- Assegure-se de que o aplicativo cliente chame System.exit()
Se eles não forem especificados, você poderá ter problemas relacionados ao carregamento de classes ou a JVMs (Java™ Virtual Machines) que não são finalizadas quando o aplicativo conclui sua execução.
Suponha que você tenha um projeto, por exemplo um projeto Cliente Aplicativo, com as seguintes configurações:
- o aspecto do projeto para Java é configurado para a versão 1.4
- o tempo de execução do servidor de destino para esse projeto tem uma opção de substituição de método a quente ativada em sua configuração do servidor
É possível que o botão Continuar na visualização Depuração não funcione corretamente. Por exemplo, quando você executa o aplicativo no servidor no modo de depuração, tenta alterar a origem em tempo de execução e, em seguida, usa o botão Continuar para continuar a depuração do aplicativo. É possível que as alterações da substituição de método a quente no código-fonte não sejam aplicadas.
Tente clicar no botão Continuar duas vezes para permitir que as alterações do tempo de execução entrem em efeito.
Nota: Esse problema não ocorre quando você configura o aspecto do projeto para Java como a versão 5.0.
O botão Remover na caixa de diálogo Gerenciar Servidores Compartilhados do WebSphere não funciona corretamente.
Dica: Para abrir a caixa de diálogo Gerenciar Servidores Compartilhados do WebSphere:
- Na barra de ferramentas, selecione Janela > Preferências. A caixa de diálogo Preferências será aberta.
- Na área de janela à esquerda, selecione Servidor > WebSphere > WebSphere v51.
- Na área de janela à direita, ao lado do campo Servidores compartilhados do WebSphere, clique no botão Gerenciar. A caixa de diálogo Gerenciar Servidores Compartilhados do WebSphere será aberta.
Se você utilizar o botão Remover, o servidor aparecerá removido. No entanto, se você sair da caixa de diálogo, abri-la novamente e atualizar as informações do servidor remoto, o servidor removido anteriormente permanecerá na caixa de diálogo.
Para obter uma solução alternativa para o problema, remova manualmente a entrada do servidor compartilhado concluindo as seguintes etapas:
- Abra o arquivo id.txt localizado no seguinte diretório:
<directory>/plugins/com.ibm.etools.websphere.tools*/properties
em que <directory> é o diretório de instalação do Agent Controller.- Exclua a entrada que faz referência ao servidor compartilhados que você deseja remover.
- Remova o diretório de implementação do WebSphere especificado para esse servidor compartilhado específico durante a criação do servidor e todos os seus subdiretórios. Exemplos de subdiretórios a serem removidos do diretório de implementação do WebSphere são: config, installedApps, temp e quaisquer outros diretórios e arquivos que residam nesse diretório.
- Na caixa de diálogo Gerenciar Servidores Compartilhados do WebSphere, especifique um nome de host e clique no botão Atualizar para verificar a remoção com êxito do servidor compartilhado.
Se você tiver servidores adicionais, como o IBM HTTP Server, instalados no mesmo perfil do WebSphere Application Server v6.x, a página Configurações do WebSphere Server do assistente Novo Servidor pode não localizar os números de porta corretos de RMI (Remote Method Invocation) ou SOAP. Além disso, o número da porta do console administrativo pode não ser recuperado.
Quando o assistente Novo Servidor não puder localizar os números de porta reais definidos para um servidor, seu comportamento padrão é preencher antecipadamente os campos de porta com os números de porta padrão: 2809 para RMI e 8880 para SOAP.
No caso em que os números de porta incorretos forem definidos, você poderá encontrar os seguintes problemas:
- Não é possível conectar-se ao novo servidor, como por exemplo, não é possível iniciar ou parar o servidor.
- Não é possível abrir o console administrativo a partir desse novo servidor e, como resultado, é possível receber um erro de porta do console administrativo não definida.
- Não é possível executar aplicativos nesse servidor, como por exemplo, o comando Executar em servidores não funciona
Solução alternativa:
- Determine os valores de porta de um perfil configurado fazendo referência a seus arquivos de configuração do servidor. Os valores de porta são armazenados no arquivo serverindex.xml localizado no seguinte diretório:
<directory>\profiles\<profileName>\config\cells\<cellName>\nodes\<nodeName>, em que <directory> é o diretório de instalação do WebSphere Application Server.
Use o arquivo serverindex.xml para preencher a tabela a seguir e determinar os números de porta reais definidos para o servidor:
Nome da porta Descrição da porta Número de porta padrão Seu número de porta designado SOAP_CONNECTOR_ADDRESS SOAP 8880 BOOTSTRAP_ADDRESS RMI 2809 WC_adminhost Console Administrativo 9060 WC_defaulthost Transporte HTTP 9080 - Para conectar ao servidor, especifique o número de porta RMI ou SOAP correto ao criar o servidor.
- Para iniciar o console administrativo, use um navegador da Web externo e digite no campo de endereço a URL da porta correta do console administrativo:
http://<machine_name>:<WC_adminhost>/IBM/console
Por exemplo: http://localhost:9060/IBM/console- Para executar aplicativos no servidor, emita um comando Executar no servidor. Quando o navegador da Web for aberto, corrija a URL com o número da porta de transporte HTTP definido para o servidor.
http://<machine_name>:<WC_defaulthost>/<ContextRoot>/<application_start_page>
Por exemplo: http://localhost:9080/MyApplication/index.jsp
Nota: Os servidores definidos automaticamente na visualização Servidores podem não fazer referência aos números de porta corretos para o servidor real. Se esse for o caso, use a mesma solução alternativa acima.
A ferramenta Gerenciamento de Perfis é uma ferramenta do WebSphere Application Server que cria o perfil para cada ambiente de tempo de execução. É possível usar o ambiente de trabalho para iniciar a ferramenta Gerenciamento de Perfis do WebSphere Application Server. No entanto, a ferramenta Gerenciamento de Perfis não funciona em um processador de 64 bits; em vez disso, use a ferramenta de linha de comandos manageprofiles fornecida pelo WebSphere Application Server.
Em sistemas operacionais Windows, se você estiver utilizando a porta RMI (Remote Method Invocation) para conectar ao WebSphere Application Server v6.x, poderá haver longos atrasos ao estabelecer uma conexão com o servidor após perder conectividade de rede. Isso pode ocorrer mesmo se o servidor for local e a conectividade de rede for pedida apenas temporariamente, o que é comum em um ambiente de rede wireless.
Se você souber que o servidor está iniciado, mas o status na visualização Servidores exibir Parado ou Iniciando, tente verificar se é possível estabelecer uma conexão com o servidor comutando a conexão do servidor de RMI para SOAP. O status do servidor deve ser alterado para Iniciado.Existem duas opções que estão disponíveis para estabelecer a conexão com um servidor em um ambiente de rede wireless:
- A opção mais fácil e segura é comutar sua conexão para usar a porta SOAP. Depois de perder conectividade de rede, as conexões SOAP têm a capacidade de se recuperar mais rapidamente, em comparação a uma conexão RMI.
- Se for necessário utilizar uma conexão RMI, você pode tentar modificar as configurações padrão relativas ao armazenamento em cache de DNS (Domain Name System) no sistema operacional Windows. Para obter detalhes, consulte o seguinte artigo de suporte da Microsoft:
http://support.microsoft.com/kb/318803
O sistema operacional Windows tem um armazenamento em cache de DNS integrado que mantém os nomes de host resolvidos. Isso permite uma mudança de direção mais rápida ao emitir consultas DNS. Entretanto, há uma desvantagem nisso, que é o caso da falha de uma consulta de DNS. O sistema operacional Windows armazena o valor com falha, por um tempo padrão de 300 segundos. Portanto, mesmo se o servidor DNS puder resolver a consulta logo depois, na realidade ele não tentará a consulta até que o tempo do cache expire. Como resultado, uma consulta DNS com falha com as configurações padrão pode demorar até 5 minutos antes que seja feita uma verdadeira nova tentativa na consulta. Configurar o tempo de cache como 0 segundos força o sistema operacional Windows a nunca armazenar em cache as pesquisas DNS com falha, permitindo que a reconexão ocorra tão logo o DNS fique disponível.
A seguir é apresentado um exemplo de desativação de armazenamento de DNS em cache para consultas com falha em sistemas operacionais Windows:
Na seguinte chave de registro: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters
Inclua uma dos seguintes valores de registro:
- Para Windows XP/2003:
"MaxNegativeCacheTtl"=dword:00000000- Para Windows 2000:
"NegativeCacheTime"=dword:00000000
Republicar o aplicativo, reiniciar o aplicativo ou desinstalar e reinstalar o aplicativo não são ações suficientes para aplicar uma variedade de alterações de recurso definidas na página Implementação do editor Descritor de Implementação do Aplicativo no servidor. Uma alteração no nome do banco de dados de uma origem de dados na página Implementação do editor é uma alteração conhecida que o servidor não pode obter; pode haver várias outras alterações que o servidor não pode obter.
Como uma solução alternativa, conclua as seguintes etapas para aplicar as alterações no servidor:
- Pare o servidor.
- Na visualização Servidores, clique com o botão direito do mouse no servidor e selecione Parar.
- Na visualização Servidores, aguarde até que o status do servidor exiba Parado e, em seguida, continue com a próxima etapa.
- Inicie o ambiente de trabalho.
NOTA: Se houver falha no início do servidor, será necessário utilizar as funções do sistema operacional para parar o processo java no qual o servidor está em execução. Como alternativa, é possível reiniciar o ambiente de trabalho e, em seguida, tentar iniciar o servidor novamente.- Inicie o servidor.
- Na visualização Servidores, clique com o botão direito do mouse no servidor e selecione Iniciar.
- Na visualização Servidores, aguarde até que a republicação seja concluída e que o status do servidor e do aplicativo exibam Iniciado e, em seguida, continue com a próxima etapa.
- Execute o aplicativo no servidor, por exemplo, utilizando o comando Executar no Servidor. Como resultado, agora o servidor poderá obter as alterações do editor Descritor de Implementação do Aplicativo.
Se você incluir um arquivo JAR do utilitário em um projeto da Web e fizer referência a classes dentro do arquivo JAR em seu código, poderá obter um erro java.lang.NoClassDefFoundError ao tentar executar o aplicativo no servidor.
A solução alternativa é: após incluir um arquivo JAR do utilitário no módulo EAR, inclua o arquivo JAR nas dependências dos Módulos J2EE do projeto da Web, concluindo as seguintes etapas:
- Inclua um arquivo JAR do utilitário no módulo EAR. Consulte o tópico Incluindo arquivos JAR do utilitário do projeto na ajuda do produto para obter detalhes.
- Clique com o botão direito do mouse no projeto da Web e selecione Propriedades. A caixa de diálogo Propriedades será aberta.
- Selecione Dependências de Módulos J2EE.
- Na guia Módulos J2EE na coluna JAR/Módulo, selecione a caixa de opções ao lado do arquivo JAR do utilitário.
Se um WebSphere Application Server V6.1 estiver em execução em uma conexão SOAP protegida, outra conexão SOAP segura com um WebSphere Application Server V6.0 irá falhar. O mesmo problema ocorre na ordem inversa, como um WebSphere Application Server V6.0 em execução em uma conexão SOAP protegida faz com que uma conexão SOAP segura com um WebSphere Application Server V6.1 falhe. No entanto, o problema não ocorre se o servidor estiver definido na visualização Servidores e seu status estiver em branco.
A solução alternativa é utilizar uma conexão RMI (Remote Method Invocation) segura com o servidor em vez de uma conexão SOAP, ou utilizar uma conexão SOAP não-segura.
Se o servidor remoto estiver parado, o assistente Novo Servidor poderá demorar bastante para ser concluído após você clicar no botão Concluir. Uma solução alternativa é iniciar o servidor remoto antes de clicar no botão Concluir no assistente Novo Servidor.
Se um arquivo com uma extensão .war for colocado na pasta EarContent de um projeto EAR e ele não estiver definido como um módulo da Web em application.xml, a publicação do aplicativo corporativo no servidor falhará com a seguinte mensagem de erro de amostra:
org.eclipse.jst.j2ee.commonarchivecore.internal.exception.OpenFailureException: IWAE0034E Não foi possível abrir o archive aninhado "abc.war" em "D:\myworkspace\PublishEAR\EarContent"A causa desse erro é que o ambiente de trabalho não pode manipular o arquivo corretamente como um módulo da Web. Escolha uma das seguintes soluções alternativas:
- Se o arquivo for um módulo da Web, inclua o arquivo como um módulo no aplicativo corporativo. Para obter detalhes, consulte o tópico Incluindo módulos em um aplicativo corporativo na ajuda do produto.
- Se o arquivo não for uma módulo da Web, uma sugestão de solução alternativa para o problema de publicação é alterar a extensão do arquivo para outra extensão diferente de .war, por exemplo, para .jar
Para um WebSphere Application Server V5.1 remoto ou um WebSphere Application Server V5.1 Express Edition remoto, se você alterar o diretório de implementação e o diretório de publicação no editor do servidor e, em seguida, republicar o aplicativo, o aplicativo continuará a publicar no destino anterior. Como resultado, as alterações nos diretórios de publicação e implementação não serão aplicadas. Esse problema ocorre ao utilizar os métodos de cópia local ou FTP.
A solução alternativa é reiniciar o ambiente de trabalho. Como resultado, as alterações na configuração do diretório de publicação e do diretório de implementação devem entrar em efeito.
Para suportar uma abordagem mais flexível para armazenar projetos, a técnica para a publicação de aplicativos foi alterada. Agora os aplicativos são copiados antes de serem publicados no servidor. Se o aplicativo for grande, por exemplo, maior de 100 megabytes, essa operação de cópia utilizada para o comando de publicação irá demorar um tempo adicional, diferentemente do que era experimentado na versão anterior.
Atualmente, não existe solução alternativa. A IBM está trabalhando em uma atualização que eliminará a necessidade de desempenhar essa nova operação de cópia para a maior parte dos casos.
Se um WebSphere Application Server v6.1 protegido for iniciado e, no editor do servidor você alterar o tipo da conexão do servidor para RMI (Remote Method Invocation) ou SOAP, você poderá ver a seguinte mensagem de erro de falha de publicação depois de salvar as alterações no editor do servidor:
A publicação não é desempenhada pois o servidor não está iniciado. Inicie o servidor antes de desempenhar a operação de publicação.
É possível ignorar com segurança o erro. Opcionalmente, depois que o status do servidor na visualização Servidores for Iniciado, você poderá concluir um comando de publicação (na visualização Servidores, clique com o botão direito do mouse no servidor e selecione Publicar).
Ao tentar gerar uma origem de dados utilizando o assistente Criador de Tabela e Origem de Dados, é possível encontrar um erro TargetInvocationException na seção detalhes da caixa de diálogo Resultados das Criações de Tabela e Origem de Dados.
A causa do erro TargetInvocationException pode ocorrer se você importar um intercâmbio de projeto que contém origens de dados definidas com o mesmo nome de JNDI (Java Naming and Directory Interface).
Para obter uma solução alternativa para o erro TargetInvocationException, verifique se uma origem de dados com o mesmo nome de JNDI já está definida no ambiente de trabalho. Em caso positivo, remova-a da página Implementação do editor Descritor de Implementação do Aplicativo e, em seguida, crie novamente a origem de dados usando um nome de JNDI diferente. O nome de JNDI precisa ser exclusivo pois é um serviço de nomenclatura e consulta utilizado para ligar um enterprise bean a uma origem de dados.
Ao parar o servidor a partir da visualização Servidores, o servidor pode não parar completamente. A visualização Servidores exibe Parado, mas o processo do servidor pode se encontrar em um estado não-responsivo. Isso normalmente ocorre quando artefatos como seu aplicativo ou o ambiente de trabalho mantêm referências a classes no servidor. A seguir são apresentados exemplos de cenários:
- Aplicativos que estão em loops sem fim ou o aplicativo mantém referências a algumas classes no servidor
- Aplicativos que fazem conexão com o banco de dados Cloudscape ou Derby sem limpar sua conexão
- Usar o botão Testar Conexão no assistente Nova Conexão das ferramentas de dados para abrir uma conexão com um banco de dados Cloudscape ou Derby sem desconectar-se do banco de dados
Restrição: Várias conexões com um único banco de dados Cloudscape ou Derby não são suportadas devido a uma restrição de configuração do Cloudscape ou do Derby. Se você mantiver uma conexão com o banco de dados a partir do Explorador de Banco de Dados e um servidor tentar estabelecer outra conexão com o Cloudscape ou o Derby por meio de uma origem de dados, a segunda conexão falhará. Como resultado, você precisa fechar a conexão a partir do Explorador de Banco de Dados antes que um servidor possa estabelecer uma conexão com o banco de dados Cloudscape ou Derby.
Para obter uma solução alternativa para o problema, será necessário utilizar as funções do sistema operacional para parar o processo java no auql o servidor está em execução. Como alternativa, é possível reiniciar o ambiente de trabalho para forçar a liberação da referência. No último cenário de exemplo descrito no terceiro marcador, é possível utilizar a visualização Explorador de Banco de Dados para conectar e, em seguida, desconectar do banco de dados Cloudscape ou Derby.
É possível que ao publicar recursos no servidor, por exemplo um enterprise bean, e utilizar o UTC (Universal Test Client) para testar um EJB, o arquivo JAR fique bloqueado e não possa ser atualizado. O resultado é que as alterações feitas no conjunto de ferramentas não são obtidas durante o teste do EJB. Quando o UTC carrega o arquivo JAR EJB, o arquivo JAR permanece bloqueado até que o aplicativo seja removido e incluído novamente, ou que o servidor seja reiniciado.
A solução alternativa é utilizar o UTC no ambiente de desenvolvimento em que os recursos do aplicativo estejam em execução fora do espaço de trabalho e não em execução no servidor. Isso pode ser configurado utilizando-se o assistente Novo Servidor, ou alterado posteriormente utilizando o editor do servidor selecionando-se Executar servidor com recursos no espaço de trabalho nas Opções de publicação. Isso permite que arquivos individuais no projeto EJB sejam atualizados sem precisar de uma substituição completa do arquivo JAR EJB inteiro.
Depois que o aplicativo for totalmente testado, ele poderá ser publicado no servidor utilizando a opção de publicação Executar servidor com recursos no Servidor.