Jboss mais uma vez mudou a implementação interna sobre VFS, quebrando o scanner de classes do GraniteDS. Mesmo assim era possível executar o GraniteDS em modo no-scan. Mas isto foi corrigido e ja é possivel utilizar no Jboss AS7.
Outro problema com Jboss AS 7 é a profunda integração que ele tem com Hibernate 4, o que deixa um tanto doloroso implantar aplicações com Hibernate 3.x. Existem algumas soluções descritas no blog do Hibernate. No entanto, é recomendado a atualização para Hibernate 4 logo que possível. GraniteDS já suporta Hibernate 4. Basta usar o grantie-hibernate4.jar ao invés de granite-hibernate.jar
Flex 4.5 quebrou algumas coisas da APIs e havia dois problemas principais com Tide:
Estes dois itens foram corrigidos e você irá encontrar um versão das bibliotecas do GraniteDS compiladas com Flex4.5 aqui. Infelizmente, ainda não está disponível com a distribuição “normal”, porque o sistema de compilação não foi capaz de compilar com versões diferentes do Flex SDK.
O suporte a lazy-loading do GraniteDS é uma das suas características mais importantes e ajuda muito na quantidade de dados transferidos através da rede. No entanto só funcionava do Servidor para o Cliente. O problema é que depois de ter carregado todas as associações no cliente, passando um objeto para uma chamada ao servidor, o método irá enviar todo o grafo do objeto para o servidor, mesmo se você tiver mudado uma propriedade simples.
public function savePerson():void {
person.lastName = "Test";
personService.save(person); // This will send all loaded collections associated to the Person object
}
Obviamente isso não é muito eficiente, então agora é possível pedir para o Tide remover a inicialização do grafo do objeto antes de enviá-lo ao servidor. Você pode fazer isso manualmente.
var uperson:Person = new EntityGraphUnintializer(tideContext).uninitializeEntityGraph(person) as Person; personService.save(uperson);
Toda a inicialização de coleção carregada no Objeto Person é removida. O objeto uperson contém o mínimo, de dados, para um correto update no servidor. Se não houver uma mudança profunda no grafo do objeto o uninitializer é capaz de identificar e enviar os dados para o servidor.
person.contacts.getItemAt(0).email = 'test@test.com'; var uperson:Person = new EntityGraphUnintializer(tideContext).uninitializeEntityGraph(person) as Person; personService.save(uperson)
Aqui o objeto uperson ainda vai conter a coleção de contacts, mas se houver outras coleções elas serão removidas.
Ficar chamando o EntityGraphUninitializer manualmente é trabalhoso e se torna feio. Para uma solução mais limpa você pode anotar os parametros dos seus métodos de serviço com a anotação @org.granite.tide.data.Lazy.
public void save(@Lazy Person person) {
}
Desta forma o GAS3 irá gerar uma anotação [Lazy] nos seus métodos de serviço. Em seguida deve registrar o componente UninitializeArgumentPreprocessor no Tide.
Tide.getInstance().addComponentes([UninitializeArgumentPreprocessor]);
Depois de feito isso todas as chamadas para PersonService.save() irá utilizar o objeto não inicializado do argumento person.
No GraniteDS 2.2 é necessário um ServletContext para recuperar o Singleton do Gravity, o que nem sempre é possível ou adequado e implica na dependência da API de Servlets. Com GrantieDS 2.3 o Singleton está disponivel no contexto do framework e pode ser simplesmente injetado.
Com Spring ou CDI
@Inject private Gravity gravity;
Com Seam
@In("org.granite.seam.gravity") private Gravity gravity;
As capacidades de DI do EJB3 são limitadas para permitir algo assim. Se você precisa ser indepente da API do Gravity, basta usar um Tópico JMS e enviar mensagens com a API de JMS.
GraniteDS fornece um recurso de envio de mensagens que permite acompanhar as atualizações de entidades JPA e de forma trasparante despachá-las através do Gravity para os clientes Flex. No entanto no GrantieDS 2.2 havia duas limitações: as atualizações podem ser controladas apenas de um segmento gerenciado pelo GraniteDS e o modo ON_COMMIT permitindo envio transacional das atualizações não era suportado.
GraniteDS 2.3 vem com um conjunto de interceptadores(infelizmente um para cada tecnologia) para gerenciar o modo ON_COMMIT que pode ser usado para rastrear qualquer mudança fora do segmento do GraniteDS.
A configuração é simples, basta adicionar o parametro useInterceptor=true na anotação @DataEnabled e usar ON_SUCCESS ou ON_COMMIT.ON_SUCCESS é o modo padrão e significa simplesmente que o envio ocorrerá para todas as chamadas recebidas. ON_COMMIT significa que o envio ocorrerá quando a transação for confirmada, ele garante que o envio é transacional, quando utilizado em conjunto com um tópico JMS transacionados.
Em seguida, configure o interceptador para a sua estrutura de destino:
Para Spring adicionar isto ao contexto
<graniteds:tide-data-publishing-advice/>
Tome cuidado que você precisa utilizar a ultima versão do xsd
xsi:schemaLocation="http://www.graniteds.org/config http://www.graniteds.org/public/dtd/2.3.0/granite-config-2.3.xsd"/
Para Seam não precisa nada de configuração quando o parametro useInterceptor=true é adicionado a anotação @DataEnabled.
Para CDI apenas habilitar o interceptor no beans.xml
<beans
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">
<interceptors>
<class>org.granite.tide.cdi.TideDataPublishingInterceptor</class>
</interceptors>
</beans>
Para EJB3, você tem que configurar o interceptor em cada EJB:
@DataEnabled(topic="myTopic", publish=PublishMode.ON_COMMIT, useInterceptor=true) public class MyServiceBean { ... }
Ou globalmente no ejb-jar.xml:
<assembly-descriptor>
<interceptor-binding>
<ejb-name>*</ejb-name>
<interceptor-class>org.granite.tide.ejb.TideDataPublishingInterceptor</interceptor-class>
</interceptor-binding>
...
</assembly-descriptor>