Lançado JBoss Richfaces 3.2.0

Eu precisa reproduzir um jinternal frame no browser mas
parece que ele não tem nenhum tipo novo de janela.

Espero que esteja resolvido alguns bugs irritantes no Tree.

rodrigoy:

Espero que esteja resolvido alguns bugs irritantes no Tree.

Mas parece que teve um total de mais de 900 bugs corrigidos entre todos os componentes.

cara, no site tá muito lento. alguém já o utilizou em produção?

Sim… é bem rápido. Como acabou de ser lançado, imagina o número de pessoas acessando né

Tem algum na internet que usa ele só pra me ver como ficou o layout.

Dúvida iniciante, qual a diferença entre o JSF, MyFaces e o JBoss RichFaces?

JSF = especificação
MyFaces = uma implementação da especificação
JSF-RI = implementação padrão
RichFaces = comjunto de componentes escritos para a especificação JSF 1.2 (pelo menos na última versão só a versão 1.2 da especificação é suportada, antes suportavam a 1.1 também)

muito bom, considero um dos melhores, senão o melhor, vamos testar pra ver como está os novos componentes e se bugs foram realmente corrigidos…

Os novos recursos na DataTable (filtro e ordenação) já valeram esse release, o progress bar e o combo box tbm ficaram bacana, até hoje não consegui usar ajax de maneira tão simples e eficiente como com o Richfaces.

usei em alguns projetos MyFaces + a4jsf …

to pensando em usar o richfaces, principalmente pelos componetes…

alguem me insentiva ??

Vi o demo…cheio de componentes! Bacana!

vcs acham que ele é mais completo, quanto a componentes, que o Struts2?Eu achei…

estudo o struts2…a questão dos interceptors (do uso exagerado e desnecessário) e do DOJO torna o struts2 um pouco lento…

senti isso tb no JSF, mas a qtd de scripts por traz de um visual agradável como esse, dependendo do caso, compensa um pouco de lentidão…

até!

soudaniel_01:

usei em alguns projetos MyFaces + a4jsf …

to pensando em usar o richfaces, principalmente pelos componetes…

alguem me insentiva ??

quando eu usei ajax com jsf, sempre fui com ajax4jsf… esse sim é a mão na roda

como o richfaces é baseado no a4j (ou uma extensão), não abro mão de usar =D

pena que o richfaces não funciona direito no oc4j =/ eu pelo menos tiver problemas seríssimos, tanto pra usar a ultima versão do ajax4jsf quanto usar o richfaces

<provocação>
Nada funciona direito no OC4J
</provocação>

Na verdade o ajax4jsf esta incorporado dentro do richfaces, desde o 3.1.

urubatan:

<provocação>
Nada funciona direito no OC4J
</provocação>

soudaniel_01:

usei em alguns projetos MyFaces + a4jsf …

to pensando em usar o richfaces, principalmente pelos componetes…

alguem me insentiva ??

sim, sim, os recursos dele são muito bons, principalmente a integração com o ajax4JSF…

urubatan:

<provocação>
Nada funciona direito no OC4J
</provocação>

<1º de Abril>
Caramba, OC4J é muito bom, funciona tudo muito bem, não existem problemas de parsing xml, de deployment, o web console é ótimo e é o melhor container J2EE que existe! Muito bom, recomendo a todos!
</1º de Abril>

Infelizmente, qualquer conjunto extra de componentes JSF hoje em dia tem muito bug. Creio que a RI, que nao tem nada extra, é o que temos de mais maduro.

IceFaces, MyFaces, Tomahawk e outros chegam a tirar a paciencia do desenvolvedor: javascripts gigantes sao gerados e acionados, html quebrado, etc. O RichFaces, apesar de nao ser perfeito, pra mim parece ser o que há de melhor hoje em dia.

mas fazer esses componentes por contra própria teria muito mais bugs

Alguns componentes da versão anterior não são compativeis, por exemplo o modalPanel.
Antes era assim:

<rich:modalPanel id="mpLogon" autosized="true">
    <f:facet name="header"><h:outputText value="Entrar" /></f:facet>
    <f:facet name="controls">
        <h:graphicImage value="/images/default/action_delete.gif" style="cursor:pointer" onclick="Richfaces.hideModalPanel('mpLogon')" />
    </f:facet>
    
</rich:modalPanel>

agora ficou assim

