Interceptors 2.0
Lucas Cavalcanti
Sérgio Lopes
--
You received this message because you are subscribed to the Google Groups "caelum-vraptor-dev" group.
To post to this group, send email to caelum-vr...@googlegroups.com.
To unsubscribe from this group, send email to caelum-vraptor-...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/caelum-vraptor-dev?hl=en.
Otávio Scherer Garcia
Rafael Ponte
--
You received this message because you are subscribed to the Google Groups "caelum-vraptor-dev" group.
To post to this group, send email to caelum-vr...@googlegroups.com.
To unsubscribe from this group, send email to caelum-vraptor-...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/caelum-vraptor-dev?hl=en.
Lucas Cavalcanti
Guilherme Silveira
grande parte dos casos de criação de interceptors.
Caçando os corner cases para suportá-los, consigo só pensar em poucos
corner cases que uma ou outra config extra resolvem:
1 e 2 - se desejo rodar um interceptor no (1) começo ou no (2) final do stack.
Meu interceptor desconhece quem é o primeiro atual e quem é o ultimo
atual, mas ele sabe que ele deseja estar na ponta, ele fica sem saber
dizer o before (1) ou o after (2) dele. Ele não saberia quem está (na
instalacao padrao é o FTDVInterceptor, mas não tenho como ter
certeza).
Nota: Só consigo ver vantagem no caso de querer ficar em ultimo da
fila (trocar o algoritmo de FTDV).
Solução simples: permitir dizer: "i am first/last". Problema
envolvido: se dois interceptors dizerem que é first, como resolver o
conflito.
3 - se desejo substituir um interceptor com a minha própria
implementação. Por exemplo, se desejo trocar o
ParametersInstantiatorInterceptor pelo meu próprio, não desejo falar
que é antes ou depois, mas sim "instead", e posso ou não querer
rodá-lo no mesmo lugar que o PII rodaria (muito provavelmente desejo
no mesmo lugar).
Solução simples: extrair interfaces de todos e usar tais interfaces
para todos os befores e afters.
4 - se algum interceptor trocar de lugar com o padrão, os befores que
referenciavam o padrão serão ignorados pelo algoritmo (ou darão erro,
pior), resultando em uma sequência indevida.
Solução simples: extrair as interfaces resolve se todos referenciarem
ela, e não a implementação. Se referenciarem a implementação, pimpa.
Manter suporte simultaneo ao Execution garante.
========
Em questão de implementação, primeiro suportar o registro programático:
interceptors.add(MeuInterceptor.class).before(Outro.class);
interceptors.add(MinhaView.class).at(Position.TAIL);
E usá-lo para suportar a anotação:
interceptors.add(Xpto.class)
.before(annotation.before())
.after(annotation.after())
.at(annotation.at());
Guilherme Silveira
Caelum | Ensino e Inovação
http://www.caelum.com.br/
2010/12/16 Lucas Cavalcanti <lucasm...@gmail.com>:
Lucas Cavalcanti
1 e 2 - se desejo rodar um interceptor no (1) começo ou no (2) final do stack.
Meu interceptor desconhece quem é o primeiro atual e quem é o ultimo
atual, mas ele sabe que ele deseja estar na ponta, ele fica sem saber
dizer o before (1) ou o after (2) dele. Ele não saberia quem está (na
instalacao padrao é o FTDVInterceptor, mas não tenho como ter
certeza).
Nota: Só consigo ver vantagem no caso de querer ficar em ultimo da
fila (trocar o algoritmo de FTDV).
Solução simples: permitir dizer: "i am first/last". Problema
envolvido: se dois interceptors dizerem que é first, como resolver o
conflito.
3 - se desejo substituir um interceptor com a minha própria
implementação. Por exemplo, se desejo trocar o
ParametersInstantiatorInterceptor pelo meu próprio, não desejo falar
que é antes ou depois, mas sim "instead", e posso ou não querer
rodá-lo no mesmo lugar que o PII rodaria (muito provavelmente desejo
no mesmo lugar).
Solução simples: extrair interfaces de todos e usar tais interfaces
para todos os befores e afters.
4 - se algum interceptor trocar de lugar com o padrão, os befores que
referenciavam o padrão serão ignorados pelo algoritmo (ou darão erro,
pior), resultando em uma sequência indevida.
Solução simples: extrair as interfaces resolve se todos referenciarem
ela, e não a implementação. Se referenciarem a implementação, pimpa.
Manter suporte simultaneo ao Execution garante.
========
Em questão de implementação, primeiro suportar o registro programático:
interceptors.add(MeuInterceptor.class).before(Outro.class);
interceptors.add(MinhaView.class).at(Position.TAIL);
E usá-lo para suportar a anotação:
interceptors.add(Xpto.class)
.before(annotation.before())
.after(annotation.after())
.at(annotation.at());
Paulo Silveira - Caelum
> O mais chato da implementação vai ser implementar na mão o algoritmo de
> ordem topologica
> (não achei pronto pra java o.o)
o ninja lucas reclamando de uma busca em profundidade?? o.o
:)
boa lucas!
Paulo
Lucas Cavalcanti
2010/12/17 Lucas Cavalcanti <lucasm...@gmail.com>:
> O mais chato da implementação vai ser implementar na mão o algoritmo deo ninja lucas reclamando de uma busca em profundidade?? o.o
> ordem topologica
> (não achei pronto pra java o.o)
Guilherme Silveira
github.com/guilhermesilveira/uva-problems tem.mas precisa procurar.
Am 17.12.2010 01:00 schrieb "Lucas Cavalcanti" <lucasm...@gmail.com>:
2010/12/17 Paulo Silveira - Caelum <paulo.s...@caelum.com.br>
>
> 2010/12/17 Lucas Cavalcanti <lucasm...@gmail.com>:
> > O mais chato da implementação vai ser...
:Pbusca em profundidade + montar um grafo. Nem lembro mais comofas :P
>
>
> :)
>
> boa lucas!
>
> Paulo
>
> > []'s
> >>
> >> Guilherme Silveira
> >> Caelum | Ensino e ...
--You received this message because you are subscribed to the Google Groups "caelum-vraptor-dev" group...
Guilherme Silveira
O problema de rodar por último é que você não sabe quem é o penúltimo e último atual.talvez seja o ftdv, mas talvez não, pois você queria substitui-lo, ou pois outro cara substituiu ele.enquanto manter compatibilidade com o executor ignora esse corner, e implementa se pedirem só...
Sobre o instead, com a configuração programática ele consegue mudar a ordem também, resolve isso, certo?
Am 17.12.2010 01:00 schrieb "Lucas Cavalcanti" <lucasm...@gmail.com>:
2010/12/17 Paulo Silveira - Caelum <paulo.s...@caelum.com.br>
>
> 2010/12/17 Lucas Cavalcanti <lucasm...@gmail.com>:
> > O mais chato da implementação vai ser...
:Pbusca em profundidade + montar um grafo. Nem lembro mais comofas :P
>
>
> :)
>
> boa lucas!
>
> Paulo
>
> > []'s
> >>
> >> Guilherme Silveira
> >> Caelum | Ensino e ...
--You received this message because you are subscribed to the Google Groups "caelum-vraptor-dev" group...
Rafael de F. Ferreira
Sobre a maneira de substituir um dos interceptors, eu acho que seria
legal aproveitar para pensar numa maneira melhor de substituir
componentes em geral. Atualmente o jeito é implementar a interface do
componente e anotar com @Component e usar o fato que o VRaptor dá
preferência para componentes da aplicação sobre os internos. O
problema é que na maioria das vezes (IME) não queremos substituir o
componente inteiro, apenas customizar um pouco. Hoje, para fazer isso
precisamos de heranca de implementacao (blergh); o ideal é claro seria
fazer um decorator.
Já encontrei isso na prática algumas vezes, a última foi para
customizar o xStream na serialização e deserialização. Tive que fazer
uns overrides feiosos de getXStream() por aí, quando a solução mais
legal seria que tivessemos uma XStreamFactory e os usuarios
customizariam o objeto XStream via decorators.
Não pensei muito sobre os detalhes, mas talvez algo assim:
@Component @Decorator
public class XStreamFactoryCustomization implements XStreamFactory {
public XStreamFactoryCustomization(XStreamFactory original) {....
E poderíamos fazer um esquema parecido com a ordenação de interceptors
para dar suporte a múltiplos decorators:
@Component @Decorator(decorates=DefaultFoo.class)
public void MyFoo1 implements Foo {
public MyFoo1(Foo original) {}
}
@Component @Decorator(decorates=MyFoo1.class)
public void MyFoo2 implements Foo {
public MyFoo1(Foo original) {}
}
Um possível problema é que poderiam argumentar que esse tipo de coisa
ficaria melhor como feature do container de DI do que do VRaptor, mas
como a proposta de ordering constraints para interceptors mostra, essa
linha está ficando menos clara.
Cheers
--
Rafael de F. Ferreira.
http://www.rafaelferreira.net/
2010/12/17 Guilherme Silveira <guilherme...@caelum.com.br>:
Rafael Ponte
Guilherme Silveira
> @Component
> public class MyFoo1 implements Foo {
> public MyFoo1(DefaultFoo original) {}
> }
> @Component
> public class MyFoo2 implements Foo {
> public MyFoo2(MyFoo1 original) {}
> }
Mais limpo, mais claro que você está atrelado ao comportamento desse
cara, mesmo resultado. Só tem que ver como suportar. E no teste, você
teria que passar um cgilibzado desse cara.
Detalhe: como na conversa que tivemos, *tudo* isso se resolveria se a
ordem de registro dos componentes no container fosse programática ao
invés de discovery no classpath, correto? O que acham? Eu ainda to com
essa pulga em relação a suportar *todo* o wiring programatico usando o
"newie".
Abraço
Guilherme Silveira
Caelum | Ensino e Inovação
http://www.caelum.com.br/
2010/12/17 Rafael de F. Ferreira <raf...@rafaelferreira.net>:
> Topological sort FTW.
>
> Sobre a maneira de substituir um dos interceptors, eu acho que seria
> legal aproveitar para pensar numa maneira melhor de substituir
> componentes em geral. Atualmente o jeito é implementar a interface do
> componente e anotar com @Component e usar o fato que o VRaptor dá
> preferência para componentes da aplicação sobre os internos. O
> problema é que na maioria das vezes (IME) não queremos substituir o
> componente inteiro, apenas customizar um pouco. Hoje, para fazer isso
> precisamos de heranca de implementacao (blergh); o ideal é claro seria
> fazer um decorator.
>
> Já encontrei isso na prática algumas vezes, a última foi para
> customizar o xStream na serialização e deserialização. Tive que fazer
> uns overrides feiosos de getXStream() por aí, quando a solução mais
> legal seria que tivessemos uma XStreamFactory e os usuarios
> customizariam o objeto XStream via decorators.
>
> Não pensei muito sobre os detalhes, mas talvez algo assim:
> @Component @Decorator
> public class XStreamFactoryCustomization implements XStreamFactory {
> public XStreamFactoryCustomization(XStreamFactory original) {....
>
> E poderíamos fazer um esquema parecido com a ordenação de interceptors
> para dar suporte a múltiplos decorators:
>
>
Lucas Cavalcanti
O problema de rodar por último é que você não sabe quem é o penúltimo e último atual.talvez seja o ftdv, mas talvez não, pois você queria substitui-lo, ou pois outro cara substituiu ele.enquanto manter compatibilidade com o executor ignora esse corner, e implementa se pedirem só...
Hoje, para fazer isso precisamos de heranca de implementacao (blergh); o ideal é claro seria fazer um decorator.
Um possível problema é que poderiam argumentar que esse tipo de coisa
ficaria melhor como feature do container de DI do que do VRaptor, mas
como a proposta de ordering constraints para interceptors mostra, essa
linha está ficando menos clara.
Lucas, o Spring ordena seus advices através da interface Ordered, você pode ver aqui, http://static.springsource.org/spring/docs/3.0.x/reference/aop.html - mais especificamente no tópico "7.2.4.7 Advice ordering".
Detalhe: como na conversa que tivemos, *tudo* isso se resolveria se a
ordem de registro dos componentes no container fosse programática ao
invés de discovery no classpath, correto? O que acham? Eu ainda to com
essa pulga em relação a suportar *todo* o wiring programatico usando o
"newie".
Rafael de F. Ferreira
> Vamos lá:
> @Guilherme
>>
>> O problema de rodar por último é que você não sabe quem é o penúltimo e
>> último atual.talvez seja o ftdv, mas talvez não, pois você queria
>> substitui-lo, ou pois outro cara substituiu ele.enquanto manter
>> compatibilidade com o executor ignora esse corner, e implementa se pedirem
>> só...
>
> não dá pra rodar depois do ftdv pq ele não chama o stack.next ;) então ele é
> o último
>
> @Ferreira
>>
>> Hoje, para fazer isso precisamos de heranca de implementacao (blergh); o
>> ideal é claro seria fazer um decorator.
>
> Não sei se decorators cobrem todos os casos.
O jeito que tá hoje pode continuar funcionando. Mas eu acho que
decorators cobrem todos os casos sim :)
Rafael de F. Ferreira
> Ferreira, não seria mais fácil sem anotação?
>
>> @Component
>> public class MyFoo1 implements Foo {
>> public MyFoo1(DefaultFoo original) {}
>> }
>
>> @Component
>> public class MyFoo2 implements Foo {
>> public MyFoo2(MyFoo1 original) {}
>> }
>
> Mais limpo, mais claro que você está atrelado ao comportamento desse
> cara, mesmo resultado. Só tem que ver como suportar. E no teste, você
> teria que passar um cgilibzado desse cara.
Looks good.
>
>
> Detalhe: como na conversa que tivemos, *tudo* isso se resolveria se a
> ordem de registro dos componentes no container fosse programática ao
> invés de discovery no classpath, correto? O que acham? Eu ainda to com
> essa pulga em relação a suportar *todo* o wiring programatico usando o
> "newie".
Não sei se vale a pena mudar o VRaptor nessa direćão. Os usuários já
estão acostumados com DI+classpath scanning.