myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Marinschek <mmarinsc...@apache.org>
Subject Re: Extended Debug Tree - MYFACES-2676
Date Thu, 27 May 2010 07:26:27 GMT
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 <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. 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.korherr@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.korherr@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.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 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.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 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.petracek@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 <lu4242@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.petracek@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.korherr@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 <mmarinschek@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
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Mime
View raw message