O Mar de Java

Aventuras de um navegante no mar de Java

  1. A tarefa agora é instalar o Joseki-3.4.3. Para que serve o Joseki? Se você vai ao site, encontra a definição: Joseki é uma engine HTTP que dá suporte ao protocolo SPARQL Protocol e à SPARQL RDF Query language. SPARQL foi desen W3C RDF Data Access Working Group. Isso significa que eu posso ter uma base de dados, no meu caso rodando MySQL com acesso remoto.
  2. Por que o acesso remoto, e por RDF etc? Trata-se de uma pesquisa envolvendo e-Learning e WEB Semântica, em que recursos de aprendizagem possam ser buscados e organizados a partir de sugestões feitas a partir da rede de dependências entre conceitos em um dado domínio conceitual. Os recursos, estarão armazenados em uma base de dados relacional, indexados por metadados escritos com base na RDF.
  3. Como esses metadados serão guardados? Os metadados estarão armazenados em um componente do Jena, o SDB que provê armazenagem escalável e queries em bases de dados RDF utilizando o SQL convencional, tanto como aplicações standalone, J2EE e outros framewoks. O SDB foi projetado para dar suporte ao SPARQL, a linguagem de consulta desenvolvida pelo W3C RDF Data Access Working Group.
  4. Para fazer isso é necessária a instalação do Joseki e do SDB combinados. As dores de cabeça começam nesse ponto. De modo geral esses aplicativos, escritos em Java, não têm documentação alguma e o navegante tem que se mover pela intuição.
  5. O mar de Java, além de ser reconhecidamente tempestuoso, tem muitos rochedos pelo caminho que você tem que navegar atravessando o nevoeiro da ignorância. Para montar o pacote a ser utlizado no servidor Apache Tomcat6, é preciso usar o Maven, um gerenciador de projetos, produzido pela Apache Foundation.
  6. Vamos lá. Como criar um aplicativo que integre o SDB e Joseki, para em seguida ser instalado no Tomcat6. Tecnicamente isso quer dizer “deploy”. Todos falam tem que instalar o arquivo no Tomcat6. Ok, mas como? Vamos ver isso mais adiante.
  7. Primeiro: baixar o Joseki do site de dowload. Simples? Mais ou menos…parece que o Joseki-3.4.3. Há diferenças entre os arquivos baixados do site e que você baixa via CVS, este naturalmente, atualizado. Resolvi usar o antigo, o 3.4.3, provavelmente mais estável.
  8. Construção de uma aplicação Web. Escolhi o Maven, como construtor. Por que? Era a referência que eu tinha. Pode-se usar o ant, dizem.
    1. O comando utilizado é:

mvn archetype:generate -DgroupID=<namespace> -DartifactId=sdb-joseki -DarchetypeArtifactId=maven-archetype-webapp

Coisas a serem observadas:

  1. o comando antigo era: mvn archetype:create, está desatualizado (deprecated);
  2. -DgroupId indica um identificador único para o projeto. Em geral é o namespace da organização: p. Ex: br.ufrj
  3. -DartifactID, é o indicador do artefato que está sendo montado. No caso seguindo o que diz… sdb-joseki
  4. -DarchetypeArtifactID=maven-archetype-webapp esse último é fundamental. Ele está definindo o tipo de aplicativo que está sendo montado, no meu caso um applicativo para web

Como resultado o Maven vai criar no meu diretório /home/ (estou usando Linux) um folder chamado sdb-joseki, todo preparado para um projeto Web. Bom, não é?

  1. Esse diretório é criado meio “vazio”. Você tem que colocar algumas coisas. Vamos lá, que coisas? Primeiro, copiar o conteúdo de Joseki/<versão>/webapps/joseki/ para o diretório sdb-joseki/src/main/webapp/; cuidado você tem que fazer isso como root. E, olha, por incrível que possa parecer, para os viciados em interfaces gráficas, como é o meu caso, trabalhar com linha de comando é melhor!
  2. Tem que adicionar, também, o joseki-config.ttl ao diretório /src/main/resources. O site do devx diz que deve adicionar também o log4j.xml. Mas não achei esse arquivo em lugar nenhum….e agora? Será que não precisa mais. Estranho…mas deixa em suspenso.
  3. O que faz o joseki-config.ttl? Bem ele é um arquivo escrito em turtle (ttl), um dialeto do RDF um pouco mais compreensível para humanos. IMPORTANTE: tem que mudar o nome do usuário e o password, para ficar compatível com o que foi definido no SDB. Lembra que o Joseki é um motor SPARQL e precisa falar com o banco de dados que armazena as triplas (um triple store) por intermédio das quais serão feitas as pesquisas.
    1. Nosso caso um pouco mais complicado: não se trata de apenas um DB-teste, mas um repositório de objetos digitais que são indexados por metadados escritos em RDF que, por sua vez, tem que ser mais ou menos compatível com o LOM do IEEE. Punk!!!
  4. Coisas sugeridas no devX, para o caso do teste: comentar o no arquivo WEB-INF/web.xml, na parte relativa livros:

