Dez 15

Injeção de Dependências nos DAOs de Entidades do Framework

Escrito por DClick Team em 1, 2.0, 4, 6, AR, arte, auto, BI, C#, class, err, exemplo, for, framework, git, Google, Hibernate, ide, IE, if, Java, Number, O, on, override, padrão, procura, Ria’s Geral, S+S, Sem categoria, Spring, string, Sun, super(), TAT, Teste, Twitter, UI @ 12 15th, 2011 | via http://blog.dclick.com.br/pt/ | Sem comentários

Twitter!

A última implementação da HibernateDAOFactory do módulo persist do DCF, agora permite que seus DAOs de entidade possuam propriedades injetadas diretamente do container de beans do Spring.

No exemplo que temos nos testes de projeto, temos o MockDAO, que possui uma propriedade String com nome ‘testeString’:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

public class MockDAO extends HibernateEntityDAO

private String testeString;

public MockDAO(SessionFactory sessionFactory)
super(MockEntity.class, sessionFactory);

@Override
protected Order getOrderForList()
return Order.asc(“number”);

public String getTesteString()
return testeString;

@Autowired
@Qualifier(“testeString”)
public void setTesteString(String testeString)
this.testeString = testeString;

}

Note que no setter da propriedade, colocamos a anotação @Autowired, para recuperar esta String do container, e também associamos o Qualifier ‘testeString’.

No arquivo de beans do spring, basta adicionarmos um bean String com o id igual ao do qualifier:

1
2
3

class=“java.lang.String” id=“testeString”>
-arg value=“stringTeste” />
>

Repare que o valor da String é ‘stringTeste’. Vamos ver em nosso teste agora se tal valor chega corretamente no DAO:

1
2
3
4
5
6
7
8
9
10

@Test
public void testRightFactory()
MockDAO dao = this.getDaoFactory().getDAO(MockEntity.class);
Assert.assertNotNull(dao);

Assert.assertEquals(this.getDaoFactory(), dao.getDaoFactory());

Assert.assertNotNull(dao.getTesteString());
Assert.assertEquals(“stringTeste”, dao.getTesteString());

Uma coisa importante a se perceber, é que a chamada da DAOFactory permanece exatamente a mesma, mantendo assim a retro-compatibilidade com as outras versões, e apenas as injeções baseadas em anotações do Spring vão ser consideradas.
NÃO é necessário apontar o component-scan do Spring para o pacote de DAOs de sua aplicação. A injeção de beans adicionais é feita completamente a parte, seguindo o mesmo padrão de nome e de instanciação dos DAOs.

Qualquer dúvida, basta me procurar.

O projeto está no github, dentro do módulo persist do dclick-framework, ou diretamente no nexus da DClick.

Dez 13

Multiple Views com Spring Web MVC

Escrito por DClick Team em .NET, 1, 2.0, 3.5, 4, 6, action, apache, app, Apresentação, AR, Arquitetura, arte, auto, BI, C#, case, class, classe, cliente, código, control, conversor, dados, Design, development, dispatch, Diversos, Documentação, err, exemplo, Ferramenta, Flex, for, framework, Frameworks, Google, handle, html, ide, IE, if, int, interface, internet, j2ee, Java, JSF, library, map, mvc, NaN, O, on, Outros, padrão, Projetos, pt, rest, RIA, Ria’s Geral, S+S, Sem categoria, servidor, site, Software, Spring, SpringFramework, state, string, strings, Sun, tag, TAT, Tecnologia, Tema, tv, Twitter, UI, uint, web, XML, XP @ 12 13th, 2011 | via http://blog.dclick.com.br/pt/ | Sem comentários

Twitter!

Uma das vantagens de utilizar a arquitetura do Spring para implementar projetos Web, é fazer uso do Sprin-WEB-MVC. Quem já usou sabe que isso é uma vantagem a se considerar quando for feita a escolha das tecnologias e frameworks que serão utilizados no projeto.
Spring WEB-MVC é uma abstração poderosa para a camada de apresentação, tornando muito flexível o uso de diferentes tipos de tecnologias no frnt-end da aplicação.
Veremos uma dessas abstrações que ajudam a modularizar e simplificar nosso trabalho do lado do servidor: Views.

Conceito de Views

Toda requisição que segue para o WEB-MVC passa pelo DispatcherServlet do spring. A partir daí, o container se responsabiliza por delegar a chamada para o controller correto, baseando-se nas configurações de sua aplicação.
Depois que a chamada é tratada pelo controller, o spring manda a resposta correspondente atrelada a uma View. Uma View é um descritor da forma com que os dados vão ser apresentados na interface, podendo ser JSP, JSF, JSon, XML, etc., ou até mesmo uma forma de encapsular os dados específica da sua aplicação.
O poder das Views está justamente no fato de ser apenas uma descrição de como os dados serão apresentados, portanto desconecta-se completamente da aplicação, e pode ser aproveitada em outras ocasiões por outros sistemas.
Uma View no Spring nada mais é do que uma interface Java que descreve o tipo do conteúdo, e é responsável por renderizar a requisição:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77

