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
