Algumas partes foram desenvolvidas usando JSF 1.1, estas partes eu me preocupei ao máximo manter a compatibilidade com o menor número de alterações possível. Antes de ter os recursos de mensagens centralizados, eu não me preocupei em manter um padrão de nomenclatura para os recursos de mensagem, meu grande erro. Conclusão, meu recurso de mensagens para o cadastro de clientes se chamava… tente adivinhar… cliente.

Como a minha humilde caixa de seleção vinculava seu valor a uma propriedade chamada cliente, começaram as dores de cabeça. Eu recebi uma exception não muito amistosa:

19/05/2008 23:06:40 javax.faces.component.UIInput updateModel
SEVERE: /contatos/contato.xhtml @44,46 value=”#{Contato.cliente}”: {0} object is read only base com.marcossousa.app.beans.ContatoBean@123efed property cliente
19/05/2008 23:06:40 com.sun.faces.lifecycle.RenderResponsePhase execute
INFO: WARNING: FacesMessage(s) have been enqueued, but may not have been displayed.
sourceId=myform:cliente[severity=(ERROR 2), summary=(/contatos/contato.xhtml @44,46 value="#{Contato.cliente}": {0} object is read only base com.marcossousa.app.beans.ContatoBean@123efed property cliente), detail=(/contatos/contato.xhtml @44,46 value="#{Contato.cliente}": {0} object is read only base com.marcossousa.app.beans.ContatoBean@123efed property cliente)]

Logo que ocorreu o problema fui verificar se o método Set do meu bean estava correto e verifiquei também se o Contato não era nulo. Tudo estava aparentemente correto, pesquisei sobre o assunto no “Oráculo” e não encontrei nenhuma informação relevante. Mais algum tempo de análise verificando se havia alguma correlação, e nada, mas estava chegando perto.

Vendo que eu iria perder muito tempo, tomei uma decisão: vou executar a aplicação usando os códigos fontes do JSF. Coloquei um breakpoint no código que seta os valores nas propriedades dos Managed Beans. Analisei os comportamentos durante cada chamada. Uma coisa não fazia sentido, era verificada a existência de um recurso de mensagens para cada propriedade. Restaurei os códigos fontes também da API para confirmar minhas suspeitas. E realmente e retornava o recurso de mensagens.

Apesar do tempo perdido, foi interessante resolver o problema. Espero que ajude alguém. Recapitulando:

<resource -bundle>
<base -name>com.foo.message</base>
<var>mymessage</var>
</resource>

public class Foo {
private String mymessage;
privates String getMymessage() {
return mymessage;
}
private void setMymessage(String s) {
this.mymessage=s
}
}

E

<h :inputText value="#{foo.mymessage}"/>

Não funciona!

Está aí uma grande vantagem de usar bibliotecas open-source, o problema é complexo, melhor olhar diretos nos fontes! Eu adoro fazer isto =)

Bom para anotar um bean basicamente há 3 anotações: @Service, @Repository e @Controller. Você pode ou não especificar um nome para seu bean. Caso você não especifique ele irá considerar o nome da classe sendo o nome do seu bean. Veja um exemplo:

@Service("mycarService")
public classe CarService {
// algum código aqui
}

Você pode está ser perguntando, mas qual a diferença e qual anotação usar para anotar meus beans? Bom segundo a documentação do Spring Framework é aconselhável que use a anotação @Repository para beans de acesso a dados (DAO), @Service para lógica de negócio e @Controller para beans que fazer o controle web.

Ainda falta responder a uma pergunta:  Como ele será automaticamente adicionado no contexto Spring? São exigidos dois passos no arquivo de configuração, o primeiro é habilitar o uso de anotações e o outro é dizer em quais pacotes estão os beans anotatos, veja um exemplo:

<!-- Faz a indentificação dos beans anotados com @Service, @Repository e @Controller -->
<context:component-scan base-package="com.marcossousa.myblog"/>
<!-- Habilita a configuração de beans via anotações -->
<context:annotation-config/>