<rich:modalPanel id="panel" width="350" height="100">
    <f:facet name="header">
        <h:panelGroup>
            <h:outputText value="Entrar" />
        </h:panelGroup>
    </f:facet>
    <f:facet name="controls">
        <h:panelGroup>
            <h:graphicImage value="/images/default/action_delete.gif" style="cursor:pointer" id="hidelink"/>
            <rich:componentControl for="panel" attachTo="hidelink" operation="hide" event="onclick"/>
        </h:panelGroup>
    </f:facet>
</rich:modalPanel>

O autosize ja era, porem o comando para fechar a janela ficou mais clean.
Esta dando um trabalho danado para ajustar todos os modelPanel da aplicação :?

Paulo Silveira:

Infelizmente, qualquer conjunto extra de componentes JSF hoje em dia tem muito bug. Creio que a RI, que nao tem nada extra, é o que temos de mais maduro.

IceFaces, MyFaces, Tomahawk e outros chegam a tirar a paciencia do desenvolvedor: javascripts gigantes sao gerados e acionados, html quebrado, etc. O RichFaces, apesar de nao ser perfeito, pra mim parece ser o que há de melhor hoje em dia.

Mas que problemas tu vê nisso? Para os componentes funcionarem, os Javascripts são mais que necessários. Talvez alguma revisão de código seja necessária pra otimizar isso, mas eu sinceramente não consigo ver bugs no Tomahawk por exemplo, muit menos problemas com javascrip.

Desculpe a ignorância, mas o que seria um “html quebrado” nesse contexto?

Eu ja uso o richfaces para atualizar para a nova versao como devo proceder?e so trocar os jar’s do projeto?

As IDE possuem plugin ou funcionalidade para arrastar e soltar estes componentes na tela ou tenho que editar JSP com taglibs?

O JBoss Tools ajuda bastante, mas está anos luz de ser um “arrastar/soltar” estilo matisse.

YES! viva o FileUpload!!!

Muito bom lançamento!

Renan

Leozin:

Mas que problemas tu vê nisso? Para os componentes funcionarem, os Javascripts são mais que necessários. Talvez alguma revisão de código seja necessária pra otimizar isso, mas eu sinceramente não consigo ver bugs no Tomahawk por exemplo, muit menos problemas com javascrip.

Desculpe a ignorância, mas o que seria um “html quebrado” nesse contexto?

David:

Leozin:

Mas que problemas tu vê nisso? Para os componentes funcionarem, os Javascripts são mais que necessários. Talvez alguma revisão de código seja necessária pra otimizar isso, mas eu sinceramente não consigo ver bugs no Tomahawk por exemplo, muit menos problemas com javascrip.

Desculpe a ignorância, mas o que seria um “html quebrado” nesse contexto?

Veja o HTML gerado pelo JSF e chore. Simplesmente isso. Obviamente o Javascript é necessário, mas do jeito que está implementado é gambiarra. E feia! ;)

A solução seria fazer esses componentes na mão por exemplo? eu passo, prefiro 500k a mais numa pagina do que 2 semanas a mais de desenvolvimento e dor de cabeça (manutenção) pro resto do projeto.

O grande problema de suites de componentes JSF com Ajax “embutido” é o desempenho… Para sites pequenos, com pouco acesso concorrente, você pode até ignorar essa carga e o conteúdo gerado por ela, mas quando o seu nível de acesso concorrente sobe para a casa dos 500-1000 usuários (muitos deles simultâneos…), passa a fazer bastante diferença.

Este é o caso do projeto onde trabalho atualmente. E eu uso o Seam + RichFaces. Das suites/frameworks no mercado, estas me parecem as melhores, e têm atendido essa nossa carga de usuários adequadamente. Mas eu passei dias otimizando glassfish e aplicação web para conseguir esse nível de desempenho. Foi uma experiência para a qual eu estava psicologicamente preparado, imaginava que teria de me empenhar nisso - mas espero nunca mais ter de repetir

Enfim, resumindo, acho que essas suites de componentes JSF poderiam sim frear um pouquinho o desenvolvimento de novas features e componentes e investir mais tempo em desempenho para aplicação de alta potencial de escalabilidade. Use plugins como o firebug + YSlow no seu firefox e veja o que algumas tabs, data-tables e modal panels fazem com a requisição HTTP

Sim, é so atualizar os jar do richfaces

