Uma versão em PDF deste manual também está disponível no diretório pdf. O diretório pdf está localizado no CD do produto VisualAge for Java, Edição Professional e no CD Additional Features do VisualAge for Java, Edição Enterprise.
Onde localizar mais informações sobre o VisualAge for Java
Este arquivo não inclui informações detalhadas sobre os componentes e recursos específicos do VisualAge for Java. Para obter essas informações, consulte as Notas do Release do produto, que podem ser acessadas selecionando Iniciar > Programas > IBM VisualAge for Java para Windows V4.0 > Notas do Release. Para todos os idiomas, as notas do release podem ser encontradas no CD do produto (ficam disponíveis depois da instalação) e na Web, no endereço http://www.ibm.com/vadd.
Este arquivo não contém informações sobre o uso do VisualAge for Java. Consulte o Guia Inicial e a ajuda online para obter essas informações. Parte da ajuda online foi agrupada em documentos PDF que podem ser exibidos e impressos com o uso do Adobe Acrobat Reader (disponível de http://www.adobe.com/). Nem todos PDFs estão disponíveis em todos os idiomas. Os arquivos PDF estão disponíveis no diretório pdf. O diretório pdf está localizado no CD do produto VisualAge for Java, Edição Professional e no CD Additional Features do VisualAge for Java, Edição Enterprise. Se você tiver uma versão eletrônica do VisualAge for Java, ela poderá ser encontrada no diretório temporário (para o qual você extraiu suas partes). Se você não fez download da parte que contém os PDFs, esse diretório não existirá.
Consulte o Índice do PDF (no Guia Inicial) para obter informações sobre o que cada arquivo de PDF contém. A ajuda online também contém uma seção "Recursos da Web" que contém links para recursos do VisualAge disponíveis na Internet.
O site da Web do VADD (VisualAge Developer Domain) oferece artigos técnicos, tutoriais, exemplos e FAQs (Perguntas Freqüentes), além de acesso fácil ao suporte e atualizações do produto para o VisualAge for Java. Desse site, você pode fazer um download das ferramentas de desenvolvimento do VisualAge for Java, assim como dos beans reutilizáveis, assistentes e conjuntos de ferramentas para complementar o desenvolvimento do applet e do servlet. Consulte http://www.ibm.com/vadd. Esse site também pode ser usado para solicitar recursos em releases futuros do VisualAge for Java.
Se já tiver se associado ao VisualAge Developers Domain, não será necessário registrar-se novamente. Você pode usar seu ID e senha atuais para obter informações atuais e atualizações do código. Se você for um novo usuário, localize o número de assinatura na caixa (ou kit de mídia) que você recebeu. Se você comprou o VisualAge for Java e não possui um número de assinatura, entre em contato com seu representante de vendas IBM(R).
A home page do VisualAge for Java tem o endereço http://www.ibm.com/software/ad/vajava
Parte A: VisualAge for Java, Edição Professional
1.0 Pré-requisitos
2.0 Instalação
2.1 Instalando o VisualAge for
Java, Versão 4.0
2.2 Instalando os componentes adicionais mais tarde
2.3 Considerações sobre a instalação do Windows(R) 2000
2.4 Instalando o IBM Developer Kit, Edição Java Technology, v1.2.2
3.0 Migrando
de uma versão anterior do VisualAge for Java
3.1 Migrando
do VisualAge for Java Versão 3.5 ou Versão 3.5.3
3.2 Migrando da Versão
2.0, 3.0x ou 3.0x Early Adopters do VisualAge for Java
4.0 Problemas e
limitações conhecidos
4.1 Problemas e limitações conhecidos
da instalação
4.2 Problemas e
limitações conhecidos da desinstalação
Parte B: VisualAge for Java, Edição Enterprise
1.0 Pré-requisitos
1.1 Pré-requisitos
gerais
1.2
Pré-requisitos específicos dos componentes
2.0 Instalando
2.1 Instalando o VisualAge for
Java, Versão 4.0
2.2 Instalando os componentes adicionais mais tarde
2.3 Instalando os clientes de equipe do VisualAge for Java
2.4 Instalando um cliente que possui um repositório independente
2.5 Considerações sobre a instalação e utilização do Windows(R) 2000
2.6 Instalando o IBM Developer Kit, Edição Java Technology,
v1.2.2
3.0 Migrando de uma versão anterior do VisualAge for Java
3.1 Migrando um repositório compartilhado de uma edição anterior do VisualAge for Java
4.0 Problemas e
limitações conhecidos
4.1 Problemas e limitações conhecidos
da instalação
4.2 Problemas e
limitações conhecidos da desinstalação
Parte C: Servidor de repositório da equipe (EMSRV)
1.0 Pré-requisitos
1.1 Plataformas suportadas
1.2 TCP/IP
1.3 Correções Novell requeridas para executar o EMSRV no NetWare 4.x
1.4 Correção da Solaris requerida para executar o EMSRV no Solaris
1.5 Sistemas de arquivos
suportados
2.0 Instalando
2.1 Instalando o EMSRV para Windows(R)
2.1.1 Instalando o EMSRV como um Serviço nos Registros do Windows
2.2 Instalando o EMSRV para NetWare
2.3 Instalando o EMSRV para OS/2
(R) Warp
2.4 Instalação de EMSRV
para AIX
2.5 Instalando o EMSRV para HP-UX/Solaris(TM)
2.6 Instalando o EMSRV para Linux
3.0 Migração
3.1 Migrando da Versão 6.x/7.0 do EMSRV para a Versão 7.1
4.0 Preparando o desenvolvimento de equipe
4.1 Preparando o servidor da equipe
4.2 Testando uma conexão do cliente
4.3 Incluindo usuários na lista de usuários do repositório
5.0 Problemas e limitações conhecidos
5.1 Desempenho
em conexões de rede de largura de banda baixa, de alta latência
5.2 Limitações de conexões TCP/IP
5.3 Detectando
conexões interrompidas inesperadamente
5.4 Intercâmbio de diferentes
versões do EMSRV e utilitários do EMSRV
5.5 Limitações de PAM
5.6
Senhas
com caracteres não-ASCII não podem ser utilizadas para
autenticar com o EMSRV
5.7
Menus e
janelas apresentam caracteres corrompidos quando executados em
NetWare japonês
5.8 O EMADMIN não copia o diretório de recursos armazenados
Parte D: Informações sobre migração específicas do componente
1.0 CICS(R) Transaction Server * +
2.0 Data Access beans
3.0 Data Access Builder * +
4.0 Ambiente de Desenvolvimento EJB(TM)+
5.0 Enterprise Access Builder e e-connectors +
6.0 Enterprise Toolkit para AS/400(R) +
7.0 Enterprise Toolkit para OS/390(R) +
8.0 Enterprise Toolkit para Workstations * +
9.0 Controle Externo de Versão
10.0 Ambiente de Desenvolvimento IDL +
11.0 Ambiente de Desenvolvimento
Integrado
12.0 Ambiente de Desenvolvimento
JSP/Servlet
13.0 Assistente de Migração *
14.0 Persistence Builder +
15.0 RMI Access Builder * +
16.0 Editor de Composição Visual
17.0 Servlet Builder e Servlet
Launcher * +
18.0 Classes Swing
19.0 XMI Toolkit +
* Esses componentes não são suportados no VisualAge for Java, Versão 4.0
+ Somente Edição Enterprise
Parte E: Informações Gerais
1.0 Lidando com recursos
do projeto e gerenciamento de recursos
2.0 Migrando do OS/2 e AIX
3.0
Novas
restrições de segurança no J2SDK v.1.2.2
4.0 Nova ferramenta do
Controle Externo de Versão (substitui a ferramenta External SCM)
5.0 Trabalhando
com ORBs de terceiros no VisualAge for Java
6.0 Conteúdo do CD
Additional Features
Apêndices
Apêndice A: Uma comparação dos recursos de acesso a dados
Esta edição do VisualAge for Java, Versão 4.0 tem os seguintes pré-requisitos de hardware e software:
Se você quiser executar o Websphere Application Server com DB2(R) e VisualAge for Java ao mesmo tempo, então, pelo menos 512 MB são recomendados.
* Nota: O VisualAge for Java não suporta o mouse de rolagem Logitech. Qualquer mouse Logitech com drivers que façam remapeamento da ação de rolagem para o mouse causará um erro do sistema ao ser utilizado para rolar.
Esta seção contém informações sobre a instalação do VisualAge for Java, Versão 4.0. Importante: Se estiver migrando de uma versão anterior do VisualAge for Java, consulte a seção 3.0 antes de instalar a Versão 4.0. Para obter informações especiais sobre a instalação no Windows 2000, consulte a seção 2.3.
Consulte também o README (que pode ser encontrado no diretório README do CD do produto) para obter informações sobre os problemas e limitações mais recentes.
A.2.1 Instalando o VisualAge for Java, Versão 4.0
Antes de instalar o produto, verifique o seguinte:
Se tentar instalar o VisualAge for Java no Windows, Millennium Edition, você será solicitado a aumentar o espaço de seu ambiente. As etapas descritas abaixo devem ser efetuadas antes que da instalação, caso contrário o sistema de ajuda do VisualAge for Java não funcionará corretamente. Para aumentar o espaço de seu ambiente, efetue as etapas a seguir:
A.2.1.1 Instalando o VisualAge for Java, Versão 4.0 a partir do CD do produto
Instalação silenciosa
Para instalar silenciosamente o VisualAge for Java, Versão 4.0, chame o seguinte comando
a partir do diretório ivj40\setup:
setup /s /v/qn
O VisualAge for Java é instalado automaticamente no diretório padrão c:\Arquivos de programas\IBM\VisualAge for Java.
Para instalar silenciosamente em um diretório diferente (por exemplo, d:\IBMVJava40), chame o seguinte comando a partir do diretório ivj40\setup:
setup /s /v"INSTALLDIR=\"d:\IBMVJava40\" /qn"
em que d:\IBMVJava40 é o diretório no qual você deseja instalar.
A.2.1.1.1 Instalando o Distributed Debugger a partir do CD do produto
Se estiver planejando depurar classes desenvolvidas
fora do IDE VisualAge for Java ou depurar programas que estejam em execução
em uma máquina separada, você deve instalar o Distributed Debugger. O Distributed
Debugger é suportado nos seguintes sistemas operacionais: Windows,
AIX, OS/2, HP-UX, Solaris, Linux e Linux/390. As instruções de instalação para
cada sistema operacional são fornecidos abaixo. Todos os arquivos
do Distributed Debugger estão no CD do produto, no diretório do Debugger.
Distributed Debugger para Windows
Distributed Debugger for OS/2
Siga as instruções no README_install.txt , que pode ser encontrado no subdiretório Debugger\OS2 no CD do produto.Distributed Debugger for HP-UX
Pré-requisito:
É necessário ter a versão 1.3 do Java para a instalação e para a depuração Java.
Distributed Debugger for Linux
Como root, digite o seguinte comando para instalar o depurador: rpm -Uvh DERJPICL-9-1.i386.rpmDistributed Debugger for Linux/390
Como root, digite o seguinte comando para instalar o depurador: rpm -Uvh DERJPICL-9-1.s390.rpm
Distributed Debugger for OS/390
A.2.1.2 Instalando a partir da imagem eletrônica do VisualAge for Java, Versão
4.0
Para reduzir o tempo de download, a imagem eletrônica do VisualAge for Java,
Edição Professional para Windows,
Versão 4.0, está dividida em partes.
A.2.1.2.1 IDE
Há nove partes das quais se pode efetuar download para o Integrated Development Environment. As
nove partes são archives de auto-extração. Você deve instalar os dois primeiros; o restante é
opcional. Consulte a lista abaixo para obter detalhes sobre o que cada archive contém.
Depois de ter feito download das duas primeiras partes mais os arquivos opcionais que deseja, execute cada archive de auto-extração e assegure que cada um seja extraído no mesmo diretório temporário. Depois de todos os arquivos terem sido extraídos, vá para o diretório temporário e execute setup.exe. Siga as instruções na tela e inicie o IDE.
Se estiver planejando trabalhar com qualquer idioma diferente do inglês, você deve efetuar download da parte correta e executar o archive de auto-extração para seu idioma antes de executar o setup.exe. Não é possível alterar ou incluir um idioma após a instalação do VisualAge for Java.
Se você estiver trabalhado com uma imagem eletrônica do VisualAge for Java, não será possível utilizar o diálogo Incluir/Remover Programas (Iniciar > Definições >Painel de Controle > Incluir/Remover Programas) para instalar componentes adicionais do VisualAge for Java depois da instalação inicial. Se isso for tentado, você receberá uma mensagem de erro e não conseguirá instalar nenhum componente adicional. O arquivo setup.exe deverá ser executado a partir do caminho de onde as partes de downloaded foram extraídas para que se possa incluir qualquer componente adicional no VisualAge for Java.
A seguir, uma descrição de cada parte do archive:
A.2.1.2.2 Distributed Debugger
Existe uma parte da qual é possível efetuar download separadamente para cada sistema operacional de destino,
que é suportado pelo Distributed Debugger. Se estiver planejando depurar classes desenvolvidas
fora do IDE VisualAge for Java ou depurar programas que estejam em execução
em uma máquina separada, você deve efetuar download e instalar o Distributed Debugger.
As instruções de instalação para cada sistema operacional são fornecidas abaixo. Você
também pode localizar estas instruções e informações sobre o contrato de licença
no arquivo readme.txt incluído com cada parte.
VisualAge for Java - Distributed Debugger para Windows contém a interface com o usuário e o mecanismo de depuração para Windows. Esta parte é um archive de auto-extração. Para instalá-lo, siga estas etapas:
VisualAge for Java - Distributed Debugger para HP-UX contém o mecanismo de depuração do HP-UX.
Pré-requisito:
É necessário ter a versão 1.3 do Java para a instalação e para a depuração Java.
Para instalá-lo, descompacte (untar) o arquivo e siga estas instruções:
VisualAge for Java - Distributed Debugger para Linux contém o mecanismo de depuração para o Linux. Para instalá-lo, descompacte (untar) o arquivo e instale o depurador seguindo estas instruções:
Como root, digite o seguinte comando: rpm -Uvh DERJPICL-9-1.i386.rpmVisualAge for Java - Distributed Debugger para Linux/390 contém o mecanismo de depuração para o Linux/390. Para instalá-lo, descompacte (untar) o arquivo e instale o depurador seguindo estas instruções:
Como root, digite o seguinte comando: rpm -Uvh DERJPICL-9-1.s390.rpm
Distributed Debugger for OS/390
A.2.1.2.3 IBM Developer Kit 1.2.2
VisualAge for Java - IBM Developer Kit 1.2.2 contém o IBM Developer Kit, Edição Java Technology, v 1.2.2, PTF 9, para a plataforma Windows. Este é um archive de auto-extração.Para
instalá-lo, execute o arquivo, o que lança automaticamente o programa de
instalação após a sua extração do archive, e siga as instruções.
A.2.2 Instalando os componentes adicionais mais tarde
Para instalar componentes adicionais do VisualAge for Java a qualquer momento após a instalação inicial, insira o CD-ROM em sua unidade de CD, selecione instalar o VisualAge for Java e selecione Modificar na tela Manutenção do Programa. Se a execução automática estiver desativada em seu sistema, você terá que executar setup.exe na raiz da unidade de CD. Se você tiver uma versão eletrônica do VisualAge for Java, você também terá de executar manualmente o setup.exe e seguir as mesmas etapas.
Todos os componentes serão listados na janela Editar Recursos, com uma indicação de seu estado de instalação atual. Um 'X' vermelho indica que um componente não está instalado atualmente. Você pode selecionar instalar esses componentes. Não selecione nenhum componente que não estejam marcados com um 'X' vermelho; eles já foram instalados.
Não é possível instalar uma segunda instância do VisualAge for Java, Versão 4.0. O idioma de instalação não pode ser alterado sem antes desinstalar o produto.
A.2.3 Considerações sobre a instalação do Windows 2000
Este release do VisualAge for Java continua fornecendo suporte de tolerância (conforme definido pela Microsoft) para o Windows 2000.
O diretório padrão de instalação é <Arquivos de programas>\IBM\VisualAge for Java. Para o Windows 2000, por padrão, a instalação em <Arquivos de Programas> pode ser executada somente por Administradores e usuários Padrão (Avançados). Usuários normais (Restritos) não podem gravar nesta localização.
Devido ao design atual do VisualAge for Java, se o produto estiver instalado nessa localização e precisar ser utilizado por um usuário Comum (Restrito), é necessário alterar as definições de segurança do diretório IBM ou IBM\VisualAge for Java nos <Arquivos de programas> a fim de permitir acesso de gravação pelos usuários comuns. Falha em fazer isso pode resultar em falhas ao tentar iniciar o IDE.
A.2.4 Instalando o IBM Developer Kit, Edição Java Technology, v1.2.2, PTF 9
Se instalou o VisualAge for Java a partir do CD do produto, você deverá executar o arquivo install.exe a partir diretório do IBM Developer Kit para instalar o IBM Developer Kit, Edição Java Technology, v1.2.2, PTF 9. Este diretório está localizado no CD do produto. Se você possuir uma versão eletrônica do VisualAge for Java, este diretório estará localizado em seu diretório temporário (para o qual você extraiu as partes). Entretanto, você não precisa executar o arquivo install.exe pois o programa de instalação é lançado automaticamente após ter sido extraído do archive do IBM Developer Kit do qual foi feito o download.
Para obter informações detalhadas sobre o IBM Developer Kit, consulte o arquivo README no diretório do IBM Developer Kit.
Consulte a Parte D e a Parte E para obter informações sobre migração específica de componente e migração geral antes de iniciar o processo de migração.
É possível migrar automaticamente da Versão 3.5 ou Versão 3.5.3. A Versão 4.0 é instalada sobre a Versão 3.5 ou Versão 3.5.3. Consulte a seção 3.1 para obter informações sobre a migração do VisualAge for Java Versão 3.5 ou Versão 3.5.3.
É preciso migrar manualmente do 3.0x, Early Adopters. Consulte a seção 3.2 para obter informações sobre a migração do VisualAge for Java, 3.0x, Early Adopters.
Se, atualmente, você estiver utilizando o VisualAge for Java, Versão 2.0, 3.0 ou 3.02 com o suporte a JDK 1.1.x, não será possível migrar automaticamente para o VisualAge for Java, Versão 4.0. Estas versões do VisualAge for Java podem coexistir com o VisualAge for Java, Versão 4.0. Consulte a seção 3.2 para obter informações sobre como migrar o conteúdo de seu repositório e os arquivos de recursos da Versão 2.0 ou 3.0x do VisualAge for Java.
Você não pode migrar do VisualAge for Java, Versão 3.5, Edição Entry Enterprise ou VisualAge for Java, Versão 3.5, ou Versão 3.5.3 Edição Enterprise, para o VisualAge for Java, Versão 4.0, Edição Professional. É necessário migrar para a Versão 4.0, Edição Enterprise.
Nota: Ao migrar do VisualAge for Java, Versão 3.5 ou Versão 3.5.3 para a Versão 4.0, o processo de instalação poderá parecer interrompido. Isso ocorre porque a função "DoCosting" (que compara as versões 3.5 ou 3.5.3 dos arquivos com as versões 4.0 dos arquivos) pode levar até três minutos para ser executada, dando a impressão de que o processo de instalação foi interrompido.
A.3.1 Migrando da Versão 3.5 ou da Versão 3.5.3
A migração do VisualAge for Java, Versão 3.5 ou Versão 3.5.3 é automática. O programa de instalação da Versão 4.0 faz automaticamente o upgrade de um produto instalado da Versão 3.5 ou Versão 3.5.3 para a Versão 4.0.
Migração automática
Caso ocorra uma falha na instalação, você deverá migrar manualmente os dados de usuário. Você também deve migrar manualmente seus dados de usuário se o IDE não for iniciado ou se for encontrado um erro pelo IDE quando ele estiver migrando seus dados de usuário.
Migração manual
A.3.2 Migrando da Versão 2.0, 3.0x ou 3.0x Early Adopters do VisualAge for Java
Você pode migrar manualmente o conteúdo de seu repositório e dos arquivos de recursos da Versão 2.0, Versão 3.0x, 3.0x, Early Adopters do VisualAge for Java. Consulte o arquivo da ajuda online "Corrigindo referências de classes ou pacotes" para obter informações sobre como corrigir interrupções.
Não é necessário desinstalar a Versão 2.0, 3.0x ou 3.0x, Early Adopters; elas podem coexistir com o VisualAge for Java, Versão 4.0.
Siga todas as etapas abaixo antes de desinstalar a Versão 2.0, 3.0x ou 3.0x, Early Adopters, se desejar importar os arquivos de repositório e de recurso da Versão 2.0, 3.0x ou 3.0x Early Adopters Environment for Java 2 Plataform, Standard Edition, v1.2 para a Versão 4.0. Se você não estiver desinstalando a Versão 2.0, 3.0x ou 3.0x Early Adopters, não será necessário executar as etapas 2, 3, 4 e 8, mas as demais etapas deverão ser executadas.
Consulte também o README (que pode ser encontrado no diretório README do CD) para obter informações sobre os problemas e limitações mais recentes.
A.4.1 Problemas e limitações conhecidos na instalação
Segue abaixo uma lista de questões das quais você deve ter conhecimento durante a instalação.
A.4.1.1 Limitações de disco
A.4.1.2 Autorização do usuário
A.4.1.3 Considerações sobre o TCP/IP
Estas opções de configuração serão aplicadas a todas os adaptadores TCP/IP, embora elas tenham sido alteradas somente para esta. Não será possível utilizar a LAN nem dial-up sem reconfiguração.
As propriedades TCP/IP da rede dial-up de seu provedor de serviço Internet (ISP) devem ser configuradas conforme documentadas pelo ISP. As propriedades TCP/IP de rede dial-up irão substituir as propriedades em propriedades TCP/IP da Placa dial-up configuradas através do ícone Rede no Painel de Controle do Windows 98 ou Windows 2000. A substituição das propriedades ocorrerá somente se as propriedades TCP/IP do Adaptador Dial-Up forem configuradas como acima. Você não deve ativar o DNS nas propriedades TCP/IP do Adaptador dial-up ou definir um endereço IP nelas, porque assim irá interferir com a configuração da rede dial-up no ISP.
Para Windows NT 4.0, você pode utilizar as configurações TCP/IP descritas acima. Se a execução for feita no modo independente, é possível ativar o Microsoft Loopback Adapter sem os outros dois adaptadores.
A.4.1.4 Extensão do Shell (Windows NT)
Se receber uma mensagem que indique que o programa de instalação detectou uma extensão shell para Windows NT, a instalação não poderá prosseguir. Será necessário, então, executar os seguintes passos:
A.4.1.5 Recuperação de uma instalação falha
Se sua instalação falhar, você deverá remover qualquer arquivo da Versão 4.0 que tenha sido instalado. Se o diretório no qual você pretende instalar o VisualAge for Java estiver vazio, o processo de instalação é retrocedido e remove todos os arquivos já instalados. O diretório vazio pode ser removido se você quiser, mas não é necessário. No entanto, se o diretório contiver arquivos, então, será necessário iniciar o processo de instalação novamente. Ele será aberto no modo de manutenção e você deverá selecionar para remover sua instalação parcial da Versão 4.0 antes de tentar instalar o produto novamente.
Será necessário excluir também a entrada do registro:
\\HKEY_LOCAL_MACHINE\SOFTWARE\IBM\VisualAge for Java para Windows
utilizando as seguintes instruções:
Se algum arquivo NetQuestion tiver sido instalado antes da instalação falhar, você deverá excluí-lo também.
IMNINSTSRV=C:\imnnq_nt
A localização de seu diretório NetQuestion pode aparecer de maneira diferente, dependendo da unidade em que o VisualAge for Java é instalado e de qual o sistema operacional que você está utilizando. Se a variável estiver definida(ou seja, se for fornecida a localização em que o NetQuestion está instalado), continue na etapa 2.
Se você receber uma mensagem de erro como "Variável de ambiente imninstsrv não definida" é possível que nenhum arquivo do NetQuestion tenha sido instalado ou que a instalação do NetQuestion não tenha sido concluída com êxito. Se isto ocorrer, selecione Iniciar > Localizar > Arquivos ou Pastas e pesquise o seguinte arquivo em seu sistema: vahelp.cfg. Se localizar este arquivo em qualquer diretório cujo nome comece com "imnnq" (por exemplo, imnnq_NT or imnnq_98), exclua-o. Não é preciso efetuar as etapas 2 e 3.
Esta ação remove qualquer arquivo NetQuestion que o VisualAge for Java tenha instalado. Ele não irá afetar os arquivos NetQuestion instalados por outros produtos (por exemplo, DB2).
Faça backup dos arquivos do repositório e de recursos, se ainda não tiver feito isso. Consulte a Parte A, Seção 3.1 para obter informações sobre como executar essa tarefa.
Reinicialize e reinstale o produto após executar todas estas etapas. Se a ajuda falhar após a reinstalação do VisualAge for Java, consulte o Manual de Resolução de Problemas para obter mais informações sobre a recuperação de falhas da ajuda. O Manual de Resolução de Problemas (trshoot.htm) está localizado no CD do produto VisualAge for Java, Edição Professional e no CD Additional Features do VisualAge for Java, Edição Enterprise. Depois de instalar o VisualAge for Java, ele também está localizado em X:\IBMVJava, em que X:\IBMVJava é o diretório de instalação do VisualAge for Java.
A.4.1.6 Erros do Windows Installer
A seguir está uma lista de erros do Windows Installer os quais você deve ter conhecimento durante a instalação.
Erro 1603 (Somente Windows NT 4.0)
Se você receber uma mensagem de erro 1603 quando estiver instalando o VisualAge for Java, isto indica que o Windows Installer falhou ao inicializar e a instalação não pode prosseguir.
Alguns produtos (como o VisualCafe da Symantec) instalam automaticamente um arquivo denominado sfc.dll quando são instalados em qualquer plataforma Windows. É utilizado somente no Windows 2000, em que o Windows Installer o chama para processamento de segurança.
Se um arquivo com este nome residir na PATH no Windows NT 4.0, o Windows Installer tentará carregá-lo, mesmo que o sfc.dll seja aplicável somente ao Windows 2000. O Windows Installer então falhará.
Para solucionar esse problema, execute estas etapas:
Erro Fatal LoadLibrary()
O erro Fatal LoadLibrary() ocorre porque um ou mais kernels de instalação do VisualAge for Java (IKernels) não foram registrados corretamente pelo Windows Installer. Para resolver este problema, você deve excluir o diretório do InstallShield em que os arquivos do IKernal residem e reinstalar o VisualAge for Java seguindo estas etapas:
Erro 1631 ou Erro Interno 2755 (somente Windows NT 4.0)
Se você instalar o VisualAge for Java no Windows NT 4.0, poderá receber uma das seguintes mensagens de erro:
Se você receber qualquer uma dessas mensagens de erro, isto indica que talvez tenha chaves de registro com valores nulos. Quando iniciar a instalação do VisualAge for Java, o arquivo userenv.dll tentará analisar várias chaves de registro e, se alguma das chaves tiver valores nulos, a instalação falhará com uma das mensagens de erro acima.
Para corrigir este comportamento, você deve remover as variáveis de ambiente nulas ou modificá-las (alterar o valor de nulo para um valor válido) antes de instalar o VisualAge for Java. Depois de instalar o VisualAge for Java, você pode retorná-las ao seu valor original.
Cuidado: Remova ou modifique as variáveis nulas com cuidado. Você deve considerar qualquer possível impacto que possa ocorrer antes da remoção ou modificação delas.
Erros Internos 2381, 1303, 1310, 1313 (somente Windows NT)
Se tiver tentando instalar o VisualAge for Java e qualquer uma ou todas as condições a seguir forem verdadeiras:
Você pode receber uma ou mais das seguintes mensagens de erro:
Foi relatado que este problema ocorre quando existem somente permissões de Leitura nas seguintes pastas:
\Arquivos de Programas\IBM\VisualAge for Java
\WinNT\Installer
Para resolver este problema, certifique-se de que tenha as permissões necessárias em suas unidades ou diretórios. Para isso, faça o seguinte:
Erro Interno 2735 Inicialização de Mecanismo
Se você receber o erro 2735, execute as seguintes etapas para resolvê-lo:
Erro 1606/Erro Interno 2707
Se você receber a seguinte mensagem de erro, isto indica que o valor do arquivo de registro das Ferramentas Administrativas Comuns pode estar incorreto:
Erro 1606. Não é possível acessar o local da rede \Profiles\AllUsers\StartMenu\Programs\Administrative
Tools\.
Erro Interno 2707. INSTALLDIR.
Você deve editar o valor do arquivo de registro das Ferramentas Administrativas Comuns antes de instalar o VisualAge for Java. Para isso, siga estas etapas:
A.4.2 Problemas e limitações conhecidos na desinstalação
Segue uma lista das questões das quais você deve ter conhecimento quando estiver removendo a instalação do VisualAge for Java.
A.4.2.1 Espaço em disco
Você deve ter ao menos 2 MB livres na unidade do sistema Windows e a variável de ambiente TEMP ou TMP deve indicar um diretório temporário válido com pelo menos 5 MB livres.
A.4.2.2 Remoção da instalação do Distributed Debugger
Se você instalou o Distributed Debugger como parte da instalação do VisualAge for Java, deve desinstalar o VisualAge for Java antes de desinstalar o Distributed Debugger. Depois de ter desinstalado o VisualAge for Java, você poderá desinstalar o Distributed Debugger indo ao diretório de instalação do Debugger e executando o programa de desinstalação.
Caso tenha desinstalado o VisualAge for Java e não consiga desinstalar o Distributed Debugger, será necessário excluir a chave de registro:
HKEY_LOCAL_MACHINE/SOFTWARE/IBM/IBM Distributed Debugger/CurrentVersion/install/ParentProducts/VisualAge for Java
e, em seguida, tentar desinstalar o Debugger novamente. NÃO siga estas etapas se estiver utilizando o Distributed Debugger com quaisquer outros produtos, porque não mais será possível utilizar o depurador após a exclusão da chave do registro.
Siga estas etapas:
Defina também o valor da seguinte chave de registro como 1:
HKEY_LOCAL_MACHINE/SOFTWARE/IBM/IBM Distributed Debugger/CurrentVersion/install/refcount
A.4.2.3 Variáveis de ambiente (Windows 98)
Ao desinstalar o VisualAge for Java no Windows 98, algumas entradas de ambiente podem ser deixadas em seu arquivo autoexec.bat. Normalmente estas entradas restantes não causam problemas, mas se você desinstalar e reinstalar o produto várias vezes, podem ocorrer dois problemas. Você poderá ter instruções de caminho conflitantes que impedirão a ajuda online de funcionar ou poderá ficar sem espaço na variável PATH, o que impedirá a reinstalação correta do produto
Para solucionar esses problemas:
A.4.2.4 Desinstalando o NetQuestion
Quando você estiver desinstalando o VisualAge for Java, o NetQuestion não pode ser desinstalado. Podem ocorrer problemas se a instalação do NetQuestion não for removida e posteriormente você tentar reinstalar o produto.
Para remover arquivos do NetQuestion instalados pelo VisualAge for Java, siga as etapas a seguir. Ele não irá afetar os arquivos NetQuestion instalados por outros produtos (por exemplo, DB2).
IMNINSTSRV=C:\imnnq_nt
A localização de seu diretório do NetQuestion pode aparecer de maneira diferente, dependendo da unidade em que o VisualAge for Java foi instalado e do sistema operacional em uso. Se você receber uma mensagem de erro como "Variável de ambiente imninstsrv não definida", então a instalação de todos os arquivos do NetQuestion terá sido removida.
Isto remove qualquer arquivo NetQuestion que o VisualAge for Java tenha instalado.
Se depois você reinstalar o VisualAge for Java e a ajuda falhar, consulte o Manual de Resolução de Problemas para obter mais informações sobre a recuperação de falhas da ajuda. O Manual de Resolução de Problemas (trshoot.htm) está localizado no CD do produto VisualAge for Java, Edição Professional e no CD Additional Features do VisualAge for Java, Edição Enterprise. Depois de instalar o VisualAge for Java, ele também está localizado em X:\IBMVJava, em que X:\IBMVJava é o diretório de instalação do VisualAge for Java.
Esta edição do VisualAge for Java, Versão 4.0, tem os seguintes pré-requisitos de hardware e software:
Se você quiser executar o Websphere Application Server com DB2 e VisualAge for Java ao mesmo tempo, então, pelo menos 512 MB são recomendados.
Você deverá utilizar o EMSRV, Versão 7.1, se estiver trabalhando em um ambiente de equipe. Para obter informações sobre como mover-se da Versão 6.x ou 7.0 para a Versão 7.1, consulte a Parte C.
* Nota: O VisualAge for Java não suporta o mouse de rolagem Logitech. Qualquer mouse Logitech com drivers que remapeiam ação de deslocamento para o mouse causará um erro de sistema quando for utilizado para deslocamento.
B.1.2 Pré-requisitos específicos do componente
Alguns componentes têm pré-requisitos específicos:
Nas estações de trabalho, o NFS Maestro Client para Windows NT ou Windows 2000. Para o NFS Client para Windows NT, você deverá efetuar uma montagem binária para o diretório do HFS para o qual os arquivos de classe serão exportados.
- IMS Connect V1.1 e IMS Versão 7 (recomendado) ou
- IMS Connect V1.1 e IMS Versão 5.1 ou 6.1
Esta seção contém informações sobre a instalação do VisualAge for Java, Versão 4.0. Importante: Se estiver migrando de uma versão anterior do VisualAge for Java, consulte a seção 3.0 abaixo antes de instalar o VisualAge for Java, Versão 4.0. Para obter informações especiais sobre a instalação no Windows 2000, consulte a seção 2.5.
Consulte também o README (que pode ser encontrado no diretório raiz do CD do produto) para obter informações sobre os problemas e limitações mais recentes.
Importante : Devido a uma limitação no suporte do sistema de arquivos de CD-ROM (CDFS) no Windows 98, a instalação de determinados arquivos conectores de e-business do CD-ROM poderão falhar e fazer com que um ou mais dos seguintes diálogos de erro sejam exibidos, dependendo dos conectores selecionados:
Todos os arquivos que não foram instalados são armazenados em um arquivo zip (econnfix.zip) localizado na raiz do CD do produto. Se você estiver tentando instalar o VisualAge for Java no Windows 98 e receber uma das mensagens acima, descompacte o econnfix.zip no diretório no qual o produto foi instalado (por exemplo, executando o comando unzip econnfix.zip -d c:\Arquivos de Programas\IBM\VisualAge for Java\ em que c:\Arquivos de Programas\IBM\VisualAge for Java\ é o diretório de instalação do produto). Depois desses arquivos estarem localizados, os conectores funcionarão corretamente.
B.2.1 Instalando o VisualAge for Java, Versão 4.0, Edição Enterprise
Antes de instalar o produto, verifique o seguinte:
Se tentar instalar o VisualAge for Java no Windows, Millennium Edition, você será solicitado a aumentar o espaço de seu ambiente. As etapas descritas abaixo devem ser efetuadas antes que da instalação, caso contrário o sistema de ajuda do VisualAge for Java não funcionará corretamente. Para aumentar o espaço de seu ambiente, efetue as etapas a seguir:
Execute as seguintes instruções, independentemente de estar instalando os clientes da equipe do VisualAge for Java ou um cliente com repositório local. Consulte a seção 2.3 para obter detalhes sobre a instalação de um cliente da equipe, ou a seção 2.4 para obter detalhes sobre a instalação de um repositório local.
B.2.1.1 Instalando o VisualAge for Java, Versão 4.0, a partir do CD do produto
Instalação silenciosa
Para instalar silenciosamente o VisualAge for Java, Versão 4.0, chame o seguinte comando
a partir do diretório ivj40\setup:
setup /s /v/qn
O VisualAge for Java é instalado automaticamente no diretório padrão c:\Arquivos de programas\IBM\VisualAge for Java.
Para instalar silenciosamente em um diretório diferente (por exemplo, d:\IBMVJava40), chame o seguinte comando a partir do diretório ivj40\setup:
setup /s /v"INSTALLDIR=\"d:\IBMVJava40\" /qn"
em que d:\IBMVJava40 é o diretório no qual você deseja instalar.
Nota: Você não pode conectar-se a um repositório compartilhado quando instalar o VisualAge for Java silenciosamente; pode conectar-se somente a um repositório local se utilizar a instalação silenciosa. Se desejar instalar silenciosamente e trabalhar ainda em um ambiente de equipe, você deverá instalar localmente e, em seguida, conectar-se a seu repositório compartilhado após ter instalado o produto e iniciado o IDE. Consulte o arquivo team.pdf no diretório pdf para obter instruções sobre como instalar localmente, mas trabalhe em um ambiente de equipe. O diretório pdf está localizado no CD Additional Features do VisualAge for Java, Edição Enterprise. Se você tiver uma versão eletrônica do VisualAge for Java, ela poderá ser encontrada no diretório temporário (para o qual você extraiu suas partes). Se você não fez download da parte que contém os PDFs, esse diretório não existirá.
B.2.1.1.1 Instalando o Distributed Debugger a partir do CD do produto
Se estiver planejando depurar classes desenvolvidas
fora do IDE VisualAge for Java ou depurar programas que estejam em execução
em uma máquina separada, você deve instalar o Distributed Debugger. O Distributed
Debugger é suportado nos seguintes sistemas operacionais: Windows,
AIX, OS/2, HP-UX, Solaris, Linux e Linux/390. As instruções de
instalação para cada sistema operacional são fornecidas
abaixo. Todos os arquivos do Distributed Debugger estão no CD
Additional Features.
Distributed Debugger para Windows
Distributed Debugger for OS/2
Siga as instruções no README_install.txt, que pode ser encontrado no subdiretório Debugger\OS2, no CD Additional Features.Distributed Debugger for HP-UX
Pré-requisito:
É necessário ter a versão 1.3 do Java para a instalação e para a depuração Java.
Distributed Debugger for Linux
Como root, digite o seguinte comando para instalar o depurador: rpm -Uvh DERJPICL-9-1.i386.rpmDistributed Debugger for Linux/390
Como root, digite o seguinte comando para instalar o depurador: rpm -Uvh DERJPICL-9-1.s390.rpm
Distributed Debugger for OS/390
B.2.1.1.2 Instalando a versão beta de componentes J2EE
Este release do VisualAge for Java inclui uma versão beta de vários componentes
do Java 2 Platform, Edição Enterprise (J2EE (TM)). A
Sun Microsystems Inc. não liberou esses componentes do J2EE oficialmente. Especificamente,
este release do VisualAge for Java inclui uma versão beta dos seguintes
componentes do J2EE:
Os componentes beta estão localizados no subdiretório extras\BetaJ2EEConnectors no CD Additional Features. Se desejar utilizar estes componentes beta, consulte o arquivo README no subdiretório BetaJ2EEConnectors, que contém instruções de instalação para os componentes.
B.2.1.2. Instalando a partir da imagem eletrônica do VisualAge for Java, Versão
4.0
Para reduzir o tempo de download, a imagem eletrônica do VisualAge for Java, Edição Enterprise para Windows,
Versão 4.0, está dividida em partes.
B.2.1.2.1 IDE
Existem quatorze partes da quais se pode efetuar download para o Integrated Development Environment. Todas as
quatorze partes são archives de auto-extração. Você deve instalar os dois primeiros; o restante é
opcional. Consulte a lista abaixo para obter detalhes sobre o que cada archive contém.
Depois de ter feito download das duas primeiras partes mais os arquivos opcionais que deseja, execute cada archive de auto-extração e assegure que cada um seja extraído no mesmo diretório temporário. Depois de todas as partes terem sido extraídas, vá para o diretório temporário e execute setup.exe. Siga as instruções na tela e inicie o IDE.
Se estiver planejando trabalhar com qualquer idioma diferente do inglês, você deve efetuar download da parte correta e executar o archive de auto-extração para seu idioma antes de executar o setup.exe. Não é possível alterar ou incluir um idioma após a instalação do VisualAge for Java
Se você estiver trabalhando com uma imagem eletrônica do VisualAge for Java, não será possível utilizar o diálogo Incluir/Remover Programas (Iniciar > Definições >Painel de Controle > Incluir/Remover Programas) para instalar componentes adicionais do VisualAge for Java depois da instalação inicial. Se isso for tentado, você receberá uma mensagem de erro e não conseguirá instalar nenhum componente adicional. O arquivo setup.exe deverá ser executado a partir do caminho de onde as partes de downloaded foram extraídas para que se possa incluir qualquer componente adicional no VisualAge for Java.
A seguir, uma descrição de cada parte:
B.2.1.2.2. Distributed Debugger
Existe uma parte da qual é possível efetuar download separadamente para cada sistema operacional de destino,
que é suportado pelo Distributed Debugger. Se estiver planejando depurar classes desenvolvidas
fora do IDE VisualAge for Java ou depurar programas que estejam em execução
em uma máquina separada, você deve efetuar download e instalar o Distributed Debugger.
As instruções de instalação para cada sistema operacional são fornecidas abaixo. Você também pode localizar estas instruções e informações sobre o contrato de licença
no arquivo readme-1st.txt incluído com cada parte.
VisualAge for Java - Distributed Debugger para Windows contém a interface com o usuário e o mecanismo de depuração para Windows. Esta parte é um archive de auto-extração. Para instalá-lo, siga estas etapas:
VisualAge for Java - Distributed Debugger para OS/2 contém o mecanismo de depuração do OS/2. Para instalá-lo, siga as instruções no README_install.txt (incluído com a parte do Distributed Debugger para OS/2).
VisualAge for Java - Distributed Debugger para HP-UX contém o mecanismo de depuração do HP-UX.
Pré-requisito:
É necessário ter a versão 1.3 do Java para a instalação e para a depuração Java.
Para instalá-lo, descompacte (untar) o arquivo e siga estas instruções:
VisualAge for Java - Distributed Debugger para Linux contém o mecanismo de depuração para o Linux. Para instalá-lo, descompacte (untar) o arquivo e instale o depurador seguindo estas instruções:
Como root, digite o seguinte comando: rpm -Uvh DERJPICL-9-1.i386.rpmVisualAge for Java - Distributed Debugger para Linux/390 contém o mecanismo de depuração para o Linux/390. Para instalá-lo, descompacte (untar) o arquivo e instale o depurador seguindo estas instruções:
Como root, digite o seguinte comando: rpm -Uvh DERJPICL-9-1.s390.rpm
Distributed Debugger for OS/390
B.2.1.2.3 EMSRV (servidor de equipe)
VisualAge for Java - EMSRV 7.1 contém o programa do servidor de repositório
para o ambiente de desenvolvimento de equipe. Uma única parte do archive contém
código do servidor par Windows, AIX, OS/2, NetWare, HP-UX, Linux e Solaris
no formato de arquivo ZIP. Para instalar, descompacte essa parte e siga as
instruções em instmigr.htm
B.2.1.2.4 IBM Developer Kit 1.2.2
VisualAge for Java - IBM Developer Kit 1.2.2 contém o IBM Developer Kit, Java Edição Technology,
v 1.2.2,
PTF 9,
para a plataforma Windows. Este é um archive de auto-extração. Para
a instalação, execute esse arquivo, que lançará automaticamente o
programa de instalação depois de ter sido extraído do archive, e siga
as instruções.
B.2.2 Instalando componentes adicionais mais tarde
Para instalar componentes adicionais do VisualAge for Java a qualquer momento após a instalação inicial, insira o CD-ROM na unidade de CD, selecione instalar o VisualAge for Java e selecione Modificar na tela Manutenção do Programa. Se a execução automática estiver desativada em seu sistema, você terá que executar setup.exe na raiz da unidade de CD. Se você tiver uma versão eletrônica do VisualAge for Java, você também terá de executar manualmente o setup.exe e seguir as mesmas etapas.
Todos os componentes serão listados na janela Editar Recursos, com uma indicação de seu estados atuais de instalação. Um 'X' vermelho indica que um componente não está instalado atualmente. Você pode selecionar instalar esses componentes. Não selecione nenhum componente que não estejam marcados com um 'X' vermelho; eles já foram instalados.
Não é possível instalar uma segunda instância do VisualAge for Java, Versão 4.0. O idioma de instalação não pode ser alterado sem antes desinstalar o produto.
B.2.3 Instalando os clientes da equipe do VisualAge for Java
Antes de cada membro da equipe de desenvolvimento poder seguir essas etapas, o administrador do EMSRV precisa ter configurado e iniciado o servidor, testado a conexão com o cliente e incluído os desenvolvedores da equipe na lista de usuários do repositório. Consulte a parte C desse manual para obter informações sobre como executar essas tarefas. A Parte C fornece também informações sobre como migrar um repositório de equipe.
Nas instruções a seguir, supõe-se que o repositório compartilhado instalado no servidor seja denominado ivj.dat. O EMSRV, Versão 7.1 deve ter sido instalado em seu servidor. Você pode receber uma mensagem de erro se tentar conectar-se a uma versão anterior do EMSRV.
B.2.4 Instalando um cliente que possui um repositório independente
Você pode querer ter seu próprio repositório de código fonte do VisualAge for Java em sua estação de trabalho para ser usado quando não estiver conectado ao repositório compartilhado. Neste caso, quando estiver instalando o VisualAge for Java, Versão 4.0, em sua estação de trabalho, especifique se seu repositório estará em sua máquina local, em vez de estar no servidor. O programa de instalação criará um repositório para você.
Quando quiser utilizar o repositório compartilhado no servidor de equipe, consulte a ajuda online ou o arquivo team.pdf. O arquivo team.pdf está no diretório pdf. O diretório pdf está localizado no CD Additional Features do VisualAge for Java, Edição Enterprise. Se você tiver uma versão eletrônica do VisualAge for Java, ela poderá ser encontrada no diretório temporário (para o qual você extraiu suas partes). Se você não fez download da parte que contém os PDFs, esse diretório não existirá.
B.2.5 Considerações sobre a instalação e utilização do Windows 2000
Este release do VisualAge for Java continua a fornecer suporte de tolerância (conforme definido pela Microsoft) ao Windows 2000.
O diretório padrão de instalação é <Arquivos de programas>\IBM\VisualAge for Java. Para o Windows 2000, por padrão, a instalação em <Arquivos de Programas> pode ser executada somente por Administradores e usuários Padrão (Avançados). Usuários normais (Restritos) não podem gravar nesta localização.
Devido ao design atual do VisualAge for Java, se o produto estiver instalado nessa localização e precisar ser utilizado por um usuário Comum (Restrito), é necessário alterar as definições de segurança do diretório IBM ou IBM\VisualAge for Java nos <Arquivos de programas> a fim de permitir acesso de gravação pelos usuários comuns. Falha em fazer isso pode resultar em falhas ao tentar iniciar o IDE ou enquanto tiver usando algumas ferramentas do VisualAge for Java no IDE.
A lista de servidores do AS/400 Enterprise Toolkit está armazenada como "<Arquivos de programas>\IBM\arquivos compartilhados\fvdctcp.txt". Novamente, por padrão, essa localização está protegida e não pode ser gravada por usuários Regulares. Se um usuário sem autoridade suficiente tentar criar ou atualizar a lista do servidor através de qualquer botão Incluir/Modificar lista do servidor dos SmartGuides do AS/400, a criação ou atualização do arquivo falhará com um erro io no código Java, que pode aparecer ou não no log ou console.
O Administrador do sistema precisa determinar se deve dar acesso de gravação ao usuário regular para essa localização ou mantê-la protegida e carregar o arquivo manualmente, impedindo que usuários não autorizados atualizem o arquivo.
B.2.6 Instalando o IBM Developer Kit, Edição Java Technology, v1.2.2, PTF 9
Se você instalou o VisualAge for Java a partir do CD do produto, deve executar o install.exe no diretório do IBM Developer Kit para instalar o IBM Developer Kit, Edição Java Technology, v1.2.2, PTF 9. Este diretório está localizado no CD Additional Features. Se você tiver uma versão eletrônica do VisualAge for Java, este diretório estará localizado em seu diretório temporário (para onde você extraiu as partes), no entanto, não é necessário executar o install.exe, porque o programa de instalação é lançado automaticamente após ser descompactado do archive do IBM Developer Kit do qual foi efetuado download.
Para obter informações detalhadas sobre o IBM Developer Kit, consulte o arquivo README no diretório do IBM Developer Kit.
Consulte a Parte D e a Parte E para obter informações sobre migração específica de componente e migração geral antes de iniciar o processo de migração.
O upgrade do VisualAge for Java, Versão 4.0, executará atualizações no repositório durante a instalação para trazer as bibliotecas de classe do sistema no repositório para o nível de release correto. Isto requer que o repositório esteja disponível para acesso no modo leitura e gravação durante este upgrade. Nenhum código de usuário será modificado durante esta operação.
Se estiver migrando de uma versão anterior do VisualAge for Java, Edição Enterprise, e trabalhar em um ambiente independente (em vez de um ambiente de equipe), siga as instruções de migração para a Edição Professional na Parte A deste documento para continuar trabalhando em um ambiente independente.
Nota: Ao migrar do VisualAge for Java, Versão 3.5 ou Versão 3.5.3 para a Versão 4.0, o processo de instalação poderá parecer interrompido. Isso ocorre porque a função "DoCosting" (que compara as versões 3.5 dos arquivos com as versões 4.0 dos arquivos) pode levar até três minutos para ser executada, dando a impressão de que o processo de instalação foi interrompido.
Se for migrar de um ambiente de equipe ou para um ambiente de equipe, considere os seguintes itens antes de começar o processo de migração.
As etapas que precisarão ser seguidas ao migrar, dependem de sua situação e de suas respostas às perguntas feitas acima.
O seguinte cenário de migração é um dos mais complicados. Neste cenário, você tem mais de um repositório compartilhado e N desenvolvedores com repositórios locais da Versão 3.5. ou da Versão 3.5.3. Você pode utilizar o novo repositório da Versão 4.0, mas também continuar utilizando todos os dados dos repositórios compartilhados antigos.
Nota: Este cenário mostra como lidar com os repositórios locais da Versão 3.5 ou Versão 3.5.3 (Java 2), não os repositórios locais do JDK 1.1.x. Para importar as informações do repositório local do JDK 1.1.x para o seu repositório da Versão 4.0, siga as instruções da Seção 3.2 da Parte A.
Agora, o processo de migração está completo e os usuários poderão alternar entre um repositório local ou um repositório compartilhado, como desejarem. Nota: Se estiver migrando de um ambiente de equipe para um ambiente local, você deverá exportar seus projetos manualmente de seu repositório compartilhado antigo para o seu repositório local. Da mesma forma, se você tinha um repositório local, será necessário importar qualquer projeto que deseje utilizar de seu antigo repositório local para o seu novo repositório local da Versão 4.0.
B.3.1 Migrando um repositório compartilhado de uma versão anterior do VisualAge for Java
Você deve fazer o upgrade para EMSRV 7.1 antes que possa executar as etapas a seguir. Você encontrará instruções sobre como executar esta tarefa na seção C.3.1
Você pode fazer upgrade de seu repositório compartilhado da Versão 2.0 ou 3.0x (baseado em JDK 1.1) ou 3.0x, Early Adopters, ou 3.5 (baseado em JDK 1.2), para trabalhar com o VisualAge for Java, Versão 4.0. Nas etapas abaixo, o administrador de equipe executa uma instalação completa do VisualAge for Java, Versão 4.0 utilizando um repositório local. Em seguida, ele exporta todo o conteúdo do repositório local para todos os repositórios compartilhados.
Para fazer upgrade de um repositório existente no servidor para trabalhar com o VisualAge for Java, Versão 4.0, siga estas etapas:
Todos os projetos são copiados para o repositório compartilhado. Seus arquivos de recursos do projeto também são exportados. Se o repositório para o qual estiver exportando chamar-se sample.dat, seus recursos de projetos serão exportados para uma pasta chamada sample.dat.pr.
Consulte também o README (que pode ser encontrado no diretório README do CD) para obter informações sobre os problemas e limitações conhecidos mais recentes.
B.4.1 Limitações e problemas conhecidos da Instalação
Segue uma lista de questões das quais você deve ter conhecimento quando estiver instalando o VisualAge for Java.
B.4.1.1 Limitações de disco
B.4.1.2 Autorização do usuário
B.4.1.3 Considerações sobre o TCP/IP
Estas opções de configuração serão aplicadas a todas os adaptadores TCP/IP, embora elas tenham sido alteradas somente para esta. Não será possível utilizar a LAN nem dial-up sem reconfiguração.
As propriedades TCP/IP da rede dial-up de seu provedor de serviço Internet (ISP) devem ser configuradas conforme documentadas pelo ISP. As propriedades TCP/IP de rede dial-up irão substituir as propriedades em propriedades TCP/IP da Placa dial-up configuradas através do ícone Rede no Painel de Controle do Windows 98 ou Windows 2000. A substituição das propriedades ocorrerá somente se as propriedades TCP/IP do Adaptador Dial-Up forem configuradas como acima. Você não deve ativar o DNS nas propriedades TCP/IP do Adaptador dial-up ou definir um endereço IP nelas, porque assim irá interferir com a configuração da rede dial-up no ISP.
Para Windows NT 4.0, você pode utilizar as configurações TCP/IP descritas acima. Se a execução for feita no modo independente, é possível ativar o Microsoft Loopback Adapter sem os outros dois adaptadores.
B.4.1.4 Extensão do Shell (Windows NT)
Se receber uma mensagem que indique que o programa de instalação detectou uma Extensão Shell para Windows NT, a instalação não poderá prosseguir. Será necessário, então, executar os seguintes passos:
B.4.1.5 Recuperando uma instalação falha
Se sua instalação falhar, você deverá remover qualquer arquivo da Versão 4.0 que tenha sido instalado. Se o diretório no qual você pretende instalar o VisualAge for Java estiver vazio, o processo de instalação é retrocedido e remove todos os arquivos já instalados. O diretório vazio pode ser removido se você quiser, mas não é necessário. No entanto, se o diretório contiver arquivos, então, será necessário iniciar o processo de instalação novamente. Ele será aberto no modo de manutenção e você deverá selecionar para remover sua instalação parcial da Versão 4.0 antes de tentar instalar o produto novamente.
Será necessário excluir também a entrada do registro:
\\HKEY_LOCAL_MACHINE\SOFTWARE\IBM\VisualAge for Java para Windows
utilizando as seguintes instruções:
Se algum arquivo NetQuestion tiver sido instalado antes da instalação falhar, você deverá excluí-lo também.
IMNINSTSRV=C:\imnnq_nt
A localização de seu diretório NetQuestion pode aparecer de maneira diferente, dependendo da unidade em que o VisualAge for Java é instalado e de qual o sistema operacional que você está utilizando. Se a variável estiver definida(ou seja, se for fornecida a localização em que o NetQuestion está instalado), continue na etapa 2.
Se você receber uma mensagem de erro como "Variável de ambiente imninstsrv não definida" é possível que nenhum arquivo do NetQuestion tenha sido instalado ou que a instalação do NetQuestion não tenha sido concluída com êxito. Se isto ocorrer, selecione Iniciar > Localizar > Arquivos ou Pastas e procure pelo seguinte arquivo em seu sistema: vahelp.cfg. Se localizar este arquivo em qualquer diretório cujo nome comece com "imnnq" (por exemplo, imnnq_NT or imnnq_98), exclua-o. Não é preciso efetuar as etapas 2 e 3.
Isto remove qualquer arquivo NetQuestion que o VisualAge for Java tenha instalado. Ele não irá afetar os arquivos NetQuestion instalados por outros produtos (por exemplo, DB2).
Faça backup dos arquivos do repositório e de recursos, se ainda não tiver feito isso. Consulte a Parte B, Seção 3.0 para obter informações sobre como executar essa tarefa.
Após executar todas essas tarefas, reinicialize e reinstale o produto. Se a ajuda falhar após você ter instalado o VisualAge for Java novamente, consulte o manual de Resolução de Problemas para obter mais informações sobre a recuperação de falhas da ajuda. O manual de Resolução de Problemas (trshoot.htm) está localizado no CD do produto VisualAge for Java, Edição Professional e no CD Additional Features do VisualAge for Java, Edição Enterprise. Depois de instalar o VisualAge for Java, ele também está localizado em X:\IBMVJava, em que X:\IBMVJava é o diretório de instalação do VisualAge for Java.
B.4.1.6 CICS Transaction Gateway
Se tiver uma versão do CICS Transaction Gateway instalada em sua máquina quando o VisualAge for Java for instalado, o VisualAge utilizará essa versão em vez de instalar a sua própria.
B.4.1.7 Erros do Windows Installer
A seguir está uma lista de erros do Windows Installer os quais você deve ter conhecimento durante a instalação.
Erro 1603 (Somente Windows NT 4.0)
Se você receber uma mensagem de erro 1603 quando estiver instalando o VisualAge for Java, isto indica que o Windows Installer falhou ao inicializar e a instalação não pode prosseguir.
Alguns produtos (como o VisualCafe da Symantec) instalam automaticamente um arquivo denominado sfc.dll quando são instalados em qualquer plataforma Windows. É utilizado somente no Windows 2000, no entanto, onde o Windows Installer o chama para processamento de segurança.
Se um arquivo com este nome residir na PATH no Windows NT 4.0, o Windows Installer tentará carregá-lo, mesmo que o sfc.dll seja aplicável somente ao Windows 2000. O Windows Installer então falhará.
Para solucionar esse problema, execute estas etapas:
Erro Fatal LoadLibrary()
O erro Fatal LoadLibrary() ocorre porque um ou mais kernels de instalação do VisualAge for Java (IKernels) não foram registrados corretamente pelo Windows Installer. Para resolver este problema, você deve excluir o diretório do InstallShield em que os arquivos do IKernal residem e reinstalar o VisualAge for Java seguindo estas etapas:
Erro 1631 ou Erro Interno 2755 (somente Windows NT 4.0)
Se você instalar o VisualAge for Java no Windows NT 4.0, poderá receber uma das seguintes mensagens de erro:
Se você receber qualquer uma dessas mensagens de erro, isto indica que talvez tenha chaves de registro com valores nulos. Quando iniciar a instalação do VisualAge for Java, o arquivo userenv.dll tentará analisar várias chaves de registro e, se alguma das chaves tiver valores nulos, a instalação falhará com uma das mensagens de erro acima.
Para corrigir este comportamento, você deve remover as variáveis de ambiente nulas ou modificá-las (alterar o valor de nulo para um valor válido) antes de instalar o VisualAge for Java. Depois de instalar o VisualAge for Java, você pode retorná-las ao seu valor original.
Cuidado: Remova ou modifique as variáveis nulas com cuidado. Você deve considerar qualquer possível impacto que possa ocorrer antes da remoção ou modificação delas.
Erros Internos 2381, 1303, 1310, 1313 (somente Windows NT)
Se tiver tentando instalar o VisualAge for Java e qualquer uma ou todas as condições a seguir forem verdadeiras:
Você pode receber uma ou mais das seguintes mensagens de erro:
Foi relatado que este problema ocorre quando existem somente permissões de Leitura nas seguintes pastas:
\Arquivos de Programas\IBM\VisualAge for Java
\WinNT\Installer
Para resolver este problema, certifique-se de que tenha as permissões necessárias em suas unidades ou diretórios. Para isso, faça o seguinte:
Erro Interno 2735 Inicialização de Mecanismo
Se você receber o erro 2735, execute as seguintes etapas para resolvê-lo:
Erro 1606/Erro Interno 2707
Se você receber a seguinte mensagem de erro, isto indica que o valor do arquivo de registro das Ferramentas Administrativas Comuns pode estar incorreto:
Erro 1606. Não é possível acessar o local da rede \Profiles\AllUsers\StartMenu\Programs\Administrative
Tools\.
Erro Interno 2707. INSTALLDIR.
Você deve editar o valor do arquivo de registro das Ferramentas Administrativas Comuns antes de instalar o VisualAge for Java. Para isso, siga estas etapas:
B.4.2 Limitações e problemas na desinstalação
A seguir é fornecida uma lista de itens dos quais você deve estar ciente durante a remoção da instalação.
B.4.2.1 Espaço em disco
Você deve ter ao menos 2 MB livres na unidade do sistema Windows e a variável de ambiente TEMP ou TMP deve indicar um diretório temporário válido com pelo menos 5 MB livres.
B.4.2.2 Remoção da instalação do Distributed Debugger
Se instalou o Distributed Debugger como parte da instalação de seu VisualAge for Java, você deverá desinstalar o VisualAge for Java ANTES de desinstalar o Distributed Debugger. Depois de ter desinstalado o VisualAge for Java, você poderá desinstalar o Distributed Debugger indo ao diretório de instalação do Debugger e executando o programa de desinstalação.
Caso tenha desinstalado o VisualAge for Java e não consiga desinstalar o Distributed Debugger, será necessário excluir a chave de registro:
HKEY_LOCAL_MACHINE/SOFTWARE/IBM/IBM Distributed Debugger/CurrentVersion/install/ParentProducts/VisualAge for Java
e, em seguida, tentar desinstalar o Debugger novamente. NÃO siga estas etapas se estiver utilizando o Distributed Debugger com outros produtos, porque não mais será possível utilizar o depurador após a exclusão da chave de registro.
Siga estas etapas:
Defina também o valor da seguinte chave de registro como 1:
HKEY_LOCAL_MACHINE/SOFTWARE/IBM/IBM Distributed Debugger/CurrentVersion/install/refcount
B.4.2.3 Variáveis de ambiente (Windows 98)
Quando você remove a instalação do VisualAge for Java no Windows 98, algumas entradas de ambiente podem ser deixadas em seu arquivo autoexec.bat. Normalmente estas entradas restantes não causam nenhum problema, mas se você desinstalar e reinstalar o produto várias vezes, poderão ocorrer dois problemas. Você poderá ter instruções de caminho conflitantes que impedirão a ajuda online de trabalhar ou poderá ficar sem espaço na variável PATH, o que impedirá a reinstalação correta do produto.
Para solucionar esses problemas:
B.4.2.4 Remoção da instalação do NetQuestion
Quando você estiver desinstalando o VisualAge for Java, o NetQuestion não pode ser desinstalado. Podem ocorrer problemas se a instalação do NetQuestion não for removida e posteriormente você tentar reinstalar o produto.
Para remover arquivos do NetQuestion instalados pelo VisualAge for Java, siga as etapas a seguir. Ele não irá afetar os arquivos NetQuestion instalados por outros produtos (por exemplo, DB2).
IMNINSTSRV=C:\imnnq_nt
A localização de seu diretório do NetQuestion pode aparecer de maneira diferente, dependendo da unidade em que o VisualAge for Java foi instalado e do sistema operacional em uso. Se você receber uma mensagem de erro como "Variável de ambiente imninstsrv não definida", então a instalação de todos os arquivos do NetQuestion terá sido removida.
Isto remove qualquer arquivo NetQuestion que o VisualAge for Java tenha instalado.
Se você tentar reinstalar o VisualAge for Java mais tarde e a ajuda falhar, consulte o manual de Resolução de Problemas para obter mais informações sobre a recuperação de falhas da ajuda. O manual de Resolução de Problemas (trshoot.htm) está localizado no CD do produto VisualAge for Java, Edição Professional e no CD Additional Features do VisualAge for Java, Edição Enterprise. Depois de instalar o VisualAge for Java, ele também está localizado em X:\IBMVJava, em que X:\IBMVJava é o diretório de instalação do VisualAge for Java.
Você deve utilizar o EMSRV, Versão 7.1, se estiver planejando trabalhar em um ambiente de equipe com a Edição Enterprise do VisualAge for Java.
Todos os arquivos do EMSRV estão localizados no CD Additional Features.
consulte também a seção "Problemas e limitações conhecidos" no fim da Parte C antes de instalar o EMSRV.
C.1.1 Plataformas Suportadas
O servidor EMSRV é suportado nas seguintes plataformas de sistemas operacionais:
* Nota: HP-UX é suportado somente em máquinas de estação de trabalho classe 700. Foi testado em uma máquina HP-UX 9000/715/60 e em uma máquina HP-UX 9000/782/200+. Como as máquinas classe 800 (servidor) têm uma arquitetura diferente e requerem binários diferentes, o EMSRV não é suportado em máquinas classe 800.
+ Para obter informações sobre como obter esta correção, consulte a seção C.1.4.
A IBM não oferece mais suporte ao EMSRV no Netware 4.11 ou Netware 5.0, mas o EMSRV pode ser executado nessa plataforma se CLIBAUX.NLM for carregado antes do EMSRV.NLM. CLIBAUX.NLM está incluso com o Support Pack 8a da Novell, mas também está disponível em separado no arquivo CLIBAUX1.EXE, que pode ser encontrado na seguinte localização:
http://support.novell.com/cgi-bin/search/download?/pub/updates/nw/nw42/clibaux1.exe
Retirada do suporte ao hardware SMP
** NOTA IMPORTANTE: A execução de qualquer release do EMSRV para Windows NT/2000 em uma máquina com mais de um processador pode danificar repositórios.
O EMSRV não é mais suportado em servidores Windows NT/2000 em execução em hardware SMP (máquinas com mais de um processador). A decisão de remover o suporte ao hardware SMP se deve à freqüência de relatórios a respeito de repositórios danificados com servidores Windows e hardware SMP. O EMSRV continua a suportar hardware SMP para todos os outros sistemas operacionais.
A IBM NÃO ACEITA A RESPONSABILIDADE POR DANOS QUE POSSAM OCORRER COMO RESULTADO DO USO DO EMSRV EM UM SERVIDOR WINDOWS NT/2000 EM EXECUÇÃO EM HARDWARE SMP, INCLUSIVE, MAS NÃO SE LIMITANDO A DANOS REIVINDICADOS POR VOCÊ COM BASE EM REIVINDICAÇÕES DE TERCEIROS. EM NENHUM CASO A IBM, SEUS FORNECEDORES, AGENTES E FUNCIONÁRIOS SERÁ RESPONSÁVEL POR QUAISQUER DANOS INDIRETOS, ESPECIAIS, PUNITIVOS, EXEMPLARES OU CONSEQÜENCIAIS RESULTANTES DO USO DO EMSRV EM UM SERVIDOR WINDOWS NT/2000 QUE EXECUTE EM HARDWARE SMP.
Caso você deseje utilizar o EMSRV em um servidor que execute em hardware SMP, utilize o parâmetro -mp ao iniciar o EMSRV. Desta forma, a verificação de hardware SMP é ignorada. Assim, o EMSRV será executado em uma plataforma não suportada e você assume inteira responsabilidade (A IBM NÃO ASSUME QUALQUER RESPONSABILIDADE OU OBRIGAÇÃO) no caso de os repositórios serem danificados.
O EMSRV não explora processadores adicionais, devido ao fato de o EMSRV ser um processo ligado à entrada/saída e não ao processador. Conseqüentemente, o desempenho do EMSRV não é afetado pelo número de processadores no servidor.
C.1.2 TCP/IP
O TCP/IP deve ser instalado e configurado no seu servidor.
C.1.3 Correções do Novell requeridas para a execução do EMSRV
Recomendamos que você obtenha e aplique a NetWare Minimum Patch List. Esses arquivos de correções estão disponíveis em http://support.novell.com/misc/patlst.htm. Será necessário selecionar e aplicar as correções apropriadas para a versão do NetWare que você está usando.
C.1.4 Correção necessária para executar o EMSRV no Solaris
Há um bug na implementação de PAM do Solaris, Versão 2.6 que impede que o EMSRV funcione corretamente. O Patch 106257-05 precisa ser aplicado se você estiver usando o EMSRV no Solaris, Versão 2.6. A correção está disponível em:
http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fpatches%2F106257&zone_32=PAM
O bug específico que essa correção corrige é:
4092227 membro pam_conv appdata_ptr não é passado pela função conv() conforme documentado
A correção não é necessária se você estiver trabalhando com a Versão 7.0 do Solaris.
C.1.5 Sistemas de arquivos suportados
O EMSRV foi testado e certificado com os seguintes sistemas de arquivos:
NetWare
OS/2
Windows NT e Windows 2000
Solaris
HP-UX
AIX
Linux
O EMSRV suporta apenas sistemas de arquivos montados localmente.
Esta seção contém instruções para a instalação do programa do servidor de repositório do EMSRV e de um repositório compartilhado. Para obter instruções para iniciar o servidor, consulte o arquivo "Configuração e administração do servidor" emsrv71.htm (emsrv70.htm para todos os idiomas diferentes do inglês), que pode ser encontrado no diretório TeamServer\docs.
C.2.1 Instalando o EMSRV para Windows(R)
Configurando o EMSRV para Windows
Antes de instalar o EMSRV no Windows, você deverá notar os seguintes fatos sobre
tipos de arquivos:
Instalando o EMSRV no Windows
Para instalar o programa servidor de repositório EMSRV e um repositório compartilhado em um servidor Windows NT ou Windows 2000, siga estas etapas:
O arquivo ide.zip está localizado no diretório ivj40\backup, que está localizado no CD Additional Features do VisualAge for Java, Edição Enterprise. Se você tiver uma versão eletrônica do VisualAge for Java, ela poderá ser encontrada no diretório temporário (para o qual você extraiu suas partes).
Esse diretório é onde você pretende armazenar repositórios de código fonte compartilhados. Ao iniciar o servidor mais tarde, você especificará este subdiretório como o diretório de trabalho do EMSRV utilizando o parâmetro de inicialização -W do EMSRV quando iniciar o servidor.
O EMSRV deve ter direitos completos de leitura, gravação e pesquisa na árvore de diretórios do ivj.dat.pr. O diretório ivj.dat.pr deve sempre ser copiado para o mesmo diretório que o ivj.dat, ou você não conseguirá acessar os recursos do projeto.
Você pode optar por renomear o arquivo do repositório, por exemplo para team1.dat. Se renomeá-lo depois dele ter sido copiado para o servidor, o diretório de recursos do projeto deverá ser renomeado adequadamente. Por exemplo, se o repositório for renomeado para team1.dat, você deverá alterar o nome do diretório de recursos do projeto para team1.dat.pr.
Os membros da equipe terão de especificar o nome do arquivo de repositório ao instalar o código do cliente do VisualAge for Java. Precisarão especificar também o caminho na máquina do servidor.
Se preferir iniciar o EMSRV como um dispositivo em vez de a partir de um prompt de comandos, poderá instalar o EMSRV no registro do Windows. Há duas vantagens instalando EMSRV como um serviço:
Dica: Se o EMSRV for iniciado como um serviço, o diretório de trabalho padrão do EMSRV é o diretório system\32 do Windows NT ou Windows 2000. Recomenda-se que você altere esse padrão utilizando o parâmetro -W ao instalar o EMSRV como serviço no registro do Windows NT ou do Windows 2000.
Importante: O EMSRV não é mais suportado em servidores Windows NT/2000 em execução em hardware SMP (máquinas com mais de um processador). A decisão de remover o suporte ao hardware SMP se deve à freqüência de relatórios a respeito de repositórios corrompidos com servidores Windows e hardware SMP. O EMSRV ainda suporta hardware para todos os outros sistemas operacionais.
A IBM NÃO ACEITA A RESPONSABILIDADE POR DANOS QUE POSSAM OCORRER COMO RESULTADO DO USO DO EMSRV EM UM SERVIDOR WINDOWS NT/2000 EM EXECUÇÃO EM HARDWARE SMP, INCLUSIVE, MAS NÃO SE LIMITANDO A DANOS REIVINDICADOS POR VOCÊ COM BASE EM REIVINDICAÇÕES DE TERCEIROS. EM NENHUM CASO A IBM, SEUS FORNECEDORES, AGENTES E FUNCIONÁRIOS SERÁ RESPONSÁVEL POR QUAISQUER DANOS INDIRETOS, ESPECIAIS, PUNITIVOS, EXEMPLARES OU CONSEQÜENCIAIS RESULTANTES DO USO DO EMSRV EM UM SERVIDOR WINDOWS NT/2000 QUE EXECUTE EM HARDWARE SMP.
Para instalar e iniciar o EMSRV como serviço Windows NT/2000 em hardware SMP é necessário instalar o serviço utilizando o parâmetro -mp. Desta forma, a verificação de hardware SMP é ignorada. Assim, o EMSRV será executado em uma plataforma não suportada e você assume inteira responsabilidade (A IBM NÃO ASSUME QUALQUER RESPONSABILIDADE OU OBRIGAÇÃO) no caso de os repositórios serem danificados.
Se o serviço não for instalado utilizando o parâmetro -mp, ele não inicia e você recebe a seguinte mensagem de erro:
Não foi possível iniciar o serviço EMSRV no \\host
Erro 2140: Ocorreu um erro interno do Windows NT.
Se você tentar instalar o EMSRV como serviço novamente (por exemplo, para incluir o parâmetro -mp), ele é instalado corretamente, mas é exibido o seguinte erro:
O arquivo de mensagens emsrvmsg.dll, não foi copiado para C:\WINNT\System32\emsrvmsg.dll
--- Erro 1224 do SO: Não foi possível executar a operação solicitada em um arquivo com uma seção mapeada de usuário aberta. Verifique se a DLL está no mesmo diretório que o EMSRV.EXE.
Você pode ignorar essa mensagem de erro, pois a DLL já foi instalada na instalação anterior do serviço.
Para instalar o EMSRV como um serviço:
Para obter mais informações sobre como iniciar o EMSRV, consulte o arquivo "Configuração e administração do servidor" emsrv71.htm(emsrv70.htm para todos os idiomas diferentes do inglês), que pode ser encontrado no diretório TeamServer\docs.
Os parâmetros que você forneceu serão usados, por padrão, sempre que EMSRV for iniciado. Você também pode substituir ou incluir a esses parâmetros se iniciar o EMSRV manualmente a partir do ícone Serviços no Painel de Controle do Windows.
C.2.2 Instalando o EMSRV para NetWareConfigurando o EMSRV para Netware
Antes de instalar o EMSRV no Netware, você deve notar as seguintes limitações:
Instalando o EMSRV no Netware
Para instalar o programa servidor de repositório EMSRV e um repositório compartilhado no NetWare, siga estas etapas:
O arquivo ide.zip está localizado no diretório ivj40\backup, que está localizado no CD Additional Features do VisualAge for Java, Edição Enterprise. Se você tiver uma versão eletrônica do VisualAge for Java, ela poderá ser encontrada no diretório temporário (para o qual você extraiu suas partes).
Quando iniciar o servidor posteriormente, você especificará este subdiretório como o diretório de trabalho do EMSRV, utilizando o parâmetro de inicialização -W do EMSRV. O EMSRV deve ter direitos completos de leitura, gravação e pesquisa na árvore de diretórios do ivj.dat.pr. O diretório ivj.dat.pr deve sempre ser copiado para o mesmo diretório que o ivj.dat, ou você não conseguirá acessar os recursos do projeto.
Você pode optar por renomear o arquivo repositório, por exemplo, para team1.dat. Se renomeá-lo depois dele ter sido copiado para o servidor, o diretório de recursos do projeto deverá ser renomeado adequadamente. Por exemplo, se o repositório for renomeado para team1.dat, você deverá alterar o nome do diretório de recursos do projeto para team1.dat.pr.
Os membros da equipe precisarão especificar o nome e a localização do arquivo repositório quando instalarem o código de cliente do VisualAge for Java.
C.2.3 Instalando o EMSRV para OS/2 Warp
Nota: O OS/2 não é mais suportado como uma plataforma de desenvolvimento. Consulte a Parte E para obter detalhes.
Configurando o EMSRV para OS/2
Antes de instalar o EMSRV no OS/2, você deverá notar o seguinte:
Instalando o EMSRV no OS/2
Para instalar o programa servidor de repositório EMSRV e um repositório compartilhado em um servidor OS/2, siga estas etapas:
Coloque esses arquivos em um subdiretório que faça parte de seu PATH ou crie um subdiretório e inclua-o no PATH. Sugerimos colocá-los em uma localização com muito espaço livre porque o arquivo emsrv.log será gravado no subdiretório em que você colocar esses arquivos.
O arquivo ide.zip está localizado no diretório ivj40\backup, que está localizado no CD Additional Features do VisualAge for Java, Edição Enterprise. Se você tiver uma versão eletrônica do VisualAge for Java, ela poderá ser encontrada no diretório temporário (para o qual você extraiu suas partes).
Este subdiretório é onde você planeja armazenar os repositórios de código fonte compartilhados. Ao iniciar o servidor posteriormente, especifique esse subdiretório como diretório de trabalho do EMSRV, utilizando o parâmetro de inicialização -W do EMSRV.
O EMSRV deve ter direitos completos de leitura, gravação e pesquisa na árvore de diretórios do ivj.dat.pr. O diretório ivj.dat.pr deve sempre ser copiado para o mesmo diretório que o ivj.dat, ou você não conseguirá acessar os recursos do projeto.
Você pode optar por renomear o arquivo do repositório, por exemplo para team1.dat. Se renomeá-lo depois dele ter sido copiado para o servidor, o diretório de recursos do projeto deverá ser renomeado adequadamente. Por exemplo, se o repositório for renomeado para team1.dat, você deverá alterar o nome do diretório de recursos do projeto para team1.dat.pr.
Os membros da equipe precisarão especificar o nome do arquivo repositório quando instalarem o código de cliente do VisualAge for Java.
C.2.4 Instalando o EMSRV para AIX
Configurando o EMSRV para AIX
Antes de instalar o EMSRV no AIX, você deve notar as seguintes características:
Instalando o EMSRV no AIX
Nas etapas abaixo, "usuário EMSRV" refere-se ao usuário que inicia o programa EMSRV.
Você deve copiar os seguintes arquivos do diretório TeamServer para sua máquina:
Coloque esses arquivos em um subdiretório que faça parte de seu PATH ou crie um subdiretório e inclua-o no PATH. Sugerimos colocá-los em uma localização com muito espaço livre porque o arquivo emsrv.log será gravado no subdiretório em que você colocar esses arquivos.
Execute estas etapas para configurar o EMSRV em uma máquina AIX:
O arquivo ide.zip está localizado no diretório ivj40\backup, que está localizado no CD Additional Features do VisualAge for Java, Edição Enterprise. Se você tiver uma versão eletrônica do VisualAge for Java, ela poderá ser encontrada no diretório temporário (para o qual você extraiu suas partes).
O EMSRV deve ter direitos completos de leitura, gravação e pesquisa na árvore de diretórios do ivj.dat.pr. O diretório ivj.dat.pr deve sempre ser copiado para o mesmo diretório que o ivj.dat, ou você não conseguirá acessar os recursos do projeto. Os diretórios devem ter os bits rw e x (pesquisa) definidos para o usuário EMSRV.
O acesso de raiz em plataformas UNIX é necessário para autenticar usuários. O EMSRV NÃO precisa ser iniciado pelo usuário principal para realizar isso. Isso poderá comprometer a segurança porque o EMSRV teria acesso completo a todos os sistemas de arquivos.
Em vez disso, você deve alterar o proprietário do executável EMSRV para 'raiz' e definir o bit SUID do executável. Isso pode ser realizado como a seguir:
chown root emsrv
chmod u+s emsrv
Quando o EMSRV tenta autenticar um usuário, ele irá alterar temporariamente a autoridade do processo EMSRV em execução para ser a autoridade do proprietário do executável. Depois da autenticação estar concluída, a autoridade do processo EMSRV em execução será alterada novamente para aquela do usuário que iniciou o EMSRV. Isso acontece com base no processo (cliente), portanto, enquanto um cliente está sendo autenticado, apenas o processo que está atendendo esse cliente tem acesso de raiz temporário.
O acesso de raiz para autenticação é necessário independentemente de como o EMSRV realmente implementa a autenticação. Interfaces como o PAM fornecem apenas uma API comum para permitir que os aplicativos suportem vários métodos de autenticação; a configuração específica a cada método de autenticação ainda deve estar correta.
C.2.5 EMSRV para HP-UX ou Solaris
C.2.5.1 Configurando o EMSRV para HP-UX ou Solaris
Antes de instalar o EMSRV no Solaris ou HP-UX, você deve notar os seguintes
requisitos:
Para Solaris
Para HP-UX
C.2.5.2 Instalando o EMSRV para HP-UX ou Solaris
Nas etapas abaixo, "usuário EMSRV" refere-se ao usuário que inicia o programa EMSRV.
Você deve copiar os seguintes arquivos do diretório TeamServer para sua máquina:
Para o HP-UX:
Para o Solaris:
Coloque esses arquivos em um subdiretório que faça parte de seu PATH ou crie um subdiretório e inclua-o no PATH. Sugerimos colocá-los em uma localização com muito espaço livre porque o arquivo emsrv.log será gravado no subdiretório em que você colocar esses arquivos.
Siga estas etapas para configurar o EMSRV em uma máquina do Solaris ou HP-UX:
O arquivo ide.zip está localizado no diretório ivj40\backup, que está localizado no CD Additional Features do VisualAge for Java, Edição Enterprise. Se você tiver uma versão eletrônica do VisualAge for Java, ela poderá ser encontrada no diretório temporário (para o qual você extraiu suas partes).
O EMSRV deve ter direitos totais para leitura, gravação e pesquisa de toda a árvore de diretórios em ivj.dat.pr.; ivj.dat.pr deve sempre ser copiado para o mesmo diretório de ivj.dat, ou você não conseguirá acessar os recursos de seu projeto. Os diretórios devem ter os bits rw e x (pesquisa) definidos para o usuário EMSRV.
O acesso de raiz em plataformas UNIX é necessário para autenticar usuários. O EMSRV NÃO precisa ser iniciado pelo usuário principal para realizar isso. Isso poderá comprometer a segurança porque o EMSRV teria acesso completo a todos os sistemas de arquivos.
Em vez disso, você deve alterar o proprietário do executável EMSRV para 'raiz' e definir o bit SUID do executável. Isso pode ser realizado como a seguir:
chown root emsrv
chmod u+s emsrv
Quando o EMSRV tenta autenticar um usuário, ele irá alterar temporariamente a autoridade do processo EMSRV em execução para ser a autoridade do proprietário do executável. Depois da autenticação estar concluída, a autoridade do processo EMSRV em execução será alterada novamente para aquela do usuário que iniciou o EMSRV. Isso acontece com base no processo (cliente), portanto, enquanto um cliente está sendo autenticado, apenas o processo que está atendendo esse cliente tem acesso de raiz temporário.
O acesso de raiz para autenticação é necessário independentemente de como o EMSRV realmente implementa a autenticação. Interfaces como o PAM fornecem apenas uma API comum para permitir que os aplicativos suportem vários métodos de autenticação; a configuração específica a cada método de autenticação ainda deve estar correta.
C.2.6 EMSRV para Linux
C.2.6.1 Configurando o EMSRV para Linux
Antes de instalar o EMSRV no Linux, você deve notar as seguintes informações:
C.2.6.2 Instalando o EMSRV para Linux
Nas etapas abaixo, "usuário EMSRV" refere-se ao usuário que inicia o programa EMSRV.
Você deve copiar os seguintes arquivos do diretório TeamServer para sua máquina:
Coloque esses arquivos em um subdiretório que faça parte de seu PATH ou crie um subdiretório e inclua-o no PATH. Sugerimos colocá-los em uma localização com muito espaço livre porque o arquivo emsrv.log será gravado no subdiretório em que você colocar esses arquivos.
Siga estas etapas para configurar o EMSRV em uma máquina do Linux:
O arquivo ide.zip está localizado no diretório ivj40\backup, que está localizado no CD Additional Features do VisualAge for Java, Edição Enterprise. Se você tiver uma versão eletrônica do VisualAge for Java, ela poderá ser encontrada no diretório temporário (para o qual você extraiu suas partes).
O EMSRV deve ter direitos completos de leitura, gravação e pesquisa na árvore de diretórios do ivj.dat.pr. O diretório ivj.dat.pr deve sempre ser copiado para o mesmo diretório que o ivj.dat, ou você não conseguirá acessar os recursos do projeto. Os diretórios devem ter os bits rw e x (pesquisa) definidos para o usuário EMSRV.
O acesso de raiz em plataformas UNIX é necessário para autenticar usuários. O EMSRV NÃO precisa ser iniciado pelo usuário principal para realizar isso. Isso poderá comprometer a segurança porque o EMSRV teria acesso completo a todos os sistemas de arquivos.
Em vez disso, você deve alterar o proprietário do executável EMSRV para 'raiz' e definir o bit SUID do executável. Isso pode ser realizado como a seguir:
chown root emsrv
chmod u+s emsrv
Quando o EMSRV tenta autenticar um usuário, ele irá alterar temporariamente a autoridade do processo EMSRV em execução para ser a autoridade do proprietário do executável. Depois da autenticação estar concluída, a autoridade do processo EMSRV em execução será alterada novamente para aquela do usuário que iniciou o EMSRV. Isso acontece com base no processo (cliente), portanto, enquanto um cliente está sendo autenticado, apenas o processo que está atendendo esse cliente tem acesso de raiz temporário.
O acesso de raiz para autenticação é necessário independentemente de como o EMSRV realmente implementa a autenticação. Interfaces como o PAM fornecem apenas uma API comum para permitir que os aplicativos suportem vários métodos de autenticação; a configuração específica a cada método de autenticação ainda deve estar correta.
C.3.1 Migrando da Versão 6.x ou Versão 7.0 do EMSRV para a Versão 7.1
Se possui atualmente a Versão 6.x ou Versão 7.0 do EMSRV instalada e deseja instalar a Versão 7.1 do EMSRV, você pode desinstalar a versão 6.x/7.0 do EMSRV e instalar a Versão 7.1 ou manter sua versão antiga do EMSRV e instalar o EMSRV 7.1.
Você deve instalar a Versão 7.1 para trabalhar com o VisualAge for Java, Versão 4.0.
Para mudar do EMSRV, Versão 6.x/7.0 para EMSRV, Versão 7.1, siga estas etapas:
O EMSRV 7.1 é compatível com o EMSRV 6.x/7.0. Por exemplo, se estiver trabalhando em uma edição anterior do VisualAge for Java (que utiliza o EMSRV 6.x/7.0), você poderá conectar-se a partir de sua versão anterior a um repositório compartilhado em execução no EMSRV 7.1.
Neste ponto, você já instalou os programas servidores de repositório e um repositório de código fonte compartilhado. Para finalizar a configuração do ambiente de desenvolvimento de equipe, você deve iniciar o servidor, conectar-se a ele a partir de um cliente VisualAge for Java e incluir usuários na lista de usuários do repositório.
Se você já tiver instalado o cliente VisualAge for Java em uma estação de trabalho, poderá consultar a ajuda online para obter mais informações sobre como configurar o ambiente de desenvolvimento de equipe. Caso contrário, consulte o arquivo team.pdf no diretório pdf. O diretório pdf está localizado no CD Additional Features do VisualAge for Java, Edição Enterprise. Se você tiver uma versão eletrônica do VisualAge for Java, ela poderá ser encontrada no diretório temporário (para o qual você extraiu suas partes). Se você não fez download da parte que contém os PDFs, esse diretório não existirá.
Nas instruções a seguir, assume-se que o repositório compartilhado que está instalado no servidor chama-se ivj.dat. Ao iniciar o programa servidor de repositório, o administrador deve fornecer o caminho do arquivo ivj.dat como o diretório de trabalho EMSRV.
C.4.1 Preparando o servidor de equipe
Antes dos desenvolvedores de equipe poderem trabalhar com o repositório compartilhado, o administrador deve configurar o servidor VisualAge for Java e iniciar o programa servidor de repositório EMSRV. Se alguns desenvolvedores desejarem começar a utilizar o VisualAge for Java, Versão 4.0, antes que o servidor esteja pronto, eles poderão instalar-se primeiro como usuários independentes e conectarem-se mais tarde ao repositório compartilhado.
C.4.2 Testando uma conexão do cliente
Para confirmar que o servidor foi iniciado com êxito, o administrador deverá conectar-se ao repositório compartilhado a partir de um cliente VisualAge for Java, Edição Enterprise, Versão 4.0. Esta ação confirmará se a conexão TCP/IP do servidor está funcionando corretamente, se o EMSRV foi iniciado com os parâmetros corretos e se o administrador sabe quais informações do servidor devem ser fornecidas durante a instalação do cliente.
Para obter informações sobre como conectar-se a um repositório compartilhado, consulte "Conectando-se a um repositório compartilhado" na ajuda online do VisualAge for Java ou no arquivo team.pdf. O arquivo team.pdf está no diretório pdf. O diretório pdf está localizado no CD Additional Features do VisualAge for Java, Edição Enterprise. Se você tiver uma versão eletrônica do VisualAge for Java, ela poderá ser encontrada no diretório temporário (para o qual você extraiu suas partes). Se você não fez download da parte que contém os PDFs, esse diretório não existirá.
C.4.3 Incluindo usuários na lista de usuários do repositório
A primeira vez que um cliente conecta-se ao repositório compartilhado, o usuário é solicitado a fornecer um nome de proprietário da área de trabalho. O usuário não pode iniciar o IDE sem primeiro selecionar um nome de proprietário da área de trabalho válido de uma lista de usuários do repositório.
Por padrão, o VisualAge for Java, Versão 4.0, possui um usuário denominado Administrador em sua lista de usuários do repositório. Inicialmente, cada usuário poderia escolher o Administrador como o nome do proprietário da área de trabalho; no entanto, é altamente recomendado que cada usuário forneça, imediatamente, um nome exclusivo para conectar-se ao servidor. No ambiente de desenvolvimento de equipe do VisualAge for Java, o controle de alteração é baseado em funções de usuário definidas, o que significa que cada desenvolvedor deve ser exclusivamente identificado. Para satisfazer este objetivo, o administrador deve incluir todos na lista de usuários do repositório. (O único usuário do VisualAge for Java que pode incluir outros em uma lista de usuários do repositório é o Administrador.)O nome exclusivo pertencente a cada usuário deverá corresponder a um nome de usuário do sistema se a verificação de senha nativa for utilizada.
Para obter informações sobre como incluir usuários na lista de repositórios, consulte a ajuda online da equipe do VisualAge for Java ou o arquivo team.pdf, no diretório pdf. O diretório pdf está localizado no CD Additional Features do VisualAge for Java, Edição Enterprise. Se você tiver uma versão eletrônica do VisualAge for Java, ela poderá ser encontrada no diretório temporário (para o qual você extraiu suas partes). Se você não fez download da parte que contém os PDFs, esse diretório não existirá.
Agora que o servidor está configurado e pronto, os usuários devem continuar a instalar seus clientes VisualAge for Java. As informações sobre como instalar clientes da equipe do VisualAge for Java podem ser encontradas na Parte B deste manual.
C.5.1 Desempenho de conexões de rede de largura de banda baixa, de alta latência
O protocolo utilizado entre clientes EMSRV e o EMSRV geralmente resulta em uma alta taxa de pacotes transmitidos ao servidor. Isto deve-se ao fato de que a grande maioria do processamento é feita no cliente. A maioria dos pedidos processados pelo EMSRV são pedidos de E/S (por exemplo, pedidos de bloqueio de registro, de leitura e gravação).
Como resultado desta arquitetura, o desempenho no terminal do cliente é altamente sensitivo à latência da rede. Espera-se que a latência (medida por tempos de pacote completos ou por 'ping') com menos de 5 ms tenha um desempenho aceitável. A latência da rede local geralmente é menor do que 1 ms, mas uma conexão da WAN ou uma conexão de modem dial-up em uma linha telefônica podem ter uma latência de até 500 ms. Mesmo com conexões DSL de alta velocidade, cabo, transmissão de estruturas ou ISDN, a latência é uma função da distância entre dois terminais.
Em geral, o desempenho em uma conexão de modem dial-up através de uma linha telefônica gera um desempenho inaceitável porque as conexões desse tipo geralmente possuem uma latência de 200 ms ou mais. As conexões de alta velocidade também geram um desempenho inaceitável, a menos que a distância entre o cliente e o servidor seja de algumas centenas de quilômetros ou menos.
O protocolo EMSRV não possui uma largura de banda particularmente intensa, mas a utilização da largura de banda é uma função do número de clientes utilizando a conexão simultaneamente.
C.5.2 Limitações da conexão do TCP/IP
O limite padrão para as conexões de cliente com o EMSRV é 512. Esse limite pode ser alterado com a opção -M da linha de comandos quando você inicia o EMSRV.
O número é limitado principalmente pela memória, porém algumas pilhas TCP/IP serão executadas sem soquetes de fluxo antes do limite de memória ser alcançado. Em geral, esse número é maior que cem, mas varia de acordo com a pilha.
C.5.3 Detectando conexões excluídas inesperadamente
O EMSRV utiliza o temporizador KEEPALIVE do TCP/IP para detectar conexões que foram eliminadas inesperadamente quando um cliente quebrou ou foi reinicializado. Algumas pilhas TCP/IP permitem que o tempo limite do KEEPALIVE seja alterado. Em geral, a definição padrão é de 120 minutos.
O EMADMIN pode ser utilizado para listar as conexões e identificar uma conexão que não interagiu com o servidor durante um longo tempo pelo tempo do último pedido. Essa conexão pode ser fechada utilizando o comando EMADMIN STOP e a opção -k .
C.5.4 Fazendo o intercâmbio de versões diferentes do EMSRV e utilitários do EMSRV
O VisualAge for Java, Versão 4.0, inclui a versão 7.1 do EMSRV e a versão 7.0 dos utilitários EMADMIN.
Você deve utilizar EMADMIN 7.0 com EMSRV 7.1. O EMADMIN 7.0 não funcionará corretamente com releases do EMSRV anteriores ao 7.0.
C.5.5 Limitações do PAM
Em plataformas do Linux e Solaris, a autenticação é implementada com o PAM (Módulos de Autenticação de Senha). Embora, teoricamente, isso possa permitir o uso de qualquer PAM (módulo) com o EMSRV através da alteração do arquivo de configuração relevante do PAM, na prática, isso não é possível.
O EMSRV não conversa com os clientes de uma maneira que seja inteiramente compatível com a arquitetura do PAM. Como resultado, a autenticação do EMSRV funcionará apenas onde o módulo solicitar inicialmente uma senha para o texto (fornecida inicialmente pelo cliente).
C.5.6 Senhas com caracteres não-ASCII não podem ser utilizadas para autenticar com o EMSRV
Devido a um problema na biblioteca de runtime do Microsoft C, qualquer senha que contenha caracteres não ASCII digitados em resposta ao prompt:
'Digite a senha do usuário que iniciou o EMSRV'
não será interpretada corretamente. A solução é digitar a senha com a opção -p ao executar o EMADMIN.
C.5.7 Menus e janelas apresentam caracteres corrompidos quando em execução em NetWare japonêsO NLM do EMSRV para NetWare utiliza NLM User Interface Developer Components (NWSNUT) da Novell. Quando em execução na NetWare japonesa, os caracteres gráficos utilizados nos menus e janelas NWSNUT não estarão disponíveis e aparecerão como caracteres corrompidos. Este não é um problema do NLM do EMSRV ou no NetWare, mas uma limitação da página de códigos Shift-JIS.
C.5.8 O EMADMIN não copia o diretório de recursos armazenadosQuando o EMADMIN 7.0 é utilizado para copiar um repositório do VisualAge for Java 4.0, ele não copia o diretório de recursos de projeto armazenado correspondente. Você deverá copiar este diretório manualmente.
Consulte a seção 18.0 para obter informações importantes sobre a migração da classe Swing.
Esta versão do VisualAge for Java não suporta o CICS(R) Transaction Server. As classes necessárias para suportar o CICS TS 1.3 e abaixo não estão incluídas com esta versão. Qualquer aplicativo CICS TS que você tente migrar de versões anteriores do VisualAge for Java não funcionará na Versão 4.0 e deverá ser excluído de sua área de trabalho e do repositório da Versão 4.0.
Se desejar trabalhar com CICS TS 1.3 ou abaixo, você deverá continuar a utilizar uma versão mais antiga (3.02 e anterior) do VisualAge for Java. Por enquanto, você também deverá utilizar uma versão mais antiga (3.02 e anterior) do VisualAge for Java se desejar utilizar a interface JCICS ou se precisar de suporte CICS a IIOP. Não oferecemos suporte ao CICS Transactions server porque ele é baseado em JDK 1.1.x.
D.2.1. Migrando da Versão 2.0 ou 3.0x do VisualAge for Java
O Data Access beans utiliza componentes e interfaces Swing. Qualquer aplicativo desenvolvido que utilize beans a serem migrados dos pacotes Swing antigos do JDK 1.1.x para os pacotes Swing J2SDK v.1.2.2 novos. Para isso, selecione as classes e pacotes afetados depois de instalar o VisualAge for Java, Versão 4.0, abra o SmartGuide - Corrigir/Migrar e selecione a caixa de opção Incluir pacotes renomeados do JDK1.2. Isto incluirá as entrada De/Para apropriadas para o Swing e permitirá migrar automaticamente as referências do Swing para o SDK do Java 2. Quaisquer erros que ocorram enquanto você estiver migrando serão registrados na janela Log.
Para obter mais informações sobre como migrar corretamente seus aplicativos, consulte o arquivo de ajuda online do Editor de Composição Visual "Corrigir/migrar diretrizes para referências de classes ou de pacotes" e o arquivo de tarefas relacionadas "Corrigindo referências de classes ou pacotes".
D.2.2. Migrando da Versão 3.5 do VisualAge for Java
Não é necessário executar nenhuma etapa extra para migrar seus Data Access Beans se você migrou para o VisualAge for Java, Versão 3.5, pois os Data Access Beans na Versão 3.5 utilizaram os pacotes Swing do J2SDK v.1.2.2.
O Data Access Builder não é mais incluído no VisualAge for Java. Se deseja continuar a utilizar o Data Access Builder, terá que continuar a trabalhar em uma versão anterior do VisualAge for Java.
Não existe recurso novo no VisualAge for Java, Versão 4.0, que substitua diretamente a funcionalidade fornecida anteriormente pelo Data Access Builder, mas existem três componentes no VisualAge for Java que fornecem funcionalidade semelhante - Data Access beans, Persistence Builder e Enterprise JavaBeans Development Environment. Cada recurso oferece uma abordagem diferente para a criação de classes de acesso a dados.
Não é possível migrar seu código para o VisualAge for Java, Versão 4.0, e reutilizá-lo em alguma destas ferramentas. Será necessário recriar seus aplicativos para utilizá-los na Versão 4.0. Utilize o recurso que melhor se adaptar ao foco principal no desenvolvimento do código e no que você deseja que seus aplicativos executem.
Uma comparação do Data Access Builder, Data Access beans e do Persistence Builder é fornecida como um apêndice neste manual.
D.4.1 Migração de beans corporativos do VisualAge for Java, Versão 2.0, Enterprise Update
Se você criou beans corporativos no VisualAge for Java, Versão 2.0, Enterprise Update, e deseja utilizá-los no VisualAge for Java, Versão 4.0, será necessário concluir as seguintes atividades em sua versão atual do VisualAge for Java, Versão 2.0, Enterprise Update:
Para terminar a migração do código do bean corporativo, no VisualAge for Java, Versão 4.0, siga as etapas no Cenário 1 ou no Cenário 2 abaixo, dependendo se estiver importando de um repositório (recomendado) ou de um arquivo JAR.
Cenário Um - Importando de um repositório
Se estiver importando seus beans de um repositório, siga estas etapas:
Você pode encontrar mais informações sobre como executar essas etapas na ajuda online do VisualAge for Java do Ambiente de Desenvolvimento EJB.
Cenário Dois - Importando de um arquivo JAR
Se você exportou seus beans corporativos para um arquivo JAR, sigas estas etapas:
Você pode encontrar mais informações sobre como executar essas etapas na ajuda online do VisualAge for Java do Ambiente de Desenvolvimento EJB.
D.4.2 Migrando beans corporativos do VisualAge for Java, Versão 3.0 ou 3.02
Se você tiver um bean corporativo existente que tenha código disponibilizado gerado utilizando o VisualAge for Java Versão 3.0 ou Versão 3.02, e agora deseja trabalhar com o bean corporativo utilizando o VisualAge for Java, Versão 4.0, será necessário migrar o bean corporativo para a Versão 4.0 e depois excluir explicitamente e gerar outra vez o código disponibilizado.
No entanto, antes de migrar o código do bean corporativo para a Versão 4.0, será necessário concluir as seguintes atividades na versão atual do VisualAge for Java (Versão 3.0 ou Versão 3.02):
Para migrar o código do bean corporativo e gerar novamente o código disponibilizado, conclua as seguintes etapas no VisualAge for Java, Versão 4.0, na ordem exata mostrada:
D.4.3 Migrando associações de EJB do VisualAge for Java, Versão 3.0
Quando você inclui, edita ou exclui uma associação em um grupo EJB criado na Versão 3.0, o VisualAge for Java automaticamente converte todas as associações para o novo formato de associação. Para concluir o processo de migração, faça as seguintes alterações manualmente:
Estes métodos não foram convertidos automaticamente por causa da alta probabilidade de modificações feitas manualmente neles. O VisualAge for Java incluirá as chamadas automaticamente quando novos beans forem criados na Versão 4.0.
Se você importa uma Versão 3.0 ou um bean de entidade CMP anterior para um grupo EJB cujas associações já tenham sido migradas e então inclui um novo bean que herda do bean de entidade CMP importado, a nova classe bean exibirá Xs vermelhos em vários métodos. Isto é porque a classe bean dos beans importados faltarão nos métodos _initLinks, _getLinks e _removeLinks. Você deve incluir esses métodos na classe do bean importado manualmente.
Quando estiver pronto para disponibilizar seu código de bean corporativo em um servidor de aplicativos de produção, você deverá assegurar que também tenha disponibilizado o arquivo JAR de runtime que contém o código de runtime requerido pelos beans de acesso e de associações. Este arquivo JAR deve ser distribuído para o seu servidor de aplicativos e deve ser incluído no caminho-de-classe do servidor de aplicativos. Informações adicionais sobre o arquivo JAR de runtime são encontradas na ajuda online do Ambiente de Desenvolvimento EJB.
D.4.4 Migrando de associação EJB do VisualAge for Java 3.02
Ao abrir pela primeira vez um grupo EJB com associações criadas na Versão 3.02 do VisualAge for Java, o grupo conterá ícones de erro próximos às classes de link geradas. Quando você inclui, edita ou exclui uma associação neste tipo de grupo EJB, o VisualAge for Java repara as classes de link para todas as associações no grupo EJB automaticamente. Se não estiver planejando fazer qualquer alteração na associação, você ainda precisará selecionar a associação no painel Propriedades da página EJB e selecionar Editar em seu menu pop-up para abrir o editor de associação. Em seguida, clique em OK para concluir o processo de migração.
O VisualAge for Java removerá automaticamente alguns métodos relacionados à associação que foram gerados no VisualAge for Java 3.02. Os métodos removidos são métodos que, devido às características da associação, não funcionariam corretamente na Versão 4.0. Por exemplo, se uma função faz parte da chave externa, o método definido para essa função não é válido. O método teria sido gerado automaticamente na Versão 3.02 e não pode ser gerado na Versão 4.0.
D.5.1 Enterprise Access Builder
D.5.1.1 Suporte ao novo conector
O Enterprise Access Builder agora suporta os conectores Common Connector Framework (CCF)
e Java 2, Edição Enterprise (J2EE) Connector Architecture. O
Enterprise Access Builder possui novas ferramentas que migrarão registros EAB, Comandos, Navegadores e
beans de sessão de um formato
CCF para um formato J2EE Connector Architecture. Além disso, os SmartGuides
e editores a seguir foram atualizados para refletir o novo suporte para o
J2EE Connector Architecture:
Para obter mais informações sobre o novo suporte aos IBM Connectors and Tools for J2EE(TM) - Beta e sobre os novos Migradores EAB, consulte a ajuda online do Enterprise Access Builder.
D.5.1.2 Gerando novamente e editando seus registros e
Comandos
Se você migrar os aplicativos EAB de uma versão anterior do VisualAge
for Java para a Versão 4.0, talvez você queira gerar seus registros
e Comandos novamente. Eles apresentarão um desempenho melhor na Versão 4.0 se forem gerados novamente.
Anteriormente, se você selecionasse "Direto" e "Encurtar nomes", sem selecionar "Classes internas", os nomes dos registros gerados
ficavam, às vezes, maiores do que o necessário. O resultado eram nomes gerados que excediam
o limite de nome de arquivo de 255 caracteres do Windows. O SmartGuide - Criar Registro a partir
do Tipo de Registro agora foi otimizado para gerar nomes o mais curto possível quando as opções
acima forem selecionadas. No entanto, se você gerar novamente com essas opções e visto que os nomes de registros podem mudar, seus aplicativos poderão ser afetados.
Se o Comando do EAB foi criado na Versão 2.0x, não será possível editá-lo no Editor de Comandos. Entretanto, você pode editá-lo no Editor de Composição Visual. A versão atual do ambiente de runtime é compatível com versões anteriores, portanto, você pode executar os Comandos da Versão 2.0x com ele.
D.5.1.3 Disponibilizando seus aplicativos
A Versão 4.0 é um release de transição para o EAB (Enterprise Access Builder). A arquitetura Common
Connector Framework (CCF) mais antiga, na qual está baseado o EAB, está sendo movida
para a nova arquitetura J2EE Connector. A documentação do EAB descreve esta transição
e as diferenças entre elas. Para este release, as duas arquiteturas são suportadas.
Em disponibilidade, isto implica que existem algumas diferenças. Leia a seção de
disponibilidade na documentação do EAB para saber estes detalhes. O parágrafo
a seguir é uma visão geral simples de disponibilidade.
Para aplicativos existentes, você pode continuar da mesma forma que no passado. Disponibilize seu aplicativo com os arquivos eab\runtime30\eablib.jar, ccf.jar, recjava.jar e JAR requeridos pelo seu conector no runtime. Para novos aplicativos que incluíram alguns componentes relacionados à arquitetura J2EE Connector, como registros e Comandos que utilizam a arquitetura J2EE, disponibilize seus aplicativos com eab\runtime35\eablib.jar. Possui dois modos, significando que suporta as duas arquiteturas. Além disso, serão necessários outros arquivos JAR relacionados somente ao J2EE, que são especificados na seção de disponibilidade da documentação do EAB.
D.5.2 E-connectors
A seção a seguir contém informações sobre migração de IMS Connect, CICS Connector e E-connector.
Importante : Devido a uma limitação no suporte do sistema de arquivos de CD-ROM (CDFS) no Windows 98, a instalação de determinados arquivos conectores de e-business do CD-ROM poderão falhar e fazer com que um ou mais dos seguintes diálogos de erro sejam exibidos, dependendo dos conectores selecionados:
Todos os arquivos que não foram instalados são armazenados em um arquivo zip (econnfix.zip) localizado na raiz do CD do produto. Se você estiver tentando instalar o VisualAge for Java no Windows 98 e receber uma das mensagens acima, descompacte o econnfix.zip no diretório onde o produto foi instalado (por exemplo, executando o comando unzip econnfix.zip -d c:\Arquivos de Programas\IBM\VisualAge for Java\ em que c:\Arquivos de Programas\IBM\VisualAge for Java\ é o diretório de instalação do produto). Depois desses arquivos estarem localizados, os conectores funcionarão corretamente.
D.5.2.1 IMS Connect
O suporte para IMS TCP/IP OTMA Connection (IMS TOC) será suspenso em março de 2001. É recomendável que os usuários
migrem do IMS TOC para IMS Connect e o utilizem, em vez do IMS TOC.
O IMS Connect é um produto da IBM instalável em SMP disponível separadamente (ele não está incluído no VisualAge for Java) que você pode utilizar em conjunto com o IMS Connector do VisualAge for Java para acessar o IMS. Após migrar do IMS TOC para o IMS Connect, você pode continuar a utilizar todos os programas IMS Connector for Java - não é necessário alterá-los ou atualizá-los.
D.5.2.2 CICS Connector
O comportamento do sinalizador CICSELUW no ECIInteractionSpec foi modificado para corrigir o modelo do CCF Connector Architecture. Em releases
anteriores, este sinalizador assumiu o padrão de FALSE no construtor e, independentemente
da existência de um Coordenador real, sempre determinou se o
LUW era estendido.
Neste release, o sinalizador CICSELUW é padronizado como TRUE no construtor ECIInteractionSpec se um Coordenador real do CCF (por exemplo, JavaCoordinator) estiver presente. A menos que você tenha definido especificamente esta propriedade no código antigo do VisualAge for Java, a propriedade CICSELUW em seu código antigo assumirá o padrão de TRUE, depois de ter sido migrada para o VisualAge for Java, Versão 4.0.
Quando nenhum Coordenador real estiver presente, este sinalizador será ignorado e todos os seus aplicativos (os antigos e os novos criados no VisualAge for Java, Versão 4.0) procederão como se o sinalizador CICSELUW fosse FALSE. Portanto, definir este sinalizador explicitamente não terá efeito, a menos que você utilize um coordenador real em seu ambiente.
D.5.2.3 Migração do E-connector
Enquanto a maior parte das versões anteriores do VisualAge for Java podem coexistir com a
Versão 4.0, a coexistência de níveis diferentes de e-connectors não é
suportada.
Migrando do VisualAge for Java, Versão 3.0x ou Versão 3.5.x
Se você tiver e-connectors instalados, será necessário seguir um dos dois cenários de migração a seguir para migrar com êxito de uma Versão 3.0x ou Versão 3.5.x do VisualAge for Java para a Versão 4.0.
A diferença entre os dois cenários de migração é o estágio em que os conectores são migrados.
No Cenário 1, os conectores são migrados durante o processo de instalação inicial. Após concluir as etapas neste cenário, você terá o VisualAge for Java, Versão 3.0x ou Versão 3.5.x sem conectores, coexistindo com o VisualAge for Java, Versão 4.0, com conectores.
No Cenário 2, os conectores são migrados após o processo de migração inicial. Depois de concluir as etapas neste cenário, você terá o VisualAge for Java, Versão 4.0, sem os conectores, coexistindo com o VisualAge for Java, Versão 3.0x ou Versão 3.5.x com os conectores. Mais tarde você poderá desinstalar os conectores da Versão 3.0x ou Versão 3.5.x e instalar os conectores da Versão 4.0.
Cenário de migração 1
Para evitar conflitos e erros em instalações futuras de conectores, as variáveis de ambiente não devem conter referências aos conectores removidos. Para editar as variáveis de ambiente:
Windows NT e Windows 2000
Windows 98
O Access Builder e o Connector para SAP R/3 também fornecem algumas classes utilitárias (por exemplo, LogonBean) com base no Swing 1.0.3. Estas classes são substituídas por classes baseadas em Swing 1.1. Ao migrar da Versão 3.0x ou Versão 3.5.x para a Versão 4.0, será necessário migrar suas próprias classes baseadas no Swing 1.0.3 para o nível 1.1 para continuar utilizando as classes de utilitários fornecidas pelo Access Builder e pelo Connector para SAP R/3. Você pode utilizar a ferramenta Corrigir/Migrar do IDE para este processo.
Cenário de migração 2
Para instalar os conectores do VisualAge for Java, Versão 4.0, você deverá desinstalar a Versão 3.0x/3.5.x ou desinstalar os conectores 3.0x/3.5.x, seguindo as etapas mencionadas no Cenário de Migração 1. Depois de ter desinstalado os conectores da Versão 3.0x/3.5.x ou do VisualAge for Java, Versão 3.0x/3.5.x, você poderá instalar os conectores da Versão 4.0 seguindo estas etapas:
Migrando do VisualAge for Java, Versão 3.5 ou Versão 3.5.3
Durante a migração do VisualAge for Java, Versão 3.5 ou 3.5.3, para o VisualAge for Java, Versão 4.0, o IBM Connectors instalado com o VisualAge for Java 3.5 ou 3.5.3 deverá, primeiro, ser desinstalado para assegurar que a versão correta do IBM Connectors esteja instalada com o VisualAge for Java 4.0.
Se você tentar instalar o VisualAge for Java, Versão 4.0, antes de remover a Versão 3.5 ou 3.5.3 do IBM Connectors, um diálogo será exibido afirmando que é necessário primeiro migrar um de seus aplicativos que utiliza o IBM Connectors antes de poder continuar com a instalação da Versão 4.0.
Para migrar seus aplicativos e desinstalar a Versão 3.5 ou 3.5.3 do IBM Connectors, siga as etapas abaixo.
Para evitar conflitos e erros em instalações futuras de conectores, as variáveis de ambiente não devem conter referências aos conectores removidos. Para editar as variáveis de ambiente:
Windows NT e Windows 2000
Windows 98
Desinstalação dos conectores
Se você desinstalar o VisualAge for Java, Versão 4.0, os conectores serão desinstalados automaticamente. Para evitar conflitos e erros em instalações futuras de conectores, as variáveis de ambiente não devem conter referências aos conectores removidos. Para editar as variáveis de ambiente, siga as etapas apropriadas abaixo:Windows NT e Windows 2000
Windows 98
Somente Windows 98: Talvez seja necessário excluir manualmente o diretório de e-connectors (que por padrão é C:\IBM Connectors) após desinstalar o VisualAge for Java.
D.6.1 Migração da Versão 2.0 do VisualAge for Java
As classes geradas utilizando o Enterprise Toolkit for AS/400 com o VisualAge for Java, Versão 2.0, não são compatíveis com as classes Java geradas utilizando o Enterprise Toolkit for AS/400 com o VisualAge for Java, Versão 4.0. A razão dessa incompatibilidade é que as classes Java ET/400 Versão 2.0 utilizavam o AWT (Abstract Windowing Toolkit) e as classes Java ET/400 Versão 4.0 utilizam o Java 2 SDK Swing.
No entanto, as classes fornecidas na Versão 2.0 ainda podem ser encontradas no pacote com.ibm.ivj.et400.util.awt, que é fornecido com o VisualAge for Java, Versão 4.0. Se você desejar utilizar as classes geradas na Versão 2.0 do VisualAge for Java, Versão 4.0, você terá que alterar as referências nas classes da Versão 2.0 do pacote com.ibm.ivj.et400.util para o pacote com.ibm.ivj.et400.util.awt. Isto pode ser feito utilizando o SmartGuide Corrigir/Migrar fornecido com o VisualAge for Java. Os erros que ocorrerem durante a migração serão registrados na janela de Log. Consulte a ajuda online para obter informações sobre o uso do SmartGuide.
D.6.2 Migração da Versão 3.0 ou 3.02 do VisualAge for Java
Se você gerou classes Java utilizando o SmartGuide - Converter Arquivo de Exibição do ET/400 com o VisualAge for Java, Versão 3.0 ou 3.02, elas não serão compatíveis com as classes Java geradas utilizando o SmartGuide - Converter Arquivo de Exibição do ET/400 do VisualAge for Java, Versão 4.0.
A razão dessa incompatibilidade é que o código gerado na Versão 3.0 e 3.02 utiliza classes desaprovadas, como as classes AS400SVisualTextField e Subfile, enquanto que o código gerado na Versão 4.0 utiliza os beans JFormatted. Todas as classes desaprovadas ainda podem ser encontradas no pacote com.ibm.ivj.et400.util, incluído com o VisualAge for Java, Versão 4.0. Se deseja utilizar as classes geradas na Versão 3.0 ou 3.02, deverá utilizar a ferramenta Corrigir/Migrar para converter todas as classes migradas para que façam referência aos novos nomes do pacote Java 2 SDK Swing. Isto pode ser feito selecionando as classes afetadas, abrindo a ferramenta Corrigir/Migrar e selecionando a caixa de opções Incluir pacotes renomeados do JDK 1.2. Esta ação migra automaticamente as referências do Swing para o SDK Java 2. Consulte a ajuda online para obter mais informações sobre essa tarefa. Os erros que ocorrerem durante a migração serão registrados na janela de Log.
O SmartGuide - Criar Subarquivo não está incluído no VisualAge for Java, Versão 4.0. Ele foi substituído pelos beans DFU mais potentes e JFormattedTable. Se desejar continuar utilizando o SmartGuide - Criar Subarquivo para gerar código, você deve continuar trabalhando com uma versão anterior (3.02 ou anterior) do VisualAge for Java. Qualquer código gerado pelo SmartGuide - Criar Subarquivo na Versão 3.0 ou 3.02 pode ser migrado para a Versão 4.0, pois as classes necessárias para o código gerado ainda são suportadas e podem ser encontradas no pacote com.ibm.ivj.et400.util. Você deve seguir as mesmas etapas documentadas no parágrafo anterior para migrar seu código.
A versão do ET/390 que você deve utilizar para desenvolver aplicativos do OS/390 depende do nível do SDK disponível em sistemas OS/390 ou aplicativos middleware e o nível de SDK suportado pelo VisualAge for Java (incluindo ET/390).
Em sistemas OS/390 e aplicativos middleware há dois níveis de SDK disponíveis, conforme mostrado na tabela a seguir:
Sistema ou aplicativo middleware | Nível de SDK |
---|---|
OS/390 | SDK 1.1.8, 1.3.0 |
WebSphere Application Server, Versão 3.0 | SDK 1.1.8 |
CICS Transaction Server, Versão 1.3 | SDK 1.1.8 para transações interpretadas e compiladas |
DB2 Universal Database, Versões 5 e 6 | SDK 1.1.8 apenas para procedimentos armazenados compilados |
No VisualAge for Java, diferentes versões do produto suportam diferentes níveis de SDK, conforme mostrado na tabela a seguir:
VisualAge for Java | Nível de SDK |
---|---|
Versões 3.5, 3.5.3 e 4.0 | SDK 1.2.2 |
Versão 3.02 | SDK 1.1.8 |
As seções a seguir descrevem os tipos de aplicativos OS/390 que você pode desenvolver utilizando diferentes versões do ET/390.
VisualAge for Java, Versões 3.5, 3.5.3 e 4.0
O ET/390 no VisualAge for Java, Versões 3.5, 3.5.3 e 4.0, é destinado, principalmente, nos seguintes tipos de aplicativos:
Para aplicativos interpretados em execução no WebSphere Application Server, Versão 3.0, você deverá criar suas classes de aplicativo de forma que elas trabalhem com as APIs Java no nível do SDK 1.1.8. Uma vez que elas tiverem sido criadas, você poderá exportar as classes para uma unidade montada do NFS, tornando-as disponíveis no sistema do OS/390. Você poderá, então, executar e depurar seu aplicativo clicando nos itens de menu Executar main e Depurar main do IDE do VisualAge for Java.
Para aplicativos independentes, interpretados em execução no sistema OS/390, você deverá criar suas classes de aplicativo de forma que elas trabalhem com as APIS Java no nível do SDK 1.3.0. Uma vez que elas tiverem sido criadas, você poderá exportar as classes para uma unidade montada do NFS, tornando-as disponíveis no sistema do OS/390. Você poderá, então, executar seu aplicativo clicando no item de menu Executar main do IDE do VisualAge for Java.
Consulte a ajuda online do ET/390 para obter detalhes sobre a geração, exportação, execução e depuração de aplicativos interpretados.
VisualAge for Java, Versão 3.02
O ET/390 no VisualAge for Java, Versão 3.0.2, é destinado em princípio para os tipos de aplicativos a seguir:
O ET/WS (Enterprise Toolkit for Workstations) e o compilador de alto desempenho (HPJ) não estão incluídos neste release do VisualAge for Java. Se desejar continuar utilizando o Enterprise Toolkit for Workstations, terá que continuar trabalhando em uma versão anterior (3.02 ou anterior) do VisualAge for Java.
Não há recursos novos no VisualAge for Java, Versão 4.0, que substituam a funcionalidade fornecida anteriormente pelo ET/WS. Uma funcionalidade semelhante à incluída com o ET/WS pode ser encontrada no compilador "Just-in-time", que faz parte da Máquina virtual Java. A máquina virtual Java está incluída no IBM Developer Kit, Edição Java Technology, v1.2.2, PTF 9.
O compilador JIT obtém bytecode e o compila no código de execução direta e depois executa os programas. O bytecode está preservado e ainda permanece portável, entretanto, o código (depois de ser compilado pelo JIT) é executado mais rapidamente. Para obter mais informações, vá para o site do Sun(TM) na Web http://java.sun.com.
Ao migrar do VisualAge for Java, Versão 3.5 para a Versão 4.0, você poderá continuar a utilizar o Controle Externo de Versão nos projetos da versão 3.5 em que ele era utilizado. Se os ícones do Controle Externo de Versão não aparecerem no início, efetue a ação Ferramentas > Controle Externo de Versão > Atualizar Projeto e eles deverão aparecer.
Poderá ser necessário reiniciar o Acesso Remoto à API de Ferramentas, o que pode ser feito a partir do diálogo Opções. Selecione Janelas > Opções para abrir o diálogo Opções. Selecione Acesso Remoto à API de Ferramentas e clique no botãoAcesso Remoto à API de Ferramentas para iniciá-lo.
Se estiver utilizando o compilador IDL-para-Java fornecido pelo recurso IBM Component Broker Series ou CICS IIOP Server Support, será necessário definir manualmente a string de chamada do compilador IDL-para-Java nos seguintes diálogos:
A página Compilação IDL-para-Java do diálogo Opções (acessível no menu Windows). Modifique a string no campo Comando.
O diálogo Alterar Opções de Compilação IDL-para-Java aparece. Na página IDL, selecione IDL > Alterar Opções de Compilação. Modifique a string no campo Comando.
Para obter mais informações sobre como modificar a string e abrir a página IDL, consulte a documentação online do Ambiente de Desenvolvimento IDL.
Consulte a seção 1.0 da Parte D para obter informações sobre suporte a CICS IIOP.
O nível do JDK foi alterado desde a Versão 3.5 (ele é agora JDK 1.2.2 PTF 9).
Se você modificou a Biblioteca de Classe Java do VisualAge for Java, Versão 3.5, substituindo qualquer pacote ou classe da biblioteca ou incluindo qualquer pacote e classe nela, essas modificações não serão reproduzidas automaticamente na Biblioteca de Classe Java Versão 4.0 depois da migração; você precisará modificá-la outra vez manualmente.
A Biblioteca de Classe Java era totalmente apenas para leitura no VisualAge for Java antes da Versão 3.5.
Se estiver migrando de uma versão anterior do VisualAge for Java para o VisualAge for Java, Versão 4.0, os dois seguintes arquivos serão sobrepostos por novas versões e todas as alterações que possam ter sido feitas neles serão perdidas:
Você pode optar por fazer cópias de backup desses arquivos antes de migrar para a Versão 4.0 e incluir as alterações antigas nas novas versões dos arquivos depois de ter terminado de migrar para o VisualAge for Java, Versão 4.0. Você não deve simplesmente copiar as versões antigas dos arquivos sobre as novas versões deles porque as novas versões contêm informações que não estão nas versões antigas desses arquivos.
O Migration Assistant for ActiveX não está incluído neste release do VisualAge for Java. Você pode migrar o código criado com o Migration Assistant em versões anteriores (3.02 ou anterior) do VisualAge for Java para a Versão 4.0, seguindo as etapas gerais de migração descritas na Parte B. Não existe nenhum recurso novo no VisualAge for Java, Versão 4.0, que substitua essa funcionalidade fornecida anteriormente pelo Migration Assistant for ActiveX.
Nota: Não é necessário aplicar o FixPak 3.5.1 ou FixPak 3.5.2 do Persistence Builder (disponível a partir do VADD) no VisualAge for Java, Versão 4.0. Essas correções já foram incorporadas ao código da Versão 4.0.
Você deve utilizar o VisualAge for Java para gerar novamente código de qualquer release anterior do Persistence Builder.
D.14.1 Fazendo o upgrade específico da Versão 2.0
As questões sobre migração a seguir são pertinentes se você estiver fazendo o upgrade do VisualAge for Java, Versão 2.0:
Para obter mais informações sobre como executar estas etapas, consulte a documentação online do Persistence Builder.
D.14.2 Fazendo o upgrade de todas as versões anteriores (incluindo a Versão 2.0)
Quando você carrega modelos, mapas ou esquemas disponíveis nos Navegadores de Modelos, o interior dos meta-dados é alterado. Não será possível carregar de modo confiável os meta-dados em uma área de trabalho que esteja em um nível de release inferior ao da Versão 4.0. O modelo, mapa ou esquema aparecerá "sujo". Salve o modelo, mapa ou esquema.
Nota: As informações a seguir aplicam-se apenas se você estiver migrando da Versão 2.0 ou 3.0x do VisualAge for Java. Elas não se aplicam se você estiver migrando da Versão 3.5.
As classes criadas em releases anteriores para consultas personalizadas terão erros. A estrutura de consulta personalizada agora lança um objeto Lançável, para permitir que você capture exceções que ocorrem quando a consulta personalizada é chamada. Como resultado, todas as consultas personalizadas pré-existentes aparecem no IDE como contendo um erro não-resolvido (com um X vermelho), porque elas não estão manipulando a exceção lançada. Para corrigir esta situação, lance a exceção de sua consulta personalizada ou capture a exceção.
Você pode encontrar mais informações sobre como lidar com erros na ajuda online do Visual for Java.
Alterações no suporte de runtime
O nome do projeto que contém os pacotes javax de
pré-requisito do runtime do Persistence Builder mudou. Isso
pode fazer com que você recalcule o caminho do projeto dos elementos
do programa que usam o Persistence Builder, desta forma:
O RMI Access Builder não está incluído no VisualAge for Java, Versão 4.0. Você pode importar as classes e projetos da biblioteca de runtime antigos gerados para a área de trabalho da Versão 4.0, mas não conseguirá executar o ROIM (Remote Object Invocation Manager), pois ele não está incluído. Você deve estar familiarizado com o novo modelo de segurança do Java 2 Platform e como suas limitações podem afetar os aplicativos do RMI Access Builder.
Incluindo a biblioteca de runtime do RMI Access Builder em sua
área de trabalho
Você deve importar a biblioteca de runtime do RMI Access Builder da
Versão 3.0x do VisualAge for Java e incluí-la em sua área de trabalho. Não
é possível executar seus aplicativos do RMI Access Builder no VisualAge for Java, Versão 4.0 sem isto.
Migrando os aplicativos do RMI Access Builder
Se seus aplicativos RMI ainda não estiverem no repositório da Versão 4.0,
siga estas etapas para importá-los para a área de trabalho.
Se você pretende executar quaisquer dos objetos do servidor, precisa primeiro criar uma linha principal do servidor. Por exemplo, se você possui um Server Proxy do servidor: Reverse1S e ServerObj2S, pode gravar o main do servidor para criar instâncias dos objetos do servidor:
import...;
public class Servermain {
public static void main(String arg[]) {
try{
Reverse1S myserver = new Reverse1S();
ServerOvj2S obj2 = new ServerObj2S();
}
catch (Exception e) {
e.printStackTrace();
}
System.out.print ln("Objetos do Servidor Iniciados.");
}
}
Da mesma forma, devido a restrições de segurança mais rígidas, será necessário definir um arquivo de política para servidores e clientes. Por exemplo, você pode ter um arquivo de política chamado "Minha política":
grant {
//Conceder todas as permissões
permission java.security.AllPermission;
};
Ou pode ter uma política que permita que qualquer um atenda em portas não-privilegiadas:
grant {
// permite que qualquer um atenda em portas não-privilegiadas
permission java.net.SocketPermission "localhost:1024-", "listen";
permission java.net.SocketPermission "localhost:1024-", "resolve";
permission java.net.SocketPermission "pathfinder:1000-4000", "listen";
permission java.net.SocketPermission "pathfinder:1000-4000", "connect";
permission java.net.SocketPermission "pathfinder:1000-4000", "resolve";
};
em que pathfinder é o nome da máquina do usuário.
Você terá que executar um comando semelhante ao seguinte para lançar corretamente o cliente:
java-Djava.security.policy=<myPolicy.file>
Por exemplo, se main() estivesse sendo executado dentro do IDE, você especificaria java.security.policy= na seção Propriedades ao selecionar o item de menu "executar com".
Você deve manter seu código na versão anterior do VisualAge for Java para que possa continuar a desenvolvê-lo ou gerá-lo novamente.
Você deve utilizar a ferramenta de migração IDE para consertar meta-dados de composições visuais. Consulte o tópico da ajuda online "Corrigir/migrar diretrizes para referências de classe ou pacote" para obter informações sobre como consertar referências de classe ou pacote interrompidas devido à migração de classes para o J2SDK v.1.2.2 ou a renomeação de elementos de programas definidos pelo usuário.
O VisualAge for Java não acompanha as dependências entre as classes que estão sendo migradas. As classes que são referidas em uma classe e que ainda não foram migradas podem ter problemas com inicialização de classe ou podem fazer uma introspecção incorreta.
Os erros que ocorrerem durante a migração serão registrados na janela de Log. Por exemplo, suponha que a seguinte mensagem apareça na janela de Log enquanto você está migrando uma classe chamada Sample.Samp:
Classe de migração: Sample.Samp
Não foi possível migrar a Classe:<Pkg>X::Y
Sample.Samp faz referência a X::Y; o VisualAge for Java encontrou problemas ao carregar a classe Y. Y ainda não foi migrado, ou está faltando. (No Editor de Composição Visual, a classe Y aparece como uma classe problema.) Para corrigir isso, migre Y primeiro ou, se Y estiver faltando, procure uma classe substituta para Y. Em casos extremos, você pode ter que abrir Samp ou Y em sua versão anterior do VisualAge for Java e redefinir beans ou propriedades para que a migração possa continuar.
Em alguns casos, abrir a classe no VCE resultará na abertura do diálogo Resolver Referências de Classe. Esse diálogo mostra as classes problema existentes no VCE. A coluna Referência de classe não-resolvida no diálogo, especifica a classe que o VisualAge for Java utilizava como uma substituição temporária. Isso aparece como a seguir:
com.ibm.uvm.abt.edit.DeletedClassView(X)
O X que aparece entre parênteses é o nome da classe problema. É provável que o X tenha sido migrado corretamente após a classe atual. Para corrigir isto, selecione a linha a ser corrigida e clique no botão Substituir . No diálogo "Escolher uma classe válida", selecione a classe X como a classe de substituição. Proceda dessa forma para todas as classes não resolvidas e clique em OK.
O Servlet Builder e o Servlet Launcher não estão incluídos no VisualAge for Java, Versão 4.0. Um arquivo JAR de runtime do Servlet Builder compatível com a Versão 4.0 está disponível no endereço http://www.ibm.com/vadd. Siga o link para "Download".
Não há nenhum recurso novo no VisualAge for Java, Versão 4.0, que substitua diretamente a funcionalidade fornecida anteriormente pelo Servlet Launcher. Para testar seus servlets, você poderá lançá-los explicitamente digitando a URL em um navegador da Web ou gerando páginas HTML ou JSP para chamá-los. Para o desenvolvimento de novos servlets, você pode utilizar o novo Servlet SmartGuide, que também irá criar uma página HTML que lançará seu servlet.
Há duas opções para uso do arquivo de runtime:
Cenário 1
Neste cenário, edite o código em sua edição anterior do VisualAge for Java, utilizando o Servlet Builder antes de exportá-lo.
Cenário 2
Neste cenário, você edita o código do Servlet Builder dentro do VisualAge for Java, testando-o no WebSphere Unit Test Environment.
Siga estas etapas:
Você pode encontrar mais informações sobre como executar essas etapas na ajuda online do VisualAge for Java.
O recurso Servlet Builder, que estava disponível em releases anteriores do VisualAge for Java, criava servlets que geravam uma interface com o usuário HTML diretamente. Esta capacidade é útil para se obter um desenvolvimento rápido do aplicativo, mas tem a desvantagem de combinar a lógica de negócios do aplicativo com sua interface com o usuário. Se for desejada uma alteração na interface com o usuário, o servlet deverá ser modificado. Para facilitar a manutenção, seria preferível utilizar a tecnologia JSP (JavaServer Pages (TM)) para separar a interface do usuário da lógica de negócios.
Uma página JSP é um gabarito HTML que inclui conteúdo gerado dinamicamente. Uma página JSP pode ser modificada com o uso de ferramentas de edição HTML, como o recurso PageDesigner no IBM WebSphere Studio. No modelo de programação do WebSphere da IBM, os servlets ainda são utilizados para interação da Web, mas delegam lógica de negócios para beans Java e a interface do usuário para o JSP. Nesse modelo de programação, os servlets e beans são desenvolvidos com as ferramentas Java e as páginas JSP são desenvolvidas com as ferramentas HTML.
Esta separação da lógica de negócios e da interface do usuário permite que você atribua responsabilidades de desenvolvimento aos membros de equipe que tenham habilidades e ferramentas apropriadas, levando a uma manutenção mais fácil.
De acordo com o modelo de programação do WebSphere, a função que foi fornecida pelo Servlet Builder foi substituída por ferramentas Java no VisualAge for Java e por ferramentas HTML no WebSphere Studio. O VisualAge for Java, Versão 4.0 fornece um novo SmartGuide (assistente) para ajudá-lo na criação de aplicativos Web que sigam o modelo do WebSphere. Você pode utilizar o SmartGuide - Criar Servlet para gerar um servlet que chame um bean para a lógica de negócios e uma página JSP para a interface com o usuário. O SmartGuide também gera um formulário HTML que pode ser utilizado para testar o servlet. O servlet pode ser testado imediatamente no WebSphere Test Environment do VisualAge for Java e depois refinado no IDE. Os arquivos JSP e HTML podem ser editados posteriormente com o WebSphere Studio ou outra ferramenta HTML.
O SmartGuide - Criar Servlet é modelado no assistente JavaBean no WebSphere Studio. Ele também inclui recursos adicionais que são necessários por programadores Java. Se você já utiliza o WebSphere Studio para o desenvolvimento de HTML, perceberá que o SmartGuide simplifica o fluxo de trabalho entre essa ferramenta e o VisualAge for Java. As etapas de desenvolvimento são:
As Classes Swing no J2SDK v1.2.2 estão em um pacote diferente do que estavam no JDK v1.1.x. Se for necessário atualizar referências para as classes swing, utilize o SmartGuide - Corrigir/Migrar.
Para migrar seus aplicativos, você deve selecionar as classes e pacotes afetados, abrir o SmartGuide - Corrigir/Migrar (clicando com o botão direito do mouse no pacote ou classe, selecionando Reorganizar > Corrigir/Migrar) e selecionar a caixa de opção Incluir pacotes renomeados do JDK1.2 para migrar automaticamente as referências do Swing para o J2SDK v1.2.2.Isto incluirá as entradas De/Para apropriadas para o Swing. Os erros que ocorrerem durante a migração serão registrados na janela de Log.
Consulte os tópicos da ajuda online:"Corrigir/migrar diretrizes para referências de classe ou pacote" e "Consertando referências de classe ou de pacote" para obter informações sobre como migrar corretamente seus aplicativos.
Pode não ser possível utilizar o Visual Composition Editor para migrar todas as propriedades Swing do JDK 1.1.7 para o Java 2, devido a mudanças na serialização entre as Versões 1.03 e 1.1.1 do Swing. Depois de ter migrado seu código para o VisualAge for Java, Versão 4.0, pode ser que você não consiga abrir algumas classes de aplicativos do Swing no VCE. isto ocorre somente quando você tiver usado a página de propriedades do VCE para definir as propriedades de um Javabean para um objeto Swing.
Para solucionar esse problema, execute estas etapas:
- Reabra a classe na versão anterior do VisualAge for Java (no VCE).
- Na página de propriedades da classe, clique no botão Redefinir. É aberta uma janela, listando todas as propriedades do bean que foram modificadas. As propriedades definidas para objetos Swing devem ser redefinidas para o padrão.
- Salve a classe e importe-a novamente para o IDE da Versão 4.0.
Para obter informações sobre a migração da versão Beta 1.2 do XMI Toolkit, consulte suas notas de release.
Se você utilizou qualquer release diferente da Versão 3.5 do XMI Toolkit (por exemplo, uma exibição técnica, um release alphaWorks ou um Beta anterior), será necessário desinstalá-la e remover as atualizações de ambiente efetuadas durante a instalação antes de utilizar este release do XMI Toolkit. As instruções de migração são fornecidas somente para o Release 1.2.
Os arquivos zip e arquivos XMI gerados dos releases Beta 1.2 e pré-Beta 1.2 não são compatíveis com qualquer release 3.5 ou 3.5.x do XMI Toolkit.
Na Versão 4.0 do VisualAge for Java, você poderá criar a versão e executar o release dos arquivos de recurso de seu projeto. Consulte a ajuda online do IDE e da equipe para obter mais informações sobre este novo recurso.
Se você migrou os projetos da Versão 2.0 ou 3.0x do
VisualAge for Java para a Versão 4.0 do VisualAge for Java, poderá seguir estas
etapas depois de ter concluído o processo de migração. Não é necessário efetuá-las imediatamente após ter concluído a migração, mas até que você o faça, as versões de seus recursos de projeto não serão criadas no repositório.
Nota: Não será necessário efetuar estas etapas se você tiver migrado seus projetos da Versão 3.5.
Se estiver planejando trabalhar em um ambiente de equipe com a Edição Enterprise do VisualAge for Java, é necessário utilizar o EMSRV, Versão 7.1.
O OS/2 e o AIX não são suportados como plataformas de desenvolvimento para o VisualAge for Java, Versão 4.0. Você só pode instalar o VisualAge for Java, Versão 4.0 como um cliente no Windows NT, Windows 98 e Windows 2000. Para utilizar a Versão 4.0 com seus repositórios do OS/2 e do AIX, você deverá conectar-se a esse repositório do IDE da Versão 4.0. Consulte a ajuda online para obter informações sobre como executar esta tarefa.
Se tiver gerado algum código específico da plataforma, você terá que gerá-lo novamente para que funcione no Windows.
Dois cenários
Nota: Você não pode ter o AIX e o Windows na mesma máquina, portanto, as etapas no Cenário 1 são aplicáveis somente ao OS/2.
Cenário 1
Se o repositório ivj.dat do OS/2 estiver na mesma máquina que o cliente Windows:
Cenário 2
Se repositório de ivj.dat do OS/2 ou do AIX estiver em uma máquina diferente que o cliente Windows:
Devido a uma alteração na política de segurança para applets em execução no Java 2 Platform v1.2.2, os applets não podem mais acessar recursos locais.
Vários exemplos disponíveis com edições anteriores do VisualAge for Java não estão incluídos no VisualAge for Java, Versão 4.0, por causa desta restrição. Além disso, alguns exemplos que estão incluídos só podem ser executados como aplicativos, caso contrário, não funcionarão corretamente. Consulte a documentação online para obter instruções sobre como executar corretamente os exemplos.
Você pode alterar as políticas de segurança padrão criando seu próprio arquivo java.policy e lançando o Visualizador de Applets com o seguinte parâmetro: -Djava.security.policy=someURL
em que someURL é a localização do novo arquivo de política. Para obter mais detalhes sobre segurança geral no Java, consulte http://java.sun.com/security Para obter informações específicas sobre segurança no Java 2 e sintaxe do arquivo de política, consulte http://java.sun.com/products/jdk/1.2/docs/guide/security
A ferramenta do Controle Externo de Versão, introduzida no VisualAge for Java, Versão 3.5, permite que você conecte-se a provedores SCM (source code management) externos como o ClearCase, PVCS Version Manager, TeamConnection(TM) e o SourceSafe(TM) a partir do VisualAge for Java. Com essa ferramenta, é possível incluir classes em seu provedor SCM, reservar e liberar arquivos de classes e recursos do sistema SCM e importar a versão reservada mais recentemente de uma classe a partir do sistema SCM.
Essa ferramenta substitui a ferramenta SCM Externo antiga e fornece funcionalidade adicional.
É possível trabalhar ORBs (Object Request Brokers) de terceiros no VisualAge for Java se eles forem compatíveis com o J2SDK v1.2.2. As classes ORB devem ser importadas para o IDE antes de você poder trabalhar com elas.
Ao importar classes Java para o IDE, você pode incluir classes de extensão ORB nas Bibliotecas de Classe Java. Você também pode substituir algumas das classes de extensão ORB encontradas nas Bibliotecas de Classe Java existentes enquanto elas não forem parte das classes do núcleo do J2SDK v1.2.2.
Você encontrará um artigo contendo mais detalhes sobre como trabalhar com ORBs de terceiros na Versão 3.5.x na Web no endereço:
http://www.ibm.com/software/vadd/Data/Document2175
Este artigo contém informações amplas sobre o desenvolvimento do CORBA (Common Object Request Broker Architecture) e aplicativos ORB no VisualAge for Java.
Determinadas classes da Biblioteca de Classe Java podem ser substituídas quando um ORB de terceiro é importado para o VisualAge for Java. A correção 2 para a Versão 3.5 corrige um defeito que erroneamente permitiu a importação de determinadas classes imutáveis (as contidas em pacotes mutáveis) para o VisualAge for Java. Após aplicar a Correção 2 do VisualAge for Java, Versão 3.5, você poderá receber avisos novos ou adicionais na janela Log quando importar um ORB de terceiros. Estes avisos aparecem porque você não pode importar classes imutáveis para o VisualAge for Java após a aplicação da Correção 2. Entretanto, eles podem ser ignorados.
O CD Additional Features do VisualAge for Java contém:
O manual de Instalação e Migração e o README do produto estão no CD Additional Features e o CD principal do produto.
Nota: O CD Additional Features está incluído somente no VisualAge for Java, Edição Enterprise. No entanto, os itens a seguir estão incluídos no VisualAge for Java, Edição Professional no CD do produto:
O manual de Instalação e Migração e o README do produto estão no CD do produto VisualAge for Java, Edição Professional.
IBM J2EE Connectors and Tools for J2EE(TM) - Beta
Este release do VisualAge for Java inclui uma versão beta de vários componentes do Java 2 Platform, Edição Enterprise (J2EE) que a Sun Microsystems Inc. não liberou oficialmente. São eles:
Os componentes beta estão localizados no subdiretório extras\BetaJ2EEConnectors. Se desejar utilizar estes componentes beta, consulte o arquivo README no subdiretório BetaJ2EEConnectors para obter instruções de instalação para os componentes.
Nota: Os componentes fornecidos com o VisualAge for Java, Versão 4.0, são suportados apenas no Windows NT e Windows 2000. Nem todos os arquivos de runtime J2EE são suportados no Windows 2000. Para obter mais informações sobre os componentes J2EE, consulte a ajuda online e as notas do release do Enterprise Access Beans.
Servidor de Equipe (EMSRV)
O diretório TeamServer no CD Additional Features contém o programa do servidor de repositório EMSRV e o arquivo "Configuração e administração do servidor" (emsrv71.htm ou emsrv70.htm para todos os idiomas diferentes do inglês). Consulte a Parte C para obter instruções sobre como instalar o EMSRV e o arquivo "Configuração e administração do servidor" (localizado no TeamServer\docs) para obter informações sobre como iniciar o servidor.
Runtimes Distribuíveis
Ao exportar e disponibilizar um applet ou aplicativo criado com o VisualAge for Java, você também precisa disponibilizar a biblioteca de runtime dos recursos com os quais você criou o código, se houver, e colocar o arquivo JAR ou Zip de runtime disponibilizado em seu classpath.
Em geral, os arquivos JAR são compactados e devem ser utilizados na execução de applets fora de um servidor. Os arquivos Zip são descompactados e devem ser colocados no CLASSPATH da máquina de disponibilização para executar aplicativos localmente.
As bibliotecas de runtime do VisualAge for Java estão contidas nos diretórios extras/runtime30 e extras/runtime35. Dependendo de quais recursos do VisualAge for Java foram instalados, algumas ou todas as bibliotecas de runtime também são fornecidas no diretório eab/runtime35 ou runtime30 da imagem de instalação. Nota: As bibliotecas de runtime do J2EE não estão incluídas no CD Additional Features. Os arquivos de runtime para os conectores J2EE estarão localizados em eab\runtime 35 e IBM Connectors\classes depois que você tiver instalado os componentes beta.
Para obter mais informações sobre instalação e utilização de bibliotecas de runtime, consulte a ajuda online.
IBM Developer Kit 1.2.2 (para Windows)
O IBM Developer Kit, Edição Java Technology, v 1.2.2, PTF 9, localizado no diretório do IBM Developer Kit, é um ambiente de desenvolvimento Java que o ajuda a desenvolver aplicativos e applets Java independentes que seguem a especificação 100% Java.
Inclui ferramentas para o desenvolvimento de aplicativos e applets Java, alguns dos quais são:
Para instalar o IBM Developer Kit, execute install.exe no diretório IBM Developer Kit. Para obter informações mais detalhadas sobre o IBM Developer Kit, consulte o arquivo README no diretório do IBM Developer Kit.
Merant DataDirect SequeLink Java Edition Versão 5.1 para Oracle e Microsoft SQLServer
O VisualAge for Java, Versão 4.0, suporta o driver DataDirect SequeLink Java Edition Versão 5.1 da Merant para acesso aos bancos de dados Microsoft SQL Server e Oracle.
Nota: O servidor Merant DataDirect SequeLink Java Edition Versão 5.1 fornecido com o VisualAge for Java, Versão 4.0, é suportado apenas no Windows NT e Windows 2000.
SequeLink é um componente de acesso da dados middle-ware que fornece conectividade de dados para os últimos padrões JDBC para uma variedade de bancos de dados como Oracle, Microsoft SQL Server e ainda dados de mainframe. O componente cliente do SequeLink é independente do banco de dados; portanto, não são necessárias alterações se forem incluídos novos bancos de dados na infra-estrutura. Um cliente SequeLink identificado está incluído no WebSphere Test Environment.
Nota: Como o cliente SequeLink é identificado, você pode comunicar-se apenas com o servidor Merant DataDirect SequeLink Java Edition Versão 5.1 enquanto estiver utilizando o cliente em conjunto com o WebSphere Test Environment ou o Websphere Application Server. O servidor Merant DataDirect SequeLink Java Edition Versão 5.1 não é um servidor totalmente licenciado; você não pode utilizá-lo para nenhum propósito que não seja o trabalho com o cliente identificado Sequelink. Se você possuir um servidor Merant DataDirect SequeLink Java Edition Versão 5.1 totalmente licenciado, o cliente identificado Sequelink também funcionará com ele.
O servidor SequeLink correspondente está disponível como uma instalação sem chave (ou seja, não será solicitada uma chave de registro quando instalá-lo). O servidor pode ser instalado a partir do subdiretório Merant\SequeLinkServer no CD Additional Features.
Como o driver deve ser configurado e instalado varia, dependendo do componente que você deseja utilizar com ele. Consulte as seguintes notas sobre o release para obter informações especificas sobre a instalação e configuração (incluindo informações sobre como configurar o cliente SequeLink incluído no WebSphere Test Environment):
Distributed Debugger
Se estiver planejando depurar classes desenvolvidas fora do IDE VisualAge for Java ou depurar programas que estejam em execução em uma máquina separada, é necessário instalar o Distributed Debugger.
O Distributed Debugger é suportado nos seguintes sistemas operacionais: Windows, AIX, OS/2, HP-UX, Solaris, Linux e Linux/390. Todos os arquivos do Debugger estão localizados no diretório Debugger no CD Additional Features. Consulte a Parte B, Seção 2.1.1.1. para obter instruções de instalação.
Pré-visualizações de Tecnologia
O CD Additional Features contém duas Pré-visualizações de Tecnologia: o IBM Stored Procedure Integration Tool for Enterprise JavaBeans e o XMI Bridge.
IBM Stored Procedure Integration Tool for Enterprise JavaBeans
Você pode utilizar o IBM Stored Procedure Integration Tool for Enterprise JavaBeans (SP integration tool for EJBs) para aperfeiçoar os EJBs de sessão sem estado, incluindo métodos que chamam procedimentos armazenados do banco de dados. Utilizando o SmartGuide - Criar Método de Chamada de Procedimento Armazenado você pode definir seus métodos e gerar o novo método em seu bean de sessão sem estado.
Utilizando o SP integration tool for EJBs, você pode alavancar a lógica de negócios contida nos procedimentos armazenados existentes em um ambiente EJB. Você pode minimizar o esforço de desenvolvimento de EJB e evitar a lógica de negócios redundante no servidor EJB e no sistema de gerência de banco de dados (DBMS). Além disso, como os procedimentos armazenados podem ajudar a reduzir o tráfego entre o servidor EJB e o DBMS, você pode melhorar o desempenho de seus aplicativos de produção.
O SP integration tool for EJBs está localizado no subdiretório extras\spt. Consulte o arquivo EJB_SPTool.PDF no diretório spt para obter mais informações sobre como instalar e utilizar a pré-visualização técnica. Após a instalação da ferramenta de integração SP para EJBs, o arquivo EJB_SPTool.PDF também estará localizado do seguinte diretório: x:\ibmvjava\ide\tools\com-ibm-ivj-sptools, em que x:\ibmvjava é o diretório de instalação de seu produto.
XMI bridge
O XMI bridge é uma pré-visualização técnica para o Persistence Builder e os Enterprise Java Beans que permite importar um arquivo de modelo Rational Rose ou documento XMI para um modelo do Persistence Builder ou do Grupo EJB.
O XMI bridge está localizado no diretório extras\xmib. É necessário incluir o XMI Toolkit na área de trabalho antes de trabalhar com o XMI bridge. Consulte o arquivo README no diretório xmib para obter mais informações sobre como instalar e utilizar a pré-visualização técnica.
Documentação Imprimível
Parte da ajuda online foi agrupada em documentos PDF que podem ser exibidos e impressos com o uso do Adobe Acrobat Reader (disponível de http://www.adobe.com/). Nem todos PDFs estão disponíveis em todos os idiomas. Os arquivos PDF estão disponíveis no diretório pdf.
Consulte o Índice do PDF (no Guia Inicial) para obter informações sobre o que cada arquivo de PDF contém.
Manual de resolução de problemas do sistema de ajuda
Consulte o manual de resolução de problemas do sistema de ajuda para obter informações sobre a recuperação de falha da ajuda. Este manual está localizado no diretório Troubleshoot no CD Additional Features e está disponível em todos os idiomas.
Repositório e recursos
O diretório ivj40 contém dois arquivos zip: ide.zip and wte_resources.zip. O arquivo ide.zip contém uma cópia do repositório (ivj.dat), do diretório de recursos do projeto (ivj.dat.pr) e do arquivo da área de trabalho (ide.icx). O arquivo wte_resources.zip contém uma cópia de backup dos recursos do projeto para o recurso WTE.
Abaixo está uma comparação do Data Access Builder, Data Access beans e Persistence Builder. Está incluída uma breve descrição do Ambiente de Desenvolvimento EJB, mas este componente não está incluído na comparação.
O recurso Data Access beans oferece uma maneira rápida de acessar visualmente dados relacionais. Esse recurso é destinado para uso com aplicativos em que um modelo de objeto reutilizável não é requerido. Você pode utilizar Data Access beans para obter ajuda na criação de aplicativos visuais que precisam de uma exibição direta de tabelas no interior do banco de dados de destino. Também pode incorporar o Data Access beans ao código manualmente.
O Ambiente de
Desenvolvimento EJB permite desenvolver beans que implementam as
especificações de programação do EJB (Enterprise JavaBeans) da Sun
Microsystems.O Ambiente de Desenvolvimento EJB fornece todo o suporte
de runtime necessário para o IBM WebSphere Application Server. Um verificador de consistência incremental assegura
que beans corporativos estejam em conformidade com a especificação de programação do EJB e indica se as alterações são necessárias
para corrigir as inconsistências. Consulte a ajuda online para obter mais
informações sobre o Ambiente de Desenvolvimento EJB.
O Persistence
Builder fornece suporte redimensionável à persistência para
modelos de objeto e é um primeiro passo em direção ao EJB para muitos
clientes. Os aplicativos criados com o Persistence Builder podem destacar o modelo de objeto ideal, reutilizável e mapeá-lo rapidamente
para qualquer banco de dados relacional suportado. O Persistence Builder suporta os mapeamentos bottom-up (Esquema para Objeto)
e top-down (Objeto para Esquema). Este recurso mapeia objetos e relacionamentos
entre objetos, para dados armazenados em bancos de dados relacionais.
O restante deste documento descreve as diferenças entre os recursos de acesso a dados - Data Access beans, Data Access Builder e Persistence Builder.
Os detalhes de implementação de cada recurso não estão incluídos aqui. A documentação online aborda a funcionalidade adicional oferecida pelo Persistence Builder e pelo Data Access beans, como relacionamentos, partes de paletas visuais e recurso avançado de transação e SmartGuide - Assistência ao SQL.
A lista de funções principais listadas abaixo representa uma visão geral das capacidades principais do Data Access Builder. Cada função principal foi implementada de maneiras diferentes por cada componente.
Parte 1: Recursos do Mapeamento de Objeto para o Relacional
Mapeamento do Esquema de Banco de Dados para o Objeto
Geração de Código
Parte 2: Recursos de runtime
Parte 3: Recursos do Data Access beans
As implementações das funções são explicadas nas páginas a seguir. As funções do Data Access Builder e do Persistence Builder são todas comparadas consecutivamente, enquanto as funções comparáveis do Data Access beans (para mapeamento) são listadas no final desta seção.
Mapeamento do Esquema de Banco de Dados para o Objeto
1.0 Esquema de Banco de Dados para Mapeamento de Objetos Utilizando Tabelas e Exibições
No Data Access Builder
Nota: Todas as etapas do Data Access Builder devem ser efetuadas em uma versão anterior (3.02 ou anterior) do VisualAge for Java que inclua o Data Access Builder.
No SmartGuide Mapear Esquema, selecione a conexão DB2 ou ODBC, depois selecione o botão de opção Selecionar tabelas ou exibições de bancos de dados. Clique em Próximo.A seguinte página é aberta, mostrando uma lista de tabelas:
Selecione as tabelas com que deseja trabalhar e clique em Finalizar. Faça mapeamentos 1 para 1 entre essas tabelas e os objetos resultantes serão criados. A janela do Data Access Builder mostra o mapeamento de coluna para atributo que ocorreu automaticamente.
No Persistence Builder
No Navegador de esquemas, selecione Esquemas > Importar esquema do banco de dados. Digite as informações sobre a conexão. O diálogo Selecionar Tabelas é aberto.
Selecione as tabelas ou exibições desejadas e clique em OK. O Navegador de Esquemas contém agora o novo esquema e lista suas tabelas, colunas e chaves.
Selecione Esquemas > Gerar Modelo a partir do Esquema. Isso gera um modelo de negócios um para um simples.
2.0 Esquema de Banco de Dados para Mapeamento de Objeto Utilizando Consultas Personalizadas
No Data Access Builder
No SmartGuide Mapear Esquema, selecione a conexão DB2 ou ODBC, depois selecione o botão de opção Digitar Instrução SQL. Clique em Próximo.Selecione as tabelas com que deseja trabalhar e clique em Próximo. A seguinte página é aberta:Digite sua consulta e clique em Finalizar. O exemplo acima mostra uma consulta de união de duas tabelas. Consultas com valores de parâmetros também são suportadas.
O objeto resultante contém os atributos de ambas as tabelas, conforme mostrado abaixo:
No Persistence Builder
Você pode utilizar o Persistence Builder para executar o mapeamento de união da consulta, mapeando o Esquema manualmente.3.0 Esquema de Banco de Dados para Mapeamento de Objeto Utilizando Procedimentos Armazenados
No Data Access Builder
No SmartGuide Mapear Esquema, selecione a conexão DB2 ou ODBC, depois selecione o botão de opção Conjunto de resultados do procedimento armazenado. A página Procedimento Armazenado é aberta, mostrando uma lista de procedimentos armazenados: Digite um nome para o mapeamento, selecione o procedimento armazenado e clique em Finalizar.
O objeto resultante contém atributos mapeados para as colunas de resultados do procedimento armazenado. As consultas ou procedimentos armazenados das operações CRUD não são predefinidas para este tipo de mapeamento.
No Persistence Builder
O Persistence Builder não tem nenhuma ferramenta que suporte mapeamento de procedimento armazenado. Você pode gerar um "Esquema de Stub" que crie classes de serviços estruturais, em que deve fornecer o código de suporte. O método all-instances pode parecer como o seguinte:
/**
* Return a query spec for the query called
allInstances
* @return java.util.Vector
*/
public java.util.Vector allInstancesQuery() {
Vector aSpecArray = new Vector();
DatabaseCompoundType aCompoundType;
DatabaseQuerySpec spec = new
DatabaseCallableQuerySpec("{call getAllEmp ()}");
aCompoundType = new DatabaseCompoundType();
aCompoundType.addField((DatabaseTypeField)(new
com.ibm.ivj.db.base.DatabaseDecimalField("COMM")).setAttributes(9,2,3,false));
aCompoundType.addField((DatabaseTypeField)(new com.ibm.ivj.db.base.DatabaseIntegerField("EMPNO")).setAttributes(4,0,4,false));
aCompoundType.addField((DatabaseTypeField)(new com.ibm.ivj.db.base.DatabaseDecimalField("SAL")).setAttributes(9,2,3,false));
aCompoundType.addField((DatabaseTypeField)(new com.ibm.ivj.db.base.DatabaseIntegerField("DEPTNO")).setAttributes(2,0,4,false));
aCompoundType.addField((DatabaseTypeField)(new com.ibm.ivj.db.base.DatabaseStringField("ENAME")).setAttributes(10,0,12,false));
((DatabaseSelectQuerySpec)spec).setOutputShape(aCompoundType);
aSpecArray.addElement(spec);
return aSpecArray;
}
Geração de Código
4.0 Operações CRUD em Objetos
Data Access Builder
As operações CRUD básicas (Criar, Recuperar, Atualizar e Excluir) são geradas automaticamente com mapeamentos de uma tabela para um objeto. Se você utilizar consultas personalizadas ou procedimentos armazenados, essas consultas ficarão faltando, e você deverá definir as consultas manualmente utilizando a Ferramenta Data Access Builder. Um exemplo disso seria uma consulta de união que define um objeto Cliente.
Digite a seguinte instrução SQL:
INSERT
INTO TPF.CUSTOMER (
CUSNO,
FIRSTNAME,
MIDINIT,
LASTNAME,
HOMEPHONE,
HOMEADDR,
WORKPHONE,
BILLADDR,
BRANCHNO,
OPEN DATE)
VALUES (?, ?, ?, ?, ?, ?, ?,?, ? ,?)
Depois do Data Access Builder validar a consulta, você deve mapear os parâmetros individualmente utilizando a página Parâmetro.
Também será necessário definir a consulta addCustomer2 para a inserção da segunda tabela de união CUSTDATA. A sincronização das duas consultas desta função atômica é manipulada pelo usuário.
Persistence Builder
O Persistence Builder irá gerar todas as operações CRUD depois de um mapa ter sido criado entre o esquema e o modelo definidos. No caso da união de várias tabelas, cada consulta de tabela será gerada e o mecanismo de serviço gerenciará essas operações como uma unidade atômica.
Os procedimentos armazenados ainda não são suportados nas ferramentas, mas "Esquemas de Stub" podem ser gerados e estendidos. Segue o exemplo de uma consulta de procedimento armazenado insert.
/**
*Return a query spec for the query called insert
* @return java.util.Vector
* @param args java.util.Vector
* @param anInjector com.ibm.vap.Persistence.BOInjector
public java.util.Vector insertQuery(java.util.Vector args,com.ibm.vap.Persistence.BOInjector anInjector) {
Vector aSpecArray = new Vector();
DatabaseCompoundType aCompoundType;
DatabaseQuerySpec spec = new DatabaseCallableQuerySpec("{call
insertEmp (?,?,?,?)}");
Vector stringArgs;
a CompoundType = new DatabaseCompoundType();
aCompoundType.addField((DatabaseTypeField)(new com.ibm.ivj.db.base.DatabaseIntegerField("EMPNO")).setAttributes(4,0,4,false));
aCompoundType.addField((DatabaseTypeField)(new com.ibm.ivj.db.base.DatabaseDecimalField("SAL")).setAttributes(9,2,3,false));
aCompoundType.addField((DatabaseTypeField)(new com.ibm.ivj.db.base.DatabaseIntegerField("DEPTNO")).setAttributes(2,0,4,false));
aCompoundType.addField((DatabaseTypeField)(new com.ibm.ivj.db.base.DatabaseStringField("ENAME")).setAttributes(10,0,12,false));
StringArgs = new Vector();
stringArgs.addElement("EMPNO");
stringArgs.addElement("SAL");
stringArgs.addElement("DEPTNO");
stringArgs.addElement("ENAME");
spec.setInputShape(aCompoundType);
spec.setInputValues(args);
spec.setInputNamesWithDuplicates(stringArgs);
aSpecArray.addElement(spec);
return aSpecArray;
5.0 Suporte a Consulta Personalizada
No Data Access Builder
As consultas personalizadas no Data Access Builder são definidas da mesma maneira que as consultas CRUD. O usuário inclui a consulta nomeada, e utiliza a página de parâmetros, se necessário. A consulta resultante aparecerá como um método na classe BusinessObjectMgr.
O Data Access Builder também fornece outros métodos de definição de consultas personalizadas, como a substituição de Predicado SQL.
TheEmpMgr.select('WHERE WORKDEPT = 'E11');
No Persistence Builder
Há duas opções para a inclusão de consultas personalizadas no Persistence Builder. As Lite Collections podem ser definidas no nível da classe utilizando o editor de classes. A página a seguir é utilizada para pesquisar e filtrar na classe especificada.
As consultas Lite collection são, geralmente, utilizadas em listas de pesquisa ou diálogos para "serem colocadas" no Objeto de Negócios apropriado. Os métodos resultantes retornam vetores de "Objetos de Dados" que podem ser utilizados para recuperar o objeto de negócios persistente correspondente.
A seguir, um exemplo de código que utiliza a consulta lite collection gerada mostrada acima:
VapCourseHomeImpl aHome = VapCourseHomeImpl.singleton();
VapDepartmentKey aKey = new VapDepartmentKey("Sales");
VapLiteCollection liteCollection = aHome.getByDepartmentLiteCollection(aKey);
Enumeration enum = liteCollection.elements();
VapCourseDataObject aDO;
VapCourse aCourse;
while (enum.hasMoreElements()) {
aDO =
(VapCourseDataObject)enum.nextElement();
aCourse =
aHome.find(aDO.getNumber());
//Fetching fully
hydrated EJBObject
}
O Persistence Builder também fornece uma estrutura de consulta personalizada que pode ser utilizada para definir várias operações em uma classe de negócios. Essas consultas retornarão Objetos de Negócios totalmente funcionais.
A seguir, o exemplo de um estudante de classe com uma consulta personalizada "retrieveStudentsOver21". A classe Original para estudantes possui o seguinte método:
public Vector retrieveStudentsOver21() throws
java.rmi.RemoteException,
com.ibm.vap.common.VapReadFailureException {
return customQuery("studentsOver21Query");
}
O QueryPool para estudantes contém os métodos correspondentes para o serviço personalizado:
/* Return a query spec for the query called studentsOver21
@return
java.util.Vector */
public java.util.Vector studentsOver21Query() {
Vector aSpecArray = new Vector();
aSpecArray.addElement(new DatabaseSelectQuerySpec(studentsOver21SqlString()));
return aSpecArray;
}
/* Return the SQL string for the query called studentsOver21Query
@return
java.lang.String */
public java.lang.String studentsOver21SqlString() {
return "SELECT T1.SNAME, T1.SNO, T1.SADVFNO, T1.SBDATE, T1.SADDR, T1.SPHNO,
T1.SMAJ, T1.SIQ FROM SPARKY.STUDENT T1 WHERE
T1.SBDATE <= (CURRENT DATE - 00210000.)";
}
Este método é executado do início, e tem comportamento de armazenamento em cache de objeto semelhante ao do método All-instances. Para obter mais informações sobre esse método, consulte a ajuda online do Persistence Builder.
1.0 Capacidade de Memória de dados/Transacional
No Data Access Builder
Os datastores do Data Access Builder podem ser configurados em vários níveis de aplicativos:
Os Datastores do Data Access Builder possuem um modelo transacional plano, em outras palavras, se forem necessárias várias transações para aplicar uma função de negócios, um datastore representando cada transação precisará ser ativado.
A seguir, um cenário simples com um modelo de Funcionário e Departamento:
EmployeeDatastore anEmpDS = new EmployeeDatastore().connect();
DepartmentDatastore aDeptDS = new DepartmentDatastore().connect();
Employee anEmp = new Employee();
Department aDept = new Department();
// Executar ações em anEmp e aDept
if (User Applied Employee Changes)
anEmpDS.commit()
else
anEmpDS.rollback();
aDeptDS.commit();
Persistence Builder
No VisualAge for Java, Versão 4.0, o Persistence Builder tem a opção de utilizar o WebSphere Connection Pool utilizando o nome do JNDI para procurar o Datasource. Essa opção está disponível ao gerar as classes de serviços.
Vários datastores no Persistence Builder serão requeridos apenas se bancos de dados diferentes forem utilizados para acessar dados modelo. São suportadas várias transações aninhadas por datastore. As transações não são inferidas como são no Data Access Builder. As transações do usuário são controladas por objetos de transação que possuem exibições nos objetos de negócios do aplicativo.
Aqui está um código snippet mostrando a mesma capacidade transacional no exemplo do Data Access Builder.
DB2Datastore aDS = DB2Datastore.singleton().activate();
Transaction empTransaction = Transaction.begin();
Employee anEmp = EmployeeHomeImpl.create("EmpNum1");
Transaction deptTransaction = Transaction.begin();
Department aDept = DepartmentHomeImpl.create("DeptNum1");// Executar algumas ações no anEmp e aDept, sempre retomando a transação apropriada antes de fazer alterações no BO correspondente.
if (User Applied Employee Changes)
empTransaction.commit();
else
empTransaction.rollback();
deptTransaction.commit();
É importante observar que, no Persistence Builder, nenhum SQL é executado até que uma transação seja consolidada. O estado transacional dos objetos é mantido internamente até que uma reversão ou consolidação explícita ocorra.
2.0 Suporte a API
Os métodos gerados nos objetos de negócios resultantes e seus objetos de gerenciamento de co-requisito são um pouco diferentes entre as três estruturas. A tabela a seguir mostra as classes e métodos utilizados para cada função.
|
Data Access Builder |
Persistence Builder |
Data Access beans |
Criar |
aBusinessObject.add(); |
aBusinessObjectHome.create(); |
aSelectBean.newRow(); |
Recuperar |
aBusinessObject.retrieve(); |
aBusinessObjectHome.find (aKey); |
aSelectBean.setParameter ("ColumnName", value); aSelectBean.execute(); |
Recuperar todas | aBusinessObjectMgr.select(); | aBusinessObjectHome.allInstances(); | aSelectBean.execute(); |
Atualizar | aBusinessObject.update(); | (*) | Não suportado |
Delete | aBusinessObject.delete(); | aBusinessObject.remove(); | Não suportado |
Excluir atual | aBusinessObject.deleteCurrent(); | Não suportado (**) | aSelectBean.deleteRow(); |
Atualizar atual | aBusinessObject.updateCurrent(); | Não suportado (**) | aSelectBean.updateRow(); |
Consolidar | aBusinessObjectDS.commit(); | currentTransaction.commit(); | aSelectBean.commit(); |
Reverter | aBusinessObjectDS.rollback(); | currentTransaction.rollback(); | aSelectBean.rollback(); |
Ativar | aBusinessObjectDS.connect(); | aDataStore.activate(); | aSelectBean.connect(); |
Redefinir | ABusinessObjectDS.disconnect(); | aDataStore.reset(); | aSelectBean.disconnect(); |
Exemplo de Código: Localize um empregado e altere o número de telefone |
|||
Employee anEmp = |
EmployeeHome aHome = EmployeeHome.singleton(); Employee anEmp = anEmp.setPhoneno("555-9988"); |
Recuperar todos os funcionários: aSelectBean.execute();
positionToEmployee
aSelectBean. aSelectBean.updateRow();
aSelectBean.commit();
Recuperar conjunto de resultados com
aSelectBean.setParameter
aSelectBean.commit(); |
(*)Operações de atualização são inferidas alterando os valores em um objeto de negócios; se a transação ativa for consolidada, as alterações serão sincronizadas com o datastore, emitindo as instruções de atualização apropriadas.
(**)A seção Suporte ao cursor mostra soluções alternativas.
Suporte a LOB
Data Access Builder |
Persistence Builder |
Data Access beans |
O Data Access Builder inclui uma classe denominada DAIOStream, que pode ser utilizada para recuperar LOBs do banco de dados, sem causar falha ao objeto completo na memória. |
Atualmente, o Persistence Builder não suporta LOBs streaming. Os objetos LOB falham na memória. |
O DAB suporta tipos de dados LOB do JDBC 2.0. Se estiver utilizando um driver JDBC 2.0 para recuperar um LOB, você terá a opção de recuperar o LOB inteiro na memória, ou apenas sua localização. |
3.0 Quickforms (Recursos RAD)
Data Access Builder |
Persistence Builder |
Data Access beans |
O recurso Quickform do Data Access Builder fornece exibições rápidas de exemplo, utilizando partes populares do AWT para representar o modelo fornecido. |
A intenção de se utilizar uma coleção de partes visuais no VCE é ajudar com as complexidades da programação visual. Essas partes representam classes transacionais que ajudam o usuário a separar visualmente as unidades de trabalho. |
A Versão 4.0 contém um Assistente de Aplicativo de Banco de Dados que gerará um aplicativo que utiliza componentes Swing para representar as colunas de uma tabela obtida por um bean Select. Também é possível utilizar as capacidades do QuickForm padrão do VCE para criar rapidamente um UI personalizado com base nas propriedades de um bean Select. |
4.0 Suporte a Data/Hora/Marca de Hora atuais
As ferramentas do Data Access Builder permitem que o usuário especifique "atual" nos tipos de dados de data/hora, que gera o SQL apropriado. O Persistence Builder e o Data Access beans não suportam isto em suas ferramentas, mas o SQL pode ser incluído manualmente.
5.0 Suporte ao Cursor
O Data Access Builder suporta as funções do cursor nos conjuntos de resultados, tais como updateCurrent() ou deleteCurrent().
Atualmente, o Persistence Builder não suporta essas operações. Neste caso, uma boa alternativa seria utilizar o recurso Data Access beans.
O Data Access beans suporta as funções de cursor com as partes visuais do DBNavigator que gerenciam a posição do cursor. A seguir, uma descrição de todos os recursos do cursor:
O JDBC v1.0 não suporta deslocamento para trás em um conjunto de resultados do JDBC. O bean Select mantém uma memória cache do conjunto de resultados que permite o deslocamento, assim como acesso direto a uma determinada linha. O bean Select possui propriedades que permitem controlar o tamanho da memória cache. Você pode buscar o conjunto de resultados completo na memória cache (o padrão), ou buscar um pacote de cada vez. O tamanho e número de pacotes é controlado pelo usuário.
Depois de se obter um conjunto de resultados, o bean Select fornece métodos de atualização, exclusão ou inserção de linhas no conjunto. O usuário não tem necessidade de gerar um novo SQL para executar essas funções.
6.0 Execução Assíncrona
O Data Access Builder suporta operação assíncrona através do fornecimento de interfaces executáveis em suas classes geradas.
O Persistence Builder também fornece interfaces executáveis para cada operação CRUD e uma para consultas personalizadas. O objeto de serviço de cada classe de negócios possui o método runAsynch(), que determina o tipo de execução para essa classe.
O Data Access beans suporta a execução através da ferramenta DBNavigator que gera instâncias executáveis do "DBAction".
Problemas de Concorrência (bloqueio/níveis de isolamento)
O Data Access Builder tem a API para definir o nível de isolamento do banco de dados na classe datastore gerada setTransactionIsolation(int).
O Persistence Builder mantém suas próprias transações e suporta os seguintes níveis de isolamento internamente.
A Transação especifica o nível de isolamento Leitura Repetível ou Leitura Não-repetível. A implementação de serviço da classe Business especifica implementação sem bloqueio ou com bloqueio. Consulte a ajuda online do Persistence Builder para saber mais detalhes sobre as diferenças entre os níveis.
O Data Access beans possui uma API para a definição do nível de isolamento do banco de dados. Isso pode ser feito especificando o nível de isolamento desejado ao fornecer as informações de conexão através do editor de propriedade personalizada ou através do método DatabaseConnection.setTransactionIsolation().
O mapeamento para DAB ocorre entre tabelas e beans Select. Este mapeamento entre uma tabela e um bean Select não é 1:1 e, assim, o bean Select não representa a tabela. No entanto, os Beans Select podem ser muito úteis para trabalhar com a linha atual e com um conjunto de resultados. É possível criar um ou dois Beans Select que podem ser utilizados para executar operações básicas de programação do banco de dados em uma tabela. Portanto, se estiver utilizando o DAX para operações do banco de dados como consultas, leitura, gravação, atualização e exclusão de uma forma simples e objetiva, o DAB pode ser um bom substituto para o DAX.
Você pode interagir com bancos de dados definindo a propriedade query (que é composta de informações de conexão e informações de Consulta SQL) de um bean Select. As informações de conexão contidas na propriedade query podem ser utilizadas por mais de um bean select.Você pode incorporar beans select em seu código visualmente, utilizando o Editor de Composição Visual ou manualmente.
A seguir, há uma descrição geral de como criar um Bean Select para trabalhar com a linha atual de uma tabela de cliente. Consulte a ajuda online para obter mais detalhes sobre como executar estas etapas:
Com este bean Select você pode executar operações básicas (ler, gravar, atualizar e excluir), em uma linha na tabela do cliente (quando o número do cliente for especificado).
Criação de um segundo bean select
Outro bean Select pode ser criado para trabalhar com um conjunto de resultados (isto é, uma consulta no banco de dados) passando pelo mesmo procedimento, sem especificar condições. Este segundo bean Select permitiria aproveitar a funcionalidade do conjunto de resultados do DAB. A classe do Database Access para este bean Select seria semelhante à seguinte:
Beans Select e consultas personalizadas
O DAB oferece um sólido suporte para a criação de beans Select que utilizam consultas personalizadas. Conforme mostrado abaixo, o SmartGuide - Assistência ao SQL pode ajudá-lo na criação de uma consulta de junção, na especificação de condições para uma consulta, na seleção de colunas, na ordenação de colunas e no mapeamento de campos.
Data Access beans e Procedimentos Armazenados
O bean Procedure Call permite trabalhar com procedimentos armazenados. A criação de um bean Procedure Call é muito semelhante à criação de um bean select. O SmartGuide para procedimentos armazenados lista os procedimentos armazenados disponíveis, conforme mostrados abaixo.
Para obter mais informações sobre como utilizar o bean Procedure Call, consulte a ajuda online do Data Access beans.
Copyright e Avisos
© Copyright IBM Corp.1997, 2001. Todos os Direitos Reservados.
Nota sobre Direitos Restritos dos Usuários do Governo Norte-Americano -- A utilização, duplicação ou divulgação são restringidos pelo GSA ADP Schedule Contract com a IBM Corp.
Referências nesta publicação a produtos, programas ou serviços IBM não significam que a IBM pretenda disponibilizá-los em todos os países onde opera. Consulte o seu representante IBM local para obter informações sobre produtos e serviços disponíveis em sua área. Referências a produtos, programas ou serviços IBM não significam que apenas produtos, programas ou serviços IBM possam ser ser utilizados. Qualquer produto, programa ou serviço funcionalmente equivalente, que não infrinja quaisquer direitos de propriedade intelectual da IBM, poderá ser utilizado em substituição a este produto, programa ou serviço. A avaliação e verificação da operação em conjunto com outros produtos, exceto aqueles expressamente designados pela IBM, são de inteira responsabilidade do usuário.
O parágrafo a seguir não se aplica a nenhum país em que tais disposições não estejam de acordo com a legislação local:
A INTERNATIONAL BUSINESS MACHINES CORPORATION FORNECE ESTA PUBLICAÇÃO "NO ESTADO" SEM GARANTIA DE ESPÉCIE ALGUMA, EXPLÍCITA OU IMPLÍCITA, INCLUINDO, MAS NÃO SE LIMITANDO ÀS GARANTIAS IMPLÍCITAS DE COMERCIALIZAÇÃO OU ADEQUAÇÃO A UM FIM ESPECÍFICO. Alguns países não permitem a exclusão de garantias explícitas ou implícitas em certas transações; portanto, esta disposição pode não se aplicar a você. Nestas informações pode haver imprecisões técnicas e erros tipográficos. São feitas alterações periódicas nas informações aqui contidas; tais alterações serão serão incorporadas em futuras edições desta publicação. A IBM pode fazer melhorias e/ou alterações no(s) produto(s) e/ou programa(s) descritos nesta publicação a qualquer momento, sem aviso prévio.
Referências nesta publicação a sites não-IBM são fornecidas apenas para conveniência e não representam de forma alguma um endosso a esses sites.
Os materiais contidos nesses sites da Web não são parte dos materiais deste produto IBM e a utilização destes sites é de inteira responsabilidade do usuário. A IBM usa e distribui as informações da forma como ela achar adequado sem que incorra em qualquer obrigação para com você.O programa licenciado aqui descrito e todo o material licenciado disponível para ele são fornecidos pela IBM em conformidade com os termos do Contrato de Cliente da IBM, Acordo para Licenças de Programas da IBM International ou com qualquer contrato equivalente celebrado entre nós.
IBM, AIX, AS/400, DB2, OS/390, OS/400, RS/6000, S/390, VisualAge e WebSphere são marcas da IBM Corporation nos Estados Unidos e/ou em outros países.
Lotus, Lotus Notes e Domino são marcas da Lotus Development Corporation nos Estados Unidos e/ou em outros países. Java e todas as marcas e logotipos baseados em Java são marcas da Sun Microsystems, Inc. nos Estados Unidos e/ou em outros países. Microsoft, Windows, e Windows NT são marcas da Microsoft Corporation nos Estados Unidos e/ou em outros países. Intel e Pentium são marcas da Intel Corporation nos Estados Unidos e/ou em outros países. Outras empresas, produtos e nomes de serviço podem ser marcas ou marcas de serviço de terceiros.