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 >
