You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Martin Marinschek <ma...@gmail.com> on 2008/03/02 06:59:42 UTC

Re: FacesContext.getCurrentInstance() provoking StackTraceException on initialization

The comment is a bit wrong - the method is present in JSF1.2, not in JSF 1.1 ;)

regards,

Martin

2008/2/28 Bruno Aranda <br...@gmail.com>:
> The problem seems to be that the orchestra FacesContextWrapper does not
> implement/override the getELContext(), the code was commented out. (seems to
> cause problems, MYFACES-1820?)
>
> // This method is present in JSF1.1, but not JSF1.2 so must not
>      // exist in this JSF1.1-compatible wrapper class. The default
>     // implementation provided by the base FacesContext class in
>     // JSF1.2 should be adequate as long as this class does NOT
>     // use install=true in the constructor. See MYFACES-1820.
>
> //    public final ELContext getELContext()
> //    {
> //        return _facesContext.getELContext();
> //    }
>
> If I uncomment this code, orchestra + trinidad 1.2 works fine. The reason
> is, that the default FacesContext.getELContext delegates to the FacesContext
> current instance getELContext() method. In Trinidad's CacheRenderKit
> implementation of the FacesContext (the current instance at the moment of
> the exception), the getElContext() method just delegates to the wrapped
> FacesContext.getElContext() provoking the infinite loop.
>
> Any ideas?
>
> Bruno
>
>
>
> On 27/02/2008, Bruno Aranda <br...@gmail.com> wrote:
> > Good, will try to see what I find. Thanks guys! :)
> >
> > Bruno
> >
> >
> >
> > On 27/02/2008, simon.kitching@chello.at <si...@chello.at> wrote:
> > > Sochor Zdeněk schrieb:
> > >
> > > > Hi,
> > > >  comments inline
> > > >
> > > > simon.kitching@chello.at napsal(a):
> > > >> Hi Bruno,
> > > >>
> > > >> Bruno Aranda schrieb:
> > > >>
> > > >>> Hi,
> > > >>>
> > > >>> I have a webapp with the combination
> > > >>>
> > > >>> myfaces core 1.2.3-SNAPSHOT
> > > >>> trinidad 1.2.7-SNAPSHOT
> > > >>> orchestra-core 1.1-SNAPSHOT
> > > >>> and others (Facelets, Spring...)
> > > >>>
> > > >>> This used to work a weeks ago, but today I was trying to start it
> > > >>> again and on initialization this exception happens:
> > > >>>
> > > >>> 2008-02-27 13:23:37,991 [btpool0-1] DEBUG (JsfFrameworkAdapter,57) -
> > > >>> Beginning request
> > > >>> 2008-02-27 13:23:37,992 [btpool0-1] DEBUG
> > > >>> (OrchestraFacesContextFactory$1,114) - Running inithandler of type
> > > >>> java.util.LinkedList$ListItr
> > > >>> 2008-02-27 13:23:37,997 [btpool0-1] DEBUG
> > > >>> (OrchestraFacesContextFactory$1,114) - Running inithandler of type
> > > >>> java.util.LinkedList$ListItr
> > > >>> 2008-02-27 13:23:38,365 [btpool0-1] DEBUG
> > > >>> (OrchestraFacesContextFactory$1,129) - Running release
> > > >>> 2008-02-27 13:23:38,368 [btpool0-1] DEBUG (JsfFrameworkAdapter,69) -
> > > >>> Ending request
> > > >>>
> > > > timed :38,368
> > > >>> 2008-02-27 13:23:38.260::WARN:  Error for
> > > >>> /intact/intact-search-webapp/search.xhtml
> > > >>>
> > > > timed :38.260
> > > > -> sooner than previous logged message (by 108 ms)
> > > > (It also use other format than DEBUG leveled messages)
> > >
> > >
> > > Well spotted, Zdenek!
> > >
> > >
> > > > Time shows issue raised IN Orchestra (it's before releasing work of
> > > > Orchestra)
> > >
> > >
> > > Well, it shows that the problem did occur between orchestra "running
> > > initHandler" and "running release". That does explain a few things.
> > >
> > > When a FacesContext is created for a new request, Orchestra tries to run
> > > a sequence of "initHandlers". If an exception happens in one of the
> > > initHandlers then it immediately runs the "release" methods of the
> > > initHandlers that successfully initialised, so that they can release any
> > > resources they acquired.
> > >
> > > One of these initHandlers must be triggering this infinite loop somehow.
> > > This *is* code that changed recently, and is almost certainly the root
> > > of the problem. It's some kind of unexpected interaction with Trinidad
> > > though, as this process works fine without Trinidad in the mix. I
> > > suspect that Trinidad is also wrapping the FacesContext, and then does
> > > not like its wrapper being called so early in the jsf lifecycle.
> > >
> > > Unfortunately I'm off on holiday for 4 days so can't help with debugging
> > > right now. Anyway, I don't use trinidad so would not be able to
> > > duplicate the problem locally.
> > >
> > > To debug this issue, you probably need to put a breakpoint at
> > >     OrchestraFacesContextFactory.getFacesContext
> > > then trace from there.
> > >
> > > Regards,
> > >
> > > Simon
> > >
> > >
> >
> >
>
>



-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces