mar 19

Adicionando um certificado e uma chave em um keystore para configurar HTTPS no JBOSS

Estava eu tentando configurar o ssl no JBOSS 7.1 Community para utilizar meu certificado obtido no StartSSL e me deparei com o seguinte problema : 2 Arquivos um com extensão .crt e outro com extensão .key . Quando você olha os tutoriais de como configurar o ssl no jboss todos vão ensinar a criar um certificado fake e colocar no keystore, mas o que eu precisava era adicionar uma certificado de verdade.

Depois de algum tempo procurando eu encontrei a solução, são necessários 2 passos que é a transformação dos 2 arquivos .crt e .key em um arquivo do tipo pkcs12 que tem a extensão .p12 , e em seguida você deve importar esse certificado criado para um keystore java qualquer que você tenha.

Você precisará de 2 ferramentas: o OpenSSL , nativo no linux e para windows você acha aqui  e o Keytool do próprio java , basta ter alguma versão do java instalado para usá-lo, aqui tem uma referência legal dos principais comandos.

Agora vamos aos comandos necessários

Comando 1:

openssl pkcs12 -export -name [nome-do-certificado] -in [certificado.crt]  -inkey [chave-certificado.key]  -out keystore
.p12

Comando 2:

 keytool  -importkeystore -destkeystore [keystore-java-criado.jks]-srck
eystore keystore.p12 -srcstoretype pkcs12 -alias [alias-desejado]

E pronto, agora você poderá configurar um connector do jboss para utilizar ssl, utilizando seu certificado digital e poder utilizar https em suas aplicações.

<subsystem xmlns="urn:jboss:domain:web:1.1" default-virtual-server="default-host" native="false"> 

  <connector name="https" scheme="https" protocol="HTTP/1.1" socket-binding="https" enable-lookups="false" secure="true">

    <ssl name="foo-ssl" password="secret" protocol="TLSv1" key-alias="[alias-desejado]" certificate-key-file="[keystore-java-criado]" />

  </connector>

</subsystem>

E é isso!

 

ago 06

Habilitar log de aplicação no JBOSS EAP 6.1

Pra quem utiliza essa versão do jboss e se não me engano toda a linha EAP funciona desta maneira já deve ter reparado que ao tentar logar utilizando log4j nada aparece no console.

Para resolver isso basta adicionar o argumento de VM -Dorg.jboss.as.logging.per-deployment=false no arquivo standalone.conf ou se você está no eclipse basta dar 2 cliques no servidor jboss que irá aparecer uma aba com dados do servidor, em seguida selecione a opção Open launch configuration e irá aparecer a caixa de texto contedo todos os argumentos de VM, basta adicionar no final.

mai 06

Jquery com JSF

Quem trabalha com JSF com certeza já viu os ids dos elementos html gerados por ele da seguinte maneira  form:idElementoPai:idElemento . Mesmo usando a propriedade prependId = false da tag h:form alguns elementos aninhados ganham o id do pai.

