uma outra desvantagem que vejo é nos merges no uso de controle de versão, em XML é um zaralho. o uso de anotações diminui este problema porque você está atualizando o artefato que você desenvolveu ou atualizou e fica mais próximo de saber o que será integrado em uma baseline, por exemplo.
[quote=lgi2020]Esse lance de ter que recompilar e refazer o deploy é a grande desvantagem de Annotation em relação ao XML.
Em ambientes de grandes empresa, solicitar um redeploy em uma aplicação é o equivalente a três partos normais ao mesmo tempo, de três mulheres histéricas juntas, em uma sala de três metros quadrados.[/quote]
eu até concordo que é um complicador, mas num ambiente que tenha controle de versão e com uma IDE, e alguns target’s via ANT ou MAVEN você consegue fazer isto rapidinho.
é só baixar do seu controle de versão efetuar a mudança ou configurar para que seu script faça-o para você.
lembrem-se que só o fato de ser XML não elimina a necessidade do restart/redeploy. O framework (ou a aplicação) precisa explicitamente recarregar as configurações no arquivo quando detectar que ele mudou (ou então reparseá-lo sempre que for usar algo).
Quase ninguém faz isso. Então de qualquer forma precisa reiniciar sim o contexto, mesmo a configuração estando em XMLs.
[quote=faelcavalcanti][quote=lgi2020]Esse lance de ter que recompilar e refazer o deploy é a grande desvantagem de Annotation em relação ao XML.
Em ambientes de grandes empresa, solicitar um redeploy em uma aplicação é o equivalente a três partos normais ao mesmo tempo, de três mulheres histéricas juntas, em uma sala de três metros quadrados.[/quote]
eu até concordo que é um complicador, mas num ambiente que tenha controle de versão e com uma IDE, e alguns target’s via ANT ou MAVEN você consegue fazer isto rapidinho.
é só baixar do seu controle de versão efetuar a mudança ou configurar para que seu script faça-o para você.[/quote]
O problema é que muitas empresas de grande porte não permitem que empresas de desenvolvimento terceirizado tenham acesso direto ao servidor de aplicações.
Um exemplo que acontece em minha empresa:
Prestamos serviço para uma grande empresa brasileira.
Para alterarmos uma aplicação em um Wesbsphere 8.1, temos que enviar o pacote para o cliente que solicita à equipe de infra da empresa que inspecione o pacote e realize o deploy da aplicação. Sempre assim. E o deploy tem hora certa para poder ser feito.
Se houver a necessidade apenas de alterar um arquivo .properties ou um .xml, podemos solicitar a alteração por e-mail e as coisas andam mais rápido, já que, uma vez que a própria equipe de infra do cliente efetuará a alteração e não haverá inspeção de pacote.
Por isso, eu, que também não sou muito fã de ficar escrevendo xmls, em alguns casos, defendo sua utilização.
Acho que poder escolher entre usar os xmls ou não é a chave do sucesso.
Num caso como esse que citei, xml é a saída.
Mas em uma outra aplicação, em outro cliente, usaria annotations com todo o prazer.
Abraços.
apesar de quase ninguém o fazer, porém deve-se estar preparado em um pior caso por exemplo, e neste caso você poderá adicionar algumas configurações adicionais via xml sobrepondo qualquer configuração anotada, já que virou bytecode compilado a partir do código java.
editado: adicionando citação abaixo.
[quote=lgi2020]Se houver a necessidade apenas de alterar um arquivo .properties ou um .xml, podemos solicitar a alteração por e-mail e as coisas andam mais rápido, já que, uma vez que a própria equipe de infra do cliente efetuará a alteração e não haverá inspeção de pacote.
[/quote]
acho que isso acontecerá da mesma forma caso vocês venham a utilizar via anotações, como mencionei acima, qualquer anotação poderá ser redefinida via xml, pelo menos é assim como a especificação preza em maioria dos frameworks que conheço.
Alguem viu alguma coisa sobre novos escopos (session, request, etc) de managed bean para o JSF 2.0???
faloww!!
o spring web flow tem um escopo de flow que é utilizado como meio para fluxo de transição de páginas, que evita trabalho braçal e uso do escopo de sessão. como o JSF 2.0 trata este problema?
acho que isso ficará por responsabilidade da WebBeans mesmo, com os seus @ConversationScoped beans
"
legal. achei esta implementação no google code desta anotação. :shock:
não sabia deste recurso. fiquei mais feliz por saber. fábio, tens usado ele bastante. o que achasse de bom ou ruim?
na verdade eu estava falando da especificação WebBeans, que está para sair e vai entrar no Java EE 6:
http://www.seamframework.org/WebBeans
Ainda não é final, mas eu tenho mexido bastante sim! Tem bastante coisa interessante que veio do Guice, Seam, Spring… Vale a pena dar uma olhada para estar preparado.
[quote=marcosalex]Uma desvantagem que eu vejo é o código ficar mais “poluido”.
Outra coisa é que se você quiser alterar alguma configuração,vai ter necessariamente de recompilar sua aplicação e dar um deploy novamente, enquanto no xml seria somente editar o arquivo.[/quote]
O xml não “sobrescreve” as anotações?
[quote=mtosatti][quote=marcosalex]Uma desvantagem que eu vejo é o código ficar mais “poluido”.
Outra coisa é que se você quiser alterar alguma configuração,vai ter necessariamente de recompilar sua aplicação e dar um deploy novamente, enquanto no xml seria somente editar o arquivo.[/quote]
O xml não “sobrescreve” as anotações?[/quote]
Não em 100% dos casos, mas na maioria sim.
Por exemplo, com EJB3 se você definir um SessionBean para Stateless via anotação, você não pode definir ele como Statefull via XML. Nesse caso o XML não sobrescreve a anotação, porém na grande maioria sobrescreve sim (na verdade, esse é o único caso que eu sei que não sobrescreve).
essa é uma situação onde o cara não sabe o que quer, ao configurar desta forma.
essa é uma situação onde o cara não sabe o que quer, ao configurar desta forma.[/quote]
A questão não é que “a pessoa” não sabe o que quer, pois em teoria, quando se trabalha com EJB3 existem várias roles, assim a role do bean provider (quem fez o componente) pode ser sobrescrita pela role do deployer (quem vai fazer o deploy da aplicação). Mas como eu disse, esse é o unico caso onde o XML não sobrescreve a anotação, pelo contrário, gera problema
isto poderia acontecer entre o Bean Provider e Application Assemlbler e não o Deployer. O Deployer resolve todas as dependências externas configuradas pelos Bean Provider e Application Assemlbler, ele não interfere ou deveria interferir neste aspecto.
mas pode sim acontecer, se a conversa não for bem feita entre ambos.
e como gera!
a uns 3 anos atras o “certo” era xml! dae foi xml para todo lado, tudo(configurações) tinha que esta em xml senão…, agora evoluimos 
agora tudo é annotations! tudo tem annotations, o hibernate,spring tem, ejb tem, jpa, guice, struts… agora me diga será que daqui 03 anos não muda novamente ? quem sabe um retorno ao XML ?
[quote=ualex]a uns 3 anos atras o “certo” era xml! dae foi xml para todo lado, tudo(configurações) tinha que esta em xml senão…, agora evoluimos agora tudo é annotations! tudo tem annotations, o hibernate,spring tem, ejb tem, jpa, guice, struts… agora me diga será que daqui 03 anos não muda novamente ? quem sabe um retorno ao XML ?
[/quote]
Bem, ainda bem que acordaram e começaram a perceber que XML é uma merda. Um dia quem sabe, quiçá, essa merda será completamente extirpada da face da Terra.
Quanto a annotations, o que poderia vir a substituí-la seria programação tradicional sem XML e nem annotations ou qualquer outra maluquice que inventem no lugar. 100% programático!
Mas, algo que seria legal e infelizmente não tem, seria colocar e retirar annotations de classes, métodos, atributos e parâmetros em tempo de execução, além de annotations mutáveis. Isso daria bastante flexibilidade ao desenvolvedor.
Outra coisa que poderia vir no lugar de annotations seriam closures.
[quote=ualex]a uns 3 anos atras o “certo” era xml! dae foi xml para todo lado, tudo(configurações) tinha que esta em xml senão…, agora evoluimos agora tudo é annotations! tudo tem annotations, o hibernate,spring tem, ejb tem, jpa, guice, struts… agora me diga será que daqui 03 anos não muda novamente ? quem sabe um retorno ao XML ?
[/quote]
Dependendo do caso, a Convention over configuration http://en.wikipedia.org/wiki/Convention_over_Configuration pode ser melhor que Annotation (vide o VRaptor ou Rails).
em que situações, não entendi? exemplifique melhor!
acho que li sobre este padrão no livro de DDD. vou dar uma olhada.