1.0 Introdução
2.0 Problemas Conhecidos
2.1 Ambiente de
Desenvolvimento da Web
2.2 Depuração
do WebSphere Application Server
2.3 Depurador de
JavaScript
2.4 Depurador de Procedimento Armazenado SQL
2.5 Ferramentas de Teste e de Implementação (Ferramentas do Servidor)
2.6
Depurador JDT (Java Development Tools)
2.7 Limitações do
Idioma Nacional
2.8
Depurador de Procedimento Armazenado SQL (Linux)
2.9 Depurador SQLJ
Os depuradores no WebSphere Studio fornecem as ferramentas necessárias para depurar aplicativos da Web, JavaScript do lado do servidor, Java, SQLJ, Procedimentos Armazenados de SQL e linguagens compiladas. Este arquivo leia-me descreve os problemas e limitações conhecidos que estão associados aos depuradores do WebSphere Studio.
Depuração de JSP:
- Os arquivos JSP podem ser depurados ao testar em um WebSphere Application Server. Se você estiver testando um servidor Tomcat, o depurador não parará nos pontos de interrupção do JSP.
- Pontos de Interrupção podem ser definidos nos arquivos JSP com as seguintes marcações:
- Scriplets JSP do formulário: <% %>
- Expressões JSP do formulário: <%= %>
- Declarações JSP do formulário: <%! %>
- As marcações jsp:useBean, jsp:getProperty, e jsp:setPropertys
- Marcações Personalizadas
- Pontos de interrupção não podem ser definidos para os seguintes conjuntos de marcação:
- Código HTML
- Diretriz JSP
- Todas as outras marcações JSP (jsp:include, jsp:forward, etc.)
- Se você estiver migrando um espaço de trabalho de uma versão mais antiga do WebSphere Studio para esta versão, será preciso excluir seus pontos de interrupção de JSP e recriá-los.
- O modo de depuração passo a passo falhará para métodos iniciais de EJB: Se você utilizar o adaptador de depuração do WebSphere Application Server para ativar uma sessão de depuração, o modo de depuração passo a passo não parará para métodos iniciais de EJB. Utilize os pontos de interrupção se deseja depurar esses métodos.
- O passo retornar de Java para o JavaScript não é suportado: Utilize pontos de interrupção se deseja poder retornar de Java para o código JavaScript.
- Depurando JSPs:
- O depurador passo-a-passo não irá funcionar para JSPs que não contenham qualquer código executável.
- Se utilizar o WebSphere Application Server Debug Adapter para lançar uma sessão do depurador, não poderá inspecionar ou exibir as variáveis e expressões JSP.
- Executar para a linha não é suportado pelos JSPs.
- Definindo pontos de interrupção JSP pode ser lento. Permita um tempo extra para o depurador inicializar se tiver muitos pontos de interrupção JSP.
- Pontos de interrupção em variáveis estáticas em blocos de declaração de JSP não funcionarão e podem causam outros problemas com pontos de interrupção.
- As propriedades dos pontos de interrupção como contagem de ocorrências, encadeamentos selecionados, e política de suspensão do VM não são suportadas para pontos de interrupção JSP.
- Não defina pontos de interrupção Java no Editor do Debugger: Os pontos de interrupção Java devem ser definidos no Editor Java e não no Editor do Debugger.
- Utilizando o item de menu pop-up Change Source File da exibição Debug: Se você alterar o arquivo fonte que é exibido utilizando o item de menu pop-up Change Source File no quadro de pilhas, o novo arquivo poderá não ser aberto no editor. Para solucionar isso, clique em um outro quadro de pilhas e, em seguida, clique novamente no quadro de pilhas original. O novo arquivo deverá então ser aberto no editor.
- Debug Console: No Debug Console, hiperlinks para tipos abertos não funcionarão.
- Etiquetas de quadros de pilhas após troca a quente: Se, após uma substituição de código a quente, algumas das etiquetas de pilhas tiverem etiquetas como
<tipo de recebimento desconhecido>(<tipo de declaração desconhecido>).<nome de método desconhecido>(<argumentos desconhecidos>) linha: <número de linha desconhecido> indisponívelvocê poderá obter as etiquetas corretas, alternando para uma perspectiva diferente e, em seguida, retorne para a perspectiva Debug.
- Um objeto JavaScript não está disponível para consulta até que seu construtor seja concluído: Você pode percorrer a execução do construtor, mas não pode examinar o objeto que está sendo construído, até que a construção seja concluída (você saiu do construtor).
- Escalonamento e quadros de pilhas abaixo do quadro de pilhas superior: O avanço e retorno de um quadro de pilhas diferente do quadro de pilhas superior não são suportados para o JavaScript.
- Inclusão de JSP: A depuração de JavaScript em uma inclusão de JSP não é suportada.
- Sair de funções recursivas: Os usuários que depuram funções recursivas de JavaScript perceberão que, quando saírem de uma função recursiva, não retornarão ao nível de execução superior.
- Não expanda objetos que contêm as variáveis writer ou inputStream: Ao examinarem os objetos JavaScript, os usuários são avisados para não expandir objetos que contêm as variáveis writer ou inputStream. Isso torna o depurador não-responsivo.
- Test Environment: A depuração de JavaScript não funcionará ao utilizar o WebSphere V5 Test Environment. Este problema é corrigido no APAR #PQ73036.
- A importação ou exclusão do banco de dados na exibição Data Definition pode causar perda de pontos de interrupção definidos: Se você depurar um procedimento armazenado SQL antes de importar o banco de dados para uma pasta na exibição Data Definition e, em seguida, importar o banco de dados, todos os pontos de interrupção de linha criados serão perdidos. Depois de importar o banco de dados, o depurador utilizará aquela pasta para exibir a origem. Se você excluir as informações do banco de dados importado, perderá também as informações do ponto de interrupção na próxima vez que tentar depurar um procedimento armazenado SQL. Isso não restaurará os pontos de interrupção perdidos quando o banco de dados foi importado pela primeira vez.
Recomendamos que você importe o banco de dados antes de depurar um procedimento armazenado para evitar esse problema.
- A depuração de procedimentos armazenados Java não é suportada: O editor permite que você inclua pontos de interrupção no código fonte de um procedimento armazenado Java. No entanto, esses pontos de interrupção são ignorados porque a depuração de procedimentos armazenados Java ainda não é suportada.
- Nomes de procedimentos armazenados delimitados: o depurador de procedimento armazenado SQL fornece suporte limitado para procedimentos armazenados com esquema delimitado ou nomes de procedimentos. Tais procedimentos devem ser ativados do diálogo Launch Configuration e não do menu de contexto na exibição Data Definition.
- Suporte para ter mais que uma sessão do depurador de procedimento armazenado SQL ativa ao mesmo tempo: Na Versão 5.0 deste produto, você não podia ter mais que uma sessão do depurador de procedimento armazenado SQL ativa ao mesmo tempo. Essa restrição não se aplica mais nas Versões 5.0.1 ou superiores deste produto.
- Procedimentos Armazenados com argumentos FOR BIT DATA: Procedimentos armazenados que tenham argumentos com o atributo FOR BIT DATA não podem ser depurados com o depurador SQL Stored Procedure do WebSphere Studio.
- A configuração de lançamento criada no produto Early Availability pode não ser reconhecida no produto atual: Se você instalou a versão Early Availability deste produto e criou uma configuração de lançamento do Depurador de Procedimento Armazenado com ela, as definições da configuração de lançamento podem não ser reconhecidas quando ela é utilizada com a versão atual deste produto. As definições da Configuração de Lançamento que foram salvas na versão Early Availability podem reverter para os valores padrão quando abertas na versão atual do produto.
Considere o seguinte, quando decidir executar um servidor no modo de depuração:
- Os servidores podem iniciar e executar mais lentamente do que quando executando em modo de não-depuração.
- O WebSphere Application Server demora bem mais para compilar páginas JSP.
Informações sobre os problemas e limitações conhecidos com as ferramentas de desenvolvimento Java estão disponíveis nas notas sobre o release de JDT (Java Development Tools) e do Workbench (IDE). Essas notas podem ser acessadas a partir de links do Leia-me principal do produto que foi instalado com este produto.
- Limitação de BiDi (bidirecional): Você não poderá utilizar o editor do Debugger quando depurar JSPs que foram codificados em uma página de códigos diferente da página de códigos nativa.
- Depurador de Linguagem Compilada:
- Em sistemas SBCS (Conjunto de Caracteres de Byte Único), o Depurador de Linguagem Compilada não suporta nomes de programas ou a transmissão de parâmetros do programa que contenham caracteres acima de 0x7F.
- A utilização de caracteres NL em nomes e argumentos depurados não é suportada.
Quando você estiver depurando um SQL Stored Procedure em um banco de dados local, é possível receber o erro número SQL1224N:
COM.ibm.db2.jdbc.DB2Exception: [IBM][CLI Driver] SQL1224N A database agent could not be started to service a request, or was terminated as a result of a database system shutdown or a force command. SQLSTATE=55032
Isso é devido a um problema no kernel do Linux (Bugzilla do kernel Linux bug #351). As instruções a seguir são uma solução alternativa que utiliza o método de conexão TCPIP do DB2 (como um loopback) em vez de CLI (Call Level Interface). Este procedimento permitirá que o depurador utilize o mesmo alias de banco de dados de antes.
- Se uma porta para clientes remotos de DB2 não tiver sido configurada, crie uma porta TCP/IP em /etc/services, (por exemplo, db2cdb2inst1 50000/tcp # porta de conexão do serviço DB2). Uma porta existente para clientes remotos DB2 pode ser utilizada.
As etapas de 2 a 7 a seguir exigem que você efetue login como proprietário da instância do DB2.
- Configure o gerenciador do banco de dados para iniciar o gerenciador de conexão para o protocolo de comunicação TCP/IP. Se você não estiver certo sobre se isso já foi feito, emita o seguinte comando:
db2set db2commSe a saída não contiver a palavra-chave tcpip, você precisará inserir o seguinte comando para atualizar a variável do registro db2comm para incluir tcpip:
db2set db2comm=<nomes de protocolos existentes>,tcpipA variável do registro db2comm determina qual gerenciador de conexão de protocolo será ativado quando o gerenciador do banco de dados for iniciado. Você pode definir essa variável para vários protocolos de comunicação separando as palavras-chave com vírgulas, por exemplo, db2set db2comm=tcpip,appc.
É preciso emitir novamente o comando db2start para iniciar os gerenciadores de conexão para os protocolos especificados pelo parâmetro do registro db2comm. Como o DB2 será reiniciado na etapa 7 a seguir, não é necessário fazer isso agora.
.- Atualize o parâmetro de configuração SVCENAME do gerenciador de banco de dados com o nome do serviço de conexão definido em /etc/services (etapa 1).
Para verificar a definição atual de SVCENAME, insira o seguinte comando:
db2 get dbm cfg | grep -i svcenameSe precisar atualizar a definição de SVCENAME, insira o seguinte comando:
db2 update dbm cfg using svcename <nome do serviço de conexão>em que <nome do serviço de conexão> faz distinção entre maiúsculas e minúsculas e deve corresponder ao nome da porta de serviço que você colocou em /etc/services (por exemplo, db2 update dbm cfg using svcename db2cdb2inst1).
A atualização da configuração do gerenciador do banco de dados não será efetivada até que o próximo comando db2start seja emitido. Isso será feito na etapa 7 a seguir.
- Catalogue o nó de loopback inserindo o seguinte comando:
db2 catalog tcpip node <nome_do_nó> remote 127.0.0.1 server <nome do serviço de conexão>em que <nome_do_nó> é um alias local para o nó a ser catalogado. Este é um nome arbitrário na estação de trabalho, utilizado para identificar o nó (por exemplo, db2 catalog tcpip node mynode remote 127.0.0.1 server db2cdb2inst1).
Para verificar se o comando catalog funcionou corretamente, emita o seguinte comando:
db2 list node directoryUma amostra da saída desse comando é (as linhas em branco foram removidas para facilitar a leitura):
Node Directory
Number of entries in the directory = 1
Node 1 entry:
Node name = MYNODE
Comment =
Protocol = TCPIP
Hostname = 127.0.0.1
Service name = db2cdb2inst1- Catalogue o banco de dados da seguinte maneira. Consulte os comandos dados a seguir para gerar saída de amostra se desejar monitorar os efeitos de cada comando:
- db2 catalog db <nome do banco de dados> as <alias do banco de dados>
- db2 uncatalog db <nome do banco de dados>
- db2 catalog db <alias do banco de dados as <nome do banco de dados> at node <nome do nó>
por exemplo,
db2 catalog db WAS as WASLOOP
db2 uncatalog db WAS
db2 catalog db WASLOOP as WAS at node MYNODENotas:
- O alias do banco de dados pode ser qualquer nome que se queira mas não pode ser igual ao nome do banco de dados.
- Você receberá o erro número SQL1334N se não tiver catalogado o banco de dados corretamente.
- É preciso repetir as etapas de 5a a 5c para cada banco de dados no qual você desejar depurar um procedimento armazenado.
Amostra da saída para as etapas 5a a 5c
Antes da etapa 5a, um banco de dados local denominado WAS já foi criado. O comando db2 list db directory tem a seguinte saída:
System Database Directory
Number of entries in the directory = 1
Database 1 entry:
Database alias = WAS
Database name = WAS
Local database directory = /home/ctsui
Database release level = 9.00
Comment =
Directory entry type = Indirect
Catalog node number = 0Após a etapa 5a, db2 list db directory tem a seguinte saída:
System Database Directory
Number of entries in the directory = 2
Database 1 entry:
Database alias = WAS
Database name = WAS
Local database directory = /home/ctsui
Database release level = 9.00
Comment =
Directory entry type = Indirect
Catalog node number = 0
Database 2 entry:
Database alias = WASLOOP
Database name = WAS
Local database directory = /home/ctsui
Database release level = 9.00
Comment =
Directory entry type = Indirect
Catalog node number = 0Após a etapa 5b, db2 list db directory tem a seguinte saída:
System Database Directory
Number of entries in the directory = 1
Database 1 entry:
Database alias = WASLOOP
Database name = WAS
Local database directory = /home/ctsui
Database release level = 9.00
Comment =
Directory entry type = Indirect
Catalog node number = 0Após a etapa 5c, db2 list db directory tem a seguinte saída:
System Database Directory
Number of entries in the directory = 2
Database 1 entry:
Database alias = WAS
Database name = WASLOOP
Node name = MYNODE
Database release level = 9.00
Comment =
Directory entry type = Remote
Catalog node number = -1
Database 2 entry:
Database alias = WASLOOP
Database name = WAS
Local database directory = /home/ctsui
Database release level = 9.00
Comment =
Directory entry type = Indirect
Catalog node number = 0
Para verificar se o comando catalog db funcionou corretamente, emita os seguintes dois comandos (e consulte a amostra de saída a seguir):
db2 connect to wasloop
db2 connect to wasem que db2 connect to wasloop deve imprimir as informações sobre a conexão e db2 connect to was deve dar SQL1403N.
Amostra da saída de db2 connect to wasloop:
Database Connection Information
System Database DirectoryDatabase server = DB2/6000 6.1.0
SQL authorization ID = CTSUI
Local database alias = WASLOOPAmostra da saída de db2 connect to was:
SQL1403N The username and/or password supplied is incorrect. SQLSTATE=08004- Atualize o mecanismo de autenticação para Client authentication. Insira o comando:
db2 update dbm cfg using authentication client
Para verificar se o comando funcionou corretamente, exiba a nova definição com o seguinte comando:
db2 get dbm cfg
Amostra da saída:
....
Database manager authentication (AUTHENTICATION) = CLIENT
....- Reinicie o DB2 para atualizar o cache do diretório. Por exemplo:
db2stop
db2start- Para o WAS, não é necessário atualizar o arquivo admin.config. Para um aplicativo do Websphere, não há necessidade de alterar a configuração de origem de dados existente.
- Se você quiser eliminar o banco de dados, faça o seguinte:
- db2 attach to <nome_do_nó> user <id_do_usuário> using <senha>
- db2 drop db <nome do banco de dados>
por exemplo, db2 attach to MYNODE user myid using mypasswd
db2 drop db WAS
Ao executar troca a quente durante depuração com a JVM J9, se houver muitos métodos SQLJ na pilha de chamadas, você verá um diálogo Obsolete methods on the stack. Se a troca a quente foi de uma classe SQLJ, a classe será recarregada na JVM, mas você não verá o novo código sendo executado até a próxima vez em que um método na classe for chamado.
Se você fizer troca a quente de uma classe SQLJ, os pontos de interrupção SQLJ podem não funcionar para essa classe durante a sessão de depuração atual.
Retornar para o arquivo leia-me principal
(C) Copyright IBM Corporation 2000, 2003. Todos os Direitos Reservados.