Encontrei este link: http://agilesoftwaretesting.com/?p=111, que fala o seguinte:

Faça um método em java como:

public static void waitForAjax(Selenium selenium, String timeout) {
    String js_condition =
      "selenium.browserbot.getCurrentWindow().jQuery.active == 0";
    selenium.waitForCondition(js_condition, timeout);
}

O valor da variável js_condition dependerá do framework JS que está sendo utilizado no site. Basicamente ele segue o seguinte formato:

"selenium.browserbot.getCurrentWindow()." + library specific string + " == 0"

Onde a parte específica pode ser:

jQuery: "jQuery.active"
Prototype: "Ajax.activeRequestCount"
Dojo: "dojo.io.XMLHTTPTransport.inFlight.length"

A entrada em produção começou no dia 30/10/2009 no início da noite, onde o sistema antigo foi alterado para não permitir a utilização do saldo nem o login dos usuários. Após um certo tempo, a migração de dados do sistema antigo para o sistema novo foi iniciada. Essa parte deve ter demorado em torno de 10 horas. Após isto, o novo sistema foi liberado para o pessoal que estava dentro do UOL para a homologação. Foram encontrados alguns problemas (nada sério, ex.: tela de consulta do CEP no cadastro não estava funcionando) que foram corrigidos de forma fácil e rápido. Após essa homologação o sistema foi liberado para os usuários no dia 01/11/2009 às 01:11:11.

Essa reescrita de sistema envolveu desde uma remodelagem completa do banco de dados (também foi trocado de SQLServer para Oracle), troca de linguagem de programação (.Net para Java), e duas coisas críticas: troca de conceitos e de regras de negócio.

A troca de conceitos deve-se ao novo jeito que as transações são vistas no sistema. Antes, cada movimentação de dinheiro (ou movimentação financeira) era feita através de uma nova transação. No novo PagSeguro cada intenção de compra, adição de fundos, etc, cria apenas uma transação, sendo que esta transação pode possuir diversas movimentações financeiras associadas.

Outra mudança grande é a maneira como o saldo é “calculado”. Antes, o sistema recalculava o saldo do usuário à partir dos status das transações. Este jeito era extremamente lento. O novo sistema consolida o saldo do usuário, sendo que sempre que é necessário saber o saldo não é necessário fazer cálculos. Essa é a mesma abordagem utilizada por diversos bancos.

Basicamente, esse projeto (na visão de desenvolvimento) durou aproximadamente 1 ano e 9 meses. Durante esse tempo todo tivemos que resolver diversos problemas, tivemos diversas brigas, diversas alegrias e diversas discussões.

Apesar de tudo: obrigado a todas as pessoas que ajudaram de alguma forma com este projeto e boa sorte pra todos nós!

Agora só falta a cervejada para comemorar!

Observação: Não fui eu quem escreveu este post. Apenas fiz a tradução e alteração pois achei muito interessante.

As coisas estúpidas feitas quando se trabalho com programação

1. ORM
   • Estupidez
     Construir um framework próprio de ORM.
   • Consequências
     O projeto vira uma bagunça depois de 2 anos de manutenção com gambiarras para passar pelo meu framework ORM desenvolvido e chamar comandos SQL’s customizados.
   • O que deveria ter sido feito?
     Usar hibernate, iBATIS, Cayenne ou outros parecidos.
2. EAV
   • Estupidez
     Usar uma modelagem de banco de dados do tipo Entity-Attribute-Value model.
   • Consequências
     Solução não escalável e impossibilidade de rodar queries úteis no banco de dados.
   • O que deveria ter sido feito?
     Usar uma modelagem de banco de dados normalizada.
3. Acesso ao Banco de dados
   • Estupidez
     Sincronizar o acesso ao banco de dados com uma conexão compartilhada.
   • Consequências
     Escalabilidade zero. Tempos de respostas muito lentos quando mais de 10 usuários estavam utilizando a aplicação.
   • O que deveria ter sido feito?
     Não fazer isto e utilizar um pool de conexões como c3p0 e usar uma “nova” (reutilizada) conexão retornada do pool para cada ciclo de request / response.
4. IDE
   • Estupidez
     Evitar aprender e utilizar uma IDE.
   • Consequências
     Falta de habilidade de compilar, testar e fazer o deploy da aplicação rapidamente e / ou geralmente fazer qualquer coisa útil.
   • O que deveria ter sido feito?
     Familiarizar-me com uma IDE. Ex.: NetBeans, eclipse, etc.
5. Transações
   • Estupidez
     Não usá-las.
   • Consequências
     Corromper os dados da aplicação.
   • O que deveria ter sido feito?
     Usar transações do banco de dados. No MySQL usar InnoDB.
6. Prepared Statements
   • Estupidez
     Usar Statements, concatenação de strings e escapar caracteres para montar queries “seguras”.
   • Consequências
     Possibilidade de SQL Injections na aplicação. É possível logar utilizando por exemplo “or 1=1;delete from users;” e alterar o estado do banco de dados de uma forma muito desagradável.
   • O que deveria ter sido feito?
     Usar Prepared Statements que montam e escapam corretamente as queries dependendo do driver JDBC utilizado.
7. Lógica de Negócios
   • Estupidez
     Fazer isto nos templates (JSP).
   • Consequências
     Aplicação de manutenção difícil.
   • O que deveria ter sido feito?
     Fazer isto utilizando o padrão MVC com servlets ou com um Front Controller. Melhor se utilizar um framework MVC open source como Struts, Spring MVC, etc.

Encontrei a solução parcial neste post:http://www.neowin.net/forum/index.php?s=d21af43a292e783de98d0644c0824b70&showtopic=689476&pid=590047756&st=0&#entry590047756

A solução descrita não funcionou, mas após algumas alterações na solução, serviu para o que eu precisava:

/***
* T3_allfiles
* based upon T3_APR.java from Shadowmite's forum
*
* This file will extract a binary file from it's
* Palm PDB prison. Just drop this in the directory
* that contains the *.pdb files, and run it. It'll
* get them all. Well, mostly. See next.
*
* This file is NOT made to extract the rom image.
* Use Grack's RomTool for that.
*/

import java.io.*;

public class T3_allfiles {

public static void main(String[] args) throws Exception {
File directory = new File(“/home/fabio/Desktop/pdb/”);
String[] files = directory.list(new PDBfilter());

for (String individualFile : files) {
pdb2(“/home/fabio/Desktop/pdb/” + individualFile);
}
}

static void pdb2(String file) throws Exception {
System.out.println(file);
RandomAccessFile in = new RandomAccessFile(file, “r”);
in.skipBytes(76);
int numRec = in.readShort();
int[] toc = new int[numRec];
for (int i = 0; i < numRec; ++i) {
toc[i] = in.readInt();
in.readInt();
}
for (int i = 0; i < numRec; ++i) {
in.seek(toc[i]);
short fileNameSize = in.readShort();
byte[] fn = new byte[fileNameSize];
in.read(fn);

String fileName = new String(fn);
System.out.println(“\t” + fileName);

String[] directories = fileName.split(“\\/”);
String directory = “.”;
for (int j = 0; j < directories.length – 1; j++) {
directory += File.separator + directories[j];
}
new File(directory).mkdirs();

BufferedOutputStream out = new BufferedOutputStream(new FileOutputStream(fileName));

if (i < toc.length – 2) {
int bytesToRead = toc[i + 1] – toc[i] – fileNameSize – 2;
while (bytesToRead > 0) {
out.write(in.read());
bytesToRead–;
}
} else {
int b;
while ((b = in.read()) > -1) {
out.write(b);
}
}

out.close();
}
}
}

class PDBfilter implements FilenameFilter {
public boolean accept(File dir, String name) {
if (new File(dir, name).isDirectory()) {
return false;
}

name = name.toLowerCase();
return name.endsWith(“.pdb”);
}
}

Após alguns dias procurando um descompilador java, achei este:

JD-Gui

Este descompilador é muito bom, devido à diversas features, como por exemplo, poder descompilar um jar inteiro, fazer links entre os arquivos descompilados, etc.

Permission denied to get property Location.href

Procurando no google, encontrei o seguinte blog:

http://www.woloszyn.org/2008/04/22/selenium-and-the-permission-denied-to-get-property-locationhref-problem/

Este blog mencionava que o problema era causado por um redirect enviado pelo response do servidor. A solução desse blog foi não utilizar o redirect.

Em outro site:

http://www.nabble.com/Permission-denied-to-get-property-Location.href-td8081383.html

Falava que só bastava utilizar o *chrome ou *iehta (no meu código estava sendo utilizado o *firefox). Após esta alteração, tudo voltou a funcionar normalmente.

package br.com.test;

public interface IService {

    int myServiceMethod(String myServiceParameter);

}

Segue abaixo a implementação, repare no uso da anotação “@Transactional” na classe (isto indica que a classe toda deve estar associada à um contexto transacional. É possível também marcar métodos:

package br.com.test;

import org.springframework.transaction.annotation.Transactional;

@Transactional
public class ServiceBean implements IService {

    public int myServiceMethod(String myServiceParameter) {
        return Integer.parseInt(myServiceParameter);
    }

}

Agora só falta configurar o “applicationContext.xml” do Spring:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xmlns:aop="http://www.springframework.org/schema/aop"
     xmlns:tx="http://www.springframework.org/schema/tx"
     xsi:schemaLocation="
     http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
     http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.5.xsd
     http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd">

  <bean id="myService" class="br.com.test.ServiceBean"/>

  <tx:annotation-driven transaction-manager="txManager"/>

  <bean id="txManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
    <property name="dataSource" ref="dataSource"/>
  </bean>

  <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
    <property name="driverClassName" value="${jdbc.driverClassName}" />
    <property name="url" value="${jdbc.url}" />
    <property name="username" value="${jdbc.username}" />
    <property name="password" value="${jdbc.password}" />
  </bean>
</beans>

Repare no uso da tag “<tx:annotation-driven transaction-manager=”txManager”/>”. Esta tag ativa a configuração de transações baseada em anotações.

Até aí é muito simples utilizar o gerenciamento de transações do Spring. O problema que tive foi o seguinte: meu serviço possuía uma interface, e esta interface estava sendo implementada por uma classe abstrata. Essa classe abstrata definia o método que eu queria que fosse transacional. Depois eu criei uma terceira classe que extendia essa classe abstrata. Coloquei a anotação “@Transactional” na classe concreta, e o Spring não gerenciava as transações no método definido na classe abstrata. Para resolver o problema só foi necessário colocar a anotação da classe abstrata.