9. Problemas solucionados nesta liberação

Os beans Microcontainer foram registrados como MBeans na implementação. Esses MBeans são opcionais e fornecem certas informações de depuração. Este comportamento foi desativado por padrão. Os beans Microcontainer não são mais registrados como MBeans na implementação por padrão.

A combinação específica do JBoss Native, 64-bit hardware e opção do Java -javaagent levou os sistemas a entrarem no estado de espera enquanto executando o script run.sh. O usuário passado do script forneceu parâmetros ao Java enquanto realizando uma chamada para checagem da arquitetura do sistema. A partir de agora, o script run.sh foi modificado para ignorar os parâmetros fornecidos pelo usuário quando realizando esta chamada, sendo que o script não permanece mais sob esta condição.

Quando uma ferramenta de gerenciamento usava a interface de gerenciamento do ProfileService (conforme o console encorporado faz) para atualizar o serviço ServiceBindingManager, o mapeamento da informação recebida era incorreto. O valor recebido para a propriedade "fixedHostName" de binding era aplicada como "fixedPort" e vice-versa. Na maioria dos casos, ambas propriedades são "falsas", portanto isto era inofensivo. No entanto, caso ambas as propriedades fossem verdadeiras, isto levaria a um binding incorreto na reinicialização do servidor, quando valores aplicados fossem aplicados. Isto foi corrigido e os mapeamentos são agora aplicados conforme o esperado.

Quando os tipos de mapeamento do tipo de usuário eram usados nas funções agregadas do ejbql como por exemplo MIN e MAX, uma exceção era lançada. Isto foi corrigido e os campos CMP dos tipos mapeados com o mapeamento do tipo do usuário podem aparecer em funções agregadas da cláusula SELECT da questão EJB-QL.

O script run.sh cria um arquivo para rastrear processos e facilitar a obtenção de IDs, jboss.pidfile. Consulte o JIRA para maiores informações.

Havia um status de erro do servlet para os apps da web <distributable>. O gerenciador de sessão do Cache possuía diferentes atributos do gerenciador da Web, mas era visto como o mesmo objeto JMX devido à falta de sensibilidade à caixa (sensibilidade às letras maiúsculas e minúsculas). O StandardManager usou o 'activeSessions' enquanto a versão com cluster estava 'ActiveSessions'. O código usado pelo servlet para processar a informação do status pode agora detectar e manusear letras maiúsculas e minúsculas nos nomes do atributo JMX para o gerenciamento de sessão.

O JBPAPP-544 ajustou o problema de segurança pela remoção do mapeamento do /status, deixando o /web-console/status disponível. No entanto, o /status não assegurado foi re-adicionado ao JBPAPP-1146. Isto foi solucionado pela configuração de segurança do ROOT.war webapp. Este procedimento resolve o problema original de segurança deixa o /status intacto.

A rodagem do servidor Microsoft SQL com o Microsoft JDBC drivers 2.0 causa construções instáveis no JBoss Messaging. Este problema é criado uma vez que o Adaptive Buffering é o comportamento padrão para o driver assim como ele apenas permite que valores grandes sejam lidos pelo uso do método get<Type>Stream. A solução atual para este problema é a troca de parâmetro responseBuffering do URL de conexão JDBC do adaptive para full (uma vez que esta era a versão 1.2 do JDBC driver).

<url>jdbc:sqlserver://[host];database=[database];responseBuffering=full;</url>

Os usuários do Red Hat Enterprise Linux 5 instalando a Plataforma do Aplicativo JBoss Enterprise rpm usando yum devem estar subscritos ao canal do Red Hat Enterprise Linux Extras, com o objetivo de satisfazer a solicitação do Java da Plataforma do Aplicativo JBoss Enterprise, tanto com o Sun ou o IBM Java Development Kit.

O uso do session.createSQLQuery causou o vazamento de memória uma vez que os métodos equals e hashCode no NativeSQLQuerySpecification foram implementados incorretamente e o uso atual do LRUMap levou o mapa a aumentar a um tamanho maior do que seu limite máximo. Estes problemas foram corrigidos e o vazamento de memória não está mais ocorrendo.

