1.0 Introdução
2.0 Software Suportado e Especificações
3.0 Problemas Conhecidos
3.1 Problemas de Atualização
3.2 Dicas e Restrições de Mapeamento Alterar-no-meio
3.3 Suporte a Arrastar e Soltar no Mapping Editor
3.4 Excluindo Tabelas e Esquemas da Exibição Navigator da Perspectiva J2EE
3.5 Predicados Otimistas para Beans de Entidade CMP 1.1
3.6 Dicas e Restrições de Herança
3.7 Fazendo Referência aos Arquivos JAR de Tempo de Execução na Hora do Desenvolvimento
3.8 Não Mapear Tipos Compostos em Várias Tabelas
3.9 Excluir uma Entidade CMP Não Remove a Entrada de Mapeamento
3.10 Limitações de EJB QL
3.11 A Validação das Referências a EJB Não É Automática
3.12 Nomes em Árabe Não-suportados para Beans e Arquivos Java
3.13 Limitações da Geração de Consulta
3.14 Problema ao Editar o Link local-ejb-ref
3.15 Erros na Lista de Tarefas Depois da Implementação de Relacionamentos do EJB 2.0
3.16 ejbCreate Especializado Faltando para as Colunas de Chave Externa Não-nulas
3.17 Limitação de Alterações dos Campos CMP da Página Source Utilizando Herança
3.18 Código de Implementação do EJB Não-excluído ao Alterar uma Classe de Bean
3.19 Chave Primária Unkown Não-suportada
3.20 Alterando a Classe da Chave Primária para um CMP 1.1 com Relacionamentos Causa Erros de Compilação
3.21
Erros de Reflexão ao Atualizar a partir do CVS Repository
3.22
Excluindo uma Consulta FIND da Exibição Outline
3.23
Página Source e Herança de EJB
3.24
Consultas EJB QL Não São Geradas Corretamente para Relacionamentos
Many to Many em uma Estrutura de Herança
3.25
Problema de Mapeamento do Servidor SQL com Tipo de Dados FLOAT
3.26
Linux: Problemas de Conexão ao Executar um Bean CMP 1.1 no DB2 em um
WebSphere Application Server V4 (Unit Test Environment)
3.27
Pode Ser Necessário Gerar Código Implementado Quando Beans
Corporativos de Outro Projeto Forem Utilizados
3.28
Suporte para Mapear Beans Corporativos para Chaves Externas e Chaves
Primárias
3.29
Restrição para Mapeamento de Herança e de Tabela Secundária
3.30
Limpando Beans de Acesso ao Migrar do EJB 1.1 para o EJB 2.0
3.31
Implementando Aplicativos EJB com Conversores e Compositores no
WebSphere Application Server v4.0.6
3.32
Migrando Projetos EJB que Contêm Classes Binárias
3.33
Implementação de Mapeamento de Baixo para Cima para Exibições
As ferramentas EJB fornecem um ambiente especializado que pode ser usado para desenvolver beans corporativos. As ferramentas EJB consistem nas seguintes entidades:
- Uma perspectiva J2EE.
- Ferramentas e assistentes para criação, importação e exportação de beans corporativos.
- Assistente para criação de bean de acesso.
- Ferramentas para construir persistência de dados em beans corporativos.
- Ferramentas para gerar código de implementação.
Esse arquivo readme descreve os problemas e limitações conhecidos e as alternativas associadas às ferramentas EJB.
A opção -dbvendor do comando ejbdeploy (ferramenta de implementação EJB) agora suporta os seguintes valores (correspondentes aos bancos de dados suportados):
mas não suporta mais estes valores:
- DB2UDB_V72 (DB2 para Windows, V7.2) -- Ele sobrepõe o DB2UDBWIN_V72 anteriormente suportado.
- DB2UDB_V81 (DB2 para Windows, V8.1) -- Ele sobrepõe o DB2UDBWIN_V81 anteriormente suportado.
- SQL92(Generic SQL 92)
- SQL99(Generic SQL 99)
- MYSQL_V323 (MySQL, V3.23)
- DB2UDBAS400_V4 (DB2 para AS/400, V4) -- Ele foi sobreposto pelo DB2UDBISERIES (DB2 para ISeries).
- DB2UDBAS400_V5 (DB2 para AS/400, V5) -- Ele foi sobreposto pelo DB2UDBISERIES (DB2 para ISeries).
- INFORMIX_V92 (Informix Dynamic Server.2000, V9.2)
- SYBASE_V1192 (Sybase Adaptive Server Enterprise, V11.9.2)
- DB2UDBWIN_V71 (DB2 para Windows, V7.1)
- DB2UDBWIN_V72 (DB2 para Windows, V7.2) -- Ele é sobreposto pelo DB2UDB_V72.
- DB2UDBWIN_V81 (DB2 para Windows, V8.1) -- Ele é sobreposto pelo DB2UDB_V81.
Se os arquivos ou recursos no workbench parecerem estar fora de sincronização ou ocorrer uma falha inesperada, por exemplo, editores e exibições não refletem as definições atuais do descritor de implementação, fechar e reabrir o projeto a partir do menu Project poderá corrigir o problema.
- Corresponder por nome - tratará somente de correspondências exatas. Se você gerou seu esquema utilizando a chave compatível com o WebSphere Application Server Versão 3.5 ou importou um JAR do WebSphere Application Server Versão 3.5, seus nomes de tabelas serão anexados com 'tbl' e não serão reconhecidos.
- Herança - os beans filho não serão mapeados se não tiverem seus próprios campos. É necessário mapear esses beans para a tabela pai manualmente.
- O java.util.Date não é suportado no mapeamento de campo CMP 1.1
- Se você estiver utilizando um compositor em um mapeamento, gere o mapa, salve-o, feche e reabra o projeto, em seguida, implemente.
Existe suporte para arrastar e soltar somente na "direção" do mapa. Por exemplo, se o mapa foi criado a partir de uma operação "De cima para baixo", então é permitido arrastar um bean corporativo para um banco de dados. As operações arrastar e soltar a seguir são permitidas:
- Arrastar um bean corporativo para uma tabela criará um mapa entre os dois.
- Arrastar um bean para um BD criará uma tabela e colunas correspondentes e o mapeará para o bean e atributos.
Se for necessário excluir uma tabela, utilize a perspectiva Dados ou a exibição Hierarquia do J2EE da perspectiva J2EE, todos os links dependentes também serão removidos. Normalmente, você não deve utilizar o Navegador ou o Navegador do J2EE para excluir recursos do J2EE porque as dependências não serão atualizadas.
No WSAD 5.0, foi adicionada a capacidade de identificação de atributos para ser utilizada para a atualização superqualificada. Os arquivos jar EJB criados utilizando releases anteriores do WSAD não contêm essa especificação para beans de entidade CMP 1.1 No entanto, quando implementados utilizando o WSAD 5,1, a semântica anterior é suportada. Especificamente, na falta de uma lista de atributos, todos os predicados disponíveis são utilizados. Observe que os beans de entidade CMP 2.0 são tratados de forma diferente. Se nenhum atributo for selecionado como predicado, então nenhum será adicionado à atualização superqualificada.
- Não utilize tipos BLOB em uma estrutura de herança de raiz-folha, se estiver utilizando o Oracle como seu banco de dados.
- O mapeamento de herança de raiz-folha pode ser suportado para os bancos de dados MySQL, InstantDB, SQL92 e SQL99. Eles não suportam os operadores de definição de SQL requeridos para as consultas complexas utilizadas para um mapeamento de raiz-folha. Para testar nestes bancos de dados, será necessário utilizar o mapeamento de tabela única.
- O mapeamento de campos CMP para colunas Não-nulas não é suportado em beans herdados. Predicados otimistas só podem ser definidos em campos CMP a partir do bean raiz.
Se for necessário compilar em arquivos JAR visíveis para o tempo de execução do Websphere Application Server (por exemplo, rt.jar, xerces.jar e assim por diante), então, como regra geral, adicione os arquivos JAR para a instalação de tempo de execução respectiva utilizando as variáveis de classpath predefinidas. Por exemplo, utilize a variável de classpath WAS_PLUGINDIR para os arquivos JAR do servidor WebSphere Application Server v4.0 e a variável de classpath WAS_50_PLUGINDIR para os arquivos JAR do servidor WebSphere Application Server v5.0.
O Editor de mapeamento permite mapear um tipo criado para várias colunas em tabelas diferentes. Isso causará erros na geração do código de implementação. Assegure-se de que todas as colunas no mapeamento de tipos criados pertençam à mesma tabela.
Quando uma entidade CMP é excluída, os mapas correspondentes aos quais esse bean faz referência não terão seus mapeamentos removidos. Quando o Mapping editor é aberto nesses arquivos após uma entidade ser excluída, os mapeamentos são removidos. Esse é o comportamento esperado. Você precisará abrir o Mapping Editor antes de gerar o código de implementação.
- As consultas EJB QL que envolvem beans corporativos com chaves formadas por relacionamentos com outros beans corporativos aparecerão como inválidas e causarão erros na hora da implementação. Este é um defeito conhecido.
- O suporte IBM a EJB QL estende a especificação EJB 2.0 de várias maneiras, incluindo o relaxamento de algumas restrições, o adicionamento de suporte para mais funções do DB2 e assim por diante. Se portabilidade em bancos de dados ou ferramentas de implementação EJB de várias marcas for uma preocupação, então deve-se tomar o cuidado de gravar todas as consultas EJB QL estritamente de acordo com o Capítulo 11 da especificação EJB 2.0.
A validação para referências locais a EJB, referências a EJB e referências a recursos não ocorre automaticamente quando são feitas alterações nessas referências. O validador de EAR precisa ser disparado explicitamente para que a validação seja concluída nessas referências.
Não utilize nomes em árabe para arquivos Java, beans Java ou beans de acesso. Não utilize nomes em árabe quando estiver trabalhando no exemplo MiniBank.
- O pré-carregamento através de relações m:n resultará na geração de SQL inválido. Essa é uma limitação conhecida que pode ser abordada no futuro.
- O pré-carregamento através de relações de auto-referenciação causará a geração de SQL inválido.
- Os relacionamentos entre os beans corporativos pai e filho na mesma hierarquia de herança que não estejam bem definidos devem ser evitados.
A tentativa de editar o link de um local-ejb-ref na página "References" do EJB Deployment Descriptor Editor com o botão "Browse" não permitirá a seleção de um bean de destino que não possua uma interface remota. A solução alternativa é excluir a referência e recriá-la.
Se você remover um relacionamento do EJB 2.0 e gerar o código de implementação novamente, você poderá ver erros inválidos na lista de tarefas. A solução alternativa é primeiro remover o código de implementação para os beans antes de gerá-lo novamente.
Ocasionalmente, os erros inválidos da lista de tarefas também são vistos depois de adicionar um relacionamento do EJB 2.0 e gerar o código de implementação novamente. Nesse caso, simplesmente gere o código novamente para remover os erros.
Se você executar um mapeamento de baixo para cima em um esquema com uma chave externa cujas colunas não sejam nulas, então um método ejbCreate() especializado precisará ser criado com o tipo de interface do cliente de uma função adicionada à assinatura. Isso não é feito automaticamente pelo mapeamento de baixo para cima.
Para suportar as especificações EJB 1.1 e 2.0, precisamos criar um cmp-field correspondente para cada bean de subtipo dentro de uma estrutura de herança do EJB. Se você abrir o editor EJB Deployment Descriptor e modificar o nome de um desses campos na página Source, a alteração do nome correspondente não será feita nos cmp-fields que foram criados nos beans de subtipo para atender às especificações de EJB. A solução alternativa é utilizar a ação Edit na página Beans para alterar o nome.
Para suportar vários beans corporativos utilizando as mesmas classes Java, o código de implementação gerado precisa utilizar uma técnica de nomenclatura para tornar os nomes das classes de implementação geradas exclusivos. Os nomes são derivados da classe de beans, interfaces e classes de chaves existentes.
Se o código de implementação tiver sido gerado para um bean e você quiser alterar uma dessas classes, será necessário excluir o código de implementação primeiro. Se o código de implementação for excluído primeiro, as classes antigas geradas não serão removidas e poderão conter erros de compilação. Isso também poderá ocorrer se você alterar o tipo de seu primkey-field utilizando a ação Edit na página Beans. Isso alterará automaticamente a classe de chave para o tipo especificado ou uma nova chave composta será criada se um primkey-field não for mais válido.
A ferramenta EJB atualmente não suporta a definição da chave primária Unknown descrita pela especificação EJB 2.0. A solução alternativa é definir uma classe de chave principal específica.
Para suportar as relações do CMP 1.1, são criadas classes Link. Essas classes Link requerem o conhecimento das classes de chave principal do bean. Se você alterar a classe de chave principal para um CMP 1.1 que esteja envolvido em relações, as classes Link geradas ainda conterão referências à classe de chave principal antiga. A solução alternativa é atualizar manualmente as classes Link. Deveria haver somente duas ocorrências nas quais a alteração seria necessária.
Se, depois de atualizar um projeto EJB a partir de um CVS Repository, Tasks exibe erros mencionando classes ou interfaces que não estão sendo refletidas, tente reconstruir o projeto EJB para fazer com que os erros desapareçam.
Os erros podem ter a seguinte aparência: "CHKJ2802E: ejb-class class test.SessionBean, or one of its supertypes, cannot be reflected. Check the classpath."
Excluir uma consulta FIND de um bean CMP 2.0 contendo uma interface da exibição Outline não remove a declaração do método da interface local. A solução alternativa é utilizar o botão Remove na seção Queries do EJB Deployment Descriptor Editor.
Se você estiver modificando a forma dos beans CMP em uma hierarquia de herança, deverá utilizar as páginas Design do EJB Deployment Descriptor Editor e não a página Source. Por exemplo, se deseja adicionar ou remover campos CMP ou alterar o campo prim-key de um bean CMP, esses campos serão sincronizados pelas ferramentas para todos os beans herdados, para manter os beans em conformidade com a especificação EJB. Essa sincronização pode não ocorrer se você alterar a origem na página Source.
Neste cenário, há uma estrutura de herança EJB definida (herança raiz/folha ou de tabela única) e existe um relacionamento Many to Many com um bean EJB dentro desta estrutura. Nesse caso, qualquer consulta EJB QL definida para esses beans terão instruções JOIN incorretas.
A seguir temos um exemplo da estrutura.
Customer <---- m:m ----> Account
|
|
------inherit------
nbsp; | |
Checking Savings
Se o seu bean CMP foi mapeado para um banco de dados de Servidor SQL, um campo de tipo float precisa ser mapeado para uma coluna de tipo FLOAT e não REAL.
Você poderá encontrar problemas de conexão ao executar um bean CMP 1.1 no DB2 no Unit Test Environment do WebSphere Application Server V4.
Solução Alternativa: Definir loopback para seu banco de dados.
Por exemplo, se o banco de dados for denominado MyDB, o nome do host for LHOST e o número da porta de serviço do banco de dados for 50000, emita os seguintes comandos:
db2 catalog TCPIP node RHOST remote LHOST server 50000
db2 catalog database MyDB as MyDBAlias
db2 uncatalog db MyDB
db2 catalog database MyDBAlias as MyDB at node RHOSTPara verificar se funcionou, emita o comando: db2 connect to MyDB user xxx
em que xxx é sua senha.
Se um bean corporativo de um projeto EJB utilizar a interface local ou remota de um segundo bean corporativo em outro projeto (por exemplo, se tiver um método que utiliza a interface remota do segundo bean corporativo como um parâmetro), será necessário gerar código implementado para os dois projetos se você alterar a interface local ou remota do segundo bean corporativo.
Isso é para assegurar que as classes geradas por RMIC para o segundo bean corporativo estejam atualizadas nos dois projetos.
Quando estiver mapeando um bean corporativo para uma tabela do banco de dados, há várias restrições que envolvem chaves externas e chaves primárias.
- Se a tabela tiver várias chaves externas que contenham várias colunas, as chaves externas não poderão se sobrepor se ambas as chaves externas forem utilizadas para dois relacionamentos EJB diferentes. Por exemplo, se a ForeignKey1 contiver ColumnA e ColumnB, a ForeignKey2 poderá conter ColumnC e ColumnD, mas não poderá conter ColumnB e ColumnC. Se a ForeignKey2 contiver ColumnB e ColumnC, as duas chaves externas se sobreporiam.
- Se a tabela tiver uma chave primária com várias colunas e uma ou mais chaves externas que compartilham essas colunas, as chaves externas devem conter exatamente as mesmas colunas que a chave primária ou devem conter colunas completamente fora da chave primária. Por exemplo, se a PrimaryKey1 contiver ColumnA e ColumnB, a ForeignKey1 poderá conter ColumnA e ColumnB ou ColumnC e ColumnD, mas não poderá conter ColumnB e ColumnC. Nesse caso de várias chaves externas, cada chave externa deve atender a esses requisitos.
Se você estiver utilizando a abordagem root-leaf para mapear a herança ou estiver utilizando mapas secundários com várias tabelas, você deve remover as limitações da chave externa do banco de dados para evitar questões de ordenação da integridade referencial (instruções SQL executadas fora de ordem).
Como os beans de acesso não são suportados para beans corporativos que possuem somente exibições de clientes, pode ser necessário fazer alguma limpeza manual se você migrar do EJB 1.1 para o EJB 2.0 e adicionar uma exibição de cliente local e remover a exibição do cliente remoto. Se você tiver um bean de acesso da classe de dados, você deve excluir a classe de fábrica associada ao bean. Se você tiver um bean de acesso auxiliar de cópia, será necessário excluir o bean de acesso em si, excluir a fábrica e limpar todos os métodos da classe do bean que possam ser inválidos.
Se você estiver utilizando conversores e compositores em seu mapeamento EJB para RDB e estiver implementando no WebSphere Application Server v4.0.6, será necessário aplicar um eFix no WebSphere Application Server. O eFix do WAS atualiza o arquivo vaprt.jar.
O eFix do WAS é o PQ76109.
No WebSphere Studio Application Developer v5.1, o arquivo vaprt.jar, que contém conversores e compositores padrão, foi alterado. Devido a essas alterações, o arquivo vaprt.jar no WebSphere Application Server v4.0.6 precisa ser atualizado. O eFix do WAS sincroniza esse arquivo vaprt.jar.
Uma solução alternativa ao eFix é copiar o vaprt.jar do diretório de tempo de execução do plug-in j2ee.core para o diretório lib de tempo de execução do WAS. Os conversores ou compositores a seguir estão desatualizados no WAS v4.0.6 sem o eFix:
VapBigDecimalToBooleanConverter VapBigDecimalToDoubleConverter VapBigDecimalToFloatConverter VapBigDecimalToIntegerConverter VapBigDecimalToLongConverter VapBigDecimalToShortConverter VapTimestampToUtilDateConverter NameComposer VapUSPhoneNumberComposer
Ao utilizar o assistente Migration para migrar um projeto EJB que contém uma ou mais classes Java binárias (arquivos .class), a migração migrará com êxito os componentes do projeto que contêm arquivos Java de origem (arquivo .java), mas não migrará as classes binárias. Será necessário corrigir os erros manualmente.
Quando você executa um mapeamento de baixo para cima (gera beans corporativos com base em tabelas existentes), por padrão o assistente não gera beans para tabelas adjacentes para exibições. No entanto, como os relacionamentos devem ser criados para chaves externas, o assistente automaticamente cria um bean para qualquer tabela que tenha quaisquer chaves externas ou cuja chave primária seja apontada por quaisquer chaves externas de outras tabelas. Se você limpar a caixa de opções Do not create beans for underlying tables for views, o assistente irá gerar beans para todas as tabelas e exibições no esquema do banco de dados.
Retornar para o arquivo Leia-me principal
(C) Copyright IBM Corporation 2000, 2003. Todos os Direitos Reservados.