/*
* Copyright 2002-2008 the original author or authors.
*
* Licensed under the Apache License, Version 2.0 (the “License”);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an “AS IS” BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/

package org.springframework.web.servlet;

import java.util.Map;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

/**
* MVC View for a web interaction. Implementations are responsible for rendering
* content, and exposing the model. A single view exposes multiple model attributes.
*
*

This class and the MVC approach associated with it is discussed in Chapter 12 of
* Expert One-On-One J2EE Design and Development
* by Rod Johnson (Wrox, 2002).
*
*

View implementations may differ widely. An obvious implementation would be
* JSP-based. Other implementations might be XSLT-based, or use an HTML generation library.
* This interface is designed to avoid restricting the range of possible implementations.
*
*

Views should be beans. They are likely to be instantiated as beans by a ViewResolver.
* As this interface is stateless, view implementations should be thread-safe.
*
* @author Rod Johnson
* @author Arjen Poutsma
* @see org.springframework.web.servlet.view.AbstractView
* @see org.springframework.web.servlet.view.InternalResourceView
*/
public interface View

/**
* Name of the @link HttpServletRequest attribute that contains the response status code.
*

Note: This attribute is not required to be supported by all
* View implementations.
*/
String RESPONSE_STATUS_ATTRIBUTE = View.class.getName() + “.responseStatus”;

/**
* Return the content type of the view, if predetermined.
*

Can be used to check the content type upfront,
* before the actual rendering process.
* @return the content type String (optionally including a character set),
* or

null

if not predetermined.
*/
String getContentType();

/**
* Render the view given the specified model.
*

The first step will be preparing the request: In the JSP case,
* this would mean setting model objects as request attributes.
* The second step will be the actual rendering of the view,
* for example including the JSP via a RequestDispatcher.
* @param model Map with name Strings as keys and corresponding model
* objects as values (Map can also be

null

in case of empty model)
* @param request current HTTP request
* @param response HTTP response we are building
* @throws Exception if rendering failed
*/
void render(Map model, HttpServletRequest request, HttpServletResponse response) throws Exception;

}

Todo o código e JavaDoc está no projeto do Spring.

JSon e XML

Vamos criar um exemplo de controller com duas views diferentes: JSon e XML. JSon e Xml são os formatos mais comuns na Web, por isso vamos ver uma das maneiras de devolvê-las em nossos contrllers.
Não vou entrar no detalhe de como configurar os controllers da sua aplicação para funcionar com o Spring-WEB-MVC, pois não é o intuito deste post, e existe bastante documentação disponível na internet sobre o assunto.

A maneira que escolhi para o exemplo, foi deixar a resposta padrão da servlet como XML, e criar uma alternativa de view em JSon. Você pode configurar como quiser a ordem e o padrão de view da sua aplicação, essa escolha serve apenas para ilustar como lidar com os dois casos.
Comece criando alguma classe de domínio para servir de resposta do nosso controller:

1
2
3
4
5
6
7
8
9
10

public class Exemplo
private String nome;

public String getNome()
return nome;

public void setNome(String nome)
this.nome = nome;

}

Agora vamos criar um Controller para devolver nosso objeto de domínio:

1
2
3
4
5
6
7
8
9
10
11
12

@Controller
public class ExemploController

@RequestMapping(“/exemplo/xml”)
@ResponseBody
public Exemplo testando()
Exemplo ret = new Exemplo();
ret.setNome(“xml”);
return ret;

}

Agora temos uma servlet que responderá por “//exemplo/xml” devolvendo a instância de exemplo que acabamos de criar no método.
Vamos configurar agora nosso ‘empacotador’ de XML para torná-lo formato padrão da aplicação. No arquivo de beans do Spring crie os seguintes beans:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

class=“org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter”>
name=“messageConverters”>
>
bean=“marshallingHttpMessageConverter” />
>
>
>

class=“org.springframework.oxm.xstream.XStreamMarshaller”
id=“xmlMarshaller”>
name=“aliases”>
>
key=“exemplo”>Exemplo
>
>
>
>

id=“marshallingHttpMessageConverter”
class=“org.springframework.http.converter.xml.MarshallingHttpMessageConverter”>
name=“marshaller” ref=“xmlMarshaller” />
name=“unmarshaller” ref=“xmlMarshaller” />
>

O que fizemos foi criar um “marshaller” de XML que usa o XStream para converter ‘de’ e ‘para’ XML. Também mapeamos nossa classe de domínio para o alias “exemplo”. Feito isso basta criar um bean que representa os conversores de mensagens do Spring, nesse caso ‘messageConverters’, e associar o conversor de XML nele.
Pronto! Agora que temos as configurações necessárias para criar XML, e anotamos nosso método do controller com ‘@ResponseBody’, o padrão do Spring será devolver o XML que representa a entidade de domínio criada:

1
2
3

>
>xml>
>

Para criar a view de JSon agora, vamos fazer de maneira diferente. Comece criando um bean em seu arquivo do Spring que representa a View de JSon:

1
2
3

id=“jsonview”
class=“org.springframework.web.servlet.view.json.MappingJacksonJsonView”>
>

Note que precisamos da dependência do ‘Jackson’ no classpath do nosso projeto, que está disponível no site do projeto ou até mesmo no repositório do maven.
Agora em nosso controler, vamos adicionar a dependência da view que acabamos de criar, e adicionar o método que tratará a requisição em JSon:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

private View jsonview;

@Autowired
@Qualifier(“jsonview”)
public void setJsonview(View jsonview)
this.jsonview = jsonview;

@RequestMapping(“/exemplo/json”)
public ModelAndView testandoJson()
Exemplo ret = new Exemplo();
ret.setNome(“json”);
return new ModelAndView(this.jsonview, “response”, ret);

Repare que não precisamos da anotação ‘@ResponseBody’, e que ao invés de devolver um ‘Exemplo’ estamos devolvendo o ModelAndView do SpringWEBMVC.
Para que a resposta chegue no formato correto, basta mandar a view de JSon que criamos junto com o ModelAndView, e o objeto de domínio. Dessa forma temos a resposta que esperamos:

