estou tentando fazer uns testes com o CustomScoped e estou tendo um probleminha. Talvez tu ou alguém do blog já tenha passado por ele. Estou usando primefaces 2.2. O problema é o seguinte, quando eu entro na página que tem um managedBean com CustomScoped, todos recursos (css e js) de dependência do prime são carregados na página, porém se eu do um “reload” ná pagina ou se eu saio e entro nela, algumas recursos não são mais carregados. Isso ocasiona uma má renderização na tela pela falta das bibliotecas que os componetens fazem uso. Ex.: PrimeFaces.widget.CommandButton is not a constructor, PrimeFaces.widget.TabView is not a constructor, etc…

Estou debugando aqui e não consigo encontrar o motivo para não carregar essa bibliotecas nas requisições posteriores ao inicio da Conversação. Vi que todos os Componentes do Prime estão anotados corretamente com as dependências do tipo:

@ResourceDependencies({
@ResourceDependency(library=”primefaces”, name=”forms/forms.css”),
@ResourceDependency(library=”primefaces”, name=”jquery/jquery.js”),
@ResourceDependency(library=”primefaces”, name=”core/core.js”),
@ResourceDependency(library=”primefaces”, name=”forms/forms.js”)
})

Será que tu ou alguém do blog já passou por esse problema?

INFO: Seam Solder 3.0.0.Final (build id: 3.0.0.Final)
INFO: Preventing class org.jboss.seam.transaction.UTTransaction from being installed as bean due to @Veto annotation
INFO: Preventing class org.jboss.seam.transaction.EntityTransaction from being installed as bean due to @Veto annotation
28/09/2011 22:49:32 org.jboss.seam.persistence.ManagedPersistenceContextExtension processAnnotatedType
INFO: Configuring Seam Managed Persistence Context from producer field pacote.library.PersistenceProducer.producerField with qualifiers [@javax.enterprise.inject.Any(), @javax.enterprise.inject.Default()]
(…)

Porém ao usar o entity manager:

Caused by: javax.persistence.PersistenceException: No Persistence provider for EntityManager named at javax.persistence.Persistence.createEntityManagerFactory(Unknown Source)

Segui o manual Seam Persistence Reference, bem escasso por sinal. E o que intrigou é o que ele manda no item 1.4.1, fala pra usar: “@PersistenceUnit”, mas onde nós especificamos o nome da unidade de persistência?! Como @PersistenceContext(unitName = “nomePU”)

Um servlet container 3.0 é um tomcat ou jetty com suporte a servlet 3.0. Essa versão de servlet permite menos configuração para adicionar coisas, pois em vez de declararmos coisas no web.xml o container lê as anotações dos jars. Então não precisamos mais colocar o servlet do nosso framework no web.xml. Aliado a isso o CDI também lê os jars, então se você usar o default também não vai precisar configurar (mas o CDI não tem a ver com o servlet container).

Concordo que o tomcat é bem mais leve e sobe em menos de 1 segundo. Mas o jboss7 e o glassfish sobem em menos de 3, então a diferença principal vai ficar no tempo que leva para a tua aplicação subir. Se você vai usar tecnologias não JEE eu acredito que valha mais a pena subir num tomcat ou jetty. Mas se você vai usar a stack padrão, fica mais simples subir logo num servidor de aplicações como jboss ou glassfish.

E valeu cara. Bom papo

Humm, então é verdade que o jboss é todo plugável?! Ótimo saber, mas é inegável o desempenho ao subir um tomcat enxuto. Você sabe do que estou falando. Porém me sinto inclinado por um JEE. E pelo JBoss!!!

- O que você diz como “servlet container 3.0″?!?!?

Tenho que concordar contigo que estou reinventando a roda, tentando transformar o tomcat num 1/2 jee, mas existe diferença. O item-a-item inegavelmente faz com que fique menor. Mas você me convenceu. Me rendo a esse fato (jboss7). Logo, com mais tempo destrincho ele.

Cara, valeu a força. Que o universo lhe devolva em dobro!!!

É simples fazer a configuração do Weld e do Seam JPA em ambiente não EE (documentação). Mas tá vendo que já vai usar seam-faces e seam-persistence? Essa visão que você está do Seam é do Seam2. O Seam3 na maioria das vezes você coloca o jar e o resto praticamente acontece sozinho. Pelo menos em ambiente JEE6, pois nesse caso não é preciso configurar as coisas pois o servidor descobre o que precisa ser implantado com base nos teus jars. Um servlet container 3.0 também vai te ajudar. E não tem diferença entre colocar Weld+Seam ou só Weld. Pois sempre você vai ter que colocar o Weld antes. E como falei, se você usa CDI e JSF, você vai querer usar seam-faces. E se quer controle transacional em ambiente não JEE, você vai usar seam-persistence. Seam3 não é o canhão pra matar formiga que era o Seam2.

Agora falando do tomcat, você vai ter que configurar uma coisinha ou outra, mas é perfeitamente possivel colocar em produção. Tem uma pancada de coisas em produção em Jetty e Tomcat. Servidor de aplicação não é escolhido por ser melhor para produção, e sim por ter vários serviços prontos. Serviços esses que você vai colocar no Tomcat. Será que no final você não vai ter praticamente um servidor de aplicação feito à mão? Se você vai usar tudo que tem num app server, será que não vale a pena dar uma olhada num jboss7 com seu esquema de modularização?

Concordo contigo. Venho percebendo que as implementações da Apache são imaturas, MUITO PORÉM são mais enxutas. Velozes! Percebemos isso pelo Tomcat que não consigo abandoná-lo. Queria transformá-lo num quase JEE. Algo que eu tenha o controle do que está plugado. Como venho fazendo. Item-a-item, vou instalando, personalizando. Pra mim está sendo boa experiência. Afinal, quero mesmo tentar arrastar para produção esse ambiente. Algumas pessoas o faz, eu acredito que seja possível e viável o uso do Tomcat em produção. Ver pra crer!
Quanto ao MyFaces, realmente eu mantenho os dois. As vezes testo no Mojarra. É que simpatizei com o output do console do MyFaces.

Sei que o Seam é uma coletânea de frameworks. Mas é que vejo poucas pessoas encarar a implantação na unha do Weld. Então recorrem logo ao “balão mágico” do Seam.

Bom, estou agora tentando agora simular um ambiente J2EE em JSE, com inject e intercept. Para controlar transação e o entity manager. Como ensina aqui:
http://seamframework.org/Documentation/WeldAndJPARunningInTomcat

- O que você acha dessa empreitada??? Não quero abarrotar o projeto com EJB, entende?!!

O Seam3 não é uma implementação de CDI, então nem teria como vc usar ele diretamente, sem OpenWebBeans ou Weld. De qualquer forma eu uso, e acho que vc também vai usar, pelo menos o seam-faces do Seam3.

O Weld é o que eu uso. Não lembro dos passos da configuração, mas na documentação tem os passos necessários. Já fiz isso há um tempo, mas agora não vou lembrar de tudo que precisa não. Mas vai pela documentação que vc consegue.

Ah… olhando o log vc está usando myfaces…. tomara que esteja melhorzinho do que a ultima vez que tentei usar….
Se fosse eu, mudaria pro mojarra. Muito mais testado, pois todo mundo usa ele. Mas aí é opção de cada um né

Um abraço.

Então: tentei de primeira a OpenEjbBean, porém empacou num erro e como a documentação dela é escassa, fiquei na mão;

Sem querer adotar o Seam 3 (pois tenho visto relatos de bugs, etc.) Decidí pelo Weld (1.1.2), só que depois de apanhar um pouco com as dependências (pois não uso nem manjo bem de maven), resolví os tropeços, fiz a aplicação subir, porém somente os ManagerBeans do JSF é que são resolvidos. Não consigo acessar os beans declarados pelo Weld. Sempre recebo:

org.apache.myfaces.view.facelets.el.ContextAwarePropertyNotFoundException: javax.el.PropertyNotFoundException: Target Unreachable, identifier ‘conversacaoBean’ resolved to null

@Named(“conversacaoBean”)
@ConversationScoped
public class ConversacaoBean implements Serializable {
private static final long serialVersionUID = 3282304148343869107L;

@Inject
private Conversation conversation;
(…)

Repare que tudo parece subir bem, sem erros:

24/09/2011 22:26:33 org.apache.catalina.startup.TaglibUriRule body
INFO: TLD skipped. URI: http://java.sun.com/jstl/xml is already defined
24/09/2011 22:26:33 org.jboss.weld.bootstrap.WeldBootstrap
INFO: WELD-000900 1.1.2 (Final)
24/09/2011 22:26:33 org.jboss.weld.bootstrap.WeldBootstrap startContainer
INFO: WELD-000101 Transactional services not available. Injection of @Inject UserTransaction not available. Transactional observers will be invoked synchronously.
24/09/2011 22:26:34 org.jboss.weld.environment.tomcat7.Tomcat7Container initialize
INFO: Tomcat 7 detected, CDI injection will be available in Servlets and Filters. Injection into Listeners is not supported
24/09/2011 22:26:34 org.apache.myfaces.shared.config.MyfacesConfig getBooleanInitParameter
INFO: No context init parameter ‘org.apache.myfaces.PRETTY_HTML’ found, using default value true
(…)
24/09/2011 22:26:38 org.apache.myfaces.config.DefaultFacesConfigurationProvider getClassloaderFacesConfig
INFO: Reading config : jar:file:/Users/developer/Servidores/apache-tomcat-7/lib/weld-servlet.jar!/META-INF/faces-config.xml
(…)

Você tem idéia do que pode estar ocorrendo?

O que você indica para meu projeto? Desejo algo simples e eficaz, mas que possa implantar sem auxílio de maven. Prefiro na unha

Desde já fico muito grato pelo auxílio, forte abraço!