Mirror DSL 1.2

afff

como que pode… realmente achei estranho mesmo… os exemplos não baterem com o que está no src. E realmente não estão, testei vários outros.


Não testei em outras versões.
Mas isso ai…

[code]Class classe = null;
List<Method> listaMetodos = Mirror.on(classe).reflectAll().methods();
String nomeMetodo = “teste”;

for (Method metodo : listaMetodos) {
if (nomeMetodo.equals(metodo.getName())) {
//Do stuff
}
}
[/code]
resolveu em partes… pois ainda não consegui pegar os nomes dos argumentos e os valores deles.
Já engoli a API Reflect e não achei…
http://java.sun.com/javase/6/docs/api/java/lang/reflect/Method.html
Mas desde já agradeço a atenção.
abraços.

É verdade cara…muito estranho…to testando aqui e não consigo pegar o nome do parâmetro por nada.

Achei isso aqui enquanto procurava alguma solução: http://paranamer.codehaus.org/

Vê se funciona…abraços.

@OCESN,

existe um erro na documentação.

Para refletir um método, o correto seria Mirror.on(clazz).reflect().method("methodName).withoutArgs();

Faltou a última chamada, pois você só consegue garantir a unicidade de um método se tiver o nome e os parâmetros.

Vou criar um issue pra corrigir isso.

Quanto ao nome dos parâmetros, eles não existem em tempo de execução. Você tem como recuperar os tipos dos parâmetros, mas não o nome (a não ser que você use o paranamer e compile em modo de debug, se não me engano).

E para pegar os valores que foram passados para o método, apenas reflection não resolveria. Você precisaria instrumentar seu método utilizando AOP (uo simplesmente colocar código no método para que ele exponha os parâmetros).

Jonas,

Baixei o código fonte do projeto e, tive um problema no eclipse.
Todos os métodos que implementavam um método de uma interface e tinham a anotação @Overrride ocorria o seguinte erro:
“The method XXX must override a superclass method”.
Parece que este era um comportamento do compilador java na versao 1.5.
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6399361

Alterei o pom para:

<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.6</source> <target>1.6</target> </configuration> </plugin>
E o erro parou de acontecer.

Vocês estão utilizando a versão 1.6 mesmo?
E parabens à equipe pelo trabalho …

Oi Rafael, tudo bom?

Estranho, no meu ambiente aqui não está dando nenhum erro de compilação. Em qual método, de qual classe isso está acontecendo aí no seu ambiente?

Sobre a versão, no nosso release nós lançamos como versão mínima a 6, no entanto, ontem colocamos no /trunk como 5, pois, no final das contas não há diferença e os usuários que por algum motivo não podem migrar para java 6 e possuam a versao 5 também possam usar o Mirror.

[]'s

Fala Adriano. Blz!

Uma das classes que deu esse erro foi net.vidageek.mirror.invoke.ConstructorHandlerByConstructor.java
Dá uma olhada nesse Sreenshot.

Compilando pela linha de comando usando Java 5 dá erro.
Já com Java6 compila.

[]'s


Oi Rafael, realmente, você tem razão.

Na versão 5 da JDK o @Override só serve para quando vc sobrescreve um método de uma superclasse (através de herança). Na versão 6 eles mudaram o conceito para além de através de herança, através de implementação de interface também, e daí o problema.

Já criei um ticket no nosso bugtracker.

Muito obrigado pelo feedback.

[]'s

[quote=jonasabreu]@OCESN,

existe um erro na documentação.

Para refletir um método, o correto seria Mirror.on(clazz).reflect().method("methodName).withoutArgs();

Faltou a última chamada, pois você só consegue garantir a unicidade de um método se tiver o nome e os parâmetros.

Vou criar um issue pra corrigir isso.

Quanto ao nome dos parâmetros, eles não existem em tempo de execução. Você tem como recuperar os tipos dos parâmetros, mas não o nome (a não ser que você use o paranamer e compile em modo de debug, se não me engano).

E para pegar os valores que foram passados para o método, apenas reflection não resolveria. Você precisaria instrumentar seu método utilizando AOP (uo simplesmente colocar código no método para que ele exponha os parâmetros).[/quote]
Beleza…vou estudar com essas informações.
E desde já agradeço a atenção.
Abraços a todos.

Bem, vamos ao meus comentários outra vez, aqui vão as alterações que eu acho pertinentes, vou colocando o código abaixo, sempre na ordem “original” e depois a minha idéia:

[code=java]//Criando clientes
Cliente cliente = Mirror.on( Cliente.class ).invoke().constructor().withArgs( new Date() );
Cliente cliente = Mirror.on( Cliente.class ).construct( new Date() ); //como eu gostaria que fosse

//chamando métodos
Mirror.on( cliente ).invoke().method( “setDataDeNascimento” ).withArgs( new Date() );
Mirror.on( cliente ).invoke(“setDataDeNascimento”).with( new Date() );

//alterando campos
Mirror.on( cliente ).get().field(“dataDeNascimento”);
Mirror.on( cliente ).get(“dataDeNascimento”);

//lendo campos
Mirror.on( cliente ).set().field(“dataDeNascimento”).withValue( new Date() );
Mirror.on( cliente ).set(“dataDeNascimento”, new Date());[/code]

Classe Cliente:

public class Cliente { private String nome; private Date dataDeNascimento; public Cliente(){} public Cliente( Date dataDeNascimento ) { this.dataDeNascimento = dataDeNascimento; } //gets e sets }

Bem, é isso aí, o arquivo com o patch pra o subversion vai anexado :slight_smile:

Olá Mauricio,

Vou levar estas sugestões para a lista de desenvolvimento.

Obrigado!