1
2
3
4

“response”:
“nome”:”json”

}

Conclusão

Para a moda REST que está tomando força nos últimos tempos, as múltiplas views do Spring é uma ótima ferramenta para fazer parte dessa onda, e ainda prover diferentes maneiras de seu servidor se comunicar com diversos tipos de dispositivos e aplicações clientes, sem comprometer código com regras de negócio.

Espero ter sido útil, e qualquer dúvida, crítica ou comentário são sempre bem vindos.

Por @Gust4v0_H4xx0r

Nov 16

Spring 3.1 RC1 – @Configuration

Escrito por DClick Team em 1, 2.0, 4, 6, action, app, AR, auto, bar, BI, blog, busca, C#, case, class, classe, classes, código, components, configuração, err, erro, error, exemplo, for, framework, Google, IE, if, int, Java, lite, map, mudanças, mvc, NaN, O, on, Plugin, refresh, rest, RIA, Ria’s Geral, RoR, S+S, Sem categoria, Spring, SpringFramework, string, Sun, super(), tag, TAT, Teste, Twitter, UI, uint, web, XML @ 11 16th, 2011 | via http://blog.dclick.com.br/pt/ | Sem comentários

Twitter!

Spring @Configuration

O que há de novo

Para habilitar certas funcionalidades do Spring que envolvem AOP, era preciso escrever tags XML como por exemplo context:component-scan para especificar os pacotes em que o Spring pode buscar por beans anotados com @Component, @Repository ou @Service.
Na versão 3.1 foram disponibilizadas as mesmas funcionalidades via anotação. São elas:

1
2
3
4
5
6
7
8

org.springframework.context.annotation.Configuration
org.springframework.context.annotation.ComponentScan
org.springframework.context.annotation.EnableLoadTimeWeaving
org.springframework.context.annotation.EnableAspectJAutoProxy
org.springframework.scheduling.annotation.EnableScheduling
org.springframework.scheduling.annotation.EnableAsync
org.springframework.transaction.annotation.EnableTransactionManagement
org.springframework.web.servlet.config.annotation.EnableWebMvc

Vamos abordar o caso básico, pois o resto é bem similar.

@ComponentScan

Caso você ainda não esteja familiarizado com as configurações por anotaçãoo, vamos ao básico.
Comece criando uma classe que representará seu container de beans, e a anote com @configuration:

1
2
3
4

@Configuration
public class TestConfiguration

Nesta classe estarão os beans que o container irá instanciar e deixar a nossa disposição.
Para iniciar o container vamos criar um test (JUnit 4) que instancia o contexto:

1
2
3
4
5
6
7
8
9
10
11

public class ConfigurationTestCase

@Test
public void testConfigurationBeans()

AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext();
ctx.register(TestConfiguration.class);
ctx.refresh();

}

Aqui criamos um container do tipo AnnotationConfigApplicationContext e registramos nossa classe de configuração nele. Repare que é possível registrar mais classes, e portanto disponibilizar mais beans no container.
Agora vamos criar nosso bean de teste:

1
2
3
4
5
6
7
8
9
10
11
12
13

public class GenericBean

private String testProperty;

public GenericBean(String testProperty)
super();
this.testProperty = testProperty;

public String getTestProperty()
return testProperty;

}

Vamos criar os métodos em nossa classe de configuração que instanciam nosso bean de duas maneiras diferentes:

1
2
3
4
5
6
7
8
9

@Bean(name = “testBean”)
public GenericBean genericTestBean()
return new GenericBean(“test”);

@Bean(name = “otherBean”)
public GenericBean genericOtherBean()
return new GenericBean(“other”);

Repare que a única diferença entre os dois é a String que passamos como parâmetro.
Agora que temos 2 beans diferentes em nosso container, vamos criar os testes para verificar o comportamento do Spring. Abaixo da inicialização do contexto, vamos adicionar as seguintes linhas:

1
2
3
4
5
6
7
8
9

GenericBean testBean = ctx.getBean(“testBean”, GenericBean.class);

Assert.assertNotNull(testBean);
Assert.assertEquals(“test”, testBean.getTestProperty());

GenericBean otherBean = ctx.getBean(“otherBean”, GenericBean.class);

Assert.assertNotNull(otherBean);
Assert.assertEquals(“other”, otherBean.getTestProperty());

Aqui estamos garantindo que nossos dois beans diferentes estarão no contexto como esperado.
Antes de rodar o teste, será necessário adicionar a dependência do CGLib ao seu projeto. Caso você esteja usando o maven, basta adicionar a seguinte dependência>

GeSHi Error: GeSHi could not find the language text (using path C:Program Fileswampwwwblogwp-contentpluginsig_syntax_hilitegeshi) (code 2)

Pronto, com isso temos o suficiente pra deixar a barra do JUnit verde. Vamos agora adicionar o @ComponentScan.
Em nossa classe de configuração (poderia ser qualquer outra registrada no contexto) adiciona a seguinte anotação:

1
2
3

@Configuration
@ComponentScan(“br.com.dclick.tentativas.configuration.beans”)
public class TestConfiguration

No meu caso meu bean está dentro do pacote br.com.dclick.tentativas.configuration.beans e portanto basta eu alterá-lo adicionando o seguinte código:

1
2
3
4
5
6
7
8

@Component(“componentBean”)
public class GenericBean

private String testProperty;

