Ainda continua o assunto sobre Visualização de Dados voltado a User Interface que comecei aqui, vamos agora abordar o tema de uma maneira mais simplificada e interessante. É muito comum algumas pessoas ficarem perdidas nesse assunto e ainda por cima não conseguirem avançar no tema sem pensar nos gráficos tradicionais, pizza e bastões. Quero lembrar…
Recentemente percebi que muitos profissionais ainda possuem uma certa dificuldade em entender as tais nomenclaturas do ramo… como UX / UI / IxD / Guideline etc. Mas o que tenho visto de mais comum é o uso do termo Guideline para referenciar a User Interface, UI. É fato que a diferença entre ambos na idéia…
? Android: o retorno da série. Um bom tempo após o primeiro tutorial sobre android (? http://www.dclick.com.br/2011/02/24/android-configuracoes-iniciais-e-hello-world/? ), estou de volta, e desta vez com 14 screencasts sobre os mais variados temas em desenvolvimento para esta plataforma que cresce espantosamente a cada dia. O conteúdo destes screencasts, que abordam temas como: ? Activity LifeCycle, Alerts, User Interface, Intents, Lists,…
Recentemente um amigo e ex aluno Rafael Daron? me pediu indicações de User Interfaces para inspirá-lo em seu novo projeto para a nuvem, citou-me que estava observando o Windows 8 e aplicações como Prezi para ter referências. E a pergunta dele me chamou bastante atenção, e a resposta me inspirou esse post. O motivo é bem…
O Visual Studio 2010 tem diversos recursos que estão muito bem escondidos nos seus vários menus e telas de configuração, mas são acessíveis por teclas de atalho. Isso é vantajoso em diversas situações pois pode agilizar a utilização desses recursos mas também pode se tornar uma irritação ou mesmo um problema se você por acaso acionar uma dessas teclas de atalho por acidente e não souber como voltar atrás. Foi o que aconteceu com um colega no trabalho recentemente.
Por acidente esse colega acionou uma tecla de atalho do Visual Studio 2010 que ativa a exibição de caracteres ocultos (white space). Em outras palavras, o Visual studio passou a exibir todos os espaços e marcação de final de arquivo na tela. O resultado foi algo semelhante ? imagem abaixo:
Não parece ser algo muito irritante neste exemplo pois há pouco código, mas em arquivos com centenas de linhas de código e em arquivo com html esse modo de visualização é bastante irritante e chega a atrapalhar a produtividade pois polue visualmente a tela. Esse colega passou quase 2 meses trabalhando com essa configuração pois não conseguia encontrar um meio de desfazer e voltar ao modo normal de visualização. Ele chegou inclusive a reinstalar o Visual Studio mas não adiantou pois o instalador não removeu as configurações problematicas.
Hoje eu dei uma pesquisada um pouco mais a fundo e acabei encontrando a solução. A opção do menu para essa configuração se encontra em Edit > Advanced > View White Space e pode ser acionada pela tecla de atalho Ctrl+E, S (que foi o que aconteceu com meu colega).
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.
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; /** This class and the MVC approach associated with it is discussed in Chapter 12 of View implementations may differ widely. An obvious implementation would be Views should be beans. They are likely to be instantiated as beans by a ViewResolver. /** Note: This attribute is not required to be supported by all
/** Can be used to check the content type upfront, if not predetermined. /** The first step will be preparing the request: In the JSP case, in case of empty model) } |
Todo o código e JavaDoc está no projeto do Spring.
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 |
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”) } |
Agora temos uma servlet que responderá por “
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”> > > > |
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 |
> |
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 |
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 |
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” } |
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
Não existe segredo quando se fala da implementação de datas no Java: é ruim de usar. Alguns chegam a dizer que é errado usar inclusive, mas não serei tão extremo.
A API de datas do Java é ruim por vários motivos, como por exemplo, é mal documentada, não é Thread Safe, é difícil de manipular datas, e o comportamento nem sempre é o esperado.
Vamos ver como susbtituir a API de datas que vem Out of the Box no Java, por uma mais efetiva, amigável e confiável: JodaTime.
Todo programador Java conhece o Calendar, e sabe que para usá-lo, basta seguir o Design Pattern singleton, ou seja, basta chamar o método de classe em Calendar que devolve a instância única do sistema para o Calendar.
Problema: não funciona.
Não funciona porque se a instância é singleton, e não utiliza threadlocking no código, então não é uma instância ThreadSafe. Logo toda vez que chamamos o getInstance() do Calendar, obtemos uma nova instância. Para ilustrar, crie um teste em JUnit 4 com o seguinte código:
|
1
2 3 4 5 6 7 |
Rode o teste e veja a barra do JUnit ficar vermelha. O comparador ‘==’ usado em objetos, compara pelo endereço de memória, o que deveria ser o mesmo se fosse seguido o padrão singleton de verdade.
Pra piorar, todos os métodos que alteram as intâncias do Date estão expostos (por mais que estejam depreciados) para mantêr compatibilidade com versões anteriores da VM. Portanto o Date também não é ThreadSafe, pois não existe controle de concorrência em sua implementação.
Agora vamos deixar o Date e o Calendar de lado, e vamos ao JodaTime.
O JodaTime diferencia muito bem os conceitos de data, instante de tempo, período, etc. A classe mais básica (interface no caso) é a ReadableInstant. Não precisa dizer que todas as modelagens de data implementam essa interface, permitindo comparar todos os tipos de modelagem de tempo pontuais. Um período não descreve um único instante ou ponto no tempo, por exemplo.
DateTime é talvez o ReadableInstant mais conhecido, e funciona muito parecido com o Date do Java.
Fatores que tornam o DateTime mais amigável são: é ThreadSafe pois é imutável, é muito bem documentado, e é muto fácil realizar operações com data. Vamos escrever um pouco de código para entender o que se passa.
Comece criando um DateTime. Como no Java, este DateTime criado possui o instante atual do sistema. Em seguida para efeito de teste (o teste pode falhar dependendo de quando for executado), adicione um dia na data criada, e verifique que o novo date aponta para amanhã:
|
1
2 3 4 5 |
DateTime date = new DateTime();
date = date.plusDays(1); Assert.assertEquals(new DateTime().getDayOfYear() + 1, date.getDayOfYear()); |
Repare que tive que reassociar o date para que ele pudesse ser alterado, afinal DateTime é imutável, o mesmo comportamento que o BinInteger possui. Repare também que pra adicionar um dia, basta chamar plusDays. Este método já se encarrega de fazer toda a lógica de adicionar um dia na data, como por exemplo mudar o mês ou ano se for preciso, por isso se esse teste for rodado no dia 31 de dezembro, ele irá falhar pois o DateTime irá adicionar mais um dia a data, e perceberá que se trata do ano seguinte, e portanto getDayOfYear irá devolver ’1′, e não ’366′ ou ’365′ como esperado.
O JodaTime também trata anos bissestos e horário de verão se for selecionado o fuzo correto.
Existe uma API bem completa em DateTime para manipular todos os campos possíveis da data, sendo assim fica muito mais fácil iterar ao longo dos dias, sem precisar delegar pro Calendar a tarefa, e depois recuperar o resultado.
Não vou abordar muito da API do JodaTime, pois está muito bem documentada e existem muitos exemplos nas internet. O objetivo desse post é tratar do assunto do próximo tópico.
Pior que manipular datas, é persistir datas. Cada banco persiste data do seu próprio jeito, e cada implementação de ORM trata o Date do seu próprio jeito. Mas se você está utilizando o Hibernate, o JodaTime tem uma solução de padronização pra você: JodaTime Hibernate.
Com o JodaTime Hibernate é possível mapear diversos tipos de representação de data em suas classes Java, com ou sem TimeZone, como String ou bigint, como período ou duração, etc.
Para se ter uma idéia do que é possível, basta verificar a documentação online.
E para utiliza é muito fácil. Imagine que você tenha uma entidade com um campo DateTime, que se chama entryDate, portanto temos o getter:
|
1
2 3 4 |
@Column(nullable = false)
public DateTime getEntryDate() return entryDate; |
Para tornar este DateTime uma data que é padrão do banco que será utilizado, por exemplo, basta adicionar a seguinte anotação:
|
1
2 3 4 5 |
@Column(nullable = false)
@Type(type = “org.joda.time.contrib.hibernate.PersistentDateTime”) public DateTime getEntryDate() return entryDate; |
Estamos falando para o hibernate utilzar o tipo de coluna descrito pelo PersistentDateTime, e utilizar o mesmo para converter a data novamente para DateTime quando for recuperado.
Caso você esteja fazendo engenharia reversa de algum banco, recomendo ler a descrição de todos os tipo disponíveis pra fazer a melhor escolha.
Com isso conseguimos obter todos os benefícios do JodaTime em nossas entidades, facilitando controlar as datas no domínio de nossas aplicações.
Espero ter despertado sua curiosidade com o JodaTime. Na minha opinião é uma das melhores bibliotecas Java disponíveis, mas não quero falar muito sobre suas funcionalidades, pois um dos pontos mais fortes da biblioteca é a facilidade de se acostumar com ela, e principalmente utilizar todos seus recursos. Quero que vocês tenham um pouco desse gostinho 
.
Por @Gust4v0_H4xx0r
No dia 18/11 aconteceu o flash mobile day edição são luis no auditório do cecen – UEMA.
Eu particularmente estou muito satisfeito com o evento, tivemos grandes palestras com conteúdo de alto nível.
Tivemos problemas durante a manhã pois estávamos sem internet para a transmissão das palestras, porém, o evento aconteceu normalmente presencialmente.
As 4 palestras envolveram as áreas de design, programação e marketing. Bom, foi muito show.
A seguir segue o link das apresentações:
Palestra: Design de interfaces para aplicativos móveis.
Palestrante: Eduardo Gibran
Link: http://dl.dropbox.com/u/16067185/palestras_fmd/desingDeInterfaces-Gibran.pdf
Palestra: Proceso de criação. Da escolha da plataforma ? app store.
Palestrante: Willian Mano
Link: http://dl.dropbox.com/u/16067185/palestras_fmd/processoDeCriacao-Willian.pdf
Palestra: Flex para dispositivos móveis
Palestrante: Bruno Araújo
Link: http://prezi.com/klmt7jez4lfv/o-poder-do-flex-para-dispositivos-moveis/
Palestra: Marketing de guerrilha, ações virais e dispositivos móveis: o real e o virtual nas suas mãos.
Palestrante: Rafaela Marques
Link: http://dl.dropbox.com/u/16067185/palestras_fmd/marketing-Rafaela.pdf
Mais uma vez obrigado ? todos que ajudaram para que esse evento fosse possível.
Um gradecimento especial ? todos que apoiaram o evento, em especial ? RIACYCLE que através do Igor Costa nos ajudou a abrilhantar um pouco mais esse evento.
Obrigado a RINO, que, através do Odair Seixas no permitiu realizar essa versão aqui nas terras longiquas de São Luis do Maranhão.
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.
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 |
> > |
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.
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 > cc lang=”XML” public interface CacheableTest @CacheEvict(value = “property”, allEntries = true) @Cacheable(“property”) 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) public String getProperty() public void setProperty(String property) public void evictCache() |
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 ApplicationContext ctx = new ClassPathXmlApplicationContext( CacheableTest bean = ctx.getBean(“cacheBean”, CacheableTest.class); bean.setProperty(“teste”); Assert.assertEquals(“teste”, bean.getProperty()); bean.setProperty(“teste2″); bean.setProperty(“teste3″); bean.evictCache();
} |
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.
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
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.
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.
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 |
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 |
|
1
2 3 4 5 6 7 8 9 10 11 12 |
|
1
2 3 4 5 6 7 8 9 10 11 12 |
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: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”> > |
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 GenericXmlApplicationContext ctx = new GenericXmlApplicationContext(); // Profile de DEV Assert.assertEquals(DEV_PROFILE, profileBean.recoverActiveProfile()); @Test GenericXmlApplicationContext ctx = new GenericXmlApplicationContext(); // Profile de QA 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.
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 |
<?xml version=“1.0″ encoding=“UTF-8″?>
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”> > |
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(); // Profile de DEV Assert.assertEquals(DEV_PROFILE, profileBean.recoverActiveProfile()); @Test GenericXmlApplicationContext ctx = new GenericXmlApplicationContext(); // Profile de QA 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.
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 |
-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″
|
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 |
> > |
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
