Hi,
yes, exactly, I just put code from WebBeansPhaseListener.afterPhase into finally block in filter with an extra null check. 1) Servlet filter must be in web.xml (PhaseListener is registered from any faces-config.xml on classpath) -> users must register it in each project in web.xml: <filter> <filter-class>org.apache.webbeans.jsf.WebBeansJSFFilter</filter-class> <filter-name>WebBeansJSFFilter</filter-name> </filter> <filter-mapping> <filter-name>WebBeansJSFFilter</filter-name> <servlet-name>Faces Servlet</servlet-name> </filter-mapping> Currently OWB examples or documentation don't contain this registration. 2) Then we should move all conversation code to filter because specification says: "The conversation scope is active: during all standard lifecycle phases of any JSF faces or >>>non-faces request<<<" - from "6.7.4. Conversation context lifecycle". https://issues.apache.org/jira/browse/OWB-467 Regards, Martin Kočí Rohit Kelapure píše v Út 05. 10. 2010 v 08:42 -0400: > Martin, > > Checking in a finally block sounds like a good idea. > The only thing I would add is to check if conversation == null before > calling conversation.setInUsed(false); > > --Thanks, > Rohit > > > > On Mon, Oct 4, 2010 at 5:16 PM, Martin Koci > <[email protected]> wrote: > > Hi, > > > > I tracked down how conversation can be locked forever. It is simple: > > > > 1) WebBeansPhaseListener.beforePhase (before restoreView): sets inUsed > > to true > > > > 2) JSF lifecycle throws a exception and servlet container shows http > > 500 error page > > > > 3) WebBeansPhaseListener.afterPhase will be never called to > > setInUse(false) > > > > You can try in with jsf2sample - just put throw new NPE() in > > ConversationData.getNumber() > > > > > > JSF PhaseListener is probably not the safe place for handling such > > locks. JSF cannot guarantee that there will be render response phase as > > reaction to faces request. At least this is true for cases: > > 1) Faces Request generates Non-Faces Response > > (facesContext.responseComplete()) - see "Request Processing Lifecycle" > > in JSF spec > > 2) error page (for example pure JSP based) as reaction to exception > > (<error-page> element in web.xml) > > 3) bug in JSF implementation which makes lifecycle crash (for example > > bug in myfaces :) ) > > > > > > This needs something more robust, something like finally {} with some > > sort of lock timeout. At first sight > > org.apache.webbeans.jsf.WebBeansJSFFilter looks like the right place. I > > think that servlet container must propagate exception up in filter chain > > and we can put there: > > > > try { > > chaindoFilter(request, responseWrapper); > > } finally { > > conversation.setInUsed(false) > > } > > > > > > WDYT? > > > > > > Regards, > > > > Kočičák > > > > > > > > Mark Struberg píše v Pá 01. 10. 2010 v 21:51 +0000: > >> Hi Martin! > >> > >> Please fill a Jira to track this issue! > >> Just in case to keep track of the status. > >> > >> txs and LieGrue, > >> strub > >> > >> --- On Fri, 10/1/10, Martin Koci <[email protected]> wrote: > >> > >> > From: Martin Koci <[email protected]> > >> > Subject: NPE in InterceptorHandler > >> > To: [email protected] > >> > Date: Friday, October 1, 2010, 6:42 PM > >> > Hi, > >> > > >> > I do some stress testing and accidentally this NPE > >> > happens: > >> > > >> > java.lang.NullPointerException > >> > java.util.ArrayList.<init>(ArrayList.java:131) > >> > org.apache.webbeans.intercept.InterceptorHandler.invoke(InterceptorHandler.java:256) > >> > org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:98) > >> > com.foo.bazz.Clazz$$_javassist_157.getFoo() > >> > sun.reflect.NativeMethodAccessorImpl.invoke0(Native > >> > Method) > >> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > >> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > >> > > >> > > >> > OWB build-up from trunk two weeks ago, problematic line 256 > >> > contains: > >> > > >> > List<InterceptorData> filteredInterceptorStack = new > >> > ArrayList<InterceptorData>(this.interceptedMethodMap.get(method)); > >> > > >> > Is this something what was fixed recently or should I > >> > create an issue? > >> > I'm rerunning tests with current OWB trunk right now. > >> > > >> > > >> > Other issue is that after this NPE occurs, subsequents > >> > requests obtains > >> > ConversionBusyException - probably some kind of lock is not > >> > released if > >> > lifecycle ends with error. > >> > > >> > > >> > Thanks, > >> > > >> > > >> > Martin Kočí > >> > > >> > > >> > >> > >> > >> > > > > > > >
