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 mmarinsc...@apache.org wrote:
Hi
That's really great news!
Regards,
Jakob
2010/5/27 Martin Marinschek mmarinsc...@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 retrieval
at all anymore - just do a getFacesContext(),
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
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
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
Hi
Ok, it is done:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=807
regards,
Leonardo
Hi guys,
well, yes - I fear so as well.
I wonder if that development switch is used often in other places as
well - do we have that same performance problem somewhere else?
best regards,
Martin
On Fri, May 21, 2010 at 6:17 PM, Jakob Korherr jakob.korh...@gmail.com wrote:
But this _could_ be
Hi Martin
I think the code that do a lot of calls to FacesContext.getCurrentInstance()
right now is on all listeners attached to system events.
One example is
DefaultFaceletsStateManagementStrategy.PostAddPreRemoveFromViewListener. It
is a listener attached to PostAddToViewEvent /
Hi guys,
ok, in any case - let's not make the issue worse.
And - Leo - can you file a spec issue for this?
thx,
regards,
Martin
On 5/25/10, Leonardo Uribe lu4...@gmail.com wrote:
Hi Martin
I think the code that do a lot of calls to FacesContext.getCurrentInstance()
right now is on all
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
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
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
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
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
Hi guys,
In the last two weeks I was working on a better debug page (ui:debug /)
for MyFaces, which contains a lot more information than the current one.
This information includes the whole component tree (how it really is
rendered), renderer information and a value lifecycle (submittedValue,
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
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
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
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
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,
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?
If the spec doesn't dictate otherwise, I'm in favor of caching it.
Another idea is to cache it in the ServletContext.
21 matches
Mail list logo
