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 de JDT (Java Development Tools)
2.7 Limitações do
Idioma Nacional
2.8 Depurador de Procedimento Armazenado de SQL (Linux)
2.9 Depurador de SQLJ
Os depuradores do 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 readme 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 uma versão mais antiga do WebSphere Studio para essa versão, então será necessário excluir os pontos de interrupção de JSP e criá-los novamente.
- O modo de depuração passo-a-passo falhará para os 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 será parado 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.
- Os pontos de interrupção dos blocos de declaração JSP não funcionarão e poderão causar outros problemas de ponto 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, os hyperlinks para abrir tipos não funcionarão.
- Rótulos de estrutura de pilha após troca a quente: Se, após uma substituição de código automático, algumas das estruturas de pilhas tiverem rótulos como
<unknown receiving type>(<unknown declaring type>).<unknown method name>(<unknown arguments>) line: not available <unknown line number>você pode obter os rótulos corretos alternando para uma perspectiva diferente e depois voltando 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á quando WebSphere V5 Test Environment for utilizado. Esse problema foi corrigido no APAR Nº 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 procedimento armazenado delimitados: o depurador de procedimento armazenado SQL fornece suporte limitado para procedimentos armazenados com nomes de esquema ou de procedimento delimitados. Esses procedimentos devem ser ativados a partir do diálogo Launch Configuration e não do menu de contexto na exibição Definição de Dados.
- Suporte para ter mais de uma sessão do depurador de procedimento armazenado de SQL aberta ao mesmo tempo: Na Versão 5.0 desse produto, você não podia ter mais de uma sessão do depurador de procedimento armazenado de SQL ativa aberta ao mesmo tempo. Essa restrição não se aplica mais nas Versões 5.0.1 ou superior desse produto.
- Procedimentos Armazenados com argumentos FOR BIT DATA: Os procedimentos armazenados que possuem argumentos com o atributo FOR BIT DATA não podem ser depurados com o depurador de Procedimento Armazenado de SQL 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 lento 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 problemas e limitações conhecidos das Java development tools estão disponíveis nas notas sobre o release de JDT (Java Development Tools) e nas notas sobre o release de Workbench (IDE). Elas estão vinculadas ao LEIA-ME do produto principal instalado com esse 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.
- Compiled Language Debugger:
- Nos sistemas SBCS (Single-byte Character System), o Depurador de Linguagem Compilada não suporta nomes de programas nem a transmissão de parâmetros do programa que contenham caracteres acima de 0x7F.
- A utilização dos caracteres NL nos nomes depurados e argumentos depurados não é suportada.
Quando você estiver depurando um Procedimento Armazenado de SQL 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 ocorre devido a um problema no kernel do Linux (Linux kernel Bugzilla bug #351). As instruções a seguir indicam uma solução alternativa que utiliza o método de conexão TCPIP do DB2 (como um loopback) em vez de uma CLI (Call Level Interface). Esse procedimento permitirá que o depurador utilize o mesmo alias de banco de dados que antes:
- Se uma porta para clientes DB2 remotos não tiver sido configurada, crie uma porta TCP/IP no diretório /etc/services, (por exemplo, db2cdb2inst1 50000/tcp # DB2 connection service port). Uma porta existente para clientes DB2 remotos pode ser utilizada.
As etapas de 2 a 7 abaixo requerem que você efetue login como o proprietário da instância do DB2.
- Configure o gerenciador de banco de dados para iniciar o gerenciador de conexões para o protocolo de comunicação TCP/IP. Se você não tiver certeza se isso já foi feito, emita o seguinte comando:
db2set db2commSe a saída não contiver a palavra-chave tcpip, será necessário inserir o seguinte comando para atualizar a variável de registro db2comm para incluir tcpip:
db2set db2comm=<existing protocol names>,tcpipA variável de registro db2comm determina qual gerenciador de conexões do protocolo será ativado quando o gerenciador de banco de dados for iniciado. Você pode definir essa variável para vários protocolos de comunicação, separando as palavras-chave por vírgulas, por exemplo, db2set db2comm=tcpip,appc.
Será necessário emitir novamente o comando db2start para iniciar os gerenciadores de conexões para os protocolos especificados pelo parâmetro de registro db2comm. Como o DB2 será iniciado novamente na etapa 7 abaixo, não será necessário fazer isso agora.
.- Atualize o parâmetro de configuração do gerenciador de banco de dados SVCENAME com o nome do serviço de conexão definido no diretório /etc/services (etapa 1).
Para verificar a definição atual do SVCENAME, insira o seguinte comando:
db2 get dbm cfg | grep -i svcenameSe for necessário atualizar a definição de SVCENAME, insira o seguinte comando:
db2 update dbm cfg using svcename <connection service name>em que <connection service name> faz distinção entre maiúsculas e minúsculas e deve corresponder ao nome da porta de serviço colocada no diretório /etc/services (por exemplo, db2 update dbm cfg using svcename db2cdb2inst1).
A atualização da configuração do gerenciador de banco de dados não será efetivada até que o próximo comando db2start seja emitido. Isso será feito na etapa 7 abaixo.
- Catalogue o nó de loopback inserindo o seguinte comando:
db2 catalog tcpip node <nodename> remote 127.0.0.1 server <connection service name>em que <nodename> é um alias local para o nó a ser catalogado. Esse é 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 do catálogo funcionou corretamente, emita o seguinte comando:
db2 list node directoryUma saída de amostra desse comando é (linhas em branco foram removidas por questão de legibilidade):
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 forma. Consulte os comandos fornecidos abaixo para gerar saída de amostra se quiser monitorar os efeitos de cada comando.
- db2 catalog db <database name> as <database alias>
- db2 uncatalog db <database name>
- db2 catalog db <database alias as <database name> at node <nodename>
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, mas não pode ser igual ao nome do banco de dados.
- O erro número SQL1334N será recebido se o banco de dados não tiver sido catalogado corretamente.
- Será necessário repetir as etapas 5a a 5c para cada banco de dados no qual você deseja depurar um procedimento armazenado.
Saída de Amostra das Etapas 5a a 5c
Antes da etapa 5a, um banco de dados local denominado WAS já havia sido 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 = 0Depois da 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 = 0Depois da 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 = 0Depois da 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 dois comandos a seguir (e veja a saída de amostra abaixo):
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 fornecer SQL1403N.
Saída de amostra do db2 connect to wasloop:
Database Connection Information
System Database DirectoryDatabase server = DB2/6000 6.1.0
SQL authorization ID = CTSUI
Local database alias = WASLOOPSaída de amostra do 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
Saída de amostra:
....
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 é necessário alterar a configuração da datasource existente.
- Se quiser eliminar o banco de dados, faça o seguinte:
- db2 attach to <nodename> user <userid> using <password>
- db2 drop db <database name>
por exemplo, db2 attach to MYNODE user myid using mypasswd
db2 drop db WAS
Ao executar troca a quente durante a depuração com a J9 JVM, se houver algum método de SQLJ na pilha de chamada, aparecerá o diálogo Obsolete methods on the stack. Se a troca a quente era de uma classe de SQLJ, a classe será recarregada na JVM, mas você não verá o novo código em execução até a próxima vez que um método da classe for chamado.
Se você trocar a quente uma classe de SQLJ, os pontos de interrupção de SQLJ poderão não funcionar para essa classe durante a sessão de depuração atual.
Retornar para o arquivo Readme principal
(C) Copyright IBM Corporation 2000, 2003. Todos os Direitos Reservados.