bom, como atualizar é preciso, já comecei aqui e como eu não esperava que fosse diferente já deu pau no que funcionava.
O problema foi num datascroller, ele está acusando que o metodo org.richfaces.component.UIDatascroller.setupFirstRowValue não existe, como eu não chamei este metodo, baixei o fonte do rf 3.2 e o metodo está lá bonitinho do jeito que tem que ser. Vai entender…vou brigar aqui com o fonte e ver se descubro o que é. qq coisa eu posto aí pro pessoal.

Lmebrem-se que a versão 3.2.0 implementa JSF 1.2, não suportando mais 1.1, sendo assim é bem provavel que alguns componentes tenham algumas alterações ou novas opções também, vale dar uma olhada com calma nas mudanças e documentações disponíveis no site.

http://jboss.com/index.html?module=bb&op=viewtopic&t=132562

Is 3.2.0 backward compatible with previous versions? How it is save to upgrade?
The major point is dropping support with JSF 1.1. So, if you still use it - do not upgrade. The backward compatibility in the rest parts should not be broken. However, how smoothly your concrete project can be upgraded depends of how thickly you use undocumented features and/or workarounds in JSF and RichFaces. If you face the problems during the upgrade, report them to the forum. The core RichFaces team is going to monitor the forum on permanent bases just after the release to detect and solve the potential problems.

Eu conheço JSF

por que você não mostra soluções mais elegantes do que as que são geradas? Eu sinceramente não ví nenhuma gambiarra (ai meu deus, não é w3c compliance?), e html eu não preciso ficar fuçando em código, ainda mais que o destino final é o usuário e não um desenvolvedor que vai ter um analizador de “html bonito”. É estranho esse tipo de crítica, sinceramente…

Luiz Aguiar:

Ai acho que cabe analisar o quão é importante pro seu projeto que o html cuspido pelo framework seja “bonito”.

A solução seria fazer esses componentes na mão por exemplo? eu passo, prefiro 500k a mais numa pagina do que 2 semanas a mais de desenvolvimento e dor de cabeça (manutenção) pro resto do projeto.

Exatamente. Se tão achando tão ruim assim, faz os componentes e as chamadas ajax tudo na mão, é rapidinho né? pelamor

javaBeats :

O grande problema de suites de componentes JSF com Ajax “embutido” é o desempenho… Para sites pequenos, com pouco acesso concorrente, você pode até ignorar essa carga e o conteúdo gerado por ela, mas quando o seu nível de acesso concorrente sobe para a casa dos 500-1000 usuários (muitos deles simultâneos…), passa a fazer bastante diferença.

Este é o caso do projeto onde trabalho atualmente. E eu uso o Seam + RichFaces. Das suites/frameworks no mercado, estas me parecem as melhores, e têm atendido essa nossa carga de usuários adequadamente. Mas eu passei dias otimizando glassfish e aplicação web para conseguir esse nível de desempenho. Foi uma experiência para a qual eu estava psicologicamente preparado, imaginava que teria de me empenhar nisso - mas espero nunca mais ter de repetir

Enfim, resumindo, acho que essas suites de componentes JSF poderiam sim frear um pouquinho o desenvolvimento de novas features e componentes e investir mais tempo em desempenho para aplicação de alta potencial de escalabilidade. Use plugins como o firebug + YSlow no seu firefox e veja o que algumas tabs, data-tables e modal panels fazem com a requisição HTTP

Na verdade em qualquer sistema com 500-1000 usuários simultâneos precisa de otimização, ou pelo menos, algumas cautelas pra evitar crashes aleatórios

Se você ver o debug do a4j tu consegue ver o tamanho das respostas que ele envia. Mas se você simplesmente cuspir código na tela, você realmente vê cabeçalhos http grandes. Existem várias formas de otimizar isso, desde usando regions até single-requests, sugiro a você estudar um pouco mais sobre os frameworks e ver que as otimizações são possível, de várias maneiras, e que faz com que o sistema aguente toda essa demanda que você cita aí.

Oi Luiz, blz né?? Sim, estou usando a implementação 1.2 da JSF. Tanto que o meu problema foi só com o datascroller. O resto funfou.

Leozin:

Eu conheço JSF

por que você não mostra soluções mais elegantes do que as que são geradas? Eu sinceramente não ví nenhuma gambiarra (ai meu deus, não é w3c compliance?), e html eu não preciso ficar fuçando em código, ainda mais que o destino final é o usuário e não um desenvolvedor que vai ter um analizador de “html bonito”. É estranho esse tipo de crítica, sinceramente…