public GenericBean()
this.testProperty = “component”;

Dessa forma posso criar mais um teste e verificar que o bean está vindo corretamente:

1
2
3
4

GenericBean componentBean = ctx.getBean(“componentBean”, GenericBean.class);

Assert.assertNotNull(componentBean);
Assert.assertEquals(“component”, componentBean.getTestProperty());

Rode o teste e deixa o JUnit feliz.
A única coisa a se ter cuidado aqui, é que com @ComponentScan, você não pode mapear o diretório da própria classe de configuração.

Demais Configurações

Daqui em diante basta anotar suas classes de configuração com as configurações que você deseja ativar, como por exemplo @EnableAsync que permite que os beans rodem de maneira assíncrona com a anotação @Async.

Brinque um pouco com as outras anotações. Acredito que vale o esforço, pois esse tipo de configuração permite abandonar um pouco os arquivos XML e tornam mais fácil o refactor dos beans, afinal teremos erros de compilação com as mudanças de código.

Por enquanto é isso, qualquer dúvida mande nos comentários que responderei assim que possível.

Por @Gust4v0_H4xx0r

Nov 8

Spring 3.1 RC1 – Cache Abstraction

Escrito por DClick Team em 1, 2.0, 4, 6, action, app, AR, Arquitetura, Banco de Dados, BI, blog, C#, cache, class, classe, configuração, dados, Documentação, Download, err, erro, exemplo, for, framework, Google, html, ide, IE, if, int, interface, Java, lite, map, mapa, O, on, Outros, padrão, pt, reference, RIA, Ria’s Geral, S+S, Sem categoria, site, Spring, Spring Framework, SpringFramework, string, Sun, tag, TAT, Teste, Twitter, UI, uint, XML, zend @ 11 8th, 2011 | via http://blog.dclick.com.br/pt/ | Sem comentários

Twitter!

Spring Cache Abstraction

Abordamos um das novas funcionalidades do Spring 3.1 RC1, profiles e environments. Ainda existem outras funcionalidades, mas hoje iremos dar uma olhada em Cache Abstraction.

Cache Abstraction é literalmente uma abstração out of the box para adicionar uma camada de cache sobre seus beans, usando uma arquitetura AOP para gerenciar o que deve e o que não deve ser feito o cache.
Usar a nova camada de cache é muito fácil se você já está habituado com Spring, e veremos uma das diferentes maneiras de configurar seus beans.

Baixando a Denpendência

Para quem utiliza maven, basta adicionar a seguinte dependência no pom do seu projeto:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

>
>
>org.springframework.maven.milestone>
>Spring Maven Milestone Repository>
>http://maven.springframework.org/milestone>
>
>

>
>
>org.springframework>
>spring-core>
>3.1.0.RC1>
>
>
>org.springframework>
>spring-context>
>3.1.0.RC1>
>
>

Se você perferir, pode baixar os jar direto do site do spring.
Sem segredos aqui, basta adicionar as dependências ao projeto e está pronto para usar.

Entendendo o funcionamento

A maneira com que o cache funciona é bem simples. Você pode enxergar o cache como um mapa chave-valor, onde a chave é o conjunto de argumentos do seu método, e o valor é o valor devolvido pelo seu método. Pensando assim fica fácil entender o funcionamento que irei mostrar no exemplo.
Referente a configuração do Spring, é necessário instanciar um gerenciador de cache, ou na linguagem spring, cacheManager. Existe algumas implementações de cache manager disponível no spring, portanto iremos utilizar uma delas em nosso exemplo.
Vamos escrever um teste unitário com JUnit 4.8.1 para ilustrar o comportamento do cache.
Comece criando um arquivo padrão de beans do spring, mas com um namespace a mais:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

>
Repare que estamos utilizando o namespace de cache além dos usuais.
A única configuração que iremos fazer aqui, é a do cache manager. Crie um bean da classe >SimpleCacheManager> e adicione o seguinte bean como cache gerenciado:
>
cc lang=”XML”
public interface CacheableTest

@CacheEvict(value = “property”, allEntries = true)
void evictCache();

@Cacheable(“property”)
String getForCache(String s);

String getProperty();

void setProperty(String property);

Repare no getter e setter que usaremos no teste, e na anotação @Cacheable(“property”). Esta anotação está dizendo que o valor que este método devolver será armazenado no cache que configuramos previamente como property. Fato importante é que este valor é referente ao argumento passado como parâmetro no método.
A outra anotação @CacheEvict(value = “property”, allEntries = true) descreve o método que chamaremos para esvaziar o cache. Note que passamos o nome do cache, e que ele deve limpar todos os valores.
É importante notar também que pode ser passado mais de um nome de cache em ambas as anotações.
Uma implementação básica para nosso bean pode ser:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

@Component(“cacheBean”)
public class CacheableBean implements CacheableTest

private String property;

public String getForCache(String s)
return this.property;

public String getProperty()
return property;

public void setProperty(String property)
this.property = property;

public void evictCache()
// Não faz nada

}

Estou usando o package scan para instanciar o bean. Agora nosso teste:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

public class CacheTest

@Test
public void testCache()

ApplicationContext ctx = new ClassPathXmlApplicationContext(
“spring31-test-beans.xml”);

CacheableTest bean = ctx.getBean(“cacheBean”, CacheableTest.class);

bean.setProperty(“teste”);

Assert.assertEquals(“teste”, bean.getProperty());
Assert.assertEquals(“teste”, bean.getForCache(“a”));

bean.setProperty(“teste2″);
Assert.assertEquals(“teste2″, bean.getProperty());
Assert.assertEquals(“teste”, bean.getForCache(“a”));
Assert.assertEquals(“teste2″, bean.getForCache(“b”));

bean.setProperty(“teste3″);
Assert.assertEquals(“teste3″, bean.getProperty());
Assert.assertEquals(“teste”, bean.getForCache(“a”));
Assert.assertEquals(“teste2″, bean.getForCache(“b”));

bean.evictCache();
bean.setProperty(“teste4″);
Assert.assertEquals(“teste4″, bean.getProperty());
Assert.assertEquals(“teste4″, bean.getForCache(“a”));
Assert.assertEquals(“teste4″, bean.getForCache(“b”));

}

O arquivo de beans se chama spring31-test-beans.xml.
Repare que estamos invocando o método getForCache passando alguns valores diferentes, e o valor devolvido é sempre igual, mesmo que depois setamos um valor diferente ao bean. Para atualizar o valor e limpar o cache, basta invocar o método evictCache que havíamos anotado com @CacheEvict.
Vale a pena brincar um pouco com o funcionamento do cache, e até mesmo criar outros caches e ver o comportamento do evict em diferentes métodos.

Últimas Considerações

As mesmas configurações que fizemos com anotações, pode-se fazer direto no XML. Não entrarei no detalhe pois o funcionamento é exatamente o mesmo, mas se você preferir basta olhar a documentação que é bem straightforward.
Lembre-se que esta camada de cache não possui nenhuma relação com o banco de dados, e deve ser usada com muito cuidado em tais casos, pois alguns erros de concistência podem aparecer devido a um cache desatualizado.
Vale a pena brincar com o cache manager, pois o spring suporta o uso do EhCache, o que pode ser muito útil se você já possui alguma configuração pré-definida para sua aplicação.

Por enquanto é isso, qualquer dúvida mande nos comentários que responderei assim que possível.

Por @Gust4v0_H4xx0r

Nov 4

Spring 3.1 RC1 – Profiles

Escrito por DClick Team em 1, 2.0, 4, 6, Air, app, AR, Banco de Dados, bar, BI, C#, carregar, class, código, dados, demo, Desenvolvimento, Dica, dispatch, Download, err, exemplo, for, framework, Google, ide, IE, if, int, interface, Java, LOB, lógica, novidade, Novidades, O, on, Outros, override, refresh, Release Candidate, RIA, Ria’s Geral, S+S, Sem categoria, site, Spring, SpringFramework, string, Sun, TAT, Teste, Twitter, UI, uint, web, XML, zend @ 11 4th, 2011 | via http://blog.dclick.com.br/pt/ | Sem comentários

Twitter!

Profiles e Environments no novo Spring 3.1

A SrpingSource adotou a estratégia de soltar mais versões do Spring com mais velocidade e escopos de funcionalidades menores.
Seguindo tal estratégia acabou de sair do forno o primeiro release candidate da versão 3.1 do framework.
Para uma estratégia de escopos menores, até que tiveram bastante trabalho e adicionaram várias novidades. Vamos cobrir as novidades aos poucos, começando com uma muito interessante: Profiles e Environments.

Especificando Profiles nos Beans

A idéia de um profile é simples. Um profile define um escopo, envirnmente como é chamado no framework, em que certos beans estarão disponíveis e outros não.
Imagine que você precisa de uma conexão com o banco de dados de testes, que é diferente do banco de dados de desenvolvimento. Com profiles podemos definir um data source do profile de desenvolvimento, e outro do profile de testes, instanciando o correto de acordo com o ambiente que a aplicação irá rodar.

Anotações

Para especificar um profile no seu bean, basta adicionar a anotação @Profile com o nome do profile correspondente. Lembrando que este é o caso em que seus Beans estão sendo criados pelo component-scan usando package scan. Vamos criar um exemplo pra ficar mais claro o que acontece.
Vamos criar uma interface comum para nossos beans:

1
2
3
4
5

public interface ProfileEspecificBean

String recoverActiveProfile();

Agora vamos criar dois profiles e dois beans diferentes para a mesma interface. Um é o bean de desenvolvimento (dev) e o outro de testes (qa).

1
2
3
4
5
6
7
8
9
10

public final class Profiles

private Profiles()

public static final String DEV_PROFILE = “dev”;

public static final String QA_PROFILE = “qa”;

}

1
2
3
4
5
6
7
8
9
10
11
12

package br.com.dclick.tentativas.beans;

@Component(“profileBean”)
@Profile(DEV_PROFILE)
public class DevEspecificBean implements ProfileEspecificBean

@Override
public String recoverActiveProfile()
return DEV_PROFILE;

}

1
2
3
4
5
6
7
8
9
10
11
12

package br.com.dclick.tentativas.beans;

@Component(“profileBean”)
@Profile(QA_PROFILE)
public class QAEspecificBean implements ProfileEspecificBean

@Override
public String recoverActiveProfile()
return QA_PROFILE;

}

Repare que já anotei os beans com @Profile respeitando os profiles específicos de cada bean.
Agora criamos o arquivo de beans do spring, dei o nome de spring31-test-beans.xml:

1
2
3
4
5
6
7
8
9
10
11

<?xml version=“1.0″ encoding=“UTF-8″?>
xmlns=“http://www.springframework.org/schema/beans”
xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance” xmlns:context=“http://www.springframework.org/schema/context”
xsi:schemaLocation=“http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.1.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-3.1.xsd”>

:component-scan base-package=“br.com.dclick.tentativas.beans” />

