Demoiselle Framework's Blog

26/12/2011

Configuração de conexão com base de dados (DataSources) no JBoss AS.

Filed under: Demoiselle,jboss6,JPA,Persistence,Persistence — esaito @ 18:52

Percebemos que esta é uma dúvida comum para os desenvolvedores que usam o Demoiselle e que vamos esclarecer um pouco agora.

Como já é bem conhecido, a partir da versão 2 do Demoiselle o padrão para interfaceamento com base de dados é a especificação JPA2. O desenvolvedor quando faz uso do Demoiselle 2 percebe que a recomendação e padrão para a configuração de conexão com banco de dados no arquivo persistence.xml (JPA), têm sido através do uso do recurso do Servidor de aplicações (no caso o JBoss) conhecido como DataSource. Um “DataSource” é um mecanismo com o qual o servidor de aplicações, gerencia o acesso a uma conexão com o banco de dados. Se a aplicação utilizará um servidor de aplicações como o JBoss, nada é mais prático e seguro que usar o recurso que já está disponível e otimizado para esse ambiente. Além disso alguns outros recursos como por exemplo um pool de conexões, são bem mais simples de se configurar. Além disso, em organizações departamentalizadas, onde os ambientes de desenvolvimento, homologação e produção são separados, as configurações de conexão de bancos de dados ficam a cargo de cada um dos setores, o que é positivo para questões como segurança por exemplo.

Mas enfim, o objetivo do post não é justificar ou embasar o uso do recurso, e sim mostra como isso pode ser feito.

