Isso quer dizer que você pode gerar um scaffold numa aplicação Rails, ir no modelo, trocar ActiveRecord::Base por ActiveLucene::Document e tudo deveria continuar funcionando, com a diferença do modelo estar sendo salvo num índice do Lucene e não num banco de dados relacional.

Dado que os documentos são salvos num índice do Lucene, podemos procurar eles utilizando a sintaxe de query do Lucene, sem esquecer que por ter uma interface similar à do ActiveRecord, podemos também procurar eles por um id.

A classe base do ActiveLucene se chama Document porque ao igual que os documentos de outros sistemas, não tem uma estrutura definida e todos os atributos são dinâmicos, pelo que você não tem que se preocupar com eles.

o ActiveLucene foi extraído do Lunr, um servidor do qual vou falar num futuro post, mas hoje também pode ser utilizado em aplicações nas quais ter um banco de dados relacionais no faz muito sentido e especialmente nas quais se deseja procurar documentos por texto.

A restrição do ActiveLucene é que somente funciona com JRuby, dado que o Lucene é uma biblioteca em Java que roda sobre a JVM. Mesmo assim, caso isso não for um problema, utilizar o ActiveLucene deve ser bem mais simples e leve que utilizar uma solução como o Sphinx ou o Solr, onde dependendo do caso pode resultar numa grande vantagem.

O Lucene tem um monte de funcionalidades e o ActiveLucene não suporta todas elas, mas dependendo das necessidades das pessoas elas serão indo adicionadas ao projeto. Hoje existe um suporte a highlighting e um pouco a paginação, como pode ser visto no seguinte video, junto com uma demonstração básica de como funciona a ferramenta:

Full text search in JRuby with ActiveLucene from Diego Carrion on Vimeo.

Se você gostou do ActiveLucene, considera me recomendar no Working With Rails. Para ficar mais perto das novidades, não deixa de me seguir no Twitter.

Basicamente permitem escrever código como o seguinte:

describe User do
  should_act_as_taggable_on :categories

  should_have_attached_file :logo

  should_index 'addresses.city', :as => :address
  should_have_index_attribute :priority
end

Se esses plugins ajudaram você, considera por favor também me ajudar me recomendando no Working With Rails.

Caso queiramos avaliar x vezes o mesmo script e estejamos chamando o método eval mencionado, o script ira ser compilado x vezes.

O mesmo script precisa ser compilado x vezes?

Não!

O que fazer ao respeito?

A especificação JSR-233 conta com uma classe chamada CompiledScript que como o mesmo nome diz, representa um script compilado, de modo que quando queiramos avaliar o script o único que vamos ter que fazer é executar ele.

Para compilar um script primeiro temos que realizar um casting do engine para a interfase Compilable e logo chamar o metodo compile:

CompiledScript compiledScript = ((Compilable) engine).compile(script)

Logo, quando queiramos avaliar o script compilado o único que vamos ter que fazer e chamar o método eval, passando como parâmetro o contexto (opcional):

Object result = compiledScript.eval(context)

no such file to load -- spec/rake/spectask

O RSpec tinha sido instalado utilizando gem install mas aparentemente existia algo errado com os caminhos: a pasta spec estava sendo procurada em /var/lib/gems/1.8/gems/rspec-1.1.4/lib quando ela estava em /usr/lib/ruby/1.8/ . Após ver essa issue descobri que não era um problema tão pessoal e tal vez algum problema relacionado à Ubuntu e RubyGems . De qualquer jeito, se algum dia alguem chegar aqui procurando a solução a tao problema, eu consegui solucioná-lo criando um link simbólico entre as duas pastas:

sudo ln -s /var/lib/gems/1.8/gems/rspec-1.1.4/lib/spec /usr/lib/ruby/1.8/spec

Executei de novo meu script Rake e dessa vez obteve:

/usr/bin/rcov:516:in `load': no such file to load -- /usr/lib/ruby/bin/spec (LoadError)
        from /usr/bin/rcov:516

Aparentemente ta tudo zoado!

Tomara que exista uma melhor solução para esses problemas de paths que sair criando links simbólicos, como fiz novamente nesse caso:

sudo ln -s /var/lib/gems/1.8/bin/spec /usr/lib/ruby/bin/spec

Que saudades senti do meu leopardo.

Como isolar aquelas duas aplicações de modo que possam utilizar uma biblioteca compartilhada que não possa ser utilizada por uma terceira aplicação?

Para responder a pergunta era necessário entender o conceito de classloader e também como trabalham os classloaders do servidor envolvido, que nesse caso era o JBoss.

Caso alguem não entenda muito bem o que são os classloaders e como eles trabalham, pode ler esse excelente post e lapidar o aprendizado com esse feedback muito bom do Rodrigo Kumpera.

Vou dizer que menti faz um pouco. Na verdade não é necessário entender o conceito de classloader para poder isolar aplicações devido a que JBoss torna o processo muito simples e transparente, mas eu acho conveniente para ter uma idéia de como funciona o negócio, o que é realizado por trás.

Mas então, o que deve ser feito? Existem varias alternativas mas a mais simples é criar um arquivo .ear contendo os projetos desejados e alterar o arquivo ear-deployer.xml localizado na pasta deploy do servidor JBoss. No arquivo mencionado devera ser trocado o valor do atributo Isolated para true:

<attribute name=\"Isolated\">true</attribute>

O JBoss utilizara um classloader para cada deploy ear, pelo que as aplicações dentro dele ficaram num contexto isolado.

Agora, o que acontece se eu tenho somente uma aplicação e quero que ela fique totalmente isolada, preciso por ela num ear? Não, nesse caso não, seria meio que uma gambiarra. No caso que queiramos um classloader para uma única aplicação e não um grupo delas o que devemos fazer é colocar as bibliotecas que desejamos sejam carregadas pelo classloader na pasta WEB-INF/lib da aplicação. Não tenho certeza se isto é uma especificação mas o JBoss Web e o Tomcat entendem que o que esta dentro da pasta WEB-INF é somente visível para a própria aplicação pelo que não teria sentido se as bibliotecas dentro da pasta lib fossem carregadas por um classloader de alto nível.

Finalmente, eu quero que minhas bibliotecas sejam visíveis para tudo mundo, onde devo colocar elas? Nesse caso a resposta é mais fácil, nesse caso basta colocar a biblioteca na pasta lib do servidor ou dentro de uma pasta (lib de preferencia) dentro do projeto ear, somente não esquecer de declarar ela no arquivo application.xml:

<library-directory>lib</library-directory>

Isso e tudo, não se esqueçam que agora a pagina conta com um formulário de contato e toda duvida sera respondida com plácer =)

Talvez tenham se perguntado: qual é a outro opção? Bom, a outra opção e utilizar “sticky sessions”, de modo que o balanceador sempre se conete com o mesmo membro do cluster, o qual possui a sessão do usuário. O ruim das sticky sessions é que ao cair algum nodo do cluster, os dados que se encontravam neles serão perdidos dado que não foram replicados.

Nesse artigo vamos configurar nossa aplicação web para que o JBoss 4.2.2.GA replique a sessão HTTP ao longo de todos os nodos do cluster cade vez que ela sofrer alguma alteração. A configuração é realizada no JBoss Web que utiliza o Tomcat, pelo que a configuração num Tomcat independente não deveria fugir muito do que ira ser mostrado aqui.

Mãos na obra

A configuração é bem simples, são necessários somente dois passos.

O primeiro passo é indicar que nossa aplicação é distribuída. Possivelmente esta configuração já foi feita devido a que estamos supondo que a aplicação já foi configurada para rodar num cluster. De qualquer modo, a configuração é realizada no arquivo web.xml da aplicação; devemos inserir o seguinte trecho dentro do nodo web-app:

<distributable />

O segundo e último passo é configurar um arquivo chamado jboss-web.xml, que sera localizado na pasta WEB-INF. Esse arquivo indicara ao JBoss como e quando replicar a sessão da aplicação:

<jboss-web>
<replication-config>
<replication-trigger>SET</replication-trigger>
<replication-granularity>SESSION</replication-granularity>
</replication-config>
</jboss-web>

O nodo replication-trigger indica quando o JBoss deve replicar os dados. Nesse caso estamos indicando que os dados devem ser replicados cada vez que seja chamado o método setAttribute da sessão (HttpSession).

O nodo replication-granularity indica o que devera ser replicado. Se a sessão não for muito grande, SESSION é uma boa opção porque sera replicada a sessão inteira. Quando a sessão é grande demais, a opção ATTRIBUTE resulta num ganho de performance devido a que somente serão replicados os atributos da sessão que sofreram alteração.

Testando a configuração

Fiz uma aplicação web bem simples para poder testar e comprovar que o JBoss esta replicando os dados da sessão dela. A aplicação guarda na sessão o número de acesos e printa o valor na tela. Cada vez que acessarmos a aplicação, deveria aparecer quantas vezes realizamos a operação, independente de qual nodo do cluster o balanceador escolher para servir.

A aplicação pode ser descarregada de aqui .

Para finalizar, agora o blog possui uma pagina de contato. Qualquer duvida ou pergunta que não quiserem colocar nos comentários pode ser enviada mediante o formulário e eu responderei assim chegar na minha caixa de email.