As alterações do JBPAPP-4471 causaram um problema quando os usuários mapearam classes diferentes do JDK Serializable com SerializableType e tentaram realizar o cache naqueles valores num cache de segundo nível. O SerializableType relatou o carregador de classe do java.io.Serializable como o carregador de classe para uso da deserialização. No entanto, este carregador de classe não pôde visualizar dentro do carregador de classe, ou classes não-JDK.

A partir de agora, o carregador de classe do org.hibernate.util.SerializationHelper.deserialize(InputStream, ClassLoader) tenta resolver o carregador de classe que precisa ser deserializado. Caso isto não seja bem sucedido, ele usará o carregador de classe do contexto a partir do segmento atual e o carregador de classe que carrega a classe Hibernate.

O Query Cache solicitou que a sessão ou gerenciador de entidade fossem encerrados e reabertos antes de se tornassem ativos, uma vez que o Hibernate compara o timestamp da consulta do cache com o timestamp da sessão atual quando recuperando uma consulta do cache. Isto foi ajustado e o Hibernate usa o nextTimestamp() para buscar o timestamp atual ao invés do timestamp com cache.

O @CollectionId descreve uma coluna do identificador para um bag (um idbag, por exemplo). O nullable deveria ser configurado para falso. Isto foi corrigido e o nullable e o nullable são agora configurados para false por padrão.

O PostgreSQL falhou em desativar o SchemaExport quando os nomes de restrições alteraram. Agora, o Hibernate imprime um cascade quando ele tenta desativar a tabela, corrigindo o problema.

O Hibernate usa StandardDialectResolver para adivinhar o dialeto Hibernate, caso a propriedade hibernate.dialect não tenha sido encontrada no perfil das propriedades do Hibernate, hibernate.cfg.xml ou persistence.xml. O StandardDialectResolver retorna o SybaseDialect, caso o nome do banco de dados extraído dos meta-dados do banco de dados seja Sybase SQL Server ou Adaptive Server Enterprise. No entanto, isto causa alguns problemas devido ao SybaseDialect ter sido substituído. Agora, o StandardDialectResolver advinha o dialeto correto, caso o hibernate.dialect não tenha sido configurado.

Quando lendo uma consulta HQL juntamente com a busca de uma coleção, o FetchingScrollableResultsImpl.last() não foi ao último resultado, caso o cursor estivesse posicionado após o último resultado. Do contrário, o cursor permaneceu em posição após o último resultado. Isto pode levar à seguinte mensagem do org.hibernate.exception.GenericJDBCException: could not perform sequential read of results. A solução para este problema garante que o cursor vá ao último resultado, conforme o esperado.

