Return-Path: Delivered-To: apmail-myfaces-dev-archive@www.apache.org Received: (qmail 57625 invoked from network); 27 May 2010 22:24:53 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 27 May 2010 22:24:53 -0000 Received: (qmail 91037 invoked by uid 500); 27 May 2010 22:24:52 -0000 Delivered-To: apmail-myfaces-dev-archive@myfaces.apache.org Received: (qmail 90902 invoked by uid 500); 27 May 2010 22:24:52 -0000 Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Development" Delivered-To: mailing list dev@myfaces.apache.org Received: (qmail 90895 invoked by uid 99); 27 May 2010 22:24:52 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 27 May 2010 22:24:52 +0000 X-ASF-Spam-Status: No, hits=1.4 required=10.0 tests=AWL,FREEMAIL_FROM,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of sethfromaustria@gmail.com designates 209.85.161.53 as permitted sender) Received: from [209.85.161.53] (HELO mail-fx0-f53.google.com) (209.85.161.53) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 27 May 2010 22:24:48 +0000 Received: by fxm14 with SMTP id 14so503992fxm.12 for ; Thu, 27 May 2010 15:24:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=w7OwraY7JZn3CY/OXDIvR5seLMKTXEM99Z6d0ae5W5g=; b=PpCSrlx2FFdpeLOzRpvWXtMwBINdXAFWP25DqX1ytRu67cR/tR93ja0d8TC+kHP+cn YJHChqsHq5IpZ8R2Ibpk0NDQ7T+NGXw/29wQPjSIe5qBx33/DMR/NlGgu7HzI2LNZjLS 9x2V/aLKFTa6Bs1F6uDd7M7a9YOlwSOKO6I2M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=OVR8WDufqkQNnMHcMo+CvA3ei7khuQV2q87mlXV1s7TnelL6AeijsfDgVEv9VjfAbL 0tJq2rHOVeq6csNHuRqggoaHjw2qRl+bWSqaTUzRwS8OvDtV0in8fZwcEXqUt+mW1815 iQZ8JA/iJwczC2NfpBNVg+Hqy1abdN2l1wHDw= MIME-Version: 1.0 Received: by 10.102.14.5 with SMTP id 5mr6958334mun.33.1274999066201; Thu, 27 May 2010 15:24:26 -0700 (PDT) Sender: sethfromaustria@gmail.com Received: by 10.103.228.12 with HTTP; Thu, 27 May 2010 15:24:26 -0700 (PDT) In-Reply-To: References: Date: Fri, 28 May 2010 00:24:26 +0200 X-Google-Sender-Auth: ocQb09oCHpzNLW2hGpgmKYDef9M Message-ID: Subject: Re: Extended Debug Tree - MYFACES-2676 From: Jakob Korherr To: MyFaces Development Content-Type: multipart/alternative; boundary=0016363b9ac46e0fd104879adaf3 --0016363b9ac46e0fd104879adaf3 Content-Type: text/plain; charset=UTF-8 That's really great news! Regards, Jakob 2010/5/27 Martin Marinschek > 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 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 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 > >> > >>> 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 > >>> > >>> 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 > >>>> > >>>> 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 > >>>>> > >>>>> 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 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 > >>>>>> > > >>>>>> >> Hi > >>>>>> >> > >>>>>> >> 2010/5/19 Jan-Kees van Andel > >>>>>> >> > >>>>>> >> 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 > >>>>>> >>> > >>>>>> >>>> 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 > >>>>>> >>>> > >>>>>> >>>> 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 > >>>>>> >>>>> > >>>>>> >>>>> 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 > >>>>>> >>>>>> > >>>>>> >>>>>> 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 > >>>>>> >>>>>>> > >>>>>> >>>>>>> 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 > -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at --0016363b9ac46e0fd104879adaf3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That's really great news!

Regards,
Jakob

2010/5/27 Martin Marinschek <mmarinschek@apache.org>
After Leonardo's work on:

https://issues.apache.org/jira/browse/MYFACES-2737

we don't need to bother about that additional faces-context retri= eval
at all anymore - just do a getFacesContext(), that's it.

best regards,

Martin