<!– Demo Service

<servlet-mapping>

<servlet-name>SPARQL service processor</servlet-name>

<url-pattern>/books</url-pattern>

</servlet-mapping>

–>

A hora do vamos ver:

  1. Muito bem, é hora de testar…Primeiro os testes da base de dados que funcionaram perfeitamente. Todas as triplas foram carregadas e as consultas básicas rodaram bem.
  2. Em seguida, testar com o Tomcat6. Os testes do Junit não se saíram muito bem não…Primeiro um erro (crasso) o arquivo .war não continha o servlet necessário…tem que carregar o Joseki<versão>.jar corretamente. Por alguma razão, o Joseki.jar utilizado não continha todos os componentes, e o principal deles, o que se refere ao servlet.
  3. Consertado o problema. Vamos ao teste outra vez. Sucesso parcial. Duas reclamações: do compilador: problemas com o UTF-8, ele avisa, não foi propriamente um erro, mas uma warning – ou seja, um cartão amarelo. E, o pior, um problema com os “bridges”. O que é isso?
  4. Algo absolutamente críptico:

ERROR [main] (SDB_QC.java:64) – Null bridge

** Error:    Slice 1(com.hp.hpl.jena.sdb.test.junit.QueryTestSDB)

com.hp.hpl.jena.sdb.compiler.SDB_QC.exec(SDB_QC.java:65)

Test: Slice 2

ERROR [main] (SDB_QC.java:64) – Null bridge

** Error:    Slice 2(com.hp.hpl.jena.sdb.test.junit.QueryTestSDB)

com.hp.hpl.jena.sdb.compiler.SDB_QC.exec(SDB_QC.java:65)

Test: Slice 3

ERROR [main] (SDB_QC.java:64) – Null bridge

** Error:    Slice 3(com.hp.hpl.jena.sdb.test.junit.QueryTestSDB)

com.hp.hpl.jena.sdb.compiler.SDB_QC.exec(SDB_QC.java:65)

Test: Slice 4

ERROR [main] (SDB_QC.java:64) – Null bridge

** Error:    Slice 4(com.hp.hpl.jena.sdb.test.junit.QueryTestSDB)

com.hp.hpl.jena.sdb.compiler.SDB_QC.exec(SDB_QC.java:65)

Test: Slice 5

ERROR [main] (SDB_QC.java:64) – Null bridge

** Error:    Slice 5(com.hp.hpl.jena.sdb.test.junit.QueryTestSDB)

com.hp.hpl.jena.sdb.compiler.SDB_QC.exec(SDB_QC.java:65)

Test: Slice 6

ERROR [main] (SDB_QC.java:64) – Null bridge

** Error:    Slice 6(com.hp.hpl.jena.sdb.test.junit.QueryTestSDB)

com.hp.hpl.jena.sdb.compiler.SDB_QC.exec(SDB_QC.java:65)

Test: Distinct 1

Test: Distinct 2

===========================================

Tests = 82 : Successes = 75 : Errors = 6 : Failures = 1

Error:    Slice 1(com.hp.hpl.jena.sdb.test.junit.QueryTestSDB): null

Error:    Slice 2(com.hp.hpl.jena.sdb.test.junit.QueryTestSDB): null

Error:    Slice 3(com.hp.hpl.jena.sdb.test.junit.QueryTestSDB): nul

Error:    Slice 4(com.hp.hpl.jena.sdb.test.junit.QueryTestSDB): null

Error:    Slice 5(com.hp.hpl.jena.sdb.test.junit.QueryTestSDB): nul

Error:    Slice 6(com.hp.hpl.jena.sdb.test.junit.QueryTestSDB): nul

Failure:  Unicode-5(com.hp.hpl.jena.sdb.test.junit.QueryTestSDB): Results sets not the same

A Hora do Pânico!

Caraca! O que é isso? Vamos à lista de discussões do Jena. Achei! Trata-se de um bug. Remédio: mudar para a versão SDB-1.3.4, ela fixa o bug… Ok, vamos começar tudo de novo… Isso fica para o próximo post…

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: