AW: CODI 1.0.1 NPE in JSF ResourceHandler when evaluating ValueExpression

Hi Christian, I have the same problem using Primefaces. Since updating to Primefaces 3.++ the @ViewAccessScope isn't working anymore. Dynamic Image unfortunately works only with SessionScope. Here is the forum thread - http://forum.primefaces.org/viewtopic.php?f=3t=17609p=54313#p54313 Cagatay

Re: CODI 1.0.1 NPE in JSF ResourceHandler when evaluating ValueExpression

Hi Thomas! This is probably already out of topic, but the main reason for the problem is, that the scope is just not available if the view restore phase is not completed. My current solution is: * Own GraphicImageRenderer implementation that uses ViewHandler.getActionURL(resourcePath) to

AW: CODI 1.0.1 NPE in JSF ResourceHandler when evaluating ValueExpression

Hi Christian, You say: * PhaseListener implementation that acts after RESTORE_VIEW that catches the dynamic content request and streams back the content just like the resource handler of primefaces does This was the solution for Primefaces 2.++ where I simply implemented my own

Re: CODI 1.0.1 NPE in JSF ResourceHandler when evaluating ValueExpression

hi @ all, actually the view-access scope is very different from the view-scope. it just needs the window-id as well as the view-id (a restored view is not needed). that means a custom implementation of ResourceHandler#handleResourceRequest just has to call:

CODI+OWB+Scheduler, ContextNotActiveException

Hi all, at first, CDI + CODI is really cool stuff for building a webapp. 1) Our Environment: We are using OWB 1.1.3, CODI 1.0.2 on a Tomcat 7 environment with CODI @Transactional. Database Producer: @PersistenceContext(unitName = myunit) private EntityManager extendedEntityManager;

Re: CODI+OWB+Scheduler, ContextNotActiveException

hi erwin, first of all: welcome @ myfaces! for a conversation a window is needed. therefore, the current conversation can't be resolved outside of a faces request. since it's possible to destroy the window-context at any time, it isn't suggested to use such scopes in an asynchronous task at all.

Re: CODI+OWB+Scheduler, ContextNotActiveException

short addition: just store all information which are needed to process the task in a storage which is valid outside of requests. + you can use e.g. @TransactionScoped (since codi 1.0.4 it also works outside of requests.) regards, gerhard http://www.irian.at Your JSF/JavaEE powerhouse - JavaEE

Re: CODI+OWB+Scheduler, ContextNotActiveException

In fact, asynchronous tasks should not even rely on @SessionScoped or @RequestScoped because they do not exist outside a servlet request ;) LieGrue, strub - Original Message - From: Gerhard Petracek gerhard.petra...@gmail.com To: MyFaces Discussion users@myfaces.apache.org Cc:

Re: CODI+OWB+Scheduler, ContextNotActiveException

Hi Mark, i would slightly disagree to that. i think it should at least be possible to use Request and SessionScope during an AsyncContext of servlet api 3. This AsyncContext is somehow associated to a specific servlet request and so IMHO Request- and Session-Scopes could be provided. Greetings,

Re: CODI+OWB+Scheduler, ContextNotActiveException

Hi Mark, i would slightly disagree to that. i think it should at least be possible to use Request and SessionScope during an AsyncContext of servlet api 3. This AsyncContext is somehow associated to a specific servlet request and so IMHO Request- and Session-Scopes could be provided. Greetings,

Re: CODI 1.0.1 NPE in JSF ResourceHandler when evaluating ValueExpression

Thank you gerhard, your suggestion, to save the viewId, worked perfectly!!! I want to share my final solution, just implemented it and tested through. I hope Primefaces will include the changes in a future version. You can find the final version of my files here:

Re: CODI+OWB+Scheduler, ContextNotActiveException

Hi Manuel! Asynchronous Servlet requests are a bit different than manually forking a new Thread. Neither OWB nor Weld use asyncSupported atm. The CDI EG is already discussing this feature and I guess we will add official support for it in CDI-1.1. LieGrue, strub - Original Message

[Trinidad] - Problem Richfaces+Myfaces+Trinidad

Personally, I have a project with myfaces richfaces 3.3.3 and 1.2.10 and had to use the component of the Trinidad - TreeTable (1.2.14). I made the configurations recommended in oficiall page, including the declaration in faces-config that promotes change in the Reder-kit-default for the trinidad

[Trinidad] Richfaces-Myfaces-Trinidad h:commandLink BUG

Hi \o/ All, I have a project with myfaces richfaces 3.3.3 and 1.2.10 and had to use the component of the Trinidad - TreeTable (1.2.14). I made the configurations recommended in oficiall page, including the declaration in faces-config that promotes change in the Reder-kit-default for the trinidad

Re: CODI 1.0.1 NPE in JSF ResourceHandler when evaluating ValueExpression

hi christian, you are welcome thx for sharing the link with the community. it looks like the status of the ticket didn't change - i hope they will include your fix, because it looks like several users would like to use such a feature. regards, gerhard http://www.irian.at Your JSF/JavaEE

AW: CODI 1.0.1 NPE in JSF ResourceHandler when evaluating ValueExpression

Hi Christian, thanks a lot for sharing your solution !! best regards Thomas -Ursprüngliche Nachricht- Von: Christian Beikov [mailto:c.bei...@curecomp.com] Gesendet: Freitag, 17. Februar 2012 12:36 An: MyFaces Discussion Betreff: Re: CODI 1.0.1 NPE in JSF ResourceHandler when