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 <mmarinsc...@apache.org> 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 <gerhard.petra...@gmail.com> 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 <jakob.korh...@gmail.com> >> >>> 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 <jakob.korh...@gmail.com> >>> >>> 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 <gerhard.petra...@gmail.com> >>>> >>>> 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 <mmarinsc...@apache.org> >>>>> >>>>> 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 <jakob.korh...@gmail.com> 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 <lu4...@gmail.com> >>>>>> > >>>>>> >> Hi >>>>>> >> >>>>>> >> 2010/5/19 Jan-Kees van Andel <jankeesvanan...@gmail.com> >>>>>> >> >>>>>> >> 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 <gerhard.petra...@gmail.com> >>>>>> >>> >>>>>> >>>> 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 <lu4...@gmail.com> >>>>>> >>>> >>>>>> >>>> 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 <gerhard.petra...@gmail.com> >>>>>> >>>>> >>>>>> >>>>> 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 <jakob.korh...@gmail.com> >>>>>> >>>>>> >>>>>> >>>>>> 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 <mmarinsc...@apache.org> >>>>>> >>>>>>> >>>>>> >>>>>>> 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