Quando um nome de coluna era definido em crase (`), os mapeamentos @JoinTable e @JoinColumn falhavam com o AnnotationException, na situação do nome de coluna com crase ter sido referenciado. A partir de agora, o Hibernate compara o referencedColumnName com o nome de cota da coluna ao invés do nome de coluna da tabela.

O getColumnSpan retornava 0 quando comparava entidades com os mapeamentos OneToOne, mesmo quando comparava a mesma entidade resultada nos TypeMismatchExceptions. O algoritmo do getColumnSpan foi alterado de forma que o span da coluna pode ser identificado por seu próprio identificador ou tipo de chave única.

O LikeExpression não manuseava o sinalizador ignoreCase apropriadamente quando o ignoreCase era configurado para falso. O SQL property like ? era construído, porém o sinalizador dentro do getTypedValues não era usado e o valor de letra minúscula era sempre produzido. Este problema foi solucionado e a letra minúscula ou original é sempre usada quando o ignoreCase for configurado para falso.

Numa sessão sem estado, a carga de consulta direciona-se ao processo de duas fases: na primeira, um contexto de persistência temporário é populado com objetos vazios, na segunda, os dados do membro do objeto são lidos a partir do banco de dados. Caso um objeto conter uma associação ou uma coleção, a consulta executa uma chamada recursiva ao método get() da sessão. Isto limpa o contexto de persistência temporariamente.

Caso o objeto pai tiver quaisquer outras associações a serem lidas como parte da segunda fase, o Hibernate lançará uma asserção uma vez que as associações não possam ser encontradas no contexto de persistência.

Isto foi solucionado pela introdução de um novo método: org.hibernate.engine.PersistenceContext.isLoadFinished(). Este método informa o StatelessSession quando limpar o contexto de persistência temporariamente.

Um bug no código org.hibernate.cfg.OneToOneSecondPass pode levar a um org.hibernate.PropertyValueException, quando processando um mapeamento um-a-um. A exceção ocorre uma vez que o JOINs não continha otherSideProperty, otherSideJoin mantendo dados antigos ao invés de ser nulo. O código org.hibernate.cfg.OneToOneSecondPass foi corrigido.

O Hibernate gerou um alias errado na estratégia de herança da pré-classe da tabela em certas circunstâncias. (Consulte o JIRA para exemplos.) A partir de agora, o AbstractCollectionPersister usa o alias de coluna chave gerado pelo Column.getAlias(Dialect,Table), para que o mapeamento de estratégia de herança de pré-classe da tabela esteja correto.

Um NoClassDefFoundError será acionado com a seguinte mensagem, quando um fornecedor do cache não for encontrado.

net/sf/ehcache/CacheException

Um HibernateException é acionado com a seguinte mensagem, quando um fornecedor da conexão não for encontrado.

Não foi possível instanciar o fornecedor de conexão: " + providerClass

Quando estes erros ocorrem, um número maior de mensagens de informação são acionadas.

A ordem de interação do HashMaps e HashSets para o JDK 6 leva a ordem das colunas em cláusulas de união ou sub-classes de união a diferir-sem, independente se o JDK 5 ou 6 é usado ou não. Uma vez que a troca na ordem da coluna é consistente através das cláusulas de união, as consultas resultantes são válidas. No entanto, esta troca pode afetar o desempenho. A implementação do HashSet foi modificada para o LinkedHashSet, para um desempenho idêntico entre os diferentes JDKs.

O Hibernate não podia ser compilado anteriormente sob o JDK 6, uma vez que as seguintes classes não implementavam inteiramente as interfaces JDK 6:

Ocorria um NoSuchMethodError quando um aplicativo solicitava um método faltante dessas classes. Os métodos faltantes foram implementados e este erro não está mais ocorrendo.

Quando o org.jboss.remoting.marshal.MarshallerLoaderHandler recebia uma solicitação de uma classe, ele retornava uma instância do org.jboss.remoting.loading.ClassBytes. Caso o MarshallerLoaderHandler era impossibilitado de encontrar a classe desejada, o objeto ClassBytes retornado possuía um valor nulo para o array bite de classe. No entanto, o org.jboss.remoting.loading.ClassByteClassLoader não verificava pela possibilidade de um array bite nulo, portanto um NullPointerException resultou. O JBREM-1184, que originou este problema, está corrigido agora.

Na injeção de um jBPM ProcessInstance para o componente Seam, a instância do processo retornada era registrada para salvar automaticamente. Isto causava um problema de execução, uma vez que o jBPM ManagedContext salva todas as instâncias no autoSaveProcessesList, quando for ele era encerrado. O código para retornar um ProcessInstance na injeção foi alterado e a instância do processo não é mais registrada para salvar automaticamente.

Uma falha de sanitização de entrada era encontrada na maneira pela qual o JBoss Seam processava certas expressões JBoss Expression Language (EL) do sistema de coordenadas. Um atacador remoto poderia usar esta falha para executar um código arbitrário através do URL, contendo apêndice, parâmetros de linguagem de expressão especialmente fabricadas, fornecidas a certos aplicativos baseados no framework do JBoss Seam. Nota: Um Java Security Manager configurado e ativado previne a utilização desta falha. (CVE-2010-1871)

A Red Hat agradece Meder Kydyraliev da Equipe de Segurança da Google por relatar este problema.

Uma alteração no método getInstanceFromFactory do Seam para ajustar o problema de concorrência levava certos aplicativos a entrarem numa situação de bloqueio numa combinação específica de circunstâncias. O ajuste original para o getInstanceFromFactory foi revisado e este problema não foi mais avistado.

O Seam era distribuído com uma cópia do activation.jar no próprio diretório /lib. Este arquivo foi fornecido pelo JDK 6. A cópia no Seam foi removida.

Os componentes Rich:comboBox nos apps Seam criados com o seam-gen não possuíam a seleção gráfica. Este problema foi solucionado pela modificação das folhas de estilo em cascata usadas para controlar a exibição do componente num navegador da web. Agora, a exibição gráfica é exibida corretamente.

O Seam falharia, caso dois componentes de mesmo nome de classe fossem encontrados no classpath, com o erro: "java.lang.IllegalStateException: Two components with the same name and precedence -", seguido pelo nomes de classe e componente. O Seam foi atualizado e irá ignorar em quaisquer classes duplicadas. Quando as classes duplicadas forem encontradas no mesmo classname, a primeira será carregada e quaisquer componentes subsequentes no classpath com o mesmo classname serão ignorados.

O MockServletContext não tinha conhecimento de que a Plataforma do Aplicativo JBoss Enterprise 5 usava o Virtual File System. Portanto, ele tentou acessar os URIs como arquivos. A partir de agora, o MockServletContext reconhece a root do aplicativo da web e busca o caminho da classe URL, garantindo que o protocolo não faz parte do parâmetro construtor java.io.File.

Os modelos Seam-gen usaram resource:// para objetos que não estavam no classpath. Isto resultou num erro de tentativa em transformar um modelo RichFaces (XCSS) num arquivo CSS. O Seam-gen não utiliza mais o resource://, ajustando este problema.

Quando um hot deployment era usado para os EARs que continham arquivos WAR múltiplos, o primeiro aplicativo da web acessado funcionava corretamente, porém as solicitações da web dos aplicativos da web subsequentes causavam um NullPointerException. Isto acontecia uma vez que o contexto do aplicativo não era configurado na rodagem do filtro hot deployment. A partir de agora, cada operação relacionada ao contexto do aplicativo da web confere o javax.servlet.ServletContext atual, solucionando este problema.

Quando usando a página de serviços da web da amostra Seambay no Internet Explorer 8, os valores adicionados nos campos de nome de usuário e senha não se propagam à área de solicitação devido ao objeto JavaScript indefinido. Isto foi ajustado.

A amostra Tarefas não funcionavam corretamente no Internet Explorer 8. Quando a opção "Desfazer Tarefa" era selecionada na página Tarefas Resolvidas, a tarefa retorna à página Tarefas, mas não desaparecia da página Tarefas Resolvidas. Este problema foi solucionado pela desativação do cache de solicitação do Ajax.

Os recursos do servlet de recurso, tais como imagens CAPTCHA, sofriam o cache pelo navegador e não re-entravam corretamente devido à resposta incorreta dos cabeçalhos no org.jboss.seam.captcha.CaptchaImage. Os cabeçalhos de resposta foram corrigidos, sendo este problema solucionado.

No correio Seam, os anexos nem sempre eram incluídos in-line, de maneira que os anexos não eram visíveis em alguns dos clientes de correio. A solução para este problema foi reforçar suporte do JBSEAM-4630 e os anexos estão visíveis agora.

O BigDecimal era convertido em duplo e retornava a um BigDecimal que levava a um valor diferente retornado, caso o ELSupport.coerceToType era chamado por uma instância BigDecimal como primeiro 'obj' de Parâmetro e BigDecimal.class como tipo.

Isto foi relacionado como upstream e ajustado na Plataforma do Aplicativo JBoss Enterprise 5.1.0 pela alteração da dependência Seam no JBoss-EL to 1.0_02.CR5.

A partir de agora, o ELSupport.coerceToType retorna um valor de entrada quando for atribuído ao tipo gerado.

O org.jboss.seam.transaction.EjbSynchronizations não compilou com as especificações do Java. Conforme mencionado anteriormente no http://java.sun.com/blueprints/guidelines/designing_enterprise_applications/transaction_management/qanda/index.html, as classes que implementam o SessionSynchronization podem não ter o TransactionsAttribute TransactionAttributeType.SUPPORTS. O TransactionsAttributeType.SUPPORTS foi substituído pelo TransactionsAttributeType.REQUIRED.

O org.jboss.seam.core.Interpolator não relatou exceções e imprimiu avisos com informações limitadas. As exceções foram reportadas e os avisos são mais informativos.

O suporte JMS do Seam não funcionou após a falhar a um nó escravo uma vez que o campo topicConnection no objeto SubscriptionRegistry tornou-se inválido quando a conexão ao nó mestre falhou. As chamadas subsequentes do SubscriptionRegistry.subscribe() falharam com o SpyJMSException e as subscrições JMS não funcionaram mais, mesmo com o nó mestre ativado. Esta situação foi ajustada.

Havia um erro tipográfico na mensagem carregada pelo org.jboss.seam.async.AsynchronousExceptionHandler enquanto manuseando uma "Exeception thrown while executing asynchronous call". A "Exeception" deveria ser "Exception". Este problema foi solucionado.\n\t\n

As solicitações foram alteradas entre a Plataforma do Aplicativo JBoss Enterprise 4.x e Plataforma do Aplicativo JBoss Enterprise 5.x, de forma que o messages.properties do nível de página no ResourceLoader deve ser armazenado no META-INF/classes, do contrário eles não funcionarão. A documentação não esclarece esta situação. Este problema foi resolvido.

O Initialization.redeploy inclui o código que criou um novo bloqueio e foi bloqueado imediatamente. Isto não forneceu qualquer nível de proteção e pode causar problemas no modo de depuração. Este problema foi solucionado pela remoção do bloqueio permanentemente.

O SeamSpace testCreateBlog falhou com o NullPointerException no IBM JDK 1.6. Agora, o método getIdentifier funciona corretamente no JDK 1.6.

O MockResponseStateManager não substitui o ResponseStateManager#isPostback no perfil ao invés da production. Isto significa que ambas solicitações Faces and não-Faces foram avaliadas como postbacks. O método isPostback(FacesContext context) foi adicionado no org.jboss.seam.mock.MockResponseStateManager, que substitui o método antigo e permite que NonFacesRequest reconheça postback.

Os serviços da web JAX-RS executados numa transação EJB não puderam ser usados na autenticação do Seam HTTP. As solicitações HTTP a um serviço da web protegido pelo AuthenticationFilter foram divididos em dois ContextualHttpRequests. É possível observar os beans EjbSynchronization, de forma que o Component.getInstance("org.jboss.seam.transaction.synchronizations", ScopeType.EVENT) falha com o NoSuchEjbException.

Este problema foi solucionado.

O s.tld no jboss-seam.ui.jar/MANIFEST.MF continha entradas de atributos que eram definidos incorretamente de acordo com o XML Schema para o descritor JSP Taglibrary. Este problema foi solucionado pela atualização para o Richfaces 3.3.1.SP1.

A amostra Seam Chatroom acionava o EJBTransactionRolledbackException quando um usuário tentava realizar o log in. Esta exceção não influencia a funcionalidade dos aplicativos e foi ajustada com a atualização ao JBoss Cache.

O /status servlet era acessado a partir do http://localhost:8080/status?full=true sem autenticação. (CVE-2008-3273)

Este problema foi solucionado e o servlet pede agora por autenticação.

O mecanismo de análise e implementação do hibernate.cfg.xml era instável. Isto resultou na inabilidade de uso regular dos nomes de propriedade Hibernate, uma vez que as propriedades deviam ser mapeadas ao org.jboss.hibernate.jmx.Hibernate class. O conjunto original dos pares chave/valor analisados são agora inseridos aos objetos o.j.h.hmx.Hibernate através do novo método setProperties(Set<BaseNamedElement>). Em seguida, o método start() constrói a configuração a partir do conjunto de propriedades.

Diversos erros tipográficos foram solucionados no Guia de Referência do Seam.

A seção de Rodagem como um Service no Windows do Installation Guide listou incorretamente os nomes curtos e longos de serviços, além da localização incorreta para o script service.bat. Este problema foi ajustado.

As solicitações RuleBasedPermissionResolver para o Drools 5 estavam desatualizadas. Isto resultou numa informação incorreta processada na documentação. A informação desatualizada foi substituída pelo conteúdo atualizado.

O Guia de Referência do Seam continha algumas informações duplicadas, que foram removidas.

A seção 'Charting' no Guia de Referência Seam não possuía informação nos tags <p:chart>. Isto foi substituído pela descrição 'exibe um gráfico já criado no Java pelo componente Seam.'

Os bloqueios do código de fonte da documentação de referência do Seam não possuía listagem de sintaxe em destaque, dificultando a leitura do código de fonte. Este código foi atualizado pela listagem correta.

O Guia de Referência não numerou os bloqueios de código de amostra. Isto dificultou a conexão ao código e as notas de explicação em acompanhamento.

O "Uso do Seam com as Ferramentas JBoss " do Seam Reference Guide não foi revisado para uso com a Plataforma do Aplicativo JBoss Enterprise e deve ser considerado obsoleto.

A documentação está agora ajustada e atualizada.

O ServerConsumerEndpoint.localClose() acionava um NullPointerException durante o encerramento. Isto foi corrigido pela atualização da versão atualizada do JBoss Messaging.

O JBoss Messaging acionava um TokenMgrError, quando os caracteres multi-bites de código único eram usados pelo Seletor de mensagens.

Este problema foi solucionado e os caracteres multi-bites estão permitidos agora.

Quando o JBoss Transactions é aprimorado da versão 4.4.0 para a versão 4.6.1, o JBoss Messaging XAResourceRecoveryTest falha. O teste é simular uma falha durante o processo de confirmação para solicitar que o Gerenciador de Recuperação recupere a transação, porém com o JBoss Transactions 4.6.1, a transação não é recuperada.

Este problema foi solucionado e um novo teste foi criado para trabalhar com a alteração do comportamento das transações.

O teste revelou problemas com a maneira em que a Plataforma do Aplicativo Enterprise 5.1.0 manuseia a transferência de muitos artigos grandes sem o MTOM ativado. Os clientes devem perceber que o MTOM deve ser ativado ao transferir arquivos grandes e que este tipo de serviço consume uma grande parte da memória. No entanto, caso você escolha em não utilizar o MTOM, você pode implementar o seguinte para impedir que seu Servidor do Aplicativo trave:

A amostra do contexto de serviços não funcionou e acionou um ClassCastException. A amostra foi corrigida e está funcionando conforme o esperado.

Quando o método com o namespace adicional do parâmetro de cabeçalho era chamado após o método que não possuía este namespace adicional, o namespace incorreto era usado na operação SOAP quando o método era serializado. Este problema foi solucionado pela correção da maneira em que as transações são realizadas entre os Java Objects e XML, de forma que o SOAP Message é gerado com os namespaces corretos.

O contexto doc/examples/jboss-web-services-examples levou diversas exceções a ocorrerem. Este erro de contexto mencionava que as amostras do JBoss Web Services não funcionaria corretamente. Este código de amostra foi modificado conforme JBPAPP-2995, de forma que as amostras estão rodando corretamente agora.

O Sun JAXB aceita silenciosamente as mensagens de erros não-fatais onde elas deveriam ser rejeitadas. A solução para JBPAPP-2114 corrige isto, de forma que as mensagens mal formadas são rejeitadas.

Ocorreu um IndexOutOfBoundsException no POJOResourceFactory, uma vez que a interface era anotada ao invés da implementação. O suporte foi adicionado para as interfaces anotadas.

Quando o aplicativo que usa o JPA e Hibernate era configurado para usar o cache de segundo nível do Hibernate com cluster, ele introduzia uma dependência explícita no CacheManager Service do servidor. Esta dependência não era gravada no sistema de dependência do serviço do servidor, de forma que quando a Plataforma era interrompida, o CacheManager encerrava antes do aplicativo. Isto levava a uma mensagem no registro quando o aplicativo encerrava. Este problema leva apenas à mensagens de erro de registro e foi solucionada com a atualização do HA Server Cache.

O ha-server-cache-jbc foi aprimorado para o 2.0.3.Final.

O mod_cluster dava prioridade às solicitações de envio de uma máquina que usava a memória de sistema maior que as demais máquinas. A métrica retornava a própria 'carga' como 'memória disponível' ao invés de 'memória usada'. Isto foi corrigido e não existe mais qualquer mensagem de erro.

O org.jboss.modcluster.demo.servlet.ThreadCountLoadServlet era removido do mod_cluster, porém continuava especificado no arquivo pertencente ao load-demo.war. Isto resultava em erros de implementação. A solução para este problema foi remover as seções <servlet> e <servlet-mapping> para o threads servlet.