Se você usa javascript puro para buscar os elementos pelo id utilizando document.getElementById(“form:idElementoPai:idElemento”) não temos problema algum, tudo funciona! Porém quando utilizamos jquery , a seleção de um elemento por id $(‘#form:idElementoPai:idElemento’)  simplesmente não funciona, e muitas vezes adotei a alternativa de buscar pelo seletor de classe, me obrigando a adicionar classes css únicas(mas não é necessário defini-las em um arquivo css, basta declarar no elemento).

Porém é possível sim utilizar o seletor do Jquery nesses casos desses ids compostos, bastando adicionar o \\ antes do caracter :(dois pontos)  ficando da seguinte maneira:

$('#form\:idElementoPai\:idElemento')

mai 03

Equals com Objeto do tipo proxy do hibernate

Há tempos que não posto nada, estou devendo muita coisa. Mas essa aqui eu tava me ferrando e acho que vale a pena registrar.

A situação é a seguinte: Tenho uma entidade A que se relaciona com a entidade B  em um relacionamento OneToOne, porém não quero utilizar o carregamento eager padrão para este relacionamento. Para resolver isso base adicionar a propriedade fetch=FetchType.LAZY na anotação OneToOne.  Mas como dizia Joseph Climber, a vida é uma caixinha de surpresas. Não é que pra minha surpresa o cache do hibernate resolveu funcionar em um select e manteve um objeto do tipo B que eu já tinha carregado a partir de um do tipo  A. Ou seja, no meio da listagens de objetos do tipo retornados do meu select * , tinha um intruso do tipo lazy do hibernate no meio da listagem WTF???!! . Ou seja, meu equals (gerado pelo eclipse) estava executando a instrução if (getClass() != obj.getClass()) e retornando true, uma vez que aquele bendito objeto lazy intruso não era da mesma classe!!

Agora chega de blablabla e vamos pras soluções:

Solução 1:

Devemos adicionar a seguinte verificação:

Onde tínhamos:  if (getClass() != obj.getClass())

Devemos ter agora:

Class<?> objProxyClass = 
HibernateProxyHelper.getClassWithoutInitializingProxy(obj);
 if (getClass() != obj.getClass() && getClass()!= objProxyClass )

e voi là , na chamada ao método getClassWithoutInitializingproxy é retornada a classe original do meu proxy e o if seguinte funciona sem problema algum!

Solução 2:

Essa solução foi retirada da documentação do hibernate

 if( !(obj instanceof B)) return false;

Essa é bem mais simples e também funciona!!

Agora fica a seu critério a utilização de uma ou de outra.

Lembrando que toda vez que seu objeto tiver a possibilidade de ser um proxy do hibernate nunca utilize diretamente os atributos no equals, faça as comparações sempre utilizando os métodos GETTERS!!!

É isso, se alguém souber uma situação que uma solução ou outra não atenda pode comentar aí, até a próxima.

set 05

Mapeando chaves compostas com JPA 2

Muitas vezes utilizamos em nossas tabelas chaves compostas para identificação de uma tupla, um exemplo seria na tabela empregado a chave primária ser composta pelos atributos cpf e matrícula do empregado, vocês podem dizer que bastaria o cpf ou a matrícula para identificar o empregado, mas aqui estou apenas exemplificando para mostrar como mapeamos esta chave composta utilizando JPA2.

Para isso a JPA nos oferece 2 estratégias de mapeamento:

  • IdClass
  • EmbeddedId

Eu até o momento ainda não identifiquei uma diferença de desempenho entre as duas estratégias, nem vejo vantagem em questão de verbosidade de uma em relação a outra, portanto mostrarei as 2 e quem quiser escolhe a que melhor convir.

Utilizando IdClass 

Para se utilizar de idClass precisamos criar uma classe com os atributos que compõem nossa chave primária da seguinte maneira:

public class EmpregadoId {

private String cpf;
private String matricula;

//getters e setters
@Override
public int hashCode() {
//código hashcode
}

@Override
public boolean equals(Object obj) {
//código equals
}
}

Devemos sempre implementar os métodos hashcode e equals da nossa classe de Id, o hibernate apenas dará um alerta caso não estejam implementados estes métodos.

Agora na nossa classe de entidade devemos ter o seguinte código:

@Entity
@IdClass(EmpregadoId.class)
public class Empregado {

@Id
private String cpf;

@Id
private String matricula;

//Outros atributos e getters e setters

Ou seja, basta anotar com @IdClass a classe de entidade, passando por parâmetro a classe que contém os atributos do id, e devemos anotar com @Id os atributos que compõem o id, que são os mesmos da classe de id.

E é só, nessa estratégia a classe que representa o id não precisa de anotações, e não será utilizada pela nossa aplicação, porém é necessária para que a estratégia funcione.

 

Utilizando EmbeddedId

Nesta  estratégia também precisamos de uma classe com os atributos da chave primária, porém esta classe deve ser anotada como @Embeddable e deve obrigatoriamente implementar a interface Serializable , além de implementar os métodos hashcode e equals assim como na estratégia anterior. Assim temos a classe de id da seguinte maneira:

@Embeddable
public class EmpregadoId implements Serializable {

private static final long serialVersionUID = 1L;
private String cpf;
private String matricula;

//getters e setters
@Override
public int hashCode() {
//código hashcode
}

@Override
public boolean equals(Object obj) {
//código equals
}
}

Já a nossa entidade ficará da seguinte maneira:

@Entity
public class Empregado {

@EmbeddedId
private EmpregadoId id;

//Outros atributos e getters e setters

Ou seja, agora para acessar os atributos da chave primária composta devemos buscar através do atributo id que será do tipo EmpregadoId, que é anotado com @EmbeddedId  .

_____________________________________________________________________________________

Vimos então como é simples mapear chaves primárias compostas utilizando JPA 2, o único problema é que sempre precisamos de uma classe auxiliar que possuirá os atributos que compõem a chave.

fev 19

Autenticação com Apache Shiro e JSF

Nesse post vou mostrar uma soluçao que eu adotei para integrar o JSF e JPA com o Shiro, não digo que seja a melhor ou a mais prática, mas é uma solução.

Primeiramente o que é Shiro?

Segundo o próprio site do Shiro :

“Apache Shiro is a powerful and easy-to-use Java security framework that performs authentication, authorization, cryptography, and session management. With Shiro’s easy-to-understand API, you can quickly and easily secure any application – from the smallest mobile applications to the largest web and enterprise applications.”

Ou seja, é um framework Java de segurança.

Este post cobre apenas a parte de autenticação. Vamos ao que interessa então:

1) Adicionar as dependências

Para quem usa Maven :

 
<dependency>
   <groupId>org.apache.shiro</groupId>
   <artifactId>shiro-core</artifactId>
   <version>1.2.1</version>
</dependency>
<dependency>
   <groupId>org.apache.shiro</groupId>
   <artifactId>shiro-web</artifactId>
   <version>1.2.1</version>
</dependency>

Essa era a versão mais recente na época do post! Caso queira se certificar disso acesse http://mvnrepository.com/ e busque por Shiro.

2) Configurar o web.xml

Você precisará registrar o filtro do Shiro para filtrar suas requisições e um listener.

 
<listener>
   <listener-class>org.apache.shiro.web.env.EnvironmentLoaderListener</listener-class>
</listener>
<filter>
   <filter-name>ShiroFilter</filter-name>
   <filter-class>org.apache.shiro.web.servlet.ShiroFilter</filter-class>
</filter>

<filter-mapping>
   <filter-name>ShiroFilter</filter-name>
   <url-pattern>/*</url-pattern>
   <dispatcher>REQUEST</dispatcher>
   <dispatcher>FORWARD</dispatcher>
   <dispatcher>INCLUDE</dispatcher>
   <dispatcher>ERROR</dispatcher>
</filter-mapping>

 

3) Criar o arquivo shiro.ini na pasta WEB-INF onde está o web.xml

Você pode colocar esse arquivo em outro lugar , mas aí você precisará indicar isso no web.xml . Vamos adotar aqui a política “convenção sobre configuração”.

Este arquivo contém a configuração necessária para que o Shiro funcione.

Se você procurar no google achará diversas maneiras de configurá-lo. Aqui estamos bem básicos:

[main]

meurealm = meupacote.MeuRealm
securityManager.realms = $meurealm
authc.loginUrl=/login.xhtml
[users]
[roles]

[urls]
# enable authc filter for all application pages
/login.xhtml = authc
/secure/** = authc

 

Neste arquivo eu configurei o meu realm autenticador. Se quiser saber mais sobre realms leia http://shiro.apache.org/realm.html .

Em seguida atribuo aos realms do securityManager. Posso ter quantos realms eu quiser.
authc.loginUrl=/login.xhtml serve para indicar minah url de autenticação.
[users]
[roles]
Não são necessários aqui pois estou guardando-os no banco de dados.
Em [urls] eu declaro quais urls precisam de autenticação. Caso eu tenha páginas públicas basta fazer o seguinte:
/public/** = anom
Ou seja, todas as páginas embaixo do diretório public não necessitam de autenticação.
Em /secure/** = authc só será permitido o acesso a essas páginas caso haja usuário logado, essa verificação fica transparente para o desenvolvedor, uma vez que o filtro do shiro declarado no web.xml fará este trabalho.

 

4) Implementar o Realm autenticador

 
public class MeuRealm implements Realm {

@Override
public AuthenticationInfo getAuthenticationInfo(AuthenticationToken token)
    throws AuthenticationException {
        String principal = (String) token.getPrincipal();

        MeuDAO dao = new MeuDAO();
        String credencial = dao.buscarCredencial(principal);

        if(credencial != null) {
             AuthenticationInfo info = new SimpleAuthenticationInfo(principal,credencial,getName());
             SimpleCredentialsMatcher cmatcher = new SimpleCredentialsMatcher();

             boolean credentialsMatch = cmatcher.doCredentialsMatch(token, info);
             if(credentialsMatch) {
                 return info;
             }

         }
         throw new AuthenticationException();

}

@Override
public String getName() {

return "MeuApp";
}

@Override
public boolean supports(AuthenticationToken token) {
   //valido o token 
     ...
   //tudo ok com ele
    return true;  
   //problema com o token
    return false;

}

 

Neste código eu implemento a interface Realm e nela eu preciso implementar os 3 métodos mostrados acima. Quando esta classe será chamada eu mostrarei mais pra frente.

Mas basicamente o que é preciso saber é o seguinte:

No método supports eu recebo um token e preciso verificar se este token é válido para meu realm, como só temos um tipo de autenticação posso retornar true direto.
No método getName deve-se retornar um nome único para esse Realm.

Já no método getAuthenticationInfo é onde temos que colocar a mão na massa. Segundo a documentação do Shiro deve-se implementá-lo da seguinte maneira, primeiro você verifica se existe o usuário contido no Principal do seu token e retorna a credencial dele. No meu caso eu retorno null caso não ache nenhum usuário, caso ache eu retorno a senha do usuário.
Em seguida você deve criar um CredentialMatcher para verificar se a credencial do token é válida, neste exemplo eu fiz a verificação mais simples que é a de igualdade.
Caso você utilize conexão segura e sua senha seja recebida em texto claro e você armazene-a em formato de hash SHA256, você pode utilizar o Sha256CredentialsMatcher por exemplo.
Caso a verificação das credenciais retorne true você deve retornar um novo objeto AuthenticationInfo. Caso não o ache a documentação diz para se retornar null, mas você pode fazer do jeito que quiser.

5) O ManagedBean de login

Aqui é bem simples também, primeiramente eu instancio um UsernamePasswordToken passando o usuário e senha digitados no formulário.
Em seguida eu busco o Subject, que é o conceito de usuário que o Shiro utiliza, através do método estático SecurityUtils.getSubject().
Por fim eu chamo o método login do Subject criado passando o token gerado.
Ao fazer isso o Shiro vai invocar o(s) Realm(s) criado(s) que você declarou no shiro.ini , e chamar o método supports, caso retorne true ele chamará o getAuthenticationInfo.
Caso este último retorne um objeto do tipo AuthenticationInfo ele irá prosseguir na execução, no meu caso redirecionando o usuário para a área restrita da aplicação.
Se retornar uma AuthenticationException, eu adiciono uma mensagem genérica no FacesContext de que o usuário é inválido.

 
public void login() throws IOException {
        FacesContext ctx = FacesContext.getCurrentInstance();
        UsernamePasswordToken token = new UsernamePasswordToken(
                usuario.getEmail(), usuario.getSenha());
        Subject currentUser = SecurityUtils.getSubject();
        try {
            currentUser.login(token);
            ctx.getExternalContext().redirect("secure/index.xhtml");
        } catch (AuthenticationException ae) {

            ctx.addMessage(null, new FacesMessage(FacesMessage.SEVERITY_WARN,
                    "Usuário/senha inválido(s)!", "Usuário/senha inválido(s)!"));
        }

    }

 

6) Todo login precisa de um logout

Por fim para deslogar o usuário basta o seguinte

 
Subject currentUser = SecurityUtils.getSubject();
currentUser.logout();

Recomendo também redirecionar o usuário, pois não é feita a validação caso você esteja utilizando ajax.

 

Bom, é isso, sei que ficou um pouco confuso, mas eu tentei resumir ao máximo este assunto, uma vez que ele é bem mais complexo do que o que foi apresentado aqui. Pra quem for utilizar produtivamente  recomento a leitura da documentação antes.

out 15

CDI no Websphere 8 com JSF 2

Voltando aos posts de tecnologia, nas duas semanas que se passaram estive com um grande problema no trabalho:

Estávamos desenvolvendo uma aplicação utilizando CDI, com JSF 2, rodando no JBOSS  AS 7, tudo funcionando as mil maravilhas. Mas, porém, contudo, no entanto, como diz Joseph Climber –  “Mas a vida é uma caixinha de surpresas” – nosso servidor de desenvolvimento roda Websphere 8 (WAS 8) , que apesar de adotar praticamente as mesmas especificações do JAVA do JBOSS 7, utiliza em sua maioria as implementações  da APACHE(Myfaces para JSF, OpenWebBeans para CDI), enquanto que o JBOSS utiliza as implementações de referência, por exemplo o WELD para CDI e o mojarra para JSF.

Então como fazer funcionar nos 2 ambientes sem ter problemas de compatibilidade? Alguns passos são necessário, primeiro para o JSF:

  • Adicionar ao web.xml :
 
<context-param>
	<param-name>org.apache.myfaces.SERIALIZE_STATE_IN_SESSION</param-name>
	<param-value>false</param-value>
</context-param>

Agora para o CDI é mais complicado, inicialmente, todas as suas classes elegíveis a injeção, por exemplo, todas as classes que você anotou com @named, devem ser serializáveis, enquanto que no JBOSS não é obrigatório, eu diria até que é uma boa prática fazer isso. Além disso, o beans.xml deve ficar dentro de WEB-INF, obrigatoriamente. No JBOSS basta estar em algum lugar do classpath, no WAS 8 não, tem que estar ao lado do web.xml, abaixo de WEB-INF.

Porém isso não é tudo, no nosso caso aqui, nada estava sendo injetado pelo container, só conseguimos resolver isso incluindo a biblioteca de CDI do myfaces no classpath da aplicação, o Myfaces CODI . Um extra sobre o CODI é que ele também possui uma implementação similar ao ViewScope do JSF que funciona para CDI (CDI padrão não possui essa anotação), que é a @ViewAccessScoped

Você pode escolher quais módulos do CODI você deseja utilizar, aqui abaixo segue o código do pom para inserir o CODI completo, na wiki do CODI você encontra esses módulos.

 
    <dependency>
	<groupId>org.apache.myfaces.extensions.cdi.bundles</groupId>
	        <artifactId>myfaces-extcdi-bundle-jsf20</artifactId>
		<version>1.0.5</version>
		<scope>compile</scope>
    </dependency>

 

ago 03

Conversor em JSF2 com Servlet 3.0

Neste post falarei de como criar um converter para uma classe do meu modelo e também como utilizá-lo com um componente selectOneMenu.

Primeiramente, precisamos sobrescrever o método equals lá do nosso bean ( ex: MeuBean.java) para o qual será feito o converter.  Caso eu o identifique por um atributo específico, por exempo um id, o nosso equals ficaria da seguinte maneira:

 
        @Override
        public boolean equals(Object obj) {
		if (this == obj)
			return true;
		if (obj == null)
			return false;
		if (getClass() != obj.getClass())
			return false;
		Conta other = (Conta) obj;
		if (id == null) {
			if (other.id != null)
				return false;
		} else if (!id.equals(other.id))
			return false;
		return true;
	}

Em seguida criamos uma nova classe chamada meuBeanConverter que irá implementar a interface Converter do pacote  javax.faces.convert , vamos anotá-la com a seguinte annotation: @FacesConverter, setando o atributo forClass da anotação com a nossa classe MeuBean.class .

Essa interface Converter possui 2 métodos que precisamos implementar:

  1. public Object getAsObject(FacesContext arg0, UIComponent arg1, String texto)
  2. public String getAsString(FacesContext arg0, UIComponent arg1, Object obj)

Onde o primeiro será acessado na fase do jsf : apply request values, quando o formulário for submitado, convertendo o atributo value  da tag option do html no objeto correspondente da nossa classe MeuBean. E o segundo no caminho inverso, quando queremos a partir de um objeto da nossa classe MeuBean,  mostrar no selectBox html o nosso objeto.

 
@FacesConverter(forClass = MeuBean.class)
public class ContaConverter implements Converter {

	@Override
	public Object getAsObject(FacesContext arg0, UIComponent arg1, String texto) {
		if (texto == null || texto.equals("")) {
			return null;
		}

		Long longId = Integer.valueOf(texto).longValue();
		MeuBean bean = //alguma maneira de recuperar o bean pelo atributo id
		return bean;

	}

	@Override
	public String getAsString(FacesContext arg0, UIComponent arg1, Object obj) {
		// TODO Auto-generated method stub
		if (obj == null || obj.toString().equals("")) {
			return "";
		}
		return ((MeuBean) obj).getId().toString();
	}

}

Por fim no nosso html teremos no value do h:selectOneMenu  a propriedade que receberá o valor escolhido que será convertido para um objeto da classe MeuBean, e na listagem de f:selectItems uma lista de objetos MeuBean ( Ex: List<MeuBean> meusBeans ).

<h:selectOneMenu id="meuBean" value="#{meuMB.meuBean}">
	<f:selectItems value="#{meuMB.meusBeans}" ></f:selectItems>
</h:selectOneMenu>

Apenas um detalhe a mais, não setando o atributo itemLabel do f:selectItems, será necessário sobrescrever o toString do MeuBean, caso contrário será impresso a representação do objeto.

ago 01

Estados de um objeto gerenciado por um EntityManager

Neste post falarei um pouco de como a especificação JPA 2 trata as entidades manipuladas pelos EntityManagers. As principais funções dos EntityManagers são:

  1. Como o próprio nome já diz, gerenciar as entidades;
  2. Sincronizar o estado dos objetos com os dados correspondentes no banco de dados

Ao falarmos em gerenciar uma entidade nos referimos a como um EntityManager manipula uma entidade, e para isso é necessário entender os estados possíveis que uma instância pode assumir para um EntityManager. São 4 estados possíveis:

  • Transient

Neste estado seu objeto acabou de ser criado e o atributo que foi anotado com @Id não possui valor . Toda vez que você dá um new em um objeto de uma Entidade este é o estado que ele se encontrará.

  • Managed

Neste estado o objeto possui valor no atributo anotado com @Id, sendo este valor atribuido pelo EntityManager e não setado manualmente. Toda vez que ocorrer uma sincronização através de um flush ou um commit, os dados do objeto são atualizados no os dados do banco de dados.

  • Removed

Neste estado,assim como no estado managed, o objeto possui valor no atributo anotado com @Id, sendo este valor atribuido pelo EntityManager e não setado manualmente. Porém quando ocorrer uma sincronização através de um flush ou um commit, o objeto passa a não ter mais vínculo com o banco de dados.

  • Detached

Neste estado,assim como no estado managed, o objeto possui valor no atributo anotado com @Id, sendo este valor atribuido pelo EntityManager ou setado manualmente. Porém este objeto não possui mais vínculo com o EntityManager, logo ele não será mais sincronizado com o banco de dados, e qualquer alteração realizada com ele residirá somente na memória da aplicação e não no banco de dados.

Para trocar de estados o EntityManager nos fornece os seguinte métodos:

  • persist : Transient -> Managed
  • merge : Transient -> Managed / Detached -> Managed
  • evict, clear ou close : Managed -> Detached
  • remove : Managed -> Removed

 

Tendo esses estados em mente e também como transitar entre eles, você consegue ter um controle muito melhor sobre o que você está fazendo ao utilizar JPA.

Fica a dica!

 

 

jul 17

Adicionando um Datasource Postgresql ao Jboss 7.1

Pra quem usa ou usava jboss 6, era bem simples você adicionar um datasource novo, bastava você copiar o default e modificar as configurações, gravando esse novo arquivo na pasta deploy do seu server. Porém no Jboss 7 é um pouco diferente, e, diria eu, um tanto quanto burocrático.

Primeiramente é necessário baixar os drivers necessários de acordo com seu banco.

Em seguida copie para

jboss-as-7.1.1.Final/modules/org/postresql/main/

O jar baixado.

O jar precisa necessariamente estar embaixo da pasta main. Além disso nesta pasta main também tem que estar um arquivo xml : module.xml com o seguinte conteúdo:

 
<module xmlns="urn:jboss:module:1.1" name="org.postgresql">
    <properties>
        <property name="jboss.api" value="private"/>
    </properties>

    <resources>
        <resource-root path="postgresql-X.X-XXX.jdbcN.jar"/>
    </resources>

    <dependencies>
        <module name="javax.api"/>
    </dependencies>
</module>

Agora abra o arquivo jboss-as-7.1.1.Final/standalone/configuration/standalone.xml  e procure pela tag <subsystem xmlns=”urn:jboss:domain:datasources:1.0″>  . Dentro dela deverá ser adicionado o seguinte conteúdo:

<datasources>
    <datasource jta="false" jndi-name="java:/PostgresDS"
        pool-name="postgres-ds" enabled="true" use-ccm="false">
        <connection-url>jdbc:postgresql://localhost:5432/meu_banco
        </connection-url>
        <driver-class>org.postgresql.Driver</driver-class>
        <driver>postgresql</driver>
        <security>
            <user-name>usuario</user-name>
            <password>senha</password>
        </security>
        <validation>
            <validate-on-match>false</validate-on-match>
            <background-validation>false</background-validation>
        </validation>
        <statement>
            <share-prepared-statements>false</share-prepared-statements>
        </statement>
    </datasource>
    <drivers>
        <driver name="postgresql" module="org.postgresql" />
    </drivers>
</datasources>

Agora… Nada mais a ser feito, fora restartar o jboss, ufa né, bem chatinho criar um datasource a partir da versão 7 do jboss, mas é isso aí.