Pra quem gosta de Javascript isso é ridículo, sinceramente…

Aqui na empresa usamos, aprovamos e recomendamos, baseados nas experiências anteriores com IceFaces.
Em relação a performance não tenho o que reclamar, o código gerado satisfaz a necessidade na maioria das vezes. Não discordo, o código poderia ser melhor, mas será que o codigo melhor produziria uma mudança perceptível, gritante? Existem alguns bugs sim, mas o comprometimento do projeto para com os usuários é inegável. Agora, com esses novos componentes, ficou ainda melhor.

Leozin:

Se você ver o debug do a4j tu consegue ver o tamanho das respostas que ele envia. Mas se você simplesmente cuspir código na tela, você realmente vê cabeçalhos http grandes. Existem várias formas de otimizar isso, desde usando regions até single-requests, sugiro a você estudar um pouco mais sobre os frameworks e ver que as otimizações são possível, de várias maneiras, e que faz com que o sistema aguente toda essa demanda que você cita aí.

Exatamente. É isso que fizemos, desde o primeiro dia de desenvolvimento, e felizmente o desempenho é bom e estamos “aguentando” toda essa demanda sem maiores problemas. Usamos regions, limitToList, e tudo o mais que está disponível no A4J/RichFaces, mas também foi necessário otimizar o glassfish, e configurações específicas de JSF - o web.xml está lotado de comentários

O que eu quero argumentar é - embora tenha performance aceitável, e seja uma das melhores (se não a melhor) suíte de componentes disponível na comunidade hoje, o renderização poderia ser melhor sim. Mas eu não consigo fazer melhor, nem tenho a menor predisposição de re-escrever componentes, então para mim está bom, obrigado

E aproveitando a deixa, eu quero fazer um elogio para o Glassfish

Aguenta esta carga toda aí, sem crashes, no máximo lentidões aleatórias em poucas requisições (considerando o volume…). O pessoal de QA usa e abusa do JMeter para testar a carga sobre a aplicação, e os resultados são ótimos. Ponto para o Glassfish

rdantas:

bom, como atualizar é preciso, já comecei aqui e como eu não esperava que fosse diferente já deu pau no que funcionava.
O problema foi num datascroller, ele está acusando que o metodo org.richfaces.component.UIDatascroller.setupFirstRowValue não existe, como eu não chamei este metodo, baixei o fonte do rf 3.2 e o metodo está lá bonitinho do jeito que tem que ser. Vai entender…vou brigar aqui com o fonte e ver se descubro o que é. qq coisa eu posto aí pro pessoal.

Abri um novo tópico com detalhes do problema: http://www.guj.com.br/posts/list/0/86576.java#463039

Caso alguem esteja passando pelo mesmo problema, ou tenha alguma idéia.

Abraços,
Rodrigo.

++

David:

Bem, isso aqui é um commandLink:

Pra quem gosta de Javascript isso é ridículo, sinceramente…

David:

Bem, isso aqui é um commandLink:

Pra quem gosta de Javascript isso é ridículo, sinceramente…

Seguindo essa tua lógica, quem usa Prototype, Dojo, scriptaculous ou algo do gênero deve odiar javascript também, porque os código-fonte são seguindo esse nível

mas, antes de tudo, você tem alguma solução melhor que essa para efetuar A MESMA OPERAÇÃO?

e também, o que há de tão ruim com Javascript? Você nem encosta, quem faz isso é o JSF, não sei porque o stress. Vale lembrar que esses component-based apps sempre vão gerar javascripts malucos. Você já mexeu com asp.NET? Já viu o que ele gera?

a propósito, esse números malucos que aparecem provavelmente é de algum desenvolvedor amador que não conhece boas práticas. Esses números são gerados porque o usuário não colocou um id para o form e um id para o commandLink. Se esse mesmo desenvolvedor reclama de “muitos javascripts”, ele é um tanto quanto hipócrita, porque ele simplesmente “cospe” código na tela da maneira que lhe convém sem nenhum conhecimento de boas práticas, ao ponto de reclamar de javascript como se fosse “algo não-bonito”

Não me leve a mal hehehe é que esses argumentos realmente não “estão descendo”, por mais que o código gerado possa ser tosco, porque devemos nos importar? Se pensar assim também, o código que o netbeans gera pra criar telas do swing é HORRÍVEL, muito pior do que qualquer javascript que o jsf gera

