That's really great news! Regards, Jakob
2010/5/27 Martin Marinschek <[email protected]> > After Leonardo's work on: > > https://issues.apache.org/jira/browse/MYFACES-2737 > > we don't need to bother about that additional faces-context retrieval > at all anymore - just do a getFacesContext(), that's it. > > best regards, > > Martin > > > On 5/27/10, Martin Marinschek <[email protected]> wrote: > > Hi guys, > > > > I am alright with this. Jakob, can you check generally if we do > > anything in static settings which would also be affected by this > > deployment scenario? I would certainly think it is possible that we > > already do so... > > > > best regards, > > > > Martin > > > > On 5/27/10, Gerhard Petracek <[email protected]> wrote: > >> to reduce possible confusions in such very special cases - we can > provide > >> a > >> meaningful default message, if the call stack is missing in dev. mode. > >> > >> -> +1 for keeping this feature (for now). > >> > >> regards, > >> gerhard > >> > >> http://www.irian.at > >> > >> Your JSF powerhouse - > >> JSF Consulting, Development and > >> Courses in English and German > >> > >> Professional Support for Apache MyFaces > >> > >> > >> > >> 2010/5/27 Jakob Korherr <[email protected]> > >> > >>> Hi guys, > >>> > >>> I'd like to sum this up and get some final opinions on whether or not > to > >>> remove the code from UIInput. > >>> > >>> Keeping the code on UIInput would provide the call stack in the > extended > >>> debug tree for submittedValue and localValue which is a very cool > >>> feature, > >>> but may lead to a small performance loss (even in production stage) > >>> unless > >>> we cache the project stage setting in UIInput. This could result in > >>> weird > >>> behavior when using MyFaces from a shared lib folder on a system with > >>> many > >>> applications with different project stage settings. > >>> > >>> This weird behavior however only means having the call stack available > >>> in > >>> the debug output or not, so it is just an extra feature which will be > >>> available or not when mixing different project stage settings and I > >>> think > >>> we > >>> can deal with this by a good documentation (e.g. adding a wiki page > >>> regarding this problem) and also I guess this will not affect many > >>> users. > >>> > >>> So my suggestion is to leave the code on UIInput but to cache the > >>> Project > >>> Stage setting in a static final attribute on UIInput to get rid of the > >>> performance issue and furthermore add a wiki page about this. > >>> > >>> > >>> What do you guys think? > >>> > >>> Regards, > >>> Jakob > >>> > >>> 2010/5/21 Jakob Korherr <[email protected]> > >>> > >>> But this _could_ be a problem, or at least result in weird behavior, so > >>> I > >>>> think it is the best solution just to remove the code from UIInput... > >>>> > >>>> Regards, > >>>> Jakob > >>>> > >>>> 2010/5/21 Gerhard Petracek <[email protected]> > >>>> > >>>> yes - that's true! i also told leonardo about it. > >>>>> in his e-mail he just skipped it... > >>>>> > >>>>> regards, > >>>>> gerhard > >>>>> > >>>>> http://www.irian.at > >>>>> > >>>>> Your JSF powerhouse - > >>>>> JSF Consulting, Development and > >>>>> Courses in English and German > >>>>> > >>>>> Professional Support for Apache MyFaces > >>>>> > >>>>> > >>>>> > >>>>> 2010/5/21 Martin Marinschek <[email protected]> > >>>>> > >>>>> Hi guys, > >>>>>> > >>>>>> if MyFaces is deployed with the web-app, the static var will reside > >>>>>> in > >>>>>> a class which is loaded by the context class-loader - so once per > >>>>>> app. > >>>>>> Problems might only arise if MyFaces is deployed only once for all > >>>>>> web-apps - which will seldom be the case, I guess. > >>>>>> > >>>>>> best regards, > >>>>>> > >>>>>> Martin > >>>>>> > >>>>>> On 5/21/10, Jakob Korherr <[email protected]> wrote: > >>>>>> > So the conclusion is to use a private static boolean on UIInput > >>>>>> > that > >>>>>> tells > >>>>>> > us if we are in Development stage or not. > >>>>>> > > >>>>>> > Any objections to that? > >>>>>> > > >>>>>> > Regards, > >>>>>> > Jakob > >>>>>> > > >>>>>> > 2010/5/20 Leonardo Uribe <[email protected]> > >>>>>> > > >>>>>> >> Hi > >>>>>> >> > >>>>>> >> 2010/5/19 Jan-Kees van Andel <[email protected]> > >>>>>> >> > >>>>>> >> Sounds plausible, we already do the same thing with the > >>>>>> ExternalContexts > >>>>>> >>> class. > >>>>>> >>> > >>>>>> >>> It's blazing fast, but the question is: Are we allowed to and do > >>>>>> >>> we > >>>>>> want > >>>>>> >>> to cache the instance? > >>>>>> >>> > >>>>>> >>> > >>>>>> >> In theory yes, because it does not change the behavior expected > by > >>>>>> the > >>>>>> >> spec. > >>>>>> >> > >>>>>> >> > >>>>>> >>> If the spec doesn't dictate otherwise, I'm in favor of caching > >>>>>> >>> it. > >>>>>> >>> > >>>>>> >>> Another idea is to cache it in the ServletContext. It's not as > >>>>>> >>> fast > >>>>>> as a > >>>>>> >>> static final field, but still pretty fast and can be inspected > >>>>>> >>> and > >>>>>> >>> modified > >>>>>> >>> through appserver tooling. > >>>>>> >>> > >>>>>> >>> > >>>>>> >> The problem is from UIInput.setValue() or > >>>>>> >> UIInput.setSubmittedValue() > >>>>>> we > >>>>>> >> don't have access to ServletContext (the only way is through > >>>>>> >> FacesContext.getCurrentInstance().getExternalContext(), and we > >>>>>> >> want > >>>>>> to > >>>>>> >> avoid > >>>>>> >> the call to FacesContext.getCurrentInstance() ). > >>>>>> >> > >>>>>> >> Talking with Gerhard, the conclusion was a static var could do > the > >>>>>> job. Is > >>>>>> >> just unrealistic assume someone has a production environment with > >>>>>> some > >>>>>> >> applications with project stage "production" and others > >>>>>> >> "development" > >>>>>> >> (note > >>>>>> >> shared variables are "shared" by all applications hosted in a web > >>>>>> server). > >>>>>> >> In the worst case, the applications will continue working. > >>>>>> >> > >>>>>> >> regards, > >>>>>> >> > >>>>>> >> Leonardo > >>>>>> >> > >>>>>> >> > >>>>>> >>> Regards, > >>>>>> >>> Jan-Kees > >>>>>> >>> > >>>>>> >>> > >>>>>> >>> 2010/5/19 Gerhard Petracek <[email protected]> > >>>>>> >>> > >>>>>> >>>> we don't have to cache the faces-context. > >>>>>> >>>> we can use e.g. an interface with a static final field. > >>>>>> >>>> > >>>>>> >>>> usage (example): > >>>>>> >>>> if(Boolean.TRUE.equals(InternalProjectStage.IS_DEV_MODE)) > >>>>>> >>>> { > >>>>>> >>>> //... > >>>>>> >>>> } > >>>>>> >>>> > >>>>>> >>>> -> there is just one evaluation. > >>>>>> >>>> > >>>>>> >>>> regards, > >>>>>> >>>> gerhard > >>>>>> >>>> > >>>>>> >>>> http://www.irian.at > >>>>>> >>>> > >>>>>> >>>> Your JSF powerhouse - > >>>>>> >>>> JSF Consulting, Development and > >>>>>> >>>> Courses in English and German > >>>>>> >>>> > >>>>>> >>>> Professional Support for Apache MyFaces > >>>>>> >>>> > >>>>>> >>>> > >>>>>> >>>> 2010/5/19 Leonardo Uribe <[email protected]> > >>>>>> >>>> > >>>>>> >>>> Hi > >>>>>> >>>>> > >>>>>> >>>>> The problem in this case is the only place we can store this > >>>>>> >>>>> information > >>>>>> >>>>> is the component instance itself. So, at least there is one > >>>>>> >>>>> lookup > >>>>>> per > >>>>>> >>>>> component. > >>>>>> >>>>> > >>>>>> >>>>> If we try to cache facesContext, unfortunately there is not > >>>>>> >>>>> safe > >>>>>> way to > >>>>>> >>>>> clean this reference (portlet case), so there is a risk of use > >>>>>> >>>>> old > >>>>>> >>>>> instances > >>>>>> >>>>> of this object in this case. > >>>>>> >>>>> > >>>>>> >>>>> regards, > >>>>>> >>>>> > >>>>>> >>>>> Leonardo Uribe > >>>>>> >>>>> > >>>>>> >>>>> 2010/5/19 Gerhard Petracek <[email protected]> > >>>>>> >>>>> > >>>>>> >>>>> hi, > >>>>>> >>>>>> > >>>>>> >>>>>> as long as we don't want to change the project stage > >>>>>> >>>>>> dynamically, > >>>>>> we > >>>>>> >>>>>> can just store e.g. a marker as static information. > >>>>>> >>>>>> > >>>>>> >>>>>> regards, > >>>>>> >>>>>> gerhard > >>>>>> >>>>>> > >>>>>> >>>>>> > >>>>>> >>>>>> http://www.irian.at > >>>>>> >>>>>> > >>>>>> >>>>>> Your JSF powerhouse - > >>>>>> >>>>>> JSF Consulting, Development and > >>>>>> >>>>>> Courses in English and German > >>>>>> >>>>>> > >>>>>> >>>>>> Professional Support for Apache MyFaces > >>>>>> >>>>>> > >>>>>> >>>>>> > >>>>>> >>>>>> > >>>>>> >>>>>> 2010/5/19 Jakob Korherr <[email protected]> > >>>>>> >>>>>> > >>>>>> >>>>>> Hi Martin, > >>>>>> >>>>>>> > >>>>>> >>>>>>> Indeed, we have to call FacesContext.getCurrentInstance() > >>>>>> everytime. > >>>>>> >>>>>>> > >>>>>> >>>>>>> So I guess it will be better to remove the code from > UIInput! > >>>>>> >>>>>>> > >>>>>> >>>>>>> Regards, > >>>>>> >>>>>>> Jakob > >>>>>> >>>>>>> > >>>>>> >>>>>>> 2010/5/19 Martin Marinschek <[email protected]> > >>>>>> >>>>>>> > >>>>>> >>>>>>> Hi Jakob, > >>>>>> >>>>>>>> > >>>>>> >>>>>>>> > The problem with this is that the code on UIInput checks > >>>>>> >>>>>>>> > the > >>>>>> >>>>>>>> ProjectStage > >>>>>> >>>>>>>> > everytime setSubmittedValue() or setValue() are called, > >>>>>> >>>>>>>> > which > >>>>>> is > >>>>>> >>>>>>>> very often > >>>>>> >>>>>>>> > and could make MyFaces a bit slower, I guess. If we > remove > >>>>>> this > >>>>>> >>>>>>>> code on > >>>>>> >>>>>>>> > UIInput, the debug output will stay mostly the same > except > >>>>>> for the > >>>>>> >>>>>>>> call > >>>>>> >>>>>>>> > stack, because this will be gone. > >>>>>> >>>>>>>> > > >>>>>> >>>>>>>> > The question now is if we should leave it the way it > >>>>>> currently is > >>>>>> >>>>>>>> (with the > >>>>>> >>>>>>>> > code on UIInput and the possibility to display the call > >>>>>> stack) or > >>>>>> >>>>>>>> if we > >>>>>> >>>>>>>> > should remove the code from UIInput (which means no > >>>>>> >>>>>>>> > slowdown > >>>>>> on > >>>>>> >>>>>>>> > setSubmittedValue() and setValue() but loosing the call > >>>>>> stack). > >>>>>> >>>>>>>> What do you > >>>>>> >>>>>>>> > guys think? Any opinions/objections? > >>>>>> >>>>>>>> > >>>>>> >>>>>>>> for me it is a question how fast this getProjectStage() > >>>>>> derivation > >>>>>> >>>>>>>> is. > >>>>>> >>>>>>>> If that means to call FacesContext.getCurrentInstance() all > >>>>>> >>>>>>>> the > >>>>>> >>>>>>>> time, > >>>>>> >>>>>>>> the impact is considerable (thread-local resolution). In > >>>>>> >>>>>>>> this > >>>>>> case > >>>>>> >>>>>>>> it > >>>>>> >>>>>>>> might be better to not have this information... > >>>>>> >>>>>>>> > >>>>>> >>>>>>>> Martin > >>>>>> >>>>>>>> > >>>>>> >>>>>>>> > Regards, > >>>>>> >>>>>>>> > Jakob > >>>>>> >>>>>>>> > > >>>>>> >>>>>>>> > -- > >>>>>> >>>>>>>> > Jakob Korherr > >>>>>> >>>>>>>> > > >>>>>> >>>>>>>> > blog: http://www.jakobk.com > >>>>>> >>>>>>>> > twitter: http://twitter.com/jakobkorherr > >>>>>> >>>>>>>> > work: http://www.irian.at > >>>>>> >>>>>>>> > > >>>>>> >>>>>>>> > >>>>>> >>>>>>>> > >>>>>> >>>>>>>> > >>>>>> >>>>>>>> -- > >>>>>> >>>>>>>> > >>>>>> >>>>>>>> http://www.irian.at > >>>>>> >>>>>>>> > >>>>>> >>>>>>>> Your JSF powerhouse - > >>>>>> >>>>>>>> JSF Consulting, Development and > >>>>>> >>>>>>>> Courses in English and German > >>>>>> >>>>>>>> > >>>>>> >>>>>>>> Professional Support for Apache MyFaces > >>>>>> >>>>>>>> > >>>>>> >>>>>>> > >>>>>> >>>>>>> > >>>>>> >>>>>>> > >>>>>> >>>>>>> -- > >>>>>> >>>>>>> Jakob Korherr > >>>>>> >>>>>>> > >>>>>> >>>>>>> blog: http://www.jakobk.com > >>>>>> >>>>>>> twitter: http://twitter.com/jakobkorherr > >>>>>> >>>>>>> work: http://www.irian.at > >>>>>> >>>>>>> > >>>>>> >>>>>> > >>>>>> >>>>>> > >>>>>> >>>>> > >>>>>> >>>> > >>>>>> >>> > >>>>>> >> > >>>>>> > > >>>>>> > > >>>>>> > -- > >>>>>> > Jakob Korherr > >>>>>> > > >>>>>> > blog: http://www.jakobk.com > >>>>>> > twitter: http://twitter.com/jakobkorherr > >>>>>> > work: http://www.irian.at > >>>>>> > > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> > >>>>>> http://www.irian.at > >>>>>> > >>>>>> Your JSF powerhouse - > >>>>>> JSF Consulting, Development and > >>>>>> Courses in English and German > >>>>>> > >>>>>> Professional Support for Apache MyFaces > >>>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> -- > >>>> Jakob Korherr > >>>> > >>>> blog: http://www.jakobk.com > >>>> twitter: http://twitter.com/jakobkorherr > >>>> work: http://www.irian.at > >>>> > >>> > >>> > >>> > >>> -- > >>> Jakob Korherr > >>> > >>> blog: http://www.jakobk.com > >>> twitter: http://twitter.com/jakobkorherr > >>> work: http://www.irian.at > >>> > >> > > > > > > -- > > > > http://www.irian.at > > > > Your JSF powerhouse - > > JSF Consulting, Development and > > Courses in English and German > > > > Professional Support for Apache MyFaces > > > > > -- > > http://www.irian.at > > Your JSF powerhouse - > JSF Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces > -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
