Migrando de um projeto com VRaptor 3

Java 7 e CDI 1.1

Para utilizar o VRaptor é necessário possuir o JDK 7 e um Application Server ou Servlet Container que possua suporte ao Servlet 3.1.

Beans.xml

Como agora o VRaptor usa o CDI como container, para ele conseguir escanear suas classes você precisa adicionar o arquivo beans.xml dentro da pasta META-INF/beans.xml de seu projeto. Se você usa maven, adicione em /src/main/resources/META-INF. Você pode usar como exemplo o arquivo beans.xml do nosso blank-project.

Containers IoC

A maior alteração do VRaptor é de usar o CDI (Context Dependency Injection). Com isso não é necessário mais usar os providers anteriores (Guice, Pico e Spring).

O CDI exige que cada classe possua o construtor padrão (sem argumentos). Sendo assim você deverá adicionar o construtor padrão em todos os componentes. E o construtor onde serão injetados os componentes deve possuir a anotação @Inject.

@Controller
public class MeuController {
    private final MeuComponente meuComponente;

    /**
     * @deprecated CDI eyes only
     */
    protected MeuController() {
        this(null);
    }

    @Inject
    public MeuController(MeuComponente meuComponente) {
        this.meuComponente = meuComponente;
    }
}

Static scanning

Se você usava este recurso, ele não é mais necessário, pois o scanning de classes é feito de forma otmizada pelo CDI. Basta remover as configurações do seu build.

Eventos de inicialização

No VRaptor 3, quando você anotava um componente com @ApplicationScoped, o código era executado na inicialização do sistema. Com o uso do CDI, agora é necessário usar a anotação @Observes:

@ApplicationScoped
public class PrintLog {

    public void whenApplicationStarts(@Observes ServletContext context) {
        logger.info("My application is UP");
    }
}

Alterações em assinaturas de métodos e classes

Muitas classes internas foram atualizadas ou removidas. Se você sobrescreveu algum comportamento interno do VRaptor, verifique em nossa api docs as novas assinaturas.

Todos os métodos anotados com @Deprecated do VRaptor 3 foram removidos.

OGNL

Se você usava o OGNL, ele não é mais suportado no VRaptor 4. Atualmente é suportado apenas o IOGI, que possui todas as funcionalidades do OGNL, além de suporte a Set e objetos imutáveis.

Validação

A validação fluente foi removida, e agora você pode usar o Bean Validation. Para compatibilidade você pode usar os métodos Validator.check(boolean, Message) para efetuar validações mais simples.

A interface Validator foi alterada de pacote, e agora está localizada em br.com.caelum.vraptor.validator.Validator.

As classes filhas de Message foram alteradas. A classe ValidationMessage agora é SimpleMessage e o construtor foi alterado para SimpleMessage(String param, String message, Object... params), mantendo assim compatibilidade com as demais implementações.

Converters

Os converters localizados agora fazem parte do pacote padrão, e são registrados automaticamente. Portanto se você tiver a declaração do pacote br.com.caelum.vraptor.converter.l10 no seu web.xml, remova-o.

Os converters sofreram alterações, e agora não recebem mais o objeto ResourceBundle no método convert. Se você precisa usar algo baseado no Locale, você deve injetá-lo no construtor.

A interface Converter foi alterada de pacote, e agora está localizada em br.com.caelum.vraptor.converter.Converter.

Remoção dos escopos

Nós removemos todos os antigos scopos do core do vraptor. No lugar deles, você pode usar os seguintes escopos definidos no pacote javax.enterprise.context:

@javax.enterprise.context.RequestScoped
@javax.enterprise.context.SessionScoped
@javax.enterprise.context.ApplicationScoped
@javax.enterprise.context.ConversationScoped
@javax.enterprise.context.Dependent

Uma alternativa simples para migrar os escopos é fazer um replace de br.com.caelum.vraptor.ioc para javax.enterprise.context nos imports.

Fabricando de componentes

A interface ComponentFactory não existe mais. Desta forma você deve usar o @Produces do CDI. Veja mais no capítulo de componentes.

Sobrescrevendo componentes

No VRaptor3 para sobrescrever os componentes era necessario apenas implementar ou estender a interface ou classe do componente. Por limitações no CDI é necessário agora anotar a sua classe com @Specializes.

@Resource substituído pelo @Controller

A anotação @Resource foi substituída pela anotação @Controller e possui o mesmo efeito.

Não existe mais a interface Localization

No lugar de receber a Localization e chamar os métodos .getLocale() ou .getBundle(), agora você pode injetar diretamente esses elementos, algo como:

public class MinhaClasse {

    @Inject
    private Locale locale;

    @Inject
    private ResourceBundle bundle;
}

A maior diferença é que onde você fazia:

localization.getBundle().getMessage("key");

Você vai chamar diretamente o getString do bundle:

bundle.getString("key");

LinkTo

A funcionalidade LinkTo foi atualizada e agora suporta o uso de métodos nas chamadas. Sendo assim você deve converter todas as chamadas de ${linkTo[Controller].metodo[0, 1]} para ${linkTo[Controller].metodo(0, 1)}. Veja mais informações no capítulo sobre Views.

Pra facilitar a migração deixamos um .sh aqui, que você pode baixar e executar um sed de atualização da sintaxe (para linux e mac, em breve faremos algo pra windows).

Serialização e deserialização

Para seguir com a especificação do HTML5, todas as datas usadas na serialização e deserialização usam o formato ISO8601.

Restfulie

Não é suportado mais no core do VRaptor, mas sim como plugin.