Hi, On Mon, Mar 17, 2008 at 9:10 AM, Bruno Aranda <[EMAIL PROTECTED]> wrote: > Good. Strangely enough I was using orchestra core 1.1-SNAPSHOT and moving to > the released 1.1 fixes the issue. Thanks!
I am really glad that this fix made it into the released 1.1 -M > > Bruno > > > > On 17/03/2008, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > [EMAIL PROTECTED] schrieb: > > > > > Hi Bruno, > > > > > > Bruno Aranda schrieb: > > > > > >> Hi, > > >> > > >> I just started the app I was working on after the great JSFDays and > > >> now I get this exception. It was using trinidad 1.2.7-SNAPSHOT, but > > >> the same happens with the 1.2.7 version - so maybe it is a bug in > > >> orchestra as well. It seems to be using the default ExternalContext, > > >> which throws an UnsupportedOperationException as defined in the JSF > > >> 1.2 spec. > > >> > > >> java.lang.UnsupportedOperationException at > > >> > javax.faces.context.ExternalContext.setRequest(ExternalContext.java:124) > > >> at > > >> > org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl._isSetRequestBugPresent(GlobalConfiguratorImpl.java:490) > > >> at > > >> > org.apache.myfaces.trinidadinternal.config.GlobalConfiguratorImpl.getExternalContext(GlobalConfiguratorImpl.java:309) > > >> at > > >> > org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl$CacheRenderKit.(FacesContextFactoryImpl.java:86) > > >> at > > >> > org.apache.myfaces.trinidadinternal.context.FacesContextFactoryImpl.getFacesContext(FacesContextFactoryImpl.java:64) > > >> at > > >> > javax.faces.webapp.FacesServlet.prepareFacesContext(FacesServlet.java:234) > > >> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:145) at > > >> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) > > >> at > > >> > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093) > > >> at > > >> > uk.ac.ebi.intact.webapp.JpaIntactSessionRequestFilter.doFilter(JpaIntactSessionRequestFilter.java:118) > > >> at > > >> > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) > > >> at > > >> > org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._invokeDoFilter(TrinidadFilterImpl.java:238) > > >> at > > >> > org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:195) > > >> at > > >> > org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:138) > > >> > > > > > > > > href=I can't initially think how Orchestra could be involved here. > Orchestra > > > > > does not mess with the ExternalContext at all, eg doesn't create a > > > decorator for it. It does wrap the FacesContext, but no FacesContext > > > instances appear to be involved in this callstack either. > > > > > > I did make a change to FacesContext.java to fix the > > > FacesContext.getELContext method, but that isn't anywhere in this > > > callstack, so that is unlikely to be the cause of the problem. > > > > > > Maybe the trinidad people have some idea what is going on here.. > > > > > > > > > Umm..I take that back. > > > > Mario has pointed out that Martin Marinschek committed a patch to > > Orchestra core *after* the 1.1 release, which adds an > > ExternalContextWrapper. And this is almost certainly the cause of the > > problem. > > > > So if you use the official 1.1 release, the problem will probably go away. > > > > The root problem is again the broken delegation model of the JSF > > specification. The ExternalContextWrapper decorates a JSF1.1 > > ExternalContext class by delegating to a "wrapped" instance. But the > > JSF1.2 spec adds a new method, so invocations of that end up in the > > default ExternalContext implementation not the wrapper. And therefore > > does not properly delegate. > > > > This can definitely be fixed by using reflection to implement this > > additional 1.2-specific method, but as I mentioned above, just using the > > core 1.1 release should also avoid this problem for the moment. > > > > Regards, > > > > Simon > > > > > > > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
