| Autor |
Mensagem |
|
|
Já estão trabalhando nisso como podemos ver aqui
|
 |
|
|
Faz uma semana que estava pronta e disponível aqui. Mas ontem foi disponibilizada no site do JCP a Public Review da JSR-299, o WebBeans.
Aqui tem o anuncio completo
http://in.relation.to/Bloggers/WebBeansPublicReviewDraftReleased
Ou no TSS http://www.theserverside.com/news/thread.tss?thread_id=51715
Já tem disponível também a referencia
http://docs.jboss.org/webbeans/reference/1.0/en-US/html/
Para quem já conhece o Seam já dá para ir se localizando, e quem não conhece já pode ir aprendendo por esse material.
Esse JEE6 promete hein 
|
|
|
|
reinaldob wrote:
Rafael Nunes wrote:Espero também que tenha melhorado o suporte a multiplos monitores.
++
++
|
|
|
|
|
Um tempo depois que saiu a implementação da EDR2 dei mais uma olhada na especificação e escrevi mais um post comentando sobre o novo escopo view que o JSF 2 vai suportar. Para explicar resumidamente, esse escopo é o tão sonhado maior que request e menor que session que o JSF 2 vai trazer "de série". Quem quiser saber mais pode dar uma olhada no link acima.
|
|
|
|
Já está disponível (desde ontem) a implementação da EDR2 para download aqui. Agora não precisa mais usar a nightly build pra testar as novas funcionalidades. Boa diversão 
|
|
|
|
Realmente posso te dizer que já passei por quase todos esses problemas que voce mencionou, mas isso há 1 ou 2 anos atras. Realmente o ajax na unha com jsf é bem complicado, mas com Ajax4Jsf não tive problemas não. Porém só comecei a usar depois que liberaram o RichFaces, então se era mais problemático antes disso eu não peguei essa época. Sobre o que voce falou sobre menos ser mais é totalmente válido, pois um ponto negativo é que hoje temos que usar várias coisas juntas para ficar bom: JSF + Coleção de componentes (uso o RichFaces) + algo para ajax (o RichFaces já tem pois inclui o ajax4jsf) + alguém com controle de contexto mais inteligentes (uso o Seam). JSF sozinho realmente deixa a desejar em detalhes como a falta de um entityConverter e um selectItems mais esperto, mas Hoje em dia não da mais pra usar JSF sozinho, tem que ter um Facelets (no 2.0 já vai estar integrado) e um Seam pra ficar bom.
Esses problemas que voce comentou que teve com o IceFaces e RichFaces eu tive com os componente Tomahawk, mas isso também quando eu usava há 1 ou 2 anos... de lá pra cá tenho usado o RichFaces sem maiores problemas, pois sempre tem versão e os bugs são corrigidos rapidamente.
Além disso com o ajax4jsf até agora não tive problema com excesso de requisições ou de dados enviados/recebidos pois dá pra especificar certinho o que vai e volta.
Um problema que eu vejo que aconte atualmente é a incompatibilidade de bibliotecas de compontenes, mas com a padronização de js que virá no JSF 2.0 isso também tende a diminuir. E sobre problema de memória, eu já vi isso acontecer em aplicações onde não tem alguém gerenciando o contexto, como o Seam por exemplo, e o desenvolvedor fica toda hora jogando e pegando dados da sessão (e acaba esquecendo coisa lá algumas vezes). Mas isso faz aplicação sentar em qualquer tecnologia. Agora pelo fato do JSF manter o estado da árvore de componentes, com certeza usa mais memória, mas nunca vi isso chegar a fazer uma aplicação sentar sem estar associado com os erros que comentei.
Mas apesar de hoje em dia eu não sofrer desses problemas que voce comentou (no passado já), é sempre bom ter críticas de quem não critica sem nunca ter visto.
|
|
|
|
jonataswingeter wrote:Espero que melhore a API e sua implementação (Sun RI).
Confesso que já nem tenho tanta vontade de vê-lo, diante de tanta
coisa ruim que já vi nesse framework. Obviamente é fácil atacar pedras,
por isso quero ver com calma.
Quanto ao WebBeans, prefiro nem comentar. 
Cara, comente com a gente quais esses problemas que voce enfrentou usando a RI e o que voce nem gostaria de comentar sobre o WebBeans. Não to querendo começar aquelas dicussões que não levam a nada, mas seria interessante ver pontos de vista de alguem que passou por problemas.
Eu por exemplo percebi que a qualidade da RI melhorou bastante depois da versão 1.2, tanto que quem usava MyFaces (entre o pessoal que eu conheço) já está voltando pra RI.
|
|
|
|
Olha, essas coisas são bem opiniões pessoais mesmo, mas vamos la.
Uma desvantagem que eu vejo é a dependencia entre as classes, mas isso não chega a ser problema pq dificilmente se voce começou um sistema com JSF + JPA vai do nada jogar tudo fora e mudar. E se for fazer isso, remover as anotações será o menor dos problemas.
Outra coisa que eu acho chato com anotações é que eu não consigo estender uma anotação. Deixa eu exemplificar:
Imagine que eu tenho uma classe anotada com @Entity, mas aí eu também quero anotar ela com @Bla, que é uma anotação minha, que eu fiz no meu sistema. Mas vamos supor que eu sei que vou usar essa anotação nos mesmos casos que a @Entity, mas eu não consigo subistituir a mesma pra quando o Hibernate perguntar pra minha classe se ela é um Entity o @Bla responder que sim. Como seria com um instanceof da vida dando um extends em uma interface.
Então as vezes a gente acaba tendo exemplos com um monte de anotações uma em cima da outra... porque uma define o nome do componente, outra define o escopo, e outra define como vai integrar com sei-lá o que.
Mas as vantagens no meu ponto de vista compensam. Como o marcelomartins falou, fica tudo num lugar só (classe e sua respectiva configuração), fácil de encontrar. Sem contar que além de estar no mesmo lugar aquilo é compilado e tem autocomplete. Porque se fosse ver só por estar no mesmo lugar, com XDoclet a gente já conseguia bastante coisa, mas sem dúvida (minha opinião) com anotações fica mais fácil.
Agora sobre o deploy, eu acho que a grande maioria dos frameworks que suportam anotação, continua suportando xml, e com uma precedencia maior justamente pra esses casos. Então se voce precisa mudar algo que com um xml resolve, põe lá que ele vai sobrescrever as anotações. Aí quando voce realmente precisar mudar algo, vc já atualiza as anotações se for possível.
|
|
|
|
é possível sim
@javax.faces.model.ManagedBean
@javax.faces.model.ManagedBeans
@javax.faces.model.ManagedProperty
Fora isso tem as anotações
@javax.faces.convert.FacesConvert
@javax.faces.validator.FacesValidator
@javax.faces.component.FacesComponent
Inclusive até já atualizei meu post comentando dos parametros dessas anotações
|
|
|
|
Está disponível a Early Draft Review 2 da especificação do JSF 2. Nessa versão já podem ser vistas mudanças na FacesContext e como deve ficar a integração com Facelets.
No entando ainda não está disponível a versão EDR2 da implementação, somente da especificação:
http://jcp.org/aboutJava/communityprocess/edr/jsr314/index2.html
Para acompanhar no código enquanto eu via a especificação eu baixei a versao shapshot do projeto:
Quem quiser dar uma olhada, eu fiz um post comentando as primeiras mudanças que eu pude perceber desde a EDR1.
|
|
|
|
|
Alguém já fez algo parecido?
|
|
|
|
Se eu fosse usar AOP provavelmente seria alguma solucao caseira também.... e é isso que eu estou preferindo nao usar.
O JAAS eu não sei se chega nesse ponto de autorizar dentro do código Java, por acaso ele faz isso também? Pensei que ele fosse mais para autorizar dentro da parte das views, mas isso eu já faço.
O acegi eu to olhando agora, mas pelo que vi é algo do spring. Não tem como fazer usando só a api do java?
|
|
|
|
Pessoal, estou querendo implementar um controle de acesso em um método. Como no Java ainda nao tem como eu especificar algo maior que package (default) e menor que public (como poderia ser feito se já existissem os módulos) eu acabei tendo que colocar meu método como public mas não queria que qualquer objeto pudesse invocá-lo. Um solução caseira seria verificar via stacktrace quem está chamando meu método, mas queria uma solução padronizada pra isso. Andei olhando a api security do java e fiquei achando que pudesse me ajudar, mas nao encontrei nenhum exemplo de como poderia utilizar para fazer o que eu quero.
Nesse exemplo que eu comentei eu iria fazer um controle de acesso em cima de chamadas locais, mas precisaria também fazer um controle de acesso remoto para validar quem está invocando meu EJB (ou WS) por exemplo. As motivações para isso tem a ver com o negócio, então não é sobre a necessidade de fazer isso que eu gostaria de discutir, queria a ajuda de voces para saber se existem uma forma padrão de tratar esses dois casos. Sem isso o jeito seria olhar a stacktrace no primeiro caso e enviar algum tipo de "login/senha" no segundo.
Obrigado pessoal, aguardo a ajuda de voces.
|
|
|
|
|
Agora eu até consegui pegar, mas teve que ser via uma classe que está no mesmo jar do properties que eu quero, mas eu gostaria de fazer isso sem precisar referencia nenhuma classe. Tem como? Obrigado.
|
|
|
|
Pessoal, estou tentando pegar um properties de dentro de um jar e nao consigo.
A minha classe que busca o properties está em um jar dentro da aplicacao, e o properties está em outro jar.
Ja tentei pegar todo tipo de ClassLoader diferente e nao funcionou. Já pesquisei as solucoes "simples" que aparecem numa busca por isso no google e também não resolveu.
Provavelmente voces ja tiveram esse problema e poderao me ajudar.
Me pergunto porque é tao complicado fazer algo desse tipo...
Ah... já tentei os métodos do ServletContext, do ExternalContext do JSF e como ja falei, um monte de exemplos de códigos da net.
alguns exemplos de coisas que já tentei...
Obrigado pessoal.
|
|
|
|