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