Ps.: eu não acho o código gerado tosco, pelo contrário, é suficiente e funcional tendo em vista o leque de opções que o JSF + a4j + rich faces nos dão

Eu concordo plenamente,
Não entendo porque essa birra toda uai, quem preferir fazer tudo na mão, que fique uma semana tentando descobrir pq o código funciona no FF mas não funfa no IE rs

eu não acho o código gerado tosco, pelo contrário, é suficiente e funcional tendo em vista o leque de opções que o JSF + a4j + rich faces nos dão

foxpv:

eu não acho o código gerado tosco, pelo contrário, é suficiente e funcional tendo em vista o leque de opções que o JSF + a4j + rich faces nos dão

Eu concordo plenamente,
Não entendo porque essa birra toda uai, quem preferir fazer tudo na mão, que fique uma semana tentando descobrir pq o código funciona no FF mas não funfa no IE rs

Opa, que é isso, parecido com aquilo ali? Onde você viu isso? E eu não gosto mesmo do prototype ou script.aculo.us, prefiro jQuery.

Bem, primeiro, um simples link não deveria precisar de Javascript. Cadê a acessibilidade? Se você usar um pocket com internet explorer não vai poder acessar um sistema feito com JSF por que o browser não suporta Javascript. Sobre a solução, eu falo já.

Eu adoro Javascript, gosto MUITO mesmo. Mas quem disse que frameworks component-based precisam de javascript? Já viu como o Wicket (http://wicket.apache.org/examples.html) funciona, por exemplo? Tá ai uma solução muito melhor.

Eu não reclamei dos números loucos, como você falou. Reclamei da forma como o javascript foi gerado para criar um link.

De jeito nenhum eu vou levar a mal. Estamos apenas discutindo idéias. E, assim como você não se importa com o Javascript gerado, eu não me importo com o código que o Netbeans gera porque eu não uso Netbeans.

foxpv:

Eu concordo plenamente,
Não entendo porque essa birra toda uai, quem preferir fazer tudo na mão, que fique uma semana tentando descobrir pq o código funciona no FF mas não funfa no IE rs

E vc acha que uma pessoa com navegador sem suporte a javascript realmente consegue navegar na maioria dos sites? isso pq vc ama javascript, imagine se odiasse. Aliás, usar javascript não está na especificação JSF. (Se não me engano o MyFaces tem a opção de não utilizar javascript, mas ninguem usa isso pq é um retrocesso)

Você acha que os caras envolvidos nisso não sabem programar em java script? ha ha ha… Existem motivos para cada uma dessas coisas que você critica, pode ter certeza.

E são vários motivos. JSF e sua árvore de componentes não é algo que nasceu para ser manipulado com javascript; Além disso, otimizações como compressão de javascript e pre-processing do código também devem rolar (não consigo confirmar, mas o código cuspido pelos componentes indica isso). Enfim, não é trabalho fácil, ou que possa ser orientado pelos preceitos do desenvolvimento tradicional em javascript.

O que eu queria defender quando postei pela primeira vez era um modo “plain”, de recursos mais magros. O CSS no RichFaces já funciona assim, você pode desabilitar os skins para que os componentes se adaptem com mais facilidade a uma estilização existente (e como isso ajuda, quem trabalha com designers de departamento de marketing sabe do que eu estou falando). Talvez fosse possível (e aí fica aberta a discussão), que ao invés de usar frameworks javascript de terceiros (scriptaculous, prototype), alguns componentes pudessem se beneficiar de javascript otimizado para páginas dinâmicas (JSF, Facelets, whatever…)

E dai? Se existe a possibilidade de você oferecer um mínimo de recursos, você vai optar por não oferecer nada a esse pessoal? Entendam que eu não estou falando dos componentes do RichFaces, estou falando de um simples link. Obviamente, pra se usar componentes mais complexos eu preciso de Javascript, mas você quer dizer que usar um link sem Javascript é um retrocesso? Outra coisa, porque eu “amo” javascript, quer dizer que eu tenho que usar em todo canto? :roll:

Bem, um dos motivos para se usar javascript em tudo no JSF é que ele trabalha com POST, já que é necessário enviar o viewstate salvo no cliente para o servidor, e essa informação normalmente é muito grande para ser enviada através de uma URL. Então, qualquer link tem que dar um submit em um formulário por causa disso. Mas e nos casos em que salvamos o viewstate no servidor? Isso continua sendo necessário? Se não for, por que não dar uma alternativa ao desenvolvedor?

Esse tipo de coisa dificulta a utilização de JSF em sistemas que necessitam de urls amigáveis, “bookmarkable pages” (não encontrei uma tradução boa), etc. Não é possível fazer isso com JSF sem utilizar o suporte de uma outra ferramenta como o RestFaces, por exemplo, ou sem escrever uma porrada de código num PhaseListener…

E dai? Se existe a possibilidade de você oferecer um mínimo de recursos, você vai optar por não oferecer nada a esse pessoal? Entendam que eu não estou falando dos componentes do RichFaces, estou falando de um simples link. Obviamente, pra se usar componentes mais complexos eu preciso de Javascript, mas você quer dizer que usar um link sem Javascript é um retrocesso? Outra coisa, porque eu “amo” javascript, quer dizer que eu tenho que usar em todo canto? :roll:
esse é o problema, você está olhando apenas para o link… isso no faces é um componente, como vários outros.

só uma pergunta: como que eu faço pra submeter um form através de um link sem usar javascript?

Sem usar javascript, não sei, mas se servir via AJAX… vc pode ter um a4j:form com a propriedade ajaxSubmit=“true” reRender=“seus, componentes, que, devem, re-renderizar, no, submit, separados, por, virgula”

Sem usar javascript, não sei, mas se servir via AJAX… vc pode ter um a4j:form com a propriedade ajaxSubmit=“true” reRender=“seus, componentes, que, devem, re-renderizar, no, submit, separados, por, virgula”

…

acho que você não entendeu a minha pergunta e a ironia também hehe

eu quero saber como submeter um form POR HTML, sem usar jsf, struts ou qualquer outra coisa, puro, sem usar NADA de javascript

leia os posts anterior que acho que você vai entender melhor o por que da minha pergunta

Sem usar javascript, não sei, mas se servir via AJAX… vc pode ter um a4j:form com a propriedade ajaxSubmit=“true” reRender=“seus, componentes, que, devem, re-renderizar, no, submit, separados, por, virgula”

Asynchronous JavaScript and XML)