Feito isso, vamos criar um teste para verificar a lógica de criação dos beans. estou usando JUnit 4.8.1.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

public class ProfileBeansTest

@Test
public void testProfileDev()

GenericXmlApplicationContext ctx = new GenericXmlApplicationContext();
ctx.getEnvironment().setActiveProfiles(DEV_PROFILE);
ctx.load(“classpath:spring31-test-beans.xml”);
ctx.refresh();

// Profile de DEV
ProfileEspecificBean profileBean = ctx.getBean(“profileBean”,
ProfileEspecificBean.class);

Assert.assertEquals(DEV_PROFILE, profileBean.recoverActiveProfile());

@Test
public void testProfileQA()

GenericXmlApplicationContext ctx = new GenericXmlApplicationContext();
ctx.getEnvironment().setActiveProfiles(QA_PROFILE);
ctx.load(“classpath:spring31-test-beans.xml”);
ctx.refresh();

// Profile de QA
ProfileEspecificBean profileBean = ctx.getBean(“profileBean”,
ProfileEspecificBean.class);

Assert.assertEquals(QA_PROFILE, profileBean.recoverActiveProfile());

}

Algumas coisas diferentes estão acontecendo nesse teste.
Estou instanciando um GenericXmlApplicationContext para carregar meus arquivos de beans, isso porque esse application context me disponibiliza um método que é importante para nosso teste: getEnvironment(). Com isso conseguimos acessar o environment do application context, e mais do que isso, conseguimos setar os profiles que estão ativos usando setActiveProfiles. Repare que é possível de setar mais de um profile como ativo, e que os beans podem precisar de mais de um profile para serem instanciados.
Outro fato importante, é que este environment que está disponível, é uma instância de ConfigurableEnvironment. Se você tentar acessar o profile diretamtente em ApplicationContext, você estará acessando um Environment o qual não permite ativar e desativar profiles. Fica a dica.

Após ativar o profile que queremos, basta chamar o load no contexto seguido do refresh para que os beans sejam criados.
Uma vez que o bean foi criado, basta recuperá-lo e executar o teste para se certificaro que se trata do bean que estamos esperando. Note que o nome dos dois beans é o mesmo, e que apenas um deles existe no application context, pois o outro profile não está ativo.

Nested Beans

Outra maneira de definir profiles nos beans é diretamente no XML do spring. Para que isso seja possível foi necessário permitir nested beans nos arquivos de beans, ou seja, definições de beans dentro de outra definição.
Além de possibilitar a definição de diferentes profiles, essa nova funcionalidade permite que sejam definidos alguns padrões de comportamento para os beans que só se apliquem no conjunto de beans que está nested. Mas isto veremos em um próximo post.
Para testar a definição de profiles direto no XML, vamos criar um outro XML chamado spring31-test-nested-beans.xml:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

profile=“dev”>
class=“br.com.dclick.tentativas.beans.DevEspecificBean” id=“profileBean” />
>

profile=“qa”>
class=“br.com.dclick.tentativas.beans.QAEspecificBean” id=“profileBean” />
>

Feito isso, vamos criar um novo teste que é idêntico ao primeiro, com exceção do arquivo de beans especificado, afinal o comportamento deve ser o mesmo em ambos os casos:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

@Test
public void testProfileDevXml()

GenericXmlApplicationContext ctx = new GenericXmlApplicationContext();
ctx.getEnvironment().setActiveProfiles(DEV_PROFILE);
ctx.load(“classpath:spring31-test-nested-beans.xml”);
ctx.refresh();

// Profile de DEV
ProfileEspecificBean profileBean = ctx.getBean(“profileBean”,
ProfileEspecificBean.class);

Assert.assertEquals(DEV_PROFILE, profileBean.recoverActiveProfile());

@Test
public void testProfileQAXml()

GenericXmlApplicationContext ctx = new GenericXmlApplicationContext();
ctx.getEnvironment().setActiveProfiles(QA_PROFILE);
ctx.load(“classpath:spring31-test-nested-beans.xml”);
ctx.refresh();

// Profile de QA
ProfileEspecificBean profileBean = ctx.getBean(“profileBean”,
ProfileEspecificBean.class);

Assert.assertEquals(QA_PROFILE, profileBean.recoverActiveProfile());

Sua barra do JUnit vai ficar verde e você vai ficar feliz com essa brincadeira rápida com profiles.

Ativando Profiles de outras maneiras

Ativa os profiles no código funciona muito bem no caso dos testes, mas o que realmente se aplica a vida real é poder ativar tais profiles de maneira independente da aplicação e do código propriamente dito. Por isso podemos ativar os profiles setando uma variável global chamada spring.profiles.active.
Podemos ativar tal variável de diversas maneiras, dentre elas no próprio web.xml como um parâmetro da sua Servlet do Spring:

1
2
3
4
5
6
7
8

>
-name>dispatcher-name>
-class>org.springframework.web.servlet.DispatcherServlet-class>
-param>
-name>spring.profiles.active-name>
-value>qa-value>
-param>
>

Podemos usar também JNDI, ou até mesmo uma variável de ambiente da VM Java. Se você preferir também pode ativar profiles diretamente no maven:

1	-Dspring.profiles.active=”profile1,profile2″

Fazendo Download

Se você usa o maven, basta adicionar o seguinte no seu pom:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

>
>
>org.springframework.maven.milestone>
>Spring Maven Milestone Repository>
>http://maven.springframework.org/milestone>
>
>

>
>
>org.springframework>
>spring-core>
>3.1.0.RC1>
>
>
>org.springframework>
>spring-beans>
>3.1.0.RC1>
>
>
>org.springframework>
>spring-context>
>3.1.0.RC1>
>
>

Caso você queira baixar diretamente do site, acesse o site do spring.

Espero ter sido útil, qualquer pergunta basta enviar nos comentários.

Por @Gust4v0_H4xx0r

Ago 9

Spring Security Flex e Java

Escrito por Felipe Borella em 1, 2.0, 4, Adobe, AR, BI, blog, C#, Dica, Documentação, facebook, Flex, Flexmania, IE, int, Java, Mate, O, on, PHP, rest, RIA, Ria’s Geral, S+S, Spring, string, TAT, UI, XP @ 08 9th, 2011 | via http://www.fborella.com.br/blog/ | Sem comentários

Ae pessoas. Blz?

Só estou passando aqui para indicar um material que vale muito a pena para quem integra Java e Flex usando Spring é do FlexMania do Fabiel Prestes.

Segue o link

Só uma pequena dica quanto as annotations isso aqui tambem funciona

@Secured ("ROLE_USER", "ROLE_ADMIN")
public void save(Contact contact);

Pode passar um array de String (by documentação do Spring Security )

Felipe

Share on Facebook

Jul 10

[Flexmania 2011] Planejando e projetando – Dashboad : Flex + Java

Escrito por Erko Bridee em .NET, 1, 2.0, 3.5, 4, 6, action, Adobe, Adobe Flex, Adobe Flex - 3, api, AR, Arquitetura, BI, Blazeds, blog, C#, class, código, dados, Download, err, event, Evento, flash, flash builder, Flex, Flex 3, Flex 4, Flex Mania, Flexmania, git, ide, IE, image, Java, mg, mysql, O, on, Oracle, Palestra, problema, prova, pt, RIA, Ria’s Geral, S+S, screen, servidor, Spring, Tema, Twitter, UI, UX, web @ 07 10th, 2011 | via http://blog.erkobridee.com | Sem comentários

Este ano (2011), tive a oportunidade de participar e palestrar no evento FlexMania, na qual participei com o tema:? Planejando e projetando – Dashboad : Flex + Java.

Onde o objetivo central da minha palestra foi auxiliar a pensar e projetar uma aplicação Dashboad.

Segue os slides da palestra:

Slides da palestra no Flex mania 2011

Código do projeto de prova de conceito apresentado na palestra:

https://github.com/erkobridee/Twitter-Analyzer

Obs.: inclui instruções de como montar o ambiente nos arquivos README, além de disponibilizar um script de criação da base de dados com uma massa de dados inicial. (Atenção o nome da base deve ser: flexmania2011 no MySQL)

Visão da arquitetura da aplicação:

Veja também:

Jul 5

Adobe @ the Museum 2

Escrito por Mauro Martins em .NET, 1, 2.0, 4, 6, Adobe, Adobe User Group, Air, Android, app, AR, AUG, BI, Blazeds, blog, break, C#, class, Desenvolvimento, Desenvolvimento RIA, development, err, event, Evento, Eventos, events, flash, Flash / Flex, flash builder, Flex, for, framework, Frameworks, image, int, Links e sugestões, map, Mate, mg, mobile, O, on, platform, produto, RIA, Ria’s Geral, S+S, site, Spring, tag, UI, User Group @ 07 5th, 2011 | via http://imauro.com/blog/ | Sem comentários

Olá a todos!

Serve este post para vos dar conhecimento do próximo evento da Adobe User Group Porto, o Adobe @ the Museum 2.

O evento vai ter lugar no Museu Soares dos Reis, no dia 16 de Julho, e tem como “estrela” internacional o Mihai Corlan da Adobe.

