Good. Strangely enough I was using orchestra core 1.1-SNAPSHOT and moving to the released 1.1 fixes the issue. Thanks!
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 > > >