Ou seja, se você submete um form via ajax, você também esta o fazendo via Javascript.

pessoal, to com um problema no rich faces 3.2

olha a exception

org.richfaces.taglib.PanelTag.setStyleClass

???

Para mim usar o richfaces quais são os jars q devo adicionar no meu projeto? e como deve ficar o meu web.xml?

iniciei um projeto com o jbosstools mais ele apenas adicionou os jars de jsf padrão e quando tento utilizar o richfaces da exception

se alguem puder me ajudar ou me passar um link de referencia

desde já agradeço a atenção de todos

Robson

Leozin:

acho que você não entendeu a minha pergunta e a ironia também hehe

eu quero saber como submeter um form POR HTML, sem usar jsf, struts ou qualquer outra coisa, puro, sem usar NADA de javascript

leia os posts anterior que acho que você vai entender melhor o por que da minha pergunta :P

Crie um navegador que entenda tags de ancora como sendo submits de formulários

O problema do command link é dos programadores que usam ele como “submit” de formulário quando o que deveria ser usado era um commandButton.

Maurício Linhares:

O problema do command link é dos programadores que usam ele como “submit” de formulário quando o que deveria ser usado era um commandButton.

robson_vs:

Para mim usar o richfaces quais são os jars q devo adicionar no meu projeto? e como deve ficar o meu web.xml?

iniciei um projeto com o jbosstools mais ele apenas adicionou os jars de jsf padrão e quando tento utilizar o richfaces da exception

se alguem puder me ajudar ou me passar um link de referencia

desde já agradeço a atenção de todos

Robson

Aqui está a lista dos jars necessários:

• richfaces-api
• richfaces-impl
• richfaces-ui

Escolha a versão e faça o download que já inclui os três jars citados anteriormente.
http://www.jboss.org/jbossrichfaces/downloads/

• commons-beanutils
• commons-collections
• commons-digester
• commons-logging

http://commons.apache.org/
*Aqui você faz o download de cada dependência individualmente

No web xml você inclui a seguinte configuração:

<!-- JSF Servlet -->
	<servlet>
		<servlet-name>Faces Servlet</servlet-name>
		<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
	</servlet>
	<servlet-mapping>
		<servlet-name>Faces Servlet</servlet-name>
		<url-pattern>*.jsf</url-pattern>
	</servlet-mapping>

