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 Nomes de Diretórios Longos podem Causar Erros no Teste de JSP
5.4 Internet Explorer: Desativar Servidor Proxy ou Socks ao Utilizar Endereços Locais
5.5
Problemas ao Utilizar o Apache Tomcat Quando Desconectado da Internet
5.6 Segurança do Servidor WebSphere
5.7 Executando Aplicativos Java Que Se Conectam ao WebSphere Application Server
5.8
Executando o WebSphere V4.0 Administrative Client com Segurança
Ativada
5.9 Versões do Ambiente de Teste do WebSphere
5.10
Utilizando Construtores no Universal Test Client
5.11
Problema de Distinção entre Maiúsculas e Minúsculas ao Publicar o
Servidor V5 Remoto no Windows
5.12 URL de Provedor JNDI Padrão no Universal Test Client
5.13 O Cliente J2EE Não Pode Acessar o Servidor de Ambiente de Teste em uma Máquina Remota
5.14 Mensagem ao Aplicar PTF do WebSphere V4
5.15 Criando Origens de Dados e Servidores no Administration Console do WebSphere v5
5.16 Movendo Configurações de Servidor e Renomeando Projetos de Servidor
5.17 Opções do Caminho para o Servidor WebSphere
5.18
Configurando o Cloudscape 5.1
5.19 Publicar Novamente o Servidor WebSphere em uma Máquina AIX Causa Mensagem de Aviso
5.20 Depuração em Velocidade Máxima e Suporte a Substituição de Método hot
5.21 Fazendo Upgrade do Cloudscape da Versão 5.0 para a Versão 5.1
5.22 Migração do WebSphere MQ
5.23 Migração de Projetos do Conector Implementado do WebSphere Studio v5.0
5.24 Servidores WebSphere Não Iniciando Devido ao Caminho do Espaço de Trabalho Começar com Barra Invertida
5.25 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 6.0 ou superior ou o Microsoft Internet Explorer 5.0 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.
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.
Se estiver usando um servidor proxy ou socks no Internet Explorer, ele deve ser desativado para endereços locais. Caso contrário, isso poderá causar problemas quando você tentar exibir o Universal Test Client ou quaisquer outros aplicativos da Web ao utilizar o navegador da Web interno ou a versão instalada do Microsoft Internet Explorer.
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.
Quando ativar a segurança para um servidor, não forneça a ele um ID de servidor que possua o mesmo nome que a máquina na qual o WebSphere Application Server está instalado. Caso contrário, o WebSphere Application Server poderá falhar ao iniciar.
O critério User Rights do ID do usuário do servidor também deve conceder ao usuário o privilégio de Act as part of the operating system.
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.
Se um projeto foi publicado em um servidor V5 remoto no Windows e, em seguida, o projeto for renomeado com o mesmo nome, mas com maiúsculas e minúsculas diferentes, ex.: renomear "MyEarProject" para "myearproject", poderão ocorrer alguns erros File does not exist durante a inicialização do servidor. É uma limitação do Windows que o WebSphere Studio não pode distinguir entre os dois projetos publicados com o mesmo nome com maiúsculas e minúsculas diferentes. O problema pode ser corrigido manualmente removendo a configuração do servidor publicada da máquina remota e, em seguida, republicando o projeto.
A URL do provedor JNDI padrão para o Universal Test Client foi alterada do WebSphere Studio versão 4.0. A nova URl do provedor é "iiop://2809", em vez de "iiop://900". Se você estiver lançando o cliente de teste manualmente e precisar do antigo número da porta (por ex.: para acessar o WebSphere v4.0), você pode alterar o URL do provedor através da página Properties no cliente de teste.
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.
Os servidores WebSphere podem não ser iniciados ao utilizar um espaço de trabalho começando com uma barra invertida. Alguns exemplos de caminhos de espaço de trabalho que causarão esse problema:
\workspaceA\my_workspaces\work1Caminhos de espaço de trabalho que começam com uma letra de unidade ou que não começam com uma barra invertida não causarão esse problema. Se você já tiver iniciado o WebSphere Studio com um espaço de trabalho que começa com uma barra invertida, siga estas etapas para possibilitar que os servidores WebSphere sejam iniciados:
- Encerre o WebSphere Studio.
- Reinicie o WebSphere Studio (utilize o sinalizador -setworkspace se tiver escolhido anteriormente ocultar a caixa de diálogo de seleção do espaço de trabalho na inicialização).
- Quando for solicitada a localização do espaço de trabalho, inclua a letra da unidade no início do caminho do espaço de trabalho. Por exemplo, \workspace1 se tornaria c:\workspace1.
- Agora, você pode iniciar o servidor WebSphere existente.
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.