A página principal exibe o código de um exemplo:

https://ol4jsf.dev.java.net

Muito simples e poderoso! Além da simplicidade, as possibilidades são incríveis.

Download:

https://ol4jsf.dev.java.net/downloads/ol4jsf-core-2.0-SNAPSHOT.jar

Usuários Maven:

Infelizmente, o repositório Maven do Java.net está somente leitura porque eles estão migrando a infraestrutura. O jeito então é atualizar o jar “na unha”.

Obs: Essa funcionalidade encontra-se disponível somente na versão 2.0-snapshot.

@Entity

@Inheritance(strategy = InheritanceType.SINGLE_TABLE

public abstract class P {

@Id @GeneratedValue(strategy = GenerationType.IDENTITY)

private int id;

//Get e Set

}

@Entity

public abstract class P1 extends P {

private String p1Atributo;

//Get e Set

}

@Entity

public abstract class P2 extends P {

private String p2Atributo;

//Get e Set

}

Tabela gerada:

create table p (

dtype character varrying(31) NOT NULL,

id serial NOT NULL,

p1atributo character varrying(255),

p2atributo character varrying(255) ,

constraint p_pkey PRIMARY KEY (id)

)

Observe que o atributo que o JPA utiliza por padrão para fazer a distinção das classes pertinentes à herança é criado antes dos demais campos. Ao chamar o método persist() no entity manager o seguinte insert é enviado ao SGBD:

INSERT INTO P1 (p1atributo) VALUES (‘Teste’) RETURING *;

Na versão 8.3 do driver, o insert acima retornaria um resultset contendo uma única linha com a chave primária sendo a primeira coluna e as demais colunas em seguida. Porém, a versão 8.4 do driver retorna a ordem física dos campos na tabela, ou seja, na ordem que eles foram criados. Dessa forma, o JPA não consegue fazer a persistência do registro. Mas uma coisa pior ainda pode acontecer! Se você tivesse mudado o tipo padrão através da anotação @DiscriminatorColumn para o mesmo tipo da chave primária, o JPA não lançaria nenhum erro e você poderia estar com um valor no ID da sua entidade que não foi o efetivamente inserido no SGBD! Como o tipo padrão é String, um erro de conversão de tipos é disparado e o registro não é inserido.

Como resolvi o problema?

Adotei uma abordagem middle-out, mudando o meu atributo “hibernate.hbm2ddl.auto” (persistence.xml) para “update” ao invés de “create-drop”. Depois disso, alterei a tabela que havia sido gerada efetuando um drop na coluna dtype e fazendo a adição dela novamente, dessa forma o id passa a ser a primeira coluna e, obviamente, a questão é resolvida. Voltei a utilizar a versão 8.4.1 do driver!

Espero ter ajudado.

Até a próxima!

Para começar 2010 com o pé direito nada como uma boa curiosidade para estimular a nossa imaginação.

Com o lançamento do filme 2012, muitas pessoas passaram a conhecer a famosa profecia Maia sobre o possível fim dos tempos ou início de uma nova era.

O fato é que o mundo tem passado por grandes mudanças climáticas. Revistas e noticiários gastam quase 1/3 de seu tempo falando sobre tais acontecimentos. Será que realmente é possível o mundo ter um fim? Talvez imaginar o planeta Terra virando pó é meio complicado. Mas a coisa muda de figura se pensarmos que não vemos nenhum Tiranossauro andando por aí atualmente.

Será que estamos sujeitos a mesma extinção que deu fim a criaturas tão enormes? Será que num futuro não muito distante não passaremos de fósseis?

Muitos podem dizer “O homem tem tecnologia para dominar ou pelo menos prever o comportamento da natureza e os dinossauros não tinham”. Será?

Toda vez que vejo a previsão do tempo dizer: “sol, com tempo nublado a parcialmente nublado com possibilidade de chuva no decorrer do período”, vejo que nossos modelos matemáticos não estão tão avançados assim. Pior ainda, o que mais vejo é gente explicando catástrofes depois que elas acontecem. Por que não conseguiram prever e salvar dezenas, centenas ou até mesmo milhares de vidas? É muito fácil criar uma pseudo lógica que serve nada mais nada menos para dar uma falsa sensação de segurança para a população que, em sua absoluta maioria, nunca vai ter interesse, ou condições, de provar tais proposições.

Certo, sobre a profecia Maia todo mundo já ouviu falar, mas o que são esses números capicua?

Números capicua são números que podem ser lidos tanto da esquerda para direita quando da direta para esquerda sem mudarem seu valor.

Exemplos: 232, 141, 15151, etc.

Mas qual a ligação dos números capicua com a profecia Maia?

Segundo a profecia, no dia 21 de dezembro de 2012 termina o grande ciclo. Em outras palavras, essa seria a última data do calendário Maia. Por coincidência, ou não,  cem anos depois, será a última vez na história da humanidade que uma data representará um número capicua. Exatamente às 21h12 21/12/2112.

Será que cometemos um erro na interpretação da última data do calendário Maia?

Será que a civilização Maia utilizou os números capicua na elaboração de seu calendário e, dessa forma, encontrou um possível fim pelo fato do modelo matemático não possuir mais números na sequência? Ou será que realmente todas essas mudanças climáticas fazem parte da profecia e o raríssimo alinhamento com o centro da via láctea que ocorrerá nessa data culminarão no fim de uma era?

Como diz aquela propaganda: “Não são as respostas que movem o mundo mas sim as perguntas”.

Até mais!

Vou ser bastante objetivo pois já são 1:31 AM e estou com sono.

Como vocês sabem o JPA permite 3 tipos de mapeamento de herança. Pois se você está tentando utilizar o Hibernate 3.3.1 (bibliotecas que acompanham o Seam 2.2.0-GA) com o Postgresql 8.4.1 e seu respectivo driver jdbc (postgresql-8.4-701.jdbc3.jar), baseando-se no mapeamento  InheritanceType.SINGLE_TABLE então… simplesmente esqueça! Não vai funcionar.

Acabei de abrir um ticket no JIRA do hibernate:

http://opensource.atlassian.com/projects/hibernate/browse/HHH-4739

Workaround:

Utilize a versão anterior do driver (postgresql-8.3-605.jdbc3).

Isso é perigoso?

Particularmente não gosto de utilizar versões de drivers diferentes da versão do database que estou utilizando, pois podem acontecer erros muito difíceis de depurar. Estou cobrindo minha aplicação com o maior número de testes possíveis para minimizar a probabilidade de ocorrerem comportamentos indesejados. Aconselho vocês a fazerem o mesmo.

Até mais!

Pensando nisso, o framework JBoss Seam fornece uma classe chamada EntityQuery que, ao ser herdada, fornece todos os métodos necessários para execução e retorno da consulta, ordenação e paginação dos registros. Por exemplo, suponha uma classe persistente chamada EntidadeA, o código abaixo já é mais do que o suficiente para construção de uma tela de exibição e pesquisa:

@Name(“entidadeAList”)

public class EntidadeAList extends EntityQuery<EntidadeA> {

private static final String EJBQL = “select a from EntidadeA a”

private static final String[] RESTRICTIONS = { “lower(a.campoA) like lower(concat(#{entidadeAList.entidade.campoA},’%'))”,}

public EntidadeAList() {

setEjbql(EJBQL);

setRestrictionExpressionStrings(Arrays.asList(RESTRICTIONS));

setMaxResults(10);

}

private EntidadeA entidade A;

//Get e Set para entidadeA

}

Prontinho!!! É só criar sua página de exibição e chamar os métodos disponíveis na classe.

Infelizmente (ou felizmente!?), nem todas as aplicações são tão simples asssim. Desenvolvimento uma dessas aplicações não tão simples, precisei de um DTO para encapsular joins espaciais e outras operações geométricas sobre as entidades persistentes. Segue abaixo o pseudo-código:

@Name(“entidadeDTOList”)

public class EntidadeDTOList extends EntityQuery<EntidadeDTO> {

private static final String EJBQL = “select new meupacote.EntidadeDTO(a.nome, intersection(a.theGeom, b.theGeom)) from EntidadeA a, EntidadeB b”

private static final String[] RESTRICTIONS = {“intersects(a.theGeom, b.theGeom) = #{true}”, “lower(a.campoA) like lower(concat(#{entidadeDTOList.entidade.campoA},’%'))”,}

public EntidadeAList() {

setEjbql(EJBQL);

setRestrictionExpressionStrings(Arrays.asList(RESTRICTIONS));

setMaxResults(10);

}

private EntidadeA entidade A;

//Get e Set para entidadeA

}

Nesse caso, simplesmente herdar de EntityQuery não funcionou. O método de navegação “lastFirstResult” dispara a exceção “invalid select clause for query”.

Investigando mais de perto, abri o código-fonte da super classe Query e observei que o erro estava acontecendo dentro do método getCountEjbql(). O grande problema é que a seguinte expressão regular usada pelo Seam não abrange casos um pouco mais complexos:

SUBJECT_PATTERN = “Pattern.compile(“^select(\\w+((\\s+|\\.)\\w+)*\\s+from”, Pattern.CASE_INSENTIVE)

Como não queria criar um fork do Seam “corrigindo” o pattern, preferi sobrescrever o método na minha classe, que no final ficou parecida com o código abaixo:

@Name(“entidadeDTOList”)

public class EntidadeDTOList extends EntityQuery<EntidadeDTO> {

private static final String EJBQL = “select %s from EntidadeA a, EntidadeB b where intersects(a.theGeom, b.theGeom) = true”

private static final String EJBQL_PROJ = “new meupacote.EntidadeDTO(a.nome, intersection(a.theGeom, b.theGeom))”

private static final String[] RESTRICTIONS = { “lower(a.campoA) like lower(concat(#{entidadeDTOList.entidade.campoA},’%'))”,}

public EntidadeAList() {

setEjbql(String.format(EJBQL, EJBQL_PROJ);

setRestrictionExpressionStrings(Arrays.asList(RESTRICTIONS));

setMaxResults(10);

}

@Override

protected String getCountEjbql() {

String query = getRenderedEjbql();

query = query.replace(EJBQL_PROJ, “count(c)”);

return query;

}

private EntidadeA entidade A;

//Get e Set para entidadeA

}

Agora sim! Funcionando de forma satisfatória, porém não ideal. Acho que o Seam já poderia ter feito uma expressão regular que contemplasse esses casos.

Até a próxima!

Vou relatar mais uma experiência que pode poupar muito o tempo de vocês quando tiverem trabalhando com a combinação Seam + Eclipse (com JBoss Developer Tools) + JBoss 5.1.

Hoje precisei fazer uma pequena alteração no faces-config.xml de meu projeto e quando dei um seam explode, sem mais nem menos, o JBoss ficava em loop ao tentar fazer o deploy do projeto. Eu fazia um unexplode e quando, para testar, executava um seam deploy, ele conseguia fazer o deploy normalmente. Resolvi investigar e percebi, pela utilização de um controle de versões (Mercurial), que quando eu salvei o projeto utilizando o JBoss Tools XML Editor ele criou outros arquivos:

>hg status
M exploded-archives\sispetroleogas.war\WEB-INF\faces-config.xml
M resources\WEB-INF\faces-config.xml
M test-build\WEB-INF\faces-config.xml
? exploded-archives\sispetroleogas.war\WEB-INF\.faces-config.xml.jsfdia
? resources\WEB-INF\.faces-config.xml.jsfdia
? test-build\WEB-INF\.faces-config.xml.jsfdia

Bingo! Por alguma razão, o arquivo .faces-config.xml.jsfdia criado no WEB-INF do projeto e copiado pelo “seam explode” no processo de build, faz o JBoss se perder e ele fica em loop infinito. Para resolver o problema bastou apagar esses arquivos e para ele não se repetir utilizo agora o XML Editor padrão do Eclipse que não cria nenhum arquivo adicional.

Até a próxima,

map.events.register(‘click’, map, function (e) {
document.getElementById(‘nodelist’).innerHTML = “Carregando… aguarde…”;
var params = {
REQUEST: “GetFeatureInfo”,
EXCEPTIONS: “application/vnd.ogc.se_xml”,
BBOX: map.getExtent().toBBOX(),
X: e.xy.x,
Y: e.xy.y,
INFO_FORMAT: ‘text/html’,
QUERY_LAYERS: map.layers[1].params.LAYERS,
FEATURE_COUNT: 50,
Srs: ‘EPSG:4291′,
Layers: ‘topp:campos’,
Styles: ”,
WIDTH: map.size.w,
HEIGHT: map.size.h,
format: ‘image/png’};
OpenLayers.loadURL(“http://localhost:8080/geoserver/wms”, params, this, setHTML, setHTML);
OpenLayers.Event.stop(e);
});

Achou muito código? Que tal utlizar o OL4JSF e deixar o código assim:

<m:getFeatureInfo url=”#{request.contextPath}/JGSProxy/wms” layers=”topp:campos” onCompleteJsFunc=”setHTML” queryLayers=”map.layers[1].params.LAYERS” />

Um código muito mais legível e fácil de manter.

Até a próxima!

Link do projeto:  https://ol4jsf.dev.java.net/

Tenho o prazer de anunciar a versão inicial do projeto que tem por objetivo criar um conjunto de componentes JSF sobre a biblioteca OpenLayers. Dessa forma, o desenvolvimento da camada de visualização torna-se mais produtivo e menos propício a erros, tendo em vista que é necessário muito menos código javascript na construção das páginas. Além disso, tem um plugin inicial para o Netbeans e o plugin do Eclipse está a caminho.

Site do projeto: https://ol4jsf.dev.java.net/

Abraços,

Até mais,

Link para pesquisa: clique aqui

* Changelog:

http://jira.codehaus.org/browse/GRAILS?report=com.atlassian.jira.plugin.system.project:changelog-panel

* Download: http://grails.org/Download .
* Documentação: http://grails.org/doc/1.1
* Notas da versão: http://grails.org/1.1+Release+Notes

Principais características da nova versão:

* Standalone GORM – Use GORM em projetos não Grails
* Suporte ao Ant+Ivy e Maven
* O novo framework de Test (disponível na versão anterior na forma de plugin)
* Plugins melhorados – resolução transitiva de plugin, plugins globais,
plugins locais e mais.
* suporte à JSP Tag Library – GSPs agora podem usar JSP taglibs
* Melhoras no Controller – Controle para evitar submissões repetidas, forwards e
includes e tratamento exceções de forma declarativa
* Suporte Spring Namespace – Use Spring namespaces dentro do BeanBuilder