<!-- Richfaces config -->
	<filter>
		<display-name>Ajax4jsf Filter</display-name>
		<filter-name>ajax4jsf</filter-name>
		<filter-class>org.ajax4jsf.Filter</filter-class>
	</filter>

	<filter-mapping>
		<filter-name>ajax4jsf</filter-name>
		<servlet-name>Faces Servlet</servlet-name>
		<dispatcher>FORWARD</dispatcher>
		<dispatcher>REQUEST</dispatcher>
		<dispatcher>INCLUDE</dispatcher>
		<dispatcher>ERROR</dispatcher>
	</filter-mapping>

Pronto!

raphaf:

robson_vs:

Para mim usar o richfaces quais são os jars q devo adicionar no meu projeto? e como deve ficar o meu web.xml?

iniciei um projeto com o jbosstools mais ele apenas adicionou os jars de jsf padrão e quando tento utilizar o richfaces da exception

se alguem puder me ajudar ou me passar um link de referencia

desde já agradeço a atenção de todos

Robson

Aqui está a lista dos jars necessários:

• richfaces-api
• richfaces-impl
• richfaces-ui

Escolha a versão e faça o download que já inclui os três jars citados anteriormente.
http://www.jboss.org/jbossrichfaces/downloads/

• commons-beanutils
• commons-collections
• commons-digester
• commons-logging

http://commons.apache.org/
*Aqui você faz o download de cada dependência individualmente

No web xml você inclui a seguinte configuração:

<!-- JSF Servlet -->
	<servlet>
		<servlet-name>Faces Servlet</servlet-name>
		<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
	</servlet>
	<servlet-mapping>
		<servlet-name>Faces Servlet</servlet-name>
		<url-pattern>*.jsf</url-pattern>
	</servlet-mapping>

<!-- Richfaces config -->
	<filter>
		<display-name>Ajax4jsf Filter</display-name>
		<filter-name>ajax4jsf</filter-name>
		<filter-class>org.ajax4jsf.Filter</filter-class>
	</filter>

	<filter-mapping>
		<filter-name>ajax4jsf</filter-name>
		<servlet-name>Faces Servlet</servlet-name>
		<dispatcher>FORWARD</dispatcher>
		<dispatcher>REQUEST</dispatcher>
		<dispatcher>INCLUDE</dispatcher>
		<dispatcher>ERROR</dispatcher>
	</filter-mapping>

Pronto!

<context-param>
		<param-name>org.richfaces.SKIN</param-name>
		<param-value>blueSky</param-value>
	</context-param>

	<filter>
		<display-name>RichFaces Filter</display-name>
		<filter-name>richfaces</filter-name>
		<filter-class>org.ajax4jsf.Filter</filter-class>
	</filter>

	<filter-mapping>
		<filter-name>richfaces</filter-name>
		<servlet-name>Faces Servlet</servlet-name>
		<dispatcher>REQUEST</dispatcher>
		<dispatcher>FORWARD</dispatcher>
		<dispatcher>INCLUDE</dispatcher>
	</filter-mapping>

	<listener>
		<listener-class>
			com.sun.faces.config.ConfigureListener
		</listener-class>
	</listener>

user este link de referencia ref ta funcionando legal.

Obrigado pela ajuda

Bom dia!

Eu to tentando usar o richfaces no jdeveloper, ja coloquei os arquivos .jar na pasta WEB-INf\lib do projeto e configurei o web.xml, mas ta dando o seguinte erro.

Classe não encontrada: org.apache.commons.collections.map.LRUMap

estou usando o Commons Collections 2.1

Desculpe, mas é que estou iniciando com o richfaces

Tente outra versão amigo, aqui estou usando commons-collections-3.2.jar e está ok!

Ola a todos(as) estou usando Netbeans 6.1 J2EE, GlasFish e…

nao estou conseguindo usar os componentes RichFaces em minhas aplicacoes…

adicionei os seguintes .jar em minha Library:

-richfaces-api-3.2.0.SR1.jar;

-richfaces-impl-3.2.0.SR1.jar;

-richfaces-ui-3.2.0.SR1.jar;

Jah adicionei no web.xml tbm…

Porem ao rodar a aplicacao dá erro 503.
description The requested service () is not currently available.

Alguem pode me ajudar?

Estou tendo o mesmo problema que o amigo ai de cima, em relacão ao erro 503

Acabei de fazer isso aqui num projetinho que começei. Qual sua dificuldade? Claro, se ainda tiver…