Com isto todos os beans antotados no pacote com.marcossousa.myblog serão adicionados automaticamente no contexto do spring. Fácil não?

Como havia dito no post anterior, o Seam suporta a injeção de objetos presentes no contexto JSF. Nesta vídeo aula foi mostrado como configurar o components.xml, VariableResolver do Spring e criado um bean de persistência de usuários para persistir usuários.

Download dos Fontes Vídeo Aula
Vídeo Aula

O fato do Seam suportar a injeção de objetos presentes no contexto JSF permite que os beans declarados com contexto do Spring sejam facilmente consumidos pelos componentes Seam. Aí surgiria um problema, como fazer os beans presentes no contexto Spring ficar disponíveis no contexto JSF? Simples, o Spring possui um VariableResolver que disponibiliza os beans existentes dentro do contexto Spring.
Download dos Fontes Vídeo Aula
Vídeo Aula

Em anotações a versão suporta as anotações descritas na JSR-250: @PostConstruct, @PreDestroy e @Resource; da  Java EE 5: @WebServiceRef e @EJB. Ela também possui suas próprias anotações: @Autowire, @Repository, @Service, @Controller, @Component. Através destas anotações é possível fazer quase tudo o que é feito nos arquivos de configuração em xml, que foi melhorado.  O suporte aos arquivos de configurações das versões anteriores foi mantido.

O spring 2.5 melhorou o suporte a jsf e agora tem um bom suporte com jsf 1.2 com o DelegatingFacesELResolver.

Mais informações em: http://www.springframework.org/

http://www.springframework.org/download

Nas vídeo-aulas basicamente foi feito a configuração de bibliotecas RichFaces e Ajax4jsf, ajuste nos templates e estilos CSS, alteração dos botões de edição e novo na página de listagem para fazer requisições em ajax permitindo a inclusão e edição de registros na própria página de listagem.

Elas podem ser vistas através dos links:
Ajax em JSF: RichFaces e Ajax4faces – Parte 1
Ajax em JSF: RichFaces e Ajax4faces – Parte 2

@Transactional(propagation=Propagation.REQUIRED)
public interface Foo{
void fazAlgumaCoisa() throws FooException;
}

e uma interface que herda de Foo:

public interface Foo2 extends Foo{
void fazOutraCoisa() throws FooException;
}

Neste exemplo podemos chegar as concluções:

1° Que as transações são herdadas apenas para os métodos declarados na interface anotada.

2° Apenas exceções não verificadas gerarão rollback, ou seja, se um FooException for gerada a transação será efetivada. Para uma FooException resultar em rollback a anotação deve estar:
@Transactional(propagation=Propagation.REQUIRED, rollbackFor=FooException.class)

3° Toda implementação das interfaces acima, utilizarão as políticas transações definidas na interfaces, a menos que elas sejam sobrescritas, ou seja, incluindo a anotação @Transactional no método ou na classe.

Bom espero que tenha ajudado um pouco.

<tx:annotation-driven transaction-manager=”transactionManager”/>

Nota: O parâmetro transaction-manager é opcional se o bean que controlará a transação tiver o nome transactionManager.

Agora para definir uma transação basta adicionar a transação ao método, a classe ou na interface. Veja as principais propriedades:

isolation – define como a transação a será controlada, as opções são: DEFAUT, READ_COMMIT, READ_UNCOMMIT e REPEATABLE_READ e SERIALIZABLE.
propagation – Tipo de propagação da transação, se é obrigatória, se requer que uma nova seja criada.
readOnly – não permite que alterações sejam feitas no banco de dados, resolve problema de flush do hibernate.
rollBackFor – arranjo de exceções verificadas que devem gerar roll back.
nonRollBackFor – arranjo de exceções que não devem gerar roll back.

Caso uma classe ou interface seja anotada, e precisa de customizar apenas um método, pode anotar o método a ter a transação customizada, pois, a anotação no método sobrescreve a anotação da classe ou interface.

Na próxima parte falarei de algumas regras e limitações.