On 5/27/10, Martin Marinschek <mmarinschek@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.petracek@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. m= ode.
>>
>> -> +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.korherr@gmail.com>
>>
>>> Hi guys,
>>>
>>> I'd like to sum this up and get some final opinions on whe= ther or not to
>>> remove the code from UIInput.
>>>
>>> Keeping the code on UIInput would provide the call stack in th= e extended
>>> debug tree for submittedValue and localValue which is a very c= ool
>>> feature,
>>> but may lead to a small performance loss (even in production s= tage)
>>> unless
>>> we cache the project stage setting in UIInput. This could resu= lt in
>>> weird
>>> behavior when using MyFaces from a shared lib folder on a syst= em with
>>> many
>>> applications with different project stage settings.
>>>
>>> This weird behavior however only means having the call stack a= vailable
>>> 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 ri= d of the
>>> performance issue and furthermore add a wiki page about this.<= br> >>>
>>>
>>> What do you guys think?
>>>
>>> Regards,
>>> Jakob
>>>
>>> 2010/5/21 Jakob Korherr <jakob.korherr@gmail.com>
>>>
>>> But this _could_ be a problem, or at least result in weird beh= avior, so
>>> I
>>>> think it is the best solution just to remove the code from= UIInput...
>>>>
>>>> Regards,
>>>> Jakob
>>>>
>>>> 2010/5/21 Gerhard Petracek <gerhard.petracek@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 <mmarinschek@apache.org>
>>>>>
>>>>> Hi guys,
>>>>>>
>>>>>> if MyFaces is deployed with the web-app, the stati= c var will reside
>>>>>> in
>>>>>> a class which is loaded by the context class-loade= r - so once per
>>>>>> app.
>>>>>> Problems might only arise if MyFaces is deployed o= nly once for all
>>>>>> web-apps - which will seldom be the case, I guess.=
>>>>>>
>>>>>> best regards,
>>>>>>
>>>>>> Martin
>>>>>>
>>>>>> On 5/21/10, Jakob Korherr <jakob.korherr@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 <lu4242@gmail.com>
>>>>>> >
>>>>>> >> Hi
>>>>>> >>
>>>>>> >> 2010/5/19 Jan-Kees van Andel <jankeesvanandel@gmail.com>
>>>>>> >>
>>>>>> >> Sounds plausible, we already do the same = thing with the
>>>>>> ExternalContexts
>>>>>> >>> class.
>>>>>> >>>
>>>>>> >>> It's blazing fast, but the questi= on 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.
>>>>>> >>
>>>>>> >>
>>>>>> >>> =C2=A0If the spec doesn't dictate= otherwise, I'm in favor of caching
>>>>>> >>> it.
>>>>>> >>>
>>>>>> >>> Another idea is to cache it in the Se= rvletContext. 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().getExte= rnalContext(), and we
>>>>>> >> want
>>>>>> to
>>>>>> >> avoid
>>>>>> >> the call to FacesContext.getCurrentInstan= ce() ).
>>>>>> >>
>>>>>> >> Talking with Gerhard, the conclusion was = a static var could do the
>>>>>> job. Is
>>>>>> >> just unrealistic assume someone has a pro= duction environment with
>>>>>> some
>>>>>> >> applications with project stage "pro= duction" and others
>>>>>> >> "development"
>>>>>> >> (note
>>>>>> >> shared variables are "shared" b= y 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.petracek@gmail.com><= br> >>>>>> >>>
>>>>>> >>>> we don't have to cache the fa= ces-context.
>>>>>> >>>> we can use e.g. an interface with= a static final field.
>>>>>> >>>>
>>>>>> >>>> usage (example):
>>>>>> >>>> if(Boolean.TRUE.equals(InternalPr= ojectStage.IS_DEV_MODE))
>>>>>> >>>> {
>>>>>> >>>> //...
>>>>>> >>>> }
>>>>>> >>>>
>>>>>> >>>> -> there is just one evaluatio= n.
>>>>>> >>>>
>>>>>> >>>> regards,
>>>>>> >>>> gerhard
>>>>>> >>>>
>>>>>> >>>> http://www.irian.at
>>>>>> >>>>
>>>>>> >>>> Your JSF powerhouse -
>>>>>> >>>> JSF Consulting, Development and >>>>>> >>>> Courses in English and German
>>>>>> >>>>
>>>>>> >>>> Professional Support for Apache M= yFaces
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>> 2010/5/19 Leonardo Uribe <lu4242@gmail.com>
>>>>>> >>>>
>>>>>> >>>> Hi
>>>>>> >>>>>
>>>>>> >>>>> The problem in this case is t= he only place we can store this
>>>>>> >>>>> information
>>>>>> >>>>> is the component instance its= elf. So, at least there is one
>>>>>> >>>>> lookup
>>>>>> per
>>>>>> >>>>> component.
>>>>>> >>>>>
>>>>>> >>>>> If we try to cache facesConte= xt, 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.<= br> >>>>>> >>>>>
>>>>>> >>>>> regards,
>>>>>> >>>>>
>>>>>> >>>>> Leonardo Uribe
>>>>>> >>>>>
>>>>>> >>>>> 2010/5/19 Gerhard Petracek &l= t;gerhard.petracek@gmail.com<= /a>>
>>>>>> >>>>>
>>>>>> >>>>> hi,
>>>>>> >>>>>>
>>>>>> >>>>>> as long as we don't w= ant to change the project stage
>>>>>> >>>>>> dynamically,
>>>>>> we
>>>>>> >>>>>> can just store e.g. a mar= ker as static information.
>>>>>> >>>>>>
>>>>>> >>>>>> regards,
>>>>>> >>>>>> gerhard
>>>>>> >>>>>>
>>>>>> >>>>>>
>>>>>> >>>>>> http://www.irian.at
>>>>>> >>>>>>
>>>>>> >>>>>> Your JSF powerhouse -
>>>>>> >>>>>> JSF Consulting, Developme= nt and
>>>>>> >>>>>> Courses in English and Ge= rman
>>>>>> >>>>>>
>>>>>> >>>>>> Professional Support for = Apache MyFaces
>>>>>> >>>>>>
>>>>>> >>>>>>
>>>>>> >>>>>>
>>>>>> >>>>>> 2010/5/19 Jakob Korherr &= lt;jakob.korherr@gmail.com&g= t;
>>>>>> >>>>>>
>>>>>> >>>>>> Hi Martin,
>>>>>> >>>>>>>
>>>>>> >>>>>>> Indeed, we have to ca= ll FacesContext.getCurrentInstance()
>>>>>> everytime.
>>>>>> >>>>>>>
>>>>>> >>>>>>> So I guess it will be= better to remove the code from UIInput!
>>>>>> >>>>>>>
>>>>>> >>>>>>> Regards,
>>>>>> >>>>>>> Jakob
>>>>>> >>>>>>>
>>>>>> >>>>>>> 2010/5/19 Martin Mari= nschek <mmarinschek@apache.org= >
>>>>>> >>>>>>>
>>>>>> >>>>>>> Hi Jakob,
>>>>>> >>>>>>>>
>>>>>> >>>>>>>> > The problem = with this is that the code on UIInput checks
>>>>>> >>>>>>>> > the
>>>>>> >>>>>>>> ProjectStage
>>>>>> >>>>>>>> > everytime se= tSubmittedValue() or setValue() are called,
>>>>>> >>>>>>>> > which
>>>>>> is
>>>>>> >>>>>>>> very often
>>>>>> >>>>>>>> > and could ma= ke 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, becau= se this will be gone.
>>>>>> >>>>>>>> >
>>>>>> >>>>>>>> > The question= now is if we should leave it the way it
>>>>>> currently is
>>>>>> >>>>>>>> (with the
>>>>>> >>>>>>>> > code on UIIn= put and the possibility to display the call
>>>>>> stack) or
>>>>>> >>>>>>>> if we
>>>>>> >>>>>>>> > should remov= e the code from UIInput (which means no
>>>>>> >>>>>>>> > slowdown
>>>>>> on
>>>>>> >>>>>>>> > setSubmitted= Value() and setValue() but loosing the call
>>>>>> stack).
>>>>>> >>>>>>>> What do you
>>>>>> >>>>>>>> > guys think? = Any opinions/objections?
>>>>>> >>>>>>>>
>>>>>> >>>>>>>> for me it is a qu= estion how fast this getProjectStage()
>>>>>> derivation
>>>>>> >>>>>>>> is.
>>>>>> >>>>>>>> If that means to = call FacesContext.getCurrentInstance() all
>>>>>> >>>>>>>> the
>>>>>> >>>>>>>> time,
>>>>>> >>>>>>>> the impact is con= siderable (thread-local resolution). In
>>>>>> >>>>>>>> this
>>>>>> case
>>>>>> >>>>>>>> it
>>>>>> >>>>>>>> might be better t= o not have this information...
>>>>>> >>>>>>>>
>>>>>> >>>>>>>> Martin
>>>>>> >>>>>>>>
>>>>>> >>>>>>>> > Regards,
>>>>>> >>>>>>>> > Jakob
>>>>>> >>>>>>>> >
>>>>>> >>>>>>>> > --
>>>>>> >>>>>>>> > Jakob Korher= r
>>>>>> >>>>>>>> >
>>>>>> >>>>>>>> > blog: http://www.jakobk.com
>>>>>> >>>>>>>> > twitter: http://twitter.c= om/jakobkorherr
>>>>>> >>>>>>>> > work: http://www.irian.at
>>>>>> >>>>>>>> >
>>>>>> >>>>>>>>
>>>>>> >>>>>>>>
>>>>>> >>>>>>>>
>>>>>> >>>>>>>> --
>>>>>> >>>>>>>>
>>>>>> >>>>>>>> http://www.irian.at
>>>>>> >>>>>>>>
>>>>>> >>>>>>>> Your JSF powerhou= se -
>>>>>> >>>>>>>> JSF Consulting, D= evelopment and
>>>>>> >>>>>>>> Courses in Englis= h and German
>>>>>> >>>>>>>>
>>>>>> >>>>>>>> Professional Supp= ort for Apache MyFaces
>>>>>> >>>>>>>>
>>>>>> >>>>>>>
>>>>>> >>>>>>>
>>>>>> >>>>>>>
>>>>>> >>>>>>> --
>>>>>> >>>>>>> Jakob Korherr
>>>>>> >>>>>>>
>>>>>> >>>>>>> blog: http://www.jakobk.com
>>>>>> >>>>>>> twitter: http://twitter.com/jakobk= orherr
>>>>>> >>>>>>> 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: ht= tp://www.irian.at
>>>>
>>>
>>>
>>>
>>> --
>>> Jakob Korherr
>>>
>>> blog: http= ://www.jakobk.com
>>> twitter: http://twitter.com/jakobkorherr
>>> work: http:/= /www.irian.at
>>>
>>
>
>
> --
>
> http://www.irian.at<= /a>
>
> 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



--
Jakob Korhe= rr

blog: http://www.jakobk.com=
twitter: http://twitter.com= /jakobkorherr
work: http://www.irian.at
--0016363b9ac46e0fd104879adaf3--