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