O Mihai é um Adobe Platform Evangelist para, Flex, AIR, BlazeDS… (podem ver o site dele em http://corlan.org/)

Aqui fica o alinhamento:

10:00 Recepção
10:30 Developing mobile apps for Android, iOS, and PlayBook with AIR and Flex – Mihai Corlan
11:15 Break
11:45 Frameworks de desenvolvimento RIA (Swiz, Mate, Parsley, Spring4AS, RobotLegs) – Rui Silva
12:30 Almoço
14:00 Hands-on: Introduction to mobile development for Android/iOS/PlayBook using Flash Builder, Flex, and AIR (part I) – Mihai Corlan
14:45 Break
15:00 Hands-on: Introduction to mobile development for Android/iOS/PlayBook using Flash Builder, Flex, and AIR (part II) – Mihai Corlan
16:30 A anunciar
17:15 Encerramento

No final ainda vamos sortear uma suite de produtos Adobe, e mais alguns souvenirs!

Se puderem passem a palavra a vossos amigos, colegas etc. e, se se quiserem registar, por favor, façam-no em http://augporto.stagehq.com/events/905

Vai ser uma oportunidade em grande e a não desperdiçar!

Jun 8

Java + JPA + Hibernate + DAO Genérico

Escrito por SamuelFacchinello em 1, 2.0, 3.5, 4, 6, action, Adobe, Adobe Flex, AR, back, Banco de Dados, blog, Blogs, break, busca, C#, catch, class, classe, dados, err, erro, exemplo, finally, Flex, for, framework, Google, Hibernate, html, IE, if, int, Java, JPA, lista, mg, O, on, print, procura, Projetos, pt, reference, RIA, Ria’s Geral, S+S, Spring, string, super(), TAT, Teste, try, UI, update, validação @ 06 8th, 2011 | via http://desenvolvendoemflex.blogspot.com/ | Sem comentários

Olá, hoje vou mostrar como fazer um DAO Genérico no Java (contendo SaveOrUpdate, Remove, FindAll, FindByID) que pode ser usado por todos os DAOs. Facilitando a criação de novos projetos, podendo ser usado com a integração com o Adobe Flex através do RemoteObject.

Isto é para quem não quer usar nenhuma espécie de Framework (ex: Spring, que faz isso de uma forma mais genérica).

Primeiramente criei minha classe contendo todos os métodos (save, update, delete, find), para minha classe ficar “genérica” ao invés de receber as entidades específicas, recebe Object (pode passar as Entidades que o java consegue reconhecer). Após criar esta classe contendo os métodos, é só criar os DAOs extendendo da classe genérica, com isso já terá todos os métodos implementados. Podendo fazer validações específicas para cada DAO.

Vamos a prática:

Este é minha classe genérica contendo todos os métodos.
GenericDAO.java
Leia mais…

Jun 6

Repositórios Dinâmicos Com Spring JPA

Escrito por Fábio Batista da Silva em .NET, 1, 2.0, action, app, AR, auto, BI, busca, buscas, C#, class, classe, CRUD, dados, Documentação, dynamic, email, Flex, geo, git, gmail, html, IE, if, image, int, interface, Java, JPA, map, mg, O, on, procura, rails, reference, RIA, Ria’s Geral, S+S, Sem categoria, Spring, string, tag, TAT, Tecnologia, UI, XML, XP @ 06 6th, 2011 | via http://www.flexria.com.br/home | Sem comentários

Olá.

Escrevendo o post Java + MongoDB + Spring Data descobri o Spring Data JPA
e fiquei surpreso em descobrir algumas features como a criação de repositórios e consultas dinâmicas.
Neste Post vou falar um pouco sobre o Spring Data JPA e como ele pode lhe proporcionar uma maneira rápida e elegante de implementar seus repositórios.

O Spring Data JPA tem como principal objetivo facilitar a implementação das camadas de acesso a dados.
O Spring fica responsável pela implementação dos repositórios e oferece algumas funcionalidades sofisticadas e comuns na maioria dos CRUDs baseado na entidade que esta sendo gerenciada.

Nessa aplicação vou usar as entidades Contact, Phone, e o repositório ContactRepository.

As entidades são bem simples, é anotadas com o mapeamento de seus atributos e relacionamentos.
Contact.java

@Entity
@Table(name="phones")
public class Phone 
  @Id
  @GeneratedValue(strategy = GenerationType.AUTO)
  private Long id;

  @ManyToOne
  @JoinColumn(name="id_contact")
  private Contact contact;
  //getter and setter methods 
  ...

Phone.java

@Entity
@Table(name="contacts")
public class Contact 

   @Id
   @Column(name="id_contact")
   @GeneratedValue(strategy = GenerationType.AUTO)
   private Long id;

   @Column(name="name")
   private String name;

   @Column(name="email",unique=true)
   private String email;

   @OneToMany(mappedBy="contact",cascade=CascadeType.ALL, fetch=FetchType.LAZY)
   @Fetch(FetchMode.JOIN)
   @private Set<Phone> phones = new HashSet<Phone>();

  //getter and setter methods 
  ...

ContactRepository.java

public interface ContactRepository extends JpaRepository<Contact, Long> 

    public Contact findByEmail(String email);

Até aqui nada de novo, porem agora como a “mágica” do Spring JPA ..rsrs

A interface do repositório estende JpaRepository, essa interface tem alguns métodos comuns como findAll, findOne, save, delete, etc…
Normalmente teríamos que implementar essa interface criando uma classe ContactRepositoryImpl e registra-la como um bean do spring
para que então possamos utilizar o repositório.

Com o Spring JPA não é necessário escrever essa implementação ..
Não é magia meus amigos, é tecnologia !!!…rsrs

O Spring JPA vai procurar por interfaces de repositórios que estendam a interface JpaRepository,
e então criar uma implementação para a interface e registra-la como um bean.

Para isso so é necessário apenas adicionar a tag jpa:repositories no contexto do spring,
com isso o Spring sabe onde procurar os repositórios que ele teve implementar.

applicationContext.xml

// Declaração dos Beans, TransactionManager, DataSource, etc...

 base-package="br.com.flexria.springjpa.repository" />

Com isso a implementação do repositório já esta pronta para ser injetada é utilizada na aplicação.

@Autowired
ContactRepository repository;

repository.save(contact);

repository.delete(contact);

List<Contact> list = contactRepository.findAll();

Isso por si so ja é algo incrível so que o Spring Data JPA vai alem.

Algo que ja é comum no Rails, são os Dynamic attribute-based finders que é a possibilidade de realizar buscas dinâmica baseadas nos atributos do objeto
Em rails temos :

//"SQL : SELECT * FROM contacts WHERE email = 'fabio.bat.silva@gmail.com'"

Contact.where(:email =>"fabio.bat.silva@gmail.com")

//Usando Dynamic attribute-based finders
Contact.find_by_email "fabio.bat.silva@gmail.com"

É exatamente isso que o Spring Data JPA faz,
além de implementar do repositório com ele é possível utilizar buscas dinâmica baseadas nos atributos do objeto.

   // HQL : select c from Contact c where c.email = ?1
    public Contact findByEmail(String email);

   // HQL : select c from Contact c where c.name like ?1
    public List<Contact> findByNameLike(String name);