Antes de mais nada, partimos do pressuposto que estamos trabalhando como uma aplicação criada pelo arquétipo demoiselle-jsf-jpa (http://demoiselle.sourceforge.net/repository/archetype-catalog.xml). Outra premissa é que a versão do JBoss-AS seja no máximo a 6.1 (http://community.jboss.org/wiki/AS610FinalReleaseNotes) pois a partir da versão 7.0 a configuração é um pouco diferente e será tópico de outro post.

Após criada a aplicação na IDE Eclipse (veja como fazer isso em http://demoiselle.sourceforge.net/docs/quickstart/2.0.4/html/ ), devemos localizar o arquivo src/main/resources/META-INF/persistence.xml.

Listando o arquivo persistence.xml, podemos verificar os trechos:

<!– If you are using jboss6 with non JTA transaction then use this persistence-unit –>

<!–

–>

<persistence-unit name=“bookmark-ds” transaction-type=“RESOURCE_LOCAL”>

<non-jta-data-source>java:/DefaultDS</non-jta-data-source>

<class>br.org.frameworkdemoiselle.bookmark.domain.Bookmark</class>

<properties>

<property name=“hibernate.show_sql” value=“true” />

<property name=“hibernate.format_sql” value=“false” />

<property name=“hibernate.hbm2ddl.auto” value=“create-drop” />

<property name=“hibernate.transaction.manager_lookup_class” value=“org.hibernate.transaction.JBossTransactionManagerLookup” />

</properties>

</persistence-unit>

<persistence-unit name=“bookmark-ds” transaction-type=“JTA”>

<jta-data-source>java:/DefaultDS</jta-data-source>

<class>br.org.frameworkdemoiselle.bookmark.domain.Bookmark</class>

<properties>

<property name=“hibernate.show_sql” value=“true” />

<property name=“hibernate.format_sql” value=“false” />

<property name=“hibernate.hbm2ddl.auto” value=“update” />

<property name=“hibernate.transaction.manager_lookup_class” value=“org.hibernate.transaction.JBossTransactionManagerLookup” />

</properties>

</persistence-unit>

As linhas que nos interessam agora são:

<non-jta-data-source>java:/DefaultDS</non-jta-data-source>

e

<jta-data-source>java:/DefaultDS</jta-data-source>

Neste post não comentaremos sobre a JTA (http://www.oracle.com/technetwork/java/javaee/jta/index.html), mas resumindo a instrução das tag em poucas palavras: non-jta-data-source significa que as transações NÃO serão gerenciadas pelo servidor de aplicações, mas as configurações de conexão serão tratadas (ex: usuário, senha, endereço do servidor de banco de dados) conforme o DataSource. Já a jta-data-source todo o gerenciamento será feito pelo servidor de aplicações. Note que há uma instrução: java:/DefaultDS,  isso tem relação com o que está configurado diretamente no servidor de aplicações. Obviamente só podemos definir um tipo de conexão JTA no arquivo de configuração persistence.xml. Para o nosso exemplo a escolha será a jta-data-source.

Dentro da aplicação, isso é tudo que precisamos saber. Sobre as outras tags do persistence.xml você encontrará informações na especificação JPA ou na documentação dos provedores de implementação (ex: Hibernate, EclipseLink). No caso do nosso exemplo, estão sendo utilizadas tags para o Hibernate que é a implementação padrão que já vem com o servidor JBoss.

Agora podemos explorar a configuração no servidor.

Neste exemplo, estamos usando o JBoss 6, mas as configurações e locais são os mesmos para as versões anteriores. Encontre o diretório de Deploy do servidor, para quem utiliza os pacotes do projeto Infra será por exemplo: /opt/demoiselle/server/jboss-6.0/server/default/deploy/ ou para quem está usando cluster: /opt/demoiselle/server/jboss-6.0/server/all/deploy

Neste diretório encontraremos o arquivo hsqldb-ds.xml.

O conteúdo do arquivo descreve uma configuração para o banco de dados Hsqldb (http://hsqldb.org/), que contém a localização do banco, o usuário, senha de acesso e outras informações importantes para a conexão. A informação que nos interessa é a tag:

<jndi-name>DefaultDS</jndi-name>

Essa tag é que está relacionada à instrução que encontramos na aplicação que foi criada anteriormente:

<jta-data-source>java:/DefaultDS</jta-data-source>

Essa relação é estabelecida por Java Naming and Directory Interface (JNDI http://www.oracle.com/technetwork/java/jndi/index.html ), portanto é esse “nome” (no exemplo: DefaultDS) que relaciona a configuração da aplicação à do servidor de aplicações. Quando o servidor de aplicações encontra esse tipo de arquivo faz automaticamente essa conexão. Especificamente no JBoss, podemos ver a instrução na console quando o servidor é iniciado:

INFO  [ConnectionFactoryBindingService] Bound ConnectionManager ‘jboss.jca:service=DataSourceBinding,name=DefaultDS’ to JNDI name ‘java:DefaultDS’

Assim, a aplicação gerada pelo arquétipo Demoiselle, faz somente a relação com uma configuração que já é provida por padrão pelo servidor JBoss. Não sendo portanto necessário nenhuma intervenção do desenvolvedor para utilizar essa conexão na aplicação.

Com isso, desvendamos a forma como a aplicação de exemplo do arquétipo Demoiselle utiliza-se do recurso JTA pré-definido no servidor JBoss.

Na prática, não será tão comum utilizar essa configuração padrão, pois é mais habitual que o gerenciador de bando de dados esteja em outro equipamento ou em uma arquitetura mais complexa como um cluster por exemplo. E também há vários gerenciadores de bancos de dados disponíveis no mercado.

Como última dica deste texto, vamos exemplificar a configuração da aplicação para um banco de dados PostgreSQL.

Vamos considerar que o servidor de banco de dados já exista, assim como um usuário de testes.

Para nos ajudar, o JBoss-AS nos oferece um conjunto de exemplos pré-configurados para uma lista de servidores de banco de dados conhecidos no mercado. Estes arquivos podem ser encontrados no diretório de documentos da instalação (/docs/jca). No nosso exemplo usaremos o: /opt/demoiselle/server/jboss-6.0/docs/examples/jca/postgres-ds.xml. Listado abaixo:

<?xml version=“1.0″ encoding=“UTF-8″?>

<!– ===================================================================== –>

<!– –>

<!– JBoss Server Configuration –>

<!– –>

<!– ===================================================================== –>

<!– See http://www.jboss.org/community/wiki/Multiple1PC for information about local-tx-datasource –>

<!– $Id: postgres-ds.xml 97536 2009-12-08 14:05:07Z jesper.pedersen $ –>

<!– ==================================================================== –>

<!– Datasource config for Postgres –>

<!– ==================================================================== –>

<datasources>

<local-tx-datasource>

<jndi-name>PostgresDS</jndi-name>

<connection-url>jdbc:postgresql://[servername]:[port]/[database name]</connection-url>

<driver-class>org.postgresql.Driver</driver-class>

<user-name>x</user-name>

<password>y</password>

<!– sql to call when connection is created. Can be anything, select 1 is valid for PostgreSQL

<new-connection-sql>select 1</new-connection-sql>

–>

<!– sql to call on an existing pooled connection when it is obtained from pool. Can be anything, select 1 is valid for PostgreSQL

<check-valid-connection-sql>select 1</check-valid-connection-sql>

–>

<!– corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) –>

<metadata>

<type-mapping>PostgreSQL 7.2</type-mapping>

</metadata>

</local-tx-datasource>

</datasources>

Aproveitando esse arquivo base, podemos definir e alterar o arquivo para o seguinte exemplo:

<?xml version=“1.0″ encoding=“UTF-8″?>

 <datasources>

<local-tx-datasource>

<jndi-name>bookmarkPostgresqlDS</jndi-name>

<connection-url>jdbc:postgresql://10.0.0.1:5432/bookmark</connection-url>

<driver-class>org.postgresql.Driver</driver-class>

<user-name>bookmark</user-name>

<password>bookmark</password>

<min-pool-size>5</min-pool-size>

<max-pool-size>30</max-pool-size>

<idle-timeout-minutes>0</idle-timeout-minutes>

<track-statements/>

<prepared-statement-cache-size>32</prepared-statement-cache-size>

<new-connection-sql>select 1</new-connection-sql>

<check-valid-connection-sql>select 1</check-valid-connection-sql>

<metadata>

<type-mapping>PostgreSQL 8.0</type-mapping>

</metadata>

</local-tx-datasource>

</datasources>

Esse arquivo deverá ser armazenado no mesmo diretório de Deploy onde localizamos o arquivo hsqldb-ds.xml.

Em seguinda devemos alterar a configuração no arquivo para se referenciar a nova configuração persistence.xml para:

<jta-data-source>java:/BookmarkPostgresqlDS</jta-data-source>

Outra coisa ser conferida é o arquivo beans.xml (em /src/main/resources/),

É provável que esteja assim:

<alternatives>
<class>br.gov.frameworkdemoiselle.transaction.JPATransaction</class>

<!–
<class>br.gov.frameworkdemoiselle.transaction.JTATransaction</class>
–>
</alternatives>

Certifique-se que a classe ativa seja a JTATransaction, ficando assim:

<alternatives>
<class>br.gov.frameworkdemoiselle.transaction.JTATransaction</class>
</alternatives>

A última providência, é a lib do driver do banco de dados que estamos utilizando, neste link estão os drivers do PostgreSQL:

http://jdbc.postgresql.org/download.html

Para que a estratégia JTA funcione corretamente, o driver deverá ser incluído diretamente no servidor, assim como é com o datasource, no seguinte diretório:

/opt/demoiselle/server/jboss-6.1/lib/

Com estas alterações a aplicação passará a utilizar o PostgreSQL ao invés do Hsqldb.

Poderíamos utilizar o mesmo nome JNDI: DefaultDS, no lugar de BookmarkPostgresqlDS, e dessa forma não precisar alterar a configuração na aplicação. Mas neste caso teríamos que excluir o arquivo hsqldb-ds.xml, ou alterar a tag <jndi-namepara outro nome. Pois não é possível ter o mesmo JNDI-Name.

Obviamente que cada Gerenciador de Banco de Dados pode ter alguma particularidade com relação à configuração do DataSource, mas geralmente é tarefa do Administrador de Banco de dados ou a área de produção. E mesmo que tudo esteja por conta do desenvolvedor, ainda assim é mais simples do que manter toda a configuração na aplicação.

19/08/2011

Demoiselle 2 com Netbeans e Tomcat

Filed under: Environment — Robson Gian Perassoli @ 16:23
Tags: ,

Demoiselle Framework é construído a partir do conceito de framework integrador, integrando diversas ferramentas utilizadas no mercado Java. Tem como objetivo facilitar o desenvolvimento de aplicações, privando o desenvolvedor de perder tempo escolhendo os frameworksespecialistas que serão usados no seu projeto, resultando grande aumento da produtividade, e facilita a manutenção dos sistemas. Possui mecanismos facilitadores voltados à resolução dos problemas mais comum em uma aplicação, entre eles estão arquitetura, segurança e configuração.

framework contém uma estrutura não monolítica, ou seja, as funcionalidades estão separadas do núcleo principal, esta forma de organização permite que aplicações específicas não necessitem compor dependências que não serão usadas.

A estrutura do Demoiselle é dividida em Core, que contém as funcionalidades que são comuns a todas aplicações, é a base, o núcleo propriamente dito. Extensões por sua vez são funcionalidades extras extremamente ligadas ao núcleo, porém específicas a um domínio, como é o caso de JPA e JSF, pois algumas aplicações não fazem uso de persistência, não fazendo sentido estar no núcleo. Por fim os Componentes, que são artefatos independentes do núcleo, não precisam estender as funcionalidades do core, têm ciclo de vida próprio, não precisa necessariamente fazer uso do Demoiselle.

Para o gerenciar o projeto é utilizado o Apache Maven, não estando preso a este. Porém uma das vantagens de usar o Maven é a possibilidade de usar os arquétipos, que são modelos de aplicações.

A execução do projeto foi feita utilizando a IDE Netbeans 7.0, justamente pelo maior suporte ao Maven, que nas versões anteriores não é tão completo. Pode ser que funcione com versões anteriores, mas os recursos do maven serão mais precários.

Nosso projeto usará um arquetipo de uma aplicação JSF com JPA. Este arquétipo contém uma aplicação simples de bookmark (links favoritos). A partir desta simples aplicação é possível entender os principais conceitos do Demoiselle.

Agora vamos ao que interessa!!! No Netbeans clique em Novo Projeto, na Categoria Maven selecione Projeto do Arquetipo.  Clicando em próximo você visualizará uma tela com vários arquetipos que estão disponíveis nos repositórios do Maven. o Arquetipo do demoiselle não está nestes repositórios. Clique em Adicionar para inserir um arquetipo externo. Os arquétipos disponibilizados pela aquipe do demoiselle estão disponíveis aqui. Os dados abaixo são referentes ao arquetipo demoiselle-jsf-jpa.

groupId: br.gov.frameworkdemoiselle.archetypes
artifactId: demoiselle-jsf-jpa
version: 2.1.2
repository: http://demoiselle.sourceforge.net/repository/release

Selecione o arquétipo criado e clique em próximo. Após informar os dados do projeto clique em Finalizar. Nesta etapa o maven irá indexar os repositórios e baixará as dependências necessárias para o projeto. Pegue um café, pois este processo demora certo tempo.

Após criar o projeto e baixar as dependências, são necessárias algumas configurações para que seja possível rodar o projeto no Tomcat. Para este tutorial foi usado o Tomcat 7 pois é a versão mais nova e que atende maior quantidade de recursos do JEE 6. Podendo não funcionar em versões anteriores.

Primeiramente devemos escolher a configuração do projeto no netbeans, selecione tomcat7 no checkbox que está localizado próximo ao botão executar na barra de ferramentas .

Após isso habilitaremos o listener do Weld (framework para CDI) no arquivo web.xml, devendo ser adicionado o seguinte conteúdo:

<listener>
    <listener-class>org.jboss.weld.environment.servlet.Listener</listener-class>
</listener>

Provavelmente este trecho apenas estará comentado, bastando apenas remover os comentários.

O próximo arquivo a ser alterado é o persistence.xml, que está localizado na pasta Outros códigos-fonte, em META-INF. Novamente nossa Persistence Unit (Unidade de persistência JPA) estará comentada, descomente a Persistence unit que está localizada abaixo do seguinte comentário: <!–If you are using tomcat6/tomcat7 then use this persistence-unit–>. Esta é a única persistence unit que deve estar neste arquivo.

O arquivo deve ficar com o seguinte conteúdo:

<persistence-unit name="bookmark-ds" transaction-type="RESOURCE_LOCAL">

    <class>com.mycompany.teste.domain.Bookmark</class>

    <properties>
        <property name="javax.persistence.jdbc.driver" value="org.hsqldb.jdbcDriver" />
        <property name="javax.persistence.jdbc.user" value="sa" />
        <property name="javax.persistence.jdbc.password" value="" />
        <property name="javax.persistence.jdbc.url" value="jdbc:hsqldb:hsql:." />

        <property name="eclipselink.logging.level" value="FINE" />
        <property name="eclipselink.ddl-generation" value="create-tables" />
        <property name="eclipselink.ddl-generation.output-mode" value="database" />
    </properties>
</persistence-unit>

Na mesma pasta devemos alterar o arquivo beans.xml, para ativar a estratégia de transação JPA do Demoiselle. Deixe apenas uma linha contendo a seguinte entrada:

<alternatives>
    <class>br.gov.frameworkdemoiselle.transaction.JPATransaction</class>
</alternatives>

Após estas configurações o projeto estará apto a rodar, o arquétipo vem configurado com uma base de dados padrão que é iniciada com o projeto.  O banco de dados utilizado é o HSQLDB.

Para compilar o projeto execute Shift+F11 ou Limpar e Construir, após finalizado este processo você verá no final do console a saída ‘BUILD SUCCESS’. Agora você pode executar seu projeto usando F6 ou Executar. Quando for clicado em executar aparecerá uma mensagem pedindo o servidor onde será executado o projeto. Selecione o Tomcat 7, e marque em lembrar permanentemente.

Sempre que você executar o projeto é indicado que você pare o servidor Tomcat. Pois quando o projeto é compilado, o maven altera alguns arquivos que estão em uso pelo servidor. Gerando um erro de compilação.

Para alterar a base de dados é possível alterar o persistence.xml com as configurações que desejadas e adicionar a dependência do driver JDBC que você quer usar.

Caso haja interesse de interagir com a comunidade demoiselle, acesse o site, onde você pode se inscrever na lista de discussão, o pessoal do demoiselle está sempre ajudando os iniciantes através deste meio. O Demoiselle e sua comunidade estão de parabéns.

Fontes:
Framework Demoiselle 2.0: Guia de Referência: <http://demoiselle.sourceforge.net/docs/reference/2.0-v6/pdf/demoiselle-reference.pdf>

Este artigo foi publicado também no meu blog que pode ser acessado aqui.

06/07/2011

Pretty URL com JSF 2 e Demoiselle 2

Filed under: Demoiselle — Cleverson Sacramento @ 8:48
Tags: ,

http://ocpsoft.com/prettyfaces

Quem aí sabe o que é pretty url, também conhecido como simple url? Há quem chame de url rewrite. Tanto faz! O que importa mesmo é para que serve. Se você não sabe, não deixe de ler este post completo. Se você sabe do que se trata, vou mostrar como implementar na sua aplicação web com JSF 2 e Demoiselle 2.

Recentemente precisei utilizar pretty urls em um projeto com JSF 2 e Demoiselle 2. Então comecei mais uma longa jornada de experimentar diversas soluções do mercado. Achei uma muito prática e simples de usar. Ops… vamos com calma! Que diacho é pretty url?

Ao acessar o Twitter você está usando pretty urls, olha só: http://twitter.com/zyc. Ao escrever “/zyc”, você vai diretamente para a página do usuário “zyc”. Olha outro exemplo: http://americanas.com.br/produto/7107451. Agora que você sabe o que é, vai perceber que é muito comum na Internet. Quer fazer isto na sua aplicação?!

No exemplo utilizei o framework Demoiselle 2 para facilitar minha vida, mas funcionaria em qualquer aplicação com JSF puro também. Criei a aplicação com base no post Iniciando com o Demoiselle 2.0. Com o Maven gerei o projeto a partir do arquétipo demoiselle-jsf-jpa (versão 2.1.0).

Utilizando o arquétipo demoiselle-jsf-jpa

Ao final do processo, minha aplicação estava pronta. O Demoiselle criou o projeto contendo um caso de uso modelo: o bookmark. Trata-se de uma listagem básica e edição dos registros. Ao acessar a página de listagem, a url no navegador finaliza assim: /bookmark_list.jsf. Mas eu gostaria que fosse simplesmente assim: /bookmark. A tela de edição está assim: /bookmark_edit.jsf?id=1. Quero que fique assim: /bookmark/1.

É óbvio que não implementei na mão! Pesquisei e achei várias soluções. As que mais gostei foram: Url Rewrite Filter e PrettyFaces. Optei pela PrettyFaces por quatro motivos: (1) a documentação está muito bem elaborada; (2) o código-fonte está hospedado no GitHub, o que facilita a evolução do projeto; (3) está mais bem integrado com o Maven e; (4) funciona redondamente com JSF.

Abri o arquivo pom.xml do meu projeto e inclui a seguinte dependência:

<dependency>
	<groupId>com.ocpsoft</groupId>
	<artifactId>prettyfaces-jsf2</artifactId>
	<version>3.3.0</version>
</dependency>

No web.xml declarei o filtro (opcional para JSF 2):

<filter>
	<filter-name>Pretty Filter</filter-name>
	<filter-class>com.ocpsoft.pretty.PrettyFilter</filter-class>
</filter>
<filter-mapping>
	<filter-name>Pretty Filter</filter-name>
	<url-pattern>/*</url-pattern>
	<dispatcher>FORWARD</dispatcher>
	<dispatcher>REQUEST</dispatcher>
	<dispatcher>ERROR</dispatcher>
</filter-mapping>

Criei o arquivo pretty-config.xml na pasta WEB-INF com o seguinte conteúdo:

<pretty-config xmlns="http://ocpsoft.com/prettyfaces/3.3.0"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://ocpsoft.com/prettyfaces/3.3.0 http://ocpsoft.com/xml/ns/prettyfaces/ocpsoft-pretty-faces-3.3.0.xsd">

	<rewrite match="^/(.*)/$" substitute="/$1" redirect="301" />

	<url-mapping id="index">
		<pattern value="/" />
		<view-id value="/index.jsf" />
	</url-mapping>

	<url-mapping id="bookmark-list">
		<pattern value="/bookmark" />
		<view-id value="/bookmark_list.jsf" />
	</url-mapping>

	<url-mapping id="bookmark-new">
		<pattern value="/bookmark/new" />
		<view-id value="/bookmark_edit.jsf" />
	</url-mapping>

	<url-mapping id="bookmark-edit">
		<pattern value="/bookmark/#{id}" />
		<view-id value="/bookmark_edit.jsf" />
	</url-mapping>
</pretty-config>

Utilizei a tag <rewrite> para remover as barras no final da url, caso exista. O primeiro mapeamento define que ao acessar a raiz, a página index.jsf atenderá a requisição. O segundo define a tela de listagem. O terceiro a edição.

Removi o arquivo index.html do projeto e fiz as seguintes modificações no bookmark_list.xhtml:

<!--
<p:commandButton title="#{messages['button.new']}" image="ui-icon-document" action="#{bookmarkListMB.getNextView}"
	actionListener="#{bookmarkListMB.clear}" ajax="false" />
-->

<p:commandButton title="#{messages['button.new']}" image="ui-icon-document" action="pretty:bookmark-new"
	actionListener="#{bookmarkListMB.clear}" ajax="false" />

Ainda no bookmark_list.xhtml, substituí a tag <h:commandLink> por <h:link> para possibilitar a passagem do parâmetro id através de query string:

<!--
<h:commandLink action="#{bookmarkListMB.getNextView}" actionListener="#{bookmarkListMB.clear}">
	<h:outputText value="#{bean.description}" />
	<f:param name="id" value="#{bean.id}" />
</h:commandLink>
-->

<h:link outcome="#{bookmarkListMB.nextView}" value="#{bean.description}">
	<f:param name="id" value="#{bean.id}" />
</h:link>

Modifiquei as anotações da classe BookmarkListMB para retornar o padrão bonito:

@ViewController
//@NextView("/bookmark_edit.xhtml")
//@PreviousView("/bookmark_list.xhtml")
@NextView("pretty:bookmark-edit")
@PreviousView("pretty:bookmark-list")
public class BookmarkListMB extends AbstractListPageBean {
	...
}

E o mesmo para o controlador BookmarkEditMB da tela de edição:

@ViewController
//@PreviousView("/bookmark_list.xhtml")
@PreviousView("pretty:bookmark-list")
public class BookmarkEditMB extends AbstractEditPageBean {
	...
}

Por fim, fiz deploy no JBoss AS 6. A tela de listagem ficou assim:

Listagem de bookmark

A edição assim:

Edição de bookmark

E inclusão:

Inclusão de bookmark

Se quiser dar uma olhada no código-fonte, está disponível no meu repositório GitHub. Se quiser contribuir, faça fork, modifique e depois faça pull request. Toda ajuda será bem vinda ;)

A ferramenta PrettyFaces oferece muitos outros recursos avançados. Para quem se interessou, vale à pena aprofundar nela. O que você achou? Conhece outra ferramenta melhor? Compartilhe sua opinião!

11/06/2011

Demoiselle 2 + two-phase commit no Tomcat 6

Filed under: Demoiselle — Dancovich @ 14:13
Tags: ,

Olá a todos, meu nome é Danilo Viana, trabalho no Serpro-SSA e este é meu primeiro post contribuindo para o Demoiselle. No momento estou participando de um projeto utilizando Demoiselle 2, Hibernate e two-phase commit, ou seja, precisariamos sincronizar acesso a dois bancos de dados em uma única transação.

Surgiu a possibilidade de nosso projeto não poder utilizar JBoss 6, que possui suporte nativo a two-phase commit através da API XATransaction. Ao invés disso o projeto passaria a executar em Tomcat 6, sem o mesmo suporte nativo. Com o projeto já bastante adiantado e sem possibilidade de voltar atrás em nossa decisão de tecnologia, foi necessário configurar o Tomcat 6 para ter suporte ao Demoiselle 2 utilizando JTA e two-phase commit.

Suporte a JSF 2

O primeiro problema que encontramos foi a implementação da Expression Language utilizada pelo Tomcat 6. No JSF 2 as expressões em EL suportam chamada de métodos com parâmetros mas esse suporte não está presente na biblioteca do Tomcat. Testamos a versão utilizada no Glassfish (disponível no repositório Maven http://download.java.net/maven/glassfish sob o group-id “el-impl”) que funcionou sem problemas.

Baixe via Maven ou acessando o repositório no browser, os arquivos “el-api.jar” e “el-impl.jar”, acesse a pasta [TOMCAT 6]\lib e copie estes arquivos lá, substituindo o arquivo el-api.jar já existente (faça um backup do arquivo original).

Além disso é necessário ensinar o Tomcat a fabricar o objeto que processa instruções EL. Para isso no arquivo “web.xml” do seu projeto web adicione o parâmetro abaixo:


<context-param>
    <param-name>com.sun.faces.expressionFactory</param-name>
    <param-value>com.sun.el.ExpressionFactoryImpl</param-value>
</context-param>

Habilitando two-phase commit

O Tomcat não tem suporte nativo a api XATransaction, que provê suporte a two-phase commit. Para ter este suporte vamos utilizar o framework Atomikos (http://www.atomikos.com), que é livre e está sob licença Apache 2.0

O Atomikos está no repositório geral Maven, então basta acrescentar em seu projeto a dependência à biblioteca “transactions-hibernate3″, que está no group-id “com.atomikos” e seu projeto já poderá utilizar two-phase commit no JPA com Hibernate como persistence provider.

É necessário copiar em seu projeto uma classe que substitui o ObjectFactory original do Tomcat 6, do contrário seu projeto não será capaz de obter instâncias de UserTransaction já que o Tomcat 6 não tem suporte a fornecer objetos dessa classe. Acesse este link do site do Atomikos e copie a classe ou o jar disponibilizado para seu projeto.

Agora para configurar o acesso à conexão. Este é um exemplo de criação de recurso JNDI no arquivo “context.xml”, onde criamos tanto o recurso de acesso à conexões quanto o recurso de acesso à transações via UserTransaction. Note o parâmetro “factory”, que referencia a classe copiada no passo anterior. Note também que estamos utilizando o PostgreSQL como exemplo, pois esse SGBP suporta transações XA, verifique se seu SGBD oferece este suporte.


<Context>
    <Resource
        name="jdbc/nome_datasource"
        auth="Container"
        type="com.atomikos.jdbc.AtomikosDataSourceBean"
        factory="com.atomikos.tomcat.BeanFactory"
        uniqueResourceName="jdbc/nome_datasource"
        xaDataSourceClassName="org.postgresql.xa.PGXADataSource"
        xaProperties.databaseName="base_principal"
        xaProperties.serverName="ip_servidor_banco_principal"
        xaProperties.user="****"
        xaProperties.password="****"
        maxPoolSize="20"
    />

    <Resource
        name="UserTransaction" auth="Container"
        type="javax.transaction.UserTransaction"
        factory="com.atomikos.icatch.jta.UserTransactionFactory"
    />
</Context>

Utilizando JTA e Hibernate como persistence provider, é necessário incluir os seguintes parâmetros no arquivo “persistence.xml”:

<persistence-unit name="unidade_persistencia">
    <jta-data-source>java:comp/env/jdbc/nome_datasource</jta-data-source>
    <properties>
        <!--...-->
        <property name="hibernate.transaction.manager_lookup_class" value="com.atomikos.icatch.jta.hibernate3.TransactionManagerLookup" />
        <!--...-->
    </properties>
</persistence-unit>

Caso esteja utilizando Hibernate nativo, sem o JTA, estas configurações devem estar presentes em seu arquivo “hibernate.cfg.xml”:

    <property name="hibernate.connection.datasource">java:comp/env/jdbc/nome_datasource</property>
    <property name="hibernate.transaction.manager_lookup_class">com.atomikos.icatch.jta.hibernate3.TransactionManagerLookup</property>
    <property name="hibernate.transaction.factory_class">org.hibernate.transaction.JTATransactionFactory</property>
    <property name="jta.UserTransaction">java:comp/env/UserTransaction</property>

Por último, o Demoiselle 2 não está preparado para produzir instâncias de UserTransaction para Tomcat 6, então por ora é necessário acrescentar ao seu projeto um produtor de UserTransaction através da anotação @Produces.

Crie a classe abaixo em seu projeto, o pacote não é importante, mas note a anotação @Produces, ela vai indicar ao CDI que esta classe é responsável por produzir instâncias de UserTransaction.

package com.tomcat6.usertransactionsupport;

import javax.enterprise.inject.Produces;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.transaction.UserTransaction;

/**
* Classe responsável por produzir UserTransactions no Tomcat 6, pois
* o Demoiselle 2 não produz estas classes normalmente em um ambiente Tomcat.
*/
public class TomcatUserTransactionProducer {

@Produces
public UserTransaction create() {
UserTransaction transaction = null;

try {
Context context = new InitialContext();
transaction = (UserTransaction) context.lookup("java:comp/env/UserTransaction");
} catch (NamingException e) {
e.printStackTrace();
}

return transaction;
}

}

Conclusão

Com esses passos você será capaz de utilizar JSF 2 e two-phase commit no Tomcat 6. Se você está desenvolvendo um sistema com estes requisitos mas não pode utilizar um container com suporte nativo a estas funcionalidades, ou acredita que o JBoss é muito pesado e seu projeto simples não necessita de tanto, esta solução pode ser o que você procura.

31/05/2011

Componente de E-mail

Filed under: Demoiselle Components — Marlon Silva Carvalho @ 15:41
Tags: ,

O componente de e-mail do Demoiselle passou por uma reestruturação para se adaptar à nova  versão 2.0 do Demoiselle. Mas não foi apenas uma simples adaptação. Na verdade, todo o componente foi reescrito e novas ideias foram incluídas. As versões anteriores contavam apenas com uma “interface” que continha métodos simples para envio de e-mail, como send(from, to, subject, body). Agora, foi aplicada um novo conceito: DSL. Esta sigla significa Domain Specific Language e retrata uma tendência comum em linguagens atuais que consiste, basicamente, em criar um subconjunto da linguagem de forma que facilite a solução de problemas simples e específicos.

Novas funcionalidades também foram adicionadas e poderão ser conferidas a partir de 01/06/2011, data em que lançaremos a versão oficialmente. Confira:

  1. Adicionar anexos através de URL e java.io.File;
  2. Adicionar endereços de BCC e CC;
  3. Adicionar endereços de Reply-To;
  4. Adicionar endereços para confirmação de entrega (Delivery Receipt);
  5. Adicionar endereços para confirmação de leitura (Read Receipt);
  6. Definir a importância do e-mail como alta, baixa ou normal;
  7. Envio de e-mail usando servidores de e-mail seguros (SSL e STARTTLS).
As configurações continuam bem parecidas, pois você continuará usando o arquivo demoiselle.properties para informar qual o servidor usar, login, senha e etc. Contudo, você notará uma grande diferença na codificação para o envio. Veja um exemplo simples abaixo.

public class Teste {

	@Inject
	private Mail mailer;

	public void send() {
		mailer
			.to("somebody@somewhere.com")
			.from("somebody@from.com")
			.body().text("Email 1")
			.attach().url("http://www.frameworkdemoiselle.gov.br/ultimas-noticias/chancelaSerpro.jpg", "logo.jpg").inline()
			.subject("Subject 1")
			.send();
	}
}

O envio de e-mail agora é baseado na interface Mail, que você deve injetar em alguma classe sua. A partir daí, basta usar os métodos da DSL que criamos. As demais opções são tão simples quanto estas do exemplo. Para definir a importância, por exemplo, basta usar mail.importance().high(). Bem intuitivo e não deixa margens para dúvidas.
O componente de e-mail do Demoiselle encontra-se na versão 2.0.0 e sua documentação em DocBook encontra-se em http://demoiselle.sourceforge.net/docs/. O nosso fórum de discussões está em https://sourceforge.net/apps/phpbb/demoiselle/viewtopic.php?f=35&t=118. O Mantis com a proposta do componente encontra-se em https://sourceforge.net/apps/mantisbt/demoiselle/view.php?id=547.

09/05/2011

Controle de acesso com o Demoiselle 2.1

Filed under: Demoiselle — Cleverson Sacramento @ 10:40
Tags: ,

Controle de acesso fácil com o Demoiselle 2.1

Na semana passada foi anunciada a versão 2.1 do framework Demoiselle. Dentre as novidades está o controle de acesso simples, fácil e flexível. Neste post explico como personalizar esta funcionalidade mostrando código funcionando. Veja como é fácil!

Se você quer controlar o acesso à sua aplicação, saiba que a versão 2.1 do Demoiselle vai facilitar muito a sua vida. No exemplo, criei uma aplicação através do arquétipo demoiselle-minimal (veja neste vídeo como fazer isto). O primeiro passo foi definir os pontos de controle. Utilizei anotações:

public class HelloWorld {

	@Inject
	private Logger logger;

	@RequiredPermission(resource = "hello", operation = "say")
	public void say() {
		logger.info("Saying hello on console");
	}

	@RequiredRole("administrators")
	public void swear() {
		logger.info("I swear...");
	}
}

Para executar o método say() é preciso ter permissão ao recurso “hello” com a ação “say”, conforme anotação @RequiredPermission. Para executar swear(), o usuário deve pertencer ao grupo de administradores. Só utilize a anotação @RequiredRole caso sua aplicação possua grupos fixos, senão dê preferência a @RequiredPermission. Se quer aprofundar neste assunto, sugiro a leitura do padrão RBAC.

O próximo passo é criar o autenticador e autorizador personalizados. Lembra dos conceitos de controle de acesso? Autenticar é identificar o usuário, autorizar é determinar o que pode ser acessado. Vamos comecei pelo autenticador. Criei um objeto para transportar as credenciais do usuário, neste caso o login e senha, mas poderia ser qualquer outra coisa:

@SessionScoped
public class MyCredentials implements Serializable {

	private String username;

	private String password;

	public void clear() {
		username = null;
		password = null;
	}

	// Getters and setters
}

Em seguida criei o autenticador, uma implementação da interface Authenticator do Demoiselle:

@Alternative
public class MyAuthenticator implements Authenticator {

	@Inject
	private MyCredentials credentials;

	@Override
	public boolean authenticate() {
		String usr = credentials.getUsername();
		String pwd = credentials.getPassword();

		boolean authenticated = false;

		if (usr.equals("admin") && pwd.equals("secret")) {
			authenticated = true;
		} else if (usr.equals("zyc") && pwd.equals("tcharam")) {
			authenticated = true;
		}

		return authenticated;
	}

	@Override
	public void unAuthenticate() {
		credentials.clear();
	}

	@Override
	public User getUser() {
		return new User() {

			@Override
			public String getId() {
				return credentials.getUsername();
			}

			@Override
			public void setAttribute(Object key, Object value) {
			}

			@Override
			public Object getAttribute(Object key) {
				return null;
			}
		};
	}
}

A implementação foi bem simples, mas poderia ler um XML, acessar banco de dados, conectar ao LDAP, consultar outro sistema, consumir serviços web ou delegar para frameworks especializados.

Ativei a estratégia de autenticação no /META-INF/beans.xml:

<beans>
	<alternatives>
		<class>examples.MyAuthenticator</class>
	</alternatives>
</beans>

Para testar o funcionamento, criei um caso de teste com JUnit:

@RunWith(DemoiselleRunner.class)
public class HelloWorldTest {

	@Inject
	private SecurityContext context;

	@Inject
	private MyCredentials credentials;

	@Test
	public void loginSuccessful() {
		// Acessando com meu usuário
		credentials.setUsername("zyc");
		credentials.setPassword("tcharam");
		context.login();
		assertEquals("zyc", context.getUser().getId());
		context.logout();

		// Acessando como admin
		credentials.setUsername("admin");
		credentials.setPassword("secret");
		context.login();
		assertEquals("admin", context.getUser().getId());
		context.logout();
	}

	@Test
	public void loginFailed() {
		// Tentando acessar com usuário inexistente
		credentials.setUsername("fake");
		credentials.setPassword("idontknow");
		context.login();
		assertNull(context.getUser());
	}
}

O acesso ao método de login() foi feito através da interface SecurityContext do Demoiselle, que delega a chamada para a estratégia de autenticação ativa. Todas as funcionalidades de segurança devem ser acessadas exclusivamente através de SecurityContext. Olha as funcionalidades que ela oferece:

interface SecurityContext {

	void login();

	void logout() throws NotLoggedInException;

	boolean isLoggedIn();

	boolean hasPermission(String resource, String operation) throws NotLoggedInException;

	boolean hasRole(String role) throws NotLoggedInException;

	User getUser();
}

Voltando ao que interessa… Criei o autorizador, uma implementação da interface Authorizator do Demoiselle:

@Alternative
public class MyAuthorizator implements Authorizator {

	private static final long serialVersionUID = 1L;

	@Inject
	private SecurityContext context;

	@Override
	public boolean hasRole(String role) {
		String usr = context.getUser().getId();
		boolean authorized = false;

		if (usr.equals("admin") &&
		    role.equals("administrators")) {
			authorized = true;
		}

		return authorized;
	}

	@Override
	public boolean hasPermission(Object res, String op) {
		String usr = context.getUser().getId();
		boolean authorized = false;

		if (usr.equals("zyc") &&
		    res.equals("hello") && op.equals("say")) {
			authorized = true;
		} else if (context.hasRole("administrators")) {
			authorized = true;
		}

		return authorized;
	}
}

O método hasRole() só retorna verdade caso “admin” esteja autenticado. O hasPersmission() implementa uma regra específica para “zyc” e permite que integrantes do grupo de administradores tenha passe-livre. Estas regras poderiam estar implementadas de forma mais complexa, acessando um banco de dados, consumindo serviço web ou delegando para frameworks especializados.

Ativei a estratégia de autorização no /META-INF/beans.xml:

<beans>
	<alternatives>
		<class>examples.MyAuthenticator</class>
		<class>examples.MyAuthorizator</class>
	</alternatives>
</beans>

Em seguida complementei o caso de teste:

@RunWith(DemoiselleRunner.class)
public class HelloWorldTest {

	@Inject
	private SecurityContext context;

	@Inject
	private MyCredentials credentials;

	@Inject
	private HelloWorld helloWorld;

	@Test
	public void loginSuccessful() {
		// Acessando com meu usuário
		credentials.setUsername("zyc");
		credentials.setPassword("tcharam");
		context.login();
		assertEquals("zyc", context.getUser().getId());
		context.logout();

		// Acessando como admin
		credentials.setUsername("admin");
		credentials.setPassword("secret");
		context.login();
		assertEquals("admin", context.getUser().getId());
		context.logout();
	}

	@Test
	public void loginFailed() {
		// Tentando acessar com usuário inexistente
		credentials.setUsername("fake");
		credentials.setPassword("idontknow");
		context.login();
		assertNull(context.getUser());
	}

	@Test
	public void authorizedAccess() {
		// Acessando o método "say" com meu usuário
		credentials.setUsername("zyc");
		credentials.setPassword("tcharam");
		context.login();
		helloWorld.say();
		context.logout();

		// Acessando o método "say" e "swear" como admin
		credentials.setUsername("admin");
		credentials.setPassword("secret");
		context.login();
		helloWorld.say();
		helloWorld.swear();
		context.logout();
	}

	@Test
	public void unauthorizedAccess() {
		// Tentando acessar o método "swear"
		credentials.setUsername("zyc");
		credentials.setPassword("tcharam");
		context.login();

		try {
			helloWorld.swear();
			fail();
		} catch (SecurityException e) {
			// Se chegar aqui, o teste deve passar
		}

		context.logout();
	}
}

Tudo pronto e funcionando perfeitamente! O código-fonte produzido pode ser acessado publicamente através deste repositório, sinta-se à vontade para baixar, experimentar e modificar. A documentação de referência do Demoiselle pode ser acessada aqui.

Para facilitar ainda mais sua vida, disponibilizamos uma extensão para o Apache Shiro e estamos trabalhando na integração com o projeto Rasea. Em breve, mais novidades!

Link para o post original: http://cleversonsacramento.wordpress.com/2011/05/09/controle-de-acesso-com-o-demoiselle-2-1/

Liberada a versão 2.1 final do Demoiselle

Filed under: Demoiselle — Cleverson Sacramento @ 9:34
Tags: , , ,
Acaba de ser liberada a versão 2.1 do Framework Demoiselle, que traz facilidades para o controle de acesso e novas tecnologias para camada de apresentação de seu projeto.
A nova versão segue o princípio da simplicidade e flexibilidade. Ser simples para facilitar o entendimento do framework, cortando gorduras desnecessárias e indo direto ao que interessa. Ser flexível para adaptá-lo à sua realidade sem amarras ou imposições. Liberdade de escolha é o que conta.
As principais funcionalidades da versão 2.1 são:
  • Controle de acesso fácil e flexível utilizando padrões de mercado, através da criação de interfaces para definição e manipulação de funcionalidades do controle de acesso baseadas no padrão RBAC (ANSI INCITS 359-2004)
  • Mais uma opção de ferramenta para projetar as telas do seu sistema, através da extensão para o Vaadin.  O Vaadin é um framework RIA baseado no GWT que lhe permite escrever 100% da sua aplicação WEB  usando apenas a linguagem Java
  • Melhoria no gerenciamento da conexão com o banco de dados e do controle transacional, implementando o padrão Session-per-request largamente difundido no mercado

E mais…

Junto com a versão 2.1 do framework, inauguramos um novo subprojeto que é o Demoiselle Tools, apresentando ferramentas de apoio ao framework visando aumentar ainda mais a produtividade no desenvolvimento. A primeira ferramenta disponibilizada é Demoiselle Nimble, um engine gerador de código automático baseado em templates escritos em Velocity, Groovy ou FreeMarker. Já são fornecidos geradores de aplicações e CRUD para as versões 1 e 2 do Demoiselle, para as camadas de apresentação JSF e Vaadin. Seu diferencial é a facilidade na customização de templates existentes ou criação de novos. O Nimble também está disponível através de plug-ins para Eclipse e NetBeans.
O portal de componentes (http://demoiselle.souceforge.net/component) foi reformulado com o objetivo de facilitar a escolha dos componentes pela compatibilidade com as versões do framework. Também será disponibilizado o roadmap do componentes e para quem quiser adicionar seu componente ao projeto verá que é bem fácil!
Se você quer criar rapidamente o primeiro projeto com o Demoiselle 2, assista:

Para conhecer algumas funcionalidades do framework, veja:

Mais links…
Sejam bem-vindos à nova versão 2.1!

28/04/2011

Rodando a aplicação contactlist em sua IDE

Filed under: Contactlist,Demoiselle Sample — Robson Ximenes @ 15:45
Tags: , , , , ,

Neste post tentarei explicar rapidamente como baixar o projeto em sua ide e coloca-lo para rodar no servidor.

IDE

No exemplo estou utilizando o eclipse, disponibilizado no projeto demoiselle-infra. Porém você pode utilizar outra ide ou versão, desde que sua IDE tenha configurado o uso de subversion, maven e servidor de aplicação integrado.

Caso você não tenha uma IDE instalada sugiro baixar do infra: http://demoiselle.sourceforge.net/infra/site/install.html

Baixando o projeto

No Eclipse, acesse o menu File / Import / Maven / Check out Maven Projects from SCM.

Selecione o tipo SVN e coloque o endereço: http://demoiselle.svn.sourceforge.net/svnroot/demoiselle/sample/trunk/contactlist

Clique em Finish e o projeto será criado e os códigos baixados.

Executando em stand alone (jse)

O projeto está dividido em 3 módulos: core, swing e jsf.  No core são disponibilizados: Beans e regras de negócio. No SWING e JSF estão apenas as classes e recursos de visão.

Para executar basta clicar no projeto contactlist-swing e clicar em:  Run As / Java Application. Selecione a classe: contactlist.Main;

Você também poderá clicar diretamente na classe Main com o botão direito e clicar também em: Run As / Java Application

Pronto! Já temos uma versão com interface swing rodando!


Executando no servidor

Primeiro é preciso ter um servidor de aplicação configurado, no meu caso é o JBoss, que veio instalado pelo demoiselle-infra, dentro do Eclipse. Depois simplesmente basta clicar e arrastar o projeto contactlist-jsf para dentro do servidor.

Depois ele vai aparecer dentro do servidor, clique no servidor e selecione a opção Start;

O projeto vai rodar no console e ficar disponível no endereço: http://localhost:8080/contactlist-jsf/

Pronto! Agora está tudo configurado! Pode usar sua criatividade!

26/04/2011

Parâmetros com a extensão Demoiselle-JSF

Filed under: Demoiselle — Cleverson Sacramento @ 14:30
Tags: ,

Parâmetros com a extensão Demoiselle-JSF

Uma funcionalidade muito útil na extensão JSF do Demoiselle 2 é a injeção de parâmetros. Ao invés de fazer malabarismo através FacesContext para obter informações dos escopos request e session, o Demoiselle 2 oferece uma funcionalidade que faz automaticamente as devidas conversões. Se você não conhece, fique à par desta facilidade.

Ao invés gastar parágrafos explicando o funcionamento, achei melhor mostrar o código. Criei uma página index.xhtml que contém apenas links com passagem de parâmetros utilizando tags do JSF 2.

<h:link value="Link 1">
	<f:param name="param1" value="Uma frase qualquer" />
</h:link>

<h:link value="Link 2">
	<f:param name="param2" value="1" />
</h:link>

No primeiro link passei um parâmetro literal, no segundo um numeral para testar a conversão automática de tipos. Estes parâmetros serão enviados para a própria página via URL. Criei a classe MyManagedBean para auxiliar o funcionamento da tela, como geralmente acontece na vida real:

@RequestScoped
@ViewController
public class MyManagedBean {

	@Inject
	private Parameter<String> param1;

	@Inject
	@SessionScoped
	@Name("param2")
	private Parameter<Long> p2;

	public String getParam1() {
		return param1.getValue();
	}

	public Long getParam2() {
		return p2.getValue();
	}
}

Como a classe possui o escopo request, à cada nova requisição o objeto será recriado e seu estado será perdido. Existem dois atributos, param1 e p2 que são injetados pelo Demoiselle 2. O primeiro atributo espera um valor do tipo literal, o segundo um valor numérico. O nome do primeiro atributo coincide com o nome do parâmetro, mas o segundo não. Por isso p2 foi nomeado como “param2″ pela anotação @Name do Demoiselle. Criei dois métodos assessores que retornam os valores dos parâmetros.

O atributo p2 foi marcado com a anotação @SessionScoped. Neste caso o parâmetro “param2″ será armazenado na sessão e depois será injetado em MyManagedBean. Caso o parâmetro “param2″ não seja submetido pela tela, o mecanismo buscará a informação no escopo de sessão. Como o param1 não define escopo, o valor será obtido através do escopo de requisição e armazenado em cache para só então ser injetado no atributo. Se você não quiser usar o cache, anote-o com @RequestScoped.

Modifiquei o arquivo index.xhtml para obter e imprimir os atributos na tela. O código-fonte ficou assim:

<html xmlns:f="http://java.sun.com/jsf/core" xmlns:h="http://java.sun.com/jsf/html">

<f:view contentType="text/html" />

<h:body>
	<h:panelGrid columns="2">
		<h:link value="Link 1">
			<f:param name="param1" value="Uma frase qualquer" />
		</h:link>
		<h:outputText value="#{myManagedBean.param1}" />

		<h:link value="Link 2">
			<f:param name="param2" value="1" />
		</h:link>
		<h:outputText value="#{myManagedBean.param2}" />
	</h:panelGrid>
</h:body>
</html>

A expressão #{myManagedBean.param1} invoca o método assessor do bean gerenciado. Por fim, implantei a aplicação no servidor JBoss AS 6.0.0.Final para testar. Ao acessar a aplicação, a visão inicial é esta:

Estado inicial

Acessei o Link 1, que submete o valor “Uma frase qualquer”.

Após a primeira submissão

Depois acessei o Link 2, que submete o valor “1″. O valor da requisição anterior foi perdido, pois estava armazenado no bean gerenciado, que é recriado à cada requisição.

Após a segunda submissão

Ao acessar novamente o Link 1 o valor submetido pelo Link 2 não é perdido, pois ele foi armazenado no escopo de sessão.

Após a terceira submissão

Passei parâmetros diretamente via URL para serem renderizados na tela.

Passagem de parâmetros via URL

Para quem quiser experimentar a, disponibilizei a aplicação de exemplo neste repositório Subversion aqui. Viu como é fácil? Mas se mesmo assim você quiser fazer da forma antiga, fique à vontade. O importante é ter opções!

Post original: http://cleversonsacramento.wordpress.com/2011/04/26/parametros-com-a-extensao-demoiselle-jsf/

25/04/2011

Eclipse Helios para o Demoiselle 2

Filed under: Demoiselle — Cleverson Sacramento @ 8:59
Tags: ,

fonte da imagem: http://4.bp.blogspot.com

Escrevi este post para ajudar os usuários do Framework Demoiselle na instalação do Eclipse e seus plug-ins. Quem já acompanha o projeto sabe que existe o Demoiselle Infra, uma ferramenta que prepara tudo automaticamente no Ubuntu Linux. Como os usuários Mac e Windows ainda não foram contemplados pelo Infra, resolvi dar uma força nesta tarefa chata.

O primeiro passo é baixar o IDE. Como não queremos carregar peso extra, vamos de Eclipse Classic. No meu caso, optei pela plataforma Mac OS X 64 Bit. Faça o download para sua plataforma: http://www.eclipse.org/downloads.

Eclipse Helios 3.6.2 para Mac OS X 64 Bit

Agora vamos instalar os plug-ins. Acesse o menu Help / Install New Software…

Install New Software

Comecemos pelo Subeclipse, um cliente para o sistema de controle de versão Subversion. Adicione o site http://subclipse.tigris.org/update_1.6.x.

Subeclipse Update Site

Selecione tudo e mande ver na instalação.

Para o Subeclipse, marque tudo

Chegou a hora do m2eclipse plug-in, que integra o Eclipse com o gerenciador de projetos Maven. Adicione o site http://m2eclipse.sonatype.org/sites/m2e.

m2eclipse Update Site

Selecione tudo aqui também o prossiga com a instalação.

Marque tudo aí também

Muita gente esquece deste, mas é muito importante: ferramentas extras para o m2eclipse. Adicione o site http://m2eclipse.sonatype.org/sites/m2e-extras.

m2eclipse Extras Update Site

Mais uma vez, marque tudo e instale.

Marque tudo outra vez

Agora vamos para o último plug-in. Instale o JBoss Tools adicionando o site http://download.jboss.org/jbosstools/updates/stable/helios.

JBoss Tools Update Site

O JBoss Tools traz várias facilidades para diversas tecnologias. Sugiro que você instale estas:

Marque estas opções...

Para garantir a integração com o Maven, não esqueça de marcar estas aqui também:

...e estas também

Finalize a instalação. A qualquer momento você pode modificar, excluir ou adicionar novos plug-ins ao seu Eclipse. Sinta-se à vontade para experimentar.

O próximo passo é por sua conta, configure o ambiente como desejar. Se você já possui Tomcat, JBoss AS ou qualquer outro servidor de aplicação instalado, basta configurar o Eclipse para acessá-los. Se você não sabe fazer isso, recorra ao Google ou aguarde o próximo post.

Postagem original em: http://cleversonsacramento.wordpress.com/2011/04/23/eclipse-helios-para-o-demoiselle-2/

Próxima Página »

Tema: Rubric. Blog no WordPress.com.

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.