1.0 Introdução
2.0 Software Suportados e Especificações
3.0 Alterações do Release Anterior
4.0 Limitações
4.1 O Servidor WebSphere Deve Ter Página de Código Correspondente
5.0 Problemas Conhecidos
5.1 Configurando Adaptadores de Recursos J2C para WebSphere v5
5.2 O WebSphere Application Server Não Pode Ser Criado nem Iniciado Devido a Caracteres Inválidos
5.3 Parar o WebSphere V4.0 Test Environment Pode Causar Erro de Gravação do Arquivo de Log
5.4
Nomes Longos de Diretórios Podem Causar Erros nos Testes de JSP
5.5
Problemas ao Utilizar o Apache Tomcat Quando Desconectado da Internet
5.6 Executando Aplicativos Java Que Se Conectam ao WebSphere Application Server
5.7 Executando o WebSphere V4.0 Administrative Client com a Segurança Ativada
5.8
Versões do Ambiente de Teste do WebSphere
5.9 Utilizando Construtores no Universal Test Client
5.10
Caminho de Classe de Provedor JDBC DB2 Padrão no Linux
5.11
Clientes de Aplicativos WebSphere Versão 4.0 no Linux
5.12 O Cliente J2EE Não Pode Acessar o Servidor de Ambiente de Teste em uma Máquina Remota
5.13 Mensagem ao Aplicar PTF do WebSphere V4
5.14 Criando Origens de Dados e Servidores no Administration Console do WebSphere v5
5.15 Movendo Configurações de Servidor e Renomeando Projetos de Servidor
5.16 Opções do Caminho para o Servidor WebSphere
5.17
Configurando o Cloudscape 5.1
5.18 Publicar Novamente o Servidor WebSphere em uma Máquina AIX Causa Mensagem de Aviso
5.19 Depuração em Velocidade Máxima e Suporte a Substituição de Método hot
5.20 Fazendo Upgrade do Cloudscape da Versão 5.0 para a Versão 5.1
5.21 Migração do WebSphere MQ
5.22 Migração de Projetos do Conector Implementado do WebSphere Studio v5.0
5.23 Corrupção do Servidor Possível ao Salvar Nova Entrada de Autenticação JAAS
O recurso Server Tools permite testar e publicar aplicativos J2EE em ambientes de tempo de execução local e remoto diferentes. O arquivo leia-me descreve as limitações, problemas conhecidos e alternativas associadas às seguintes funções do Server Tools:
- Configurar o servidor utilizando um servidor e uma configuração do servidor. (Servidores e configurações do servidor são construções utilizadas pelo Server Tools para testar e publicar em ambientes de tempo de execução diferentes.)
- Testar projetos J2EE no IBM WebSphere Application Server ou no Apache Tomcat.
- Testar beans corporativos no Universal Test Client.
- Suporte a projetos Web estáticos.
A ajuda on-line para testar e publicar contém informações adicionais sobre as restrições das Server Tools e sobre como contornar os problemas nas Server Tools.
Para obter informações sobre ambientes de tempo de execução suportados, consulte o leia-me do produto.
O Universal Test Client requer a utilização do Netscape Versão 4.6 ou Mozilla Versão 0.7 ou superior
As ferramentas do servidor suportam o teste e a publicação de projetos nos servidores WebSphere nas máquinas Windows, Linux e AIX.
Ao testar com servidores WebSphere remotos, a máquina remota deve ter a mesma página de código que a máquina local. Executar o servidor local e o remoto com páginas de código diferentes não é suportado e pode corromper o console.
Você pode receber um erro ao clicar no botão Add na página J2C do editor de configuração do servidor WebSphere v5. Uma solução alternativa para esse problema é configurar o módulo conector em um EAR ou executar as seguintes etapas:
1. Ativar o WebSphere Administrative Console e iniciar o servidor.
2. Abrir e efetuar login no Administrative Console. Selecionar Resources > Resource Adapters a partir da esquerda.
3. Clicar em New. Inserir o Nome do módulo conector e especificar o caminho completo para a pasta connectorModule em seu projeto. Por exemplo, C:\workspace\myConnector\connectorModule.
4. Clicar em Apply e depois Atualizar o projeto do servidor no IDE. Agora você pode continuar a usar o editor de configuração do servidor para quaisquer alterações adicionais.
Se você instalar o WebSphere Studio em um diretório cujo nome contenha um cifrão ($) ou qualquer caractere incomum como #, %, + ou *, o servidor WebSphere pode não ser criado ou não será iniciado com êxito. Para evitar isso, não instale o WebSphere Studio em um diretório que contenha um desses caracteres.
Ao criar um servidor WebSphere ou projeto de servidor que conterá um servidor WebSphere, não inclua o caractere #, %, & ou * no nome. O WebSphere Application Server não suporta esses caracteres.
Ao parar o ambiente de teste do WebSphere V4.0 no Linux, você poderá obter os seguintes erros na exibição Console:
Unable to obtain Shared Log Lock file /opt/wsappdev/plugins/com.ibm.etools.websphere.runtime/logs/activity.log.lck
Stack trace:
com.ibm.ejs.ras.SharedLogLockException
at com.ibm.ejs.ras.SharedLogBase.acquireHostLock(SharedLogBase.java:251)
at com.ibm.ejs.ras.SharedLogWriter.log(SharedLogWriter.java:255)
...
Previous exception:
Message:
null
Stack trace:
java.io.IOException: Permission denied
at java.io.UnixFileSystem.createFileExclusively(Native Method)
at java.io.File.createNewFile(File.java:697)
...O problema é causado quando o servidor falha ao gravar no arquivo activity.log. O processo do servidor será parado com êxito mesmo que você receba essa mensagem de erro. Seguramente você pode ignorar estas mensagens de erro.
Se você utilizar um espaço de trabalho em um diretório com um caminho longo ou escolher nomes longos para seu projeto Enterprise Application ou projeto da Web, você poderá receber a seguinte mensagem de erro ao tentar executar uma página JSP:
Error Message: JSPG0113E: JSP file
"Xxx/Yyy_jsp_0.java (Filename too long)" not foundSe você receber esse erro, uma das seguintes ações podem ser tomadas:
- Mova seu espaço de trabalho para uma localização com um caminho mais curto, por exemplo, c:/workspace.
- Renomeie o projeto Enterprise Application e/ou projeto da Web para um nome mais curto.
- Diminua a profundidade da pasta da página JSP dentro do aplicativo da Web. Por exemplo, mova as páginas JSP para uma pasta comum ou raiz da pasta Web Content, em vez de aninhá-las mais abaixo.
O arquivo web.xml padrão enviado com o Apache Tomcat contém uma referência para um arquivo DTD na Internet. Devido a isso, os servidores Tomcat não iniciarão quando desconectado da Internet. No WebSphere Studio, essas referências foram removidas da configuração do Tomcat versão 3.2 de modo que você possa trabalhar enquanto executa no modo autônomo. Se você importar uma configuração do servidor Tomcat do WebSphere Studio externo ou estiver usando o Tomcat versão 4.0, você pode ter problemas trabalhando enquanto desconectado da Internet. Se isso ocorrer, execute as seguintes etapas para remover essa referência.
Se você tiver problemas ao iniciar o servidor, pode ser necessário conectar-se à Internet e incluir novamente o elemento DOCTYPE utilizando o arquivo web.xml de backup.
- Faça backup do arquivo web.xml da configuração do seu servidor Tomcat.
- Edite o arquivo web.xml na configuração do seu servidor Tomcat usando um editor de texto.
- Remova o elemento DOCTYPE inteiramente do arquivo.
- Salve e feche o editor.
O WebSphere Application Server possui uma restrição de que todos os aplicativos Java que utilizam o cliente WebSphere para conexão a beans corporativos em execução em um servidor WebSphere devem utilizar o mesmo nível do IBM Java ORB utilizado para construir o cliente WebSphere. Se você não utilizar o mesmo nível de ORB, poderá receber um erro semelhante ao mostrado a seguir quando executar o aplicativo cliente:
java.lang.NoClassDefFoundError: com/ibm/rmi/iiop/GIOPVersionException
Para assegurar que o nível ORB correto seja utilizado, você pode executar o aplicativo cliente utilizando o WebSphere JRE. Para fazer isso, execute as etapas a seguir:
- Abra o diálogo Launch Configurations utilizando os itens do menu Run > Run ou Run > Debug na perspectiva Debug.
- Selecione a Configuração de Lançamento de Aplicativo Java que você deseja editar.
- Vá para a página JRE e selecione o WebSphere JRE apropriado a partir da caixa de combinação.
- Aplique as alterações.
Como alternativa, você pode executar o aplicativo cliente com qualquer JRE contanto que assegure que o nível de ORB correspondente seja utilizado. Para fazer isso, execute as etapas a seguir:
- Abra o diálogo Launch Configurations utilizando os itens do menu Run > Run ou Run > Debug na perspectiva Debug.
- Selecione a Configuração de Lançamento de Aplicativo Java que você deseja editar.
- Vá para a página Arguments e inclua o seguinte no campo VM Arguments:
-Xbootclasspath/p:WAS_installdir\java\jre\lib\ext\ibmorb.jar
em que WAS_installdir é o diretório que contém o tempo de execução, por ex., c:\Program Files\IBM\WebSphere Studio\runtimes\aes_v4- Aplique as alterações.
O WebSphere Versão 4 Administrative Client não pode ser lançado diretamente a partir do workbench quando a segurança está ativada. Para lançar o cliente administrativo, siga estas etapas:
- Inicie o servidor WebSphere.
- Abra um navegador da Web e digite a seguinte URL: http://[localhost:8080]/admin, em que [localhost:8080] é o nome do servidor e porta que você está utilizado.
- Digite o ID do usuário e senha utilizados para configurar a segurança. Clique em Send.
- No painel à direita, clique em Configuration > Open.
- Selecione "Enter full path to file on server".
- Digite o caminho completo para a configuração do servidor no campo de texto. Por exemplo: C:\studio\eclipse\workspace\Servers\was.wsc\server-cfg.xml.
- Clicar em OK.
O ambiente de teste do WebSphere versão 4 baseia-se no WebSphere versão 4.06. O ambiente de teste do WebSphere versão 5 baseia-se no WebSphere versão 5.02. Quando migrar de uma versão anterior do WebSphere Studio, os e-fixes para o Ambiente de Teste do WebSphere serão removidos e você deve reinstalá-los manualmente.
Ao utilizar o Universal Test Client, você não poderá construir objetos que consideram interfaces como parâmetros na página de parâmetros. Todos os objetos a ser construídos a partir de parâmetros com tipos de interface devem utilizar a seção de referências de classe.
Primeiro carregue e construa um objeto do tipo interface ou abstrato. Em seguida, carregue a classe que contém o construtor com o tipo abstrato/interface. Agora escolha o objeto pré-criado na página de parâmetros.
O caminho de classe padrão do Provedor JDBC do DB2 no Linux é definido como ${DB2_JDBC_DRIVER_PATH}/db2java.zip. A localização da instalação do DB2 não pode ser detectada no Linux. Portanto, será necessário remover manualmente essa entrada de caminho de classe e adicionar uma nova com o caminho correto no editor do servidor se quiser utilizar uma origem de dados do DB2 no Linux.
Para acessar os beans corporativos de um aplicativo cliente em execução no WebSphere versão 4.0, é necessário especificar a porta correta de bootstrap de ORB do servidor. Isso pode ser feito definindo-se o URL do Provedor JNDI do contexto inicial ou, se você estiver utilizando beans de acesso, especificando-se a porta de bootstrap de ORB na linha de comandos adicionando -CCBootstrapPort=2809 como um Program Argument na página Arguments do assistente Launch Configuration.
Você pode obter org.omg.CORBA.COMM_FAILURE ao tentar acessar um servidor de ambiente de teste a partir de um cliente J2EE em execução em uma máquina remota. Precisará configurar o nome do host do bootstrap de ORB definido na configuração do servidor remoto para corrigir o problema. Para editar o nome do host do bootstrap de ORB, vá para a página Ports do editor do servidor e defina o campo Host name na seção de porta de bootstrap de ORB com o nome do host remoto.
Depois de fazer a alteração, salve-a e inicie novamente o servidor de ambiente de teste para que seja efetivada.
Ao aplicar o PTF do WebSphere V4, você poderá ver a mensagem "NOTE: Please regenerate the plugin configuration once the server is started in order to update the plugin-cfg.xml file". Poderá ignorá-la sem problemas.
Você pode receber um NullPointerException ou outros erros ao adicionar origens de dados ou criar servidores utilizando o WebSphere v5 Administration Console no WebSphere Studio. Utilize uma das seguintes soluções alternativas:
- Se estiver criando uma origem de dados, utilize o editor do servidor do WebSphere v5 no lugar. O editor pode ser aberto clicando duas vezes em seu servidor WebSphere v5 na exibição Servers ou Server Configurations. Vá para a página Data source para adicionar, editar ou remover origens de dados do servidor.
- Pare o servidor.
- Copie o diretório de gabaritos do seguinte diretório (em que WS_installdir é o diretório em que o WebSphere Studio foi instalado):
WS_installdir\runtimes\base_v5\config\templates
para seu espaço de trabalho atual na:
pasta workspace_ dir\server_ project\server_ name.wsc- Inicie novamente o servidor e tente novamente.
A associação entre um servidor e sua configuração do servidor inclui o projeto na qual a configuração do servidor reside. Quando você renomeia um projeto do servidor ou move uma configuração do servidor para um projeto diferente, os servidores que utilizam as configurações terão suas associações interrompidas. Para resolver o problema, na exibição Servers, clique com o botão direito do mouse no servidor e selecione Switch Configuration > server_configuration_name para reassociar a configuração ao servidor.
A funcionalidade Path Option na página Environment do editor do servidor WebSphere não funciona. O caminho inserido no campo Java Library Path será adicionado ao servidor PATH existente. Você não terá controle sobre onde os dados serão adicionados, por exemplo, se serão adicionados ao início, final ou substituindo o servidor PATH existente.
Para instalar o Cloudscape 5.1, execute o arquivo installCloudscape51.bat no Windows ou arquivo Cloudscape51.sh no Linux. Esse arquivo está localizado no diretório WS_installdir/runtimes/base_v5/cloudscape51 (em que WSinstalldir é o diretório em que o WebSphere Studio foi instalado. O instalador ativa um instalador Cloudscape específico do WebSphere. Quando solicitado pelo Directory name, procure ou digite seu diretório WS_installdir/runtimes/base_v5.
Nota: Depois de instalar o Cloudscape 5.1, não será possível executar ou ter qualquer origem de dados definida pelo Cloudscape 5.0. Se quiser executar o Cloudscape 5.0, desinstale primeiro o Cloudscape 5.1 e, em seguida, remova as origens de dados do Cloudscape 5.1 ou altere-as para as origens de dados do Cloudscape 5.0.
Ao publicar novamente um servidor WebSphere em uma máquina AIX, você pode obter algumas mensagens de aviso sobre falha ao excluir alguns arquivos na caixa de diálogo "Publishing". Você pode ignorar com segurança essas mensagens de aviso.
A depuração na velocidade máxima e a substituição do método hot só é suportado ao depurar no ambiente de teste do WebSphere V5. Depurar aplicativos fora do ambiente de teste do WebSphere V5 não é suportado.
Se você fizer o upgrade do Cloudscape versão 5.0 para a versão 5.1, esteja ciente de que o Cloudscape será incluído no servidor de aplicativos de produção e no servidor de aplicativos do ambiente de testes dentro do WebSphere Studio Site Developer. Você deve fazer o upgrade das duas instâncias do Cloudscape para 5.1.
O componente WebSphere MQ não suporta a compatibilidade de versão cruzada. Você deve assegurar que a versão do WebSphere MQ que está utilizando esteja no mesmo nível de fixpack que o ambiente de teste do WebSphere ou o server do WebSphere para o qual está implementando.
Por exemplo, você não deve utilizar o WebSphere MQ instalado pelo WebSphere Studio v5.0 com um ambiente de teste do WebSphere v5.0.2. Em vez disso, você deve desinstalar o WebSphere MQ e instalar a versão fornecida com o WebSphere Studio v5.1.
Espaços de trabalho criados no WebSphere Studio v5.0 contendo projetos de conector que são implementados para um ambiente de teste do WebSphere ou servidor WebSphere não são migrados automaticamente ao mover para um release superior. Você pode receber erros quando tentar publicar os projetos do conector para o servidor.
Uma solução alternativa para o problema é, na exibição Servers, clicar com o botão direito no servidor e selecionar Add and remove projects. Remova o projeto EAR do servidor e inclua-o novamente. Isso corrigirá a configuração do servidor WebSphere para que os projetos do conector sejam implementados corretamente.
Se abrir um editor do servidor V5, crie e salve uma nova Entrada de Autenticação JAAS sem sair do editor e vá para a guia Data Source e inclua uma origem de dados V5; um diálogo File changed aparecerá. Você deve clicar em NO para evitar corromper a configuração do servidor.
Retornar para o Arquivo Leia-me Principal
(C) Copyright IBM Corporation 2000, 2003. Todos os Direitos Reservados.