Re: [VOTE] release of MyFaces Core 2.1.8
+1 Leonardo Uribe píše v St 13. 06. 2012 v 18:41 +0200: Hi, I was running the needed tasks to get the 2.1.8 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.1.6 [1] 2. Maven artifact group org.apache.myfaces.core v2.1.8 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.1.8 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-234/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces218binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12320759
Re: [core] steps for release of myfaces core 2.1.8 / 2.0.14
Hi, it would be nice to solve https://issues.apache.org/jira/browse/MYFACES-3191 - users ask for it, topic Weird partial-response behavior with 2 partial-response tags in user list. And a trivial one: https://issues.apache.org/jira/browse/MYFACES-3243 Leonardo Uribe píše v Po 11. 06. 2012 v 18:00 +0200: Hi It could be good to do a release of myfaces core this week. If you have some bug that requires to be fixed, this is the moment to say something about it. regards, Leonardo Uribe
Re: [VOTE] Release of Extensions CDI (CODI) 1.0.5
+1 Gerhard Petracek píše v Čt 05. 04. 2012 v 10:36 +0200: Hi, I was running the needed tasks to get the 12th release of Apache MyFaces Extensions CDI (aka MyFaces CODI) out. The artifacts are deployed to Nexus [1] (and [2]). The release contains the following modules: - CODI Core - CODI JSF Module (for 1.2 and 2.0 and 2.1) - CODI JPA Module - CODI BV Module - CODI I18N-Message Module - CODI Scripting Module - CODI Trinidad Support Module (for 1.x and 2.x) - CODI Java-EE5 Support Module (for OpenWebBeans and Weld) - CODI Bundles - CODI OSGi Bundles - CODI Base Test-Infrastructure Module - CODI JUnit-Support Module - CODI Cargo-Support Module - CODI OpenWebBeans Test-Support Module - CODI JSF Test-Support Module - CODI JSF Example Please take a look at the 1.0.5 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Gerhard [1] https://repository.apache.org/content/repositories/orgapachemyfaces-005/ [2] https://repository.apache.org/content/repositories/orgapachemyfaces-005/org/apache/myfaces/extensions/cdi/myfaces-extcdi-parent/1.0.5/myfaces-extcdi-parent-1.0.5-source-release.zip [3] http://www.apache.org/foundation/voting.html#ReleaseVotes
Re: [VOTE] release of myfaces core 2.1.7
+1 Leonardo Uribe píše v St 04. 04. 2012 v 00:42 -0500: Hi, I was running the needed tasks to get the 2.1.7 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.1.5 [1] 2. Maven artifact group org.apache.myfaces.core v2.1.7 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.1.7 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-010/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces217binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12319845
Re: [core] performance: cache infos for views without build time modifications
Leonardo Uribe píše v Po 20. 02. 2012 v 17:51 -0500:
Hi
Unfortunately we can't cache facelets generated unique ids into
ComponentTagHandlerDelegate because a tag handler can be used in many
views because a view is the result of execute many facelet
compositions.
In facelets there are two hierarchical counters, one for
MARK_CREATED (FaceletContext.generateUniqueId) and the other for
component unique ids
(FaceletCompositionContext.generateUniqueComponentId). In theory if
the view is static, which means it generates the same component tree
each time, the list of generated ids will be the same. What we can do
is create a per-view cache, holding an ordered list with the generated
ids. In theory, when a dynamic part of a tree is about to begin, a new
level is started calling
FaceletCompositionContext.startComponentUniqueIdSection(), which
increase the level calling
SectionUniqueIdCounter.startUniqueIdSection() for both counters. So we
could add some logic into SectionUniqueIdCounter to store the values
of the counter on the base level and reuse it per view. It is not
going to be an easy trick but it seems reasonable, because it will
save a bunch of memory.
Ahh, I see. The idea with an ordered list is very good, it is better
store for ids.
Semi-related question: Can you please take a look at MYFACES-3470,
please? It can save the generateUniqueId now, but I'm not sure.
About @ResourceDependency annotations: The current code in
RequestViewContext check if the annotation was processed on the same
view, which means if the resource has been already added. That code is
ok. Note there is another cache that checks if the class has
@ResourceDependency annotations, to prevent scan it, but what we don't
have is one cache to store the classes that does not have any
@ResourceDependency and prevent any scanning at all. Which is more
expensive? a get() over a ConcurrentHashMap or a call to
inspectedClass.getAnnotation()? Only if the first is cheaper, the
cache has sense.
This one was only a though what is cacheable in static views, current
implementation is not a performance problem.
Finally, I don't think we can do anything for clientId, because its
generation is more tied to UIComponentBase internals. If an UIData or
UIRepeat or any other iteration component is used, clientId changes
per row, and is reset using setId() call. I think we can pass the
clientId through component attribute map, using some special attribute
name, but it doesn't sound good to me. After all, clientId calculation
is responsibility of UIComponent and it could be changed on the
related Renderer.
Yes, iteration components are problem. Generally many invocations of
getCliendId() come from
DefaultFaceletsStateManagementStrategy.restoreStateFromMap and thus is
this memory allocation coming from getClientId related to state saving.
But you have proposed solutions to state(ful, less) problem in email
discussion about stateless jsf implementation and that can minimize
String allocation in stateless/thread safe cases.
Regards,
Kočičák
regards,
Leonardo Uribe
2012/2/20 Martin Koci martin.kocicak.k...@gmail.com:
Same situation for clientId: in stable component tree is clientId
always the same (state saving depends on it)
unfortunately has UIComponent no method setClientId. But we can try set
it via reflexion and compare if it brings an improvement or not.
Currently getClientId() uses lazy init and involves:
findParentNamingContainer
namingContainer.getContainerClientId
stringBuilder appends
renderer.convertClientId
Martin Koci píše v Pá 17. 02. 2012 v 18:56 +0100:
Hi,
in situation, where no build-time tags (c:if, co:foreach, ...) and no
ui:include src=#{} are used (and no direct component.getChildren()
manipulation of course), builds VDL.buildView every time the same
component structure (same graph).
In this case compute myfaces some informations again and again but every
time with same results. For example, creating of unique ids is very
expensive:
FaceletContext.generateUniqueId
FaceletCompositionContext.generateUniqueComponentId
UniqueIdVendor.createUniqueId
in ComponentTagHandlerDelegate.apply(FaceletContext, UIComponent)
Can we cache this ids at ComponentTagHandlerDelegate in production in
case of view without build time modifications ? This is similar to [1].
Same situation with @ResourceDependency annotations: ApplicationImpl.
_handleAttachedResourceDependencyAnnotations computes the same result
with every request/response.
Others ideas what can be cached?
Regards,
Kočičák
[1] https://issues.apache.org/jira/browse/MYFACES-3160
Re: [core] discussion about stateless jsf implementation
Leonardo Uribe píše v Po 20. 02. 2012 v 19:04 -0500: Hi Hi, I did check only the original source code from blog some time ago and it I have found practically same problems as you. I have been studying the proposed code attached to MYFACES-3465. Unfortunately, I have found some issues with the related code that needs to be discussed under dev list. The code has the following drawbacks: - It uses request uri to mark the views instead viewId. This causes when multiple POST are chained with stateless views, a ViewExpiredException is thrown. It is known there's a difference about how myfaces and mojarra deals with viewId, which were clarified in JSF 2.1, with the introduction of ViewHandler.deriveLogicalViewId(). So instead use request uri as the marker, a combination of viewId/deriveLogicalViewId() should be used. yes, and user can also expect something what JSF already have, like j.f.FULL_STATE_SAVING_VIEW_IDS id web.xml - other context parameter. - Instead use vdl.buildView() call, it replaces it with com.rits.cloning.Cloner, to duplicate the view and use it on the current request. I think in this case, vdl.buildView() will be faster and more optimal from memory perspective, because we can cache information at Facelet/TagHandler/TagAttribute level like ValueExpressions, attribute values and others, and a deep clone will create unnecessary objects each time. Comparing MyFaces and Mojarra, our implementation of vdl.buildView() is very fast, and for cases when the view is has no dynamic parts it is only built once, so from MyFaces perspective the is not visible difference here (but from Mojarra you can see a difference). This means we don't really need the cache proposed at all. Sometimes less is more. cleary this is resposibility of vdl.buildView - cloning is slower and is not smart enough to do some optimalizations. - Some synchronized blocks can slow down performance without need (by thread contention), and I have found other bugs when the code deals with high concurrency. There were static synchronized methods and the pool was static map or something like that. those constructs were not nice for sure and also far from ideal in multi classloader scenario/shared myfaces/osgi. Pool are generally good idea for heavyweight object like Db connection, but pool itself causes thread waiting when number of threads is greater as max size of pool. I did profiling of commons-pool, c3p0, atomikos JTA pool and some others and the result aren't nice ... not suitable for myfaces - just for information. Anyway, the trick is good enough, in cases where you don't want to deal with view state load, even if with the changes done over the time in that part until 2.1.6 have made view state very small. It is an easy way to say to the state manager ... don't save the state for this view Or StateHandlingStrategy? I think stateManager in @deprecated in 2.2. After looking the code, I think we could add this as an built-in specific feature for MyFaces Core, rather than a subproject. Anyway, I have an idea that we can do for enhance performance in a significant way. You idea is simply great! I did some analysis of views two year ago and also some prototypes, but I leaved it , while 99% of ours view is stateful. I have found following groups of views: 1) singleton-per-webapp view, readOnly, non-actionable only one instance exists per web application and server all request. It is no possible to input values with EditableValueHolder and it is not possible fire event with ActionSources. This view is something like old JSP (but component oriented) and use cases are reports, overviews usw. There was possible to navigate to other views with plain link (outputLink). All state per view must be available within ValueExpression 2) Singleton-per-webapp, readOnly, actionable similar as 1), but it is possible to fire event with ActionSource. This was done with custom ViewRoot where all events go and threadLocal event store. Use cases were main menus, dashboards ... in such views are no EditableValueHolders and user only clicks on a menu item. 3) Singleton-per-webapp, editable, actionable same as 2, but EditableValueHolders were capable to update model but without conversion and validation - only String values in model were permitted (no localValue in EVH). these three are similar to stateless JSF and thread safe components together, but I did analysis of ours view and that would be an overkill to do it for 10 views from two thousands ;) stateless JSf tries to preserve editableHolders functionality but clear localValues in separate thread ... 4) stateful normal views - view with at least one component with own state, like component.setRendered(false) or setValid(false)- every post request with viewState must obtain own component tree with own state. In theory, we can classify JSF views into two groups - static view: views that as an invariant always has the same
Re: [core] performance: cache infos for views without build time modifications
Really I prefer do the previous improvement and make vdl.buildView
faster and cheaper, than do a component tree thread safe, because the
later one has a lot more code and it is something really outside the
spec. I think that
create a component tree is cheap, and in practice we should try to reduce
innecessary allocations of strings (like unique ids and others), and
try to make the component tree itself lighter. At the end, it will be more
effective to improve performance, and the side effects will be more limited.
of course, 10 minor optimalizations = 1 major opt. and we can always find
others 10 minor ;) (in every code)
Leonardo Uribe píše v Út 21. 02. 2012 v 11:32 -0500:
Hi
2012/2/21 Martin Koci martin.kocicak.k...@gmail.com:
Leonardo Uribe píše v Po 20. 02. 2012 v 17:51 -0500:
Hi
Unfortunately we can't cache facelets generated unique ids into
ComponentTagHandlerDelegate because a tag handler can be used in many
views because a view is the result of execute many facelet
compositions.
In facelets there are two hierarchical counters, one for
MARK_CREATED (FaceletContext.generateUniqueId) and the other for
component unique ids
(FaceletCompositionContext.generateUniqueComponentId). In theory if
the view is static, which means it generates the same component tree
each time, the list of generated ids will be the same. What we can do
is create a per-view cache, holding an ordered list with the generated
ids. In theory, when a dynamic part of a tree is about to begin, a new
level is started calling
FaceletCompositionContext.startComponentUniqueIdSection(), which
increase the level calling
SectionUniqueIdCounter.startUniqueIdSection() for both counters. So we
could add some logic into SectionUniqueIdCounter to store the values
of the counter on the base level and reuse it per view. It is not
going to be an easy trick but it seems reasonable, because it will
save a bunch of memory.
Ahh, I see. The idea with an ordered list is very good, it is better
store for ids.
Semi-related question: Can you please take a look at MYFACES-3470,
please? It can save the generateUniqueId now, but I'm not sure.
The suggestion is feasible, but it only will work when
org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS
is set on auto mode. In this mode, the view is checked for dynamic
parts and if has one, it activates a flag for do refresh if the view does
not changes. It is also feasible to do not set those attributes if the
view is rendered for first time when PSS mode is active, because the
delta only contains the attributes that change, and on a later postback,
the attribute will be set if necessary. In practice, we are changing the
initial state, so I need to check if our algorithm could resist that.
Note what we are proposing here is something risky. In few words, we are
assuming facelets dynamic views will only be created using the known
methods (c:if, ui:include src=#{...}, ...). It is reasonable, because at
this
moment there is no evidence of somebody has some tag that changes the
view dinamically (adding or removing components) different to those ones.
Additionally, there are some cases like when the view has metadata
(f:metadata, f:viewParam, ... ) that makes the view to be refreshed again
in that part, so the algorithm should be enabled there.
About @ResourceDependency annotations: The current code in
RequestViewContext check if the annotation was processed on the same
view, which means if the resource has been already added. That code is
ok. Note there is another cache that checks if the class has
@ResourceDependency annotations, to prevent scan it, but what we don't
have is one cache to store the classes that does not have any
@ResourceDependency and prevent any scanning at all. Which is more
expensive? a get() over a ConcurrentHashMap or a call to
inspectedClass.getAnnotation()? Only if the first is cheaper, the
cache has sense.
This one was only a though what is cacheable in static views, current
implementation is not a performance problem.
Ok, so it is better let it as is.
Finally, I don't think we can do anything for clientId, because its
generation is more tied to UIComponentBase internals. If an UIData or
UIRepeat or any other iteration component is used, clientId changes
per row, and is reset using setId() call. I think we can pass the
clientId through component attribute map, using some special attribute
name, but it doesn't sound good to me. After all, clientId calculation
is responsibility of UIComponent and it could be changed on the
related Renderer.
Yes, iteration components are problem. Generally many invocations of
getCliendId() come from
DefaultFaceletsStateManagementStrategy.restoreStateFromMap and thus is
this memory allocation coming from getClientId related to state saving.
But you have proposed solutions to state(ful, less) problem
Re: [core] performance: cache infos for views without build time modifications
Same situation for clientId: in stable component tree is clientId
always the same (state saving depends on it)
unfortunately has UIComponent no method setClientId. But we can try set
it via reflexion and compare if it brings an improvement or not.
Currently getClientId() uses lazy init and involves:
findParentNamingContainer
namingContainer.getContainerClientId
stringBuilder appends
renderer.convertClientId
Martin Koci píše v Pá 17. 02. 2012 v 18:56 +0100:
Hi,
in situation, where no build-time tags (c:if, co:foreach, ...) and no
ui:include src=#{} are used (and no direct component.getChildren()
manipulation of course), builds VDL.buildView every time the same
component structure (same graph).
In this case compute myfaces some informations again and again but every
time with same results. For example, creating of unique ids is very
expensive:
FaceletContext.generateUniqueId
FaceletCompositionContext.generateUniqueComponentId
UniqueIdVendor.createUniqueId
in ComponentTagHandlerDelegate.apply(FaceletContext, UIComponent)
Can we cache this ids at ComponentTagHandlerDelegate in production in
case of view without build time modifications ? This is similar to [1].
Same situation with @ResourceDependency annotations: ApplicationImpl.
_handleAttachedResourceDependencyAnnotations computes the same result
with every request/response.
Others ideas what can be cached?
Regards,
Kočičák
[1] https://issues.apache.org/jira/browse/MYFACES-3160
[core] performance: cache infos for views without build time modifications
Hi,
in situation, where no build-time tags (c:if, co:foreach, ...) and no
ui:include src=#{} are used (and no direct component.getChildren()
manipulation of course), builds VDL.buildView every time the same
component structure (same graph).
In this case compute myfaces some informations again and again but every
time with same results. For example, creating of unique ids is very
expensive:
FaceletContext.generateUniqueId
FaceletCompositionContext.generateUniqueComponentId
UniqueIdVendor.createUniqueId
in ComponentTagHandlerDelegate.apply(FaceletContext, UIComponent)
Can we cache this ids at ComponentTagHandlerDelegate in production in
case of view without build time modifications ? This is similar to [1].
Same situation with @ResourceDependency annotations: ApplicationImpl.
_handleAttachedResourceDependencyAnnotations computes the same result
with every request/response.
Others ideas what can be cached?
Regards,
Kočičák
[1] https://issues.apache.org/jira/browse/MYFACES-3160
Re: [VOTE] Release of Extensions CDI (CODI) 1.0.4
+1 Gerhard Petracek píše v Po 13. 02. 2012 v 17:59 +0100: Hi, I was running the needed tasks to get the 11th release of Apache MyFaces Extensions CDI (aka MyFaces CODI) out. The artifacts are deployed to Nexus [1] (and [2]). The release contains the following modules: - CODI Core - CODI JSF Module (for 1.2 and 2.0 and 2.1) - CODI JPA Module - CODI BV Module - CODI I18N-Message Module - CODI Scripting Module - CODI Trinidad Support Module (for 1.x and 2.x) - CODI Java-EE5 Support Module (for OpenWebBeans and Weld) - CODI Alternative Config and Impl Modules - CODI Bundles - CODI OSGi Bundles - CODI Base Test-Infrastructure Module - CODI JUnit-Support Module - CODI Cargo-Support Module - CODI OpenWebBeans Test-Support Module - CODI JSF Test-Support Module - CODI JSF Example Please take a look at the 1.0.4 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Gerhard [1] https://repository.apache.org/content/repositories/orgapachemyfaces-224/ [2] https://repository.apache.org/content/repositories/orgapachemyfaces-224/org/apache/myfaces/extensions/cdi/myfaces-extcdi-parent/1.0.4/myfaces-extcdi-parent-1.0.4-source-release.zip [3] http://www.apache.org/foundation/voting.html#ReleaseVotes
Re: [VOTE] release for myfaces master pom v 13
+1 Leonardo Uribe píše v St 18. 01. 2012 v 09:18 -0500: Hi, I was running the needed tasks to get the version 13 release of Apache MyFaces Master POM. This release is necessary to update the site information about MyFaces contributors. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.myfaces v 13 [1] The artifacts are deployed to a nexus staging repository [1]. Please take a look at the version 13 pom and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-087/ https://repository.apache.org/content/groups/staging/org/apache/myfaces/myfaces/13/
Re: [VOTE] Release of Extensions CDI (CODI) 1.0.3
+1 Gerhard Petracek píše v Ne 08. 01. 2012 v 21:21 +0100: Hi, I was running the needed tasks to get the 10th release of Apache MyFaces Extensions CDI (aka MyFaces CODI) out. The artifacts are deployed to Nexus [1] (and [2]). The release contains the following modules: - CODI Core - CODI JSF Module (for 1.2 and 2.0 and 2.1) - CODI JPA Module - CODI BV Module - CODI I18N-Message Module - CODI Scripting Module - CODI Trinidad Support Module (for 1.x and 2.x) - CODI Java-EE5 Support Module (for OpenWebBeans and Weld) - CODI Alternative Config and Impl Modules - CODI Bundles - CODI OSGi Bundles - CODI Base Test-Infrastructure Module - CODI JUnit-Support Module - CODI Cargo-Support Module - CODI OpenWebBeans Test-Support Module - CODI JSF Test-Support Module - CODI JSF Example Please take a look at the 1.0.3 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Gerhard [1] https://repository.apache.org/content/repositories/orgapachemyfaces-034/ [2] https://repository.apache.org/content/repositories/orgapachemyfaces-034/org/apache/myfaces/extensions/cdi/myfaces-extcdi-parent/1.0.3/myfaces-extcdi-parent-1.0.3-source-release.zip [3] http://www.apache.org/foundation/voting.html#ReleaseVotes
Re: [VOTE] release of myfaces core 2.1.2
+1 Leonardo Uribe píše v Po 22. 08. 2011 v 23:28 -0500: Hi, I was running the needed tasks to get the 2.1.2 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.1.1 [1] 2. Maven artifact group org.apache.myfaces.core v2.1.2 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.1.2 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-057/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces212binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316512
Re: [core] performance: custom implicit objects
Hi,
I also agree (with Gerhard) that in first place it is better to some
improvements in myfaces core (without unnecessary burden for clients).
But it is not easy (or even possible?) to intercept EL expression
evaluation, because the only API we can use in myfaces is ELResolver and
method getValue. Evaluation of EL Expression itself is internal part of
EL impl and I don't see any elegant way how to detect that evaluated
base or property in ELResolver.getValue() is root bean or not. Any
ideas?
More about custom imlicit objects:
I still think that the idea is good and myfaces or JSF generally should
support it. Use cases:
1) Custom implicit object for render kits and JSF libraries like skin.
For example, richfaces have own ELResolver and they use a managed bean
in it [1].
2) project-specific implicit object. Many projects has something like
projectConfiguration with properties like version:
#{projectConfiguration.version}. Currently the projectConfiguration must
be managed-bean or IoC container (CDI, Spring) managed and named bean.
With possibility of custom implicit object, project can define own names
and optimize EL resolving for object where managed bean is an performace
overhead (configuration in this example can be a instance of Properties
and completely unmanaged). Imlicit object is de facto a well-known
build-in named bean.
3) Jakob mentioned JSF managed-beans. In this case two managed beans can
have same name and different scope. User can specify
#{sessionScope.sameName} and #{requestScope.sameName} to differentiate
them. It this possible for CDI beans too?
Everything has advantages and disadvatages and I think (custom) implicit
objects is underestimated area in JSF that has it's purpose in specific
use cases.
Regards,
Kočičák
[1] https://issues.jboss.org/browse/RF-10755
Jakob Korherr píše v Út 09. 08. 2011 v 19:35 +0200:
Hi,
That's a good idea, however we need to be very careful with such
improvements. There are some cases in which you need different EL
resolvers for the same object. For example, JSF managed beans are
created by the ManagedBean EL resolver (very late in the chain), but
if they already exist, they are resolved by the respective scope EL
resolver (e.g. session EL resolver for @SessionScoped managed beans).
Please keep that in mind!
Regards,
Jakob
2011/8/8 Gerhard Petracek gerhard.petra...@gmail.com:
hi martin,
a smarter approach might be useful. e.g. after the first lookup of a
root-bean myfaces-core could store the el-resolver which found the bean in a
mapping.
before the resolver chain gets invoked, myfaces-core could do a lookup in
the stored mapping and use the mapped el-resolver (if there is one). if the
el-resolver can't resolve the bean any more (or there is no mapped
el-resolver), the whole chain would be invoked as usual.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/8/8 Martin Koci martin.kocicak.k...@gmail.com
Gerhard Petracek píše v Po 08. 08. 2011 v 16:36 +0200:
hi martin,
i think most users will be fine with the
OpenWebBeansELResolverComparator [1]
yes, this comparator moves OWB resolver to the last posititon. Thas good
because most of the EL expression nodes are generally not cdi beans
names. Custom implicit object was only proposition how to specify that
following node in expression is CDI bean.
and a custom InterceptorHandler (btw. an add-on like the scope-boost
for codi).
I'll take a look at it.
(esp. because an implicit variable would also break e.g. ide support.)
yes, that is a disadvantage. But generally IDEs must support something
like that, because custom scopes are possible in JSF 2.0
however, if you have concrete numbers, we could start a vote about it.
with 100 000 and more invocation of CompositeELResolver.getValue during
one render response is improvement noticeable, especially if every EL
expression is #{someCDIBean.someProperty}
But I incorrectly mixed together two problems:
1) posibility of custom implicit objects for myfaces core, independent
from usage.
2) example of usage : CDI/CODI integration.
regards,
gerhard
[1] https://cwiki.apache.org/confluence/display/MYFACES/ELResolver
+ordering
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/8/8 Martin Koci martin.kocicak.k...@gmail.com
Hi,
the OWB el-resolver itself is fast enough, thats not the
problem. The
problem is when you use CDI managed bean in big ELResolver
chain. For
example, consider this chain:
ImplicitObjectResolver
MapELResolver
ResourceResolver
[core] performance: custom implicit objects
Hi,
if user uses plain old JSF style with managed beans like:
#{sessionScope.mySessionScopedBean} or
#{requestScope.myRequestScopedBean} or
#{requestScope.varFromDataTable.property}
it can achieve excellent performance during render response phase,
because every EL resolution takes only two steps:
1) o.a.m.ImplicitObjectResolver resolves sessionScope or requestScope to
java.util.Map
2) javax.el.MapELResolver reads map.get(mySessionScopedBean) and sets
elContext.setPropertyResolved
(at first access ManagedBeanResolver must create bean instance but we
can ignore it for simplicity).
Specially if user uses EL resolvers ordering [1] and creates chain of
(ImlicitObjectResolver,MapELResolver, other resolvers) then resolving
takes only two first resolvers.
Now compare it with situation where CDI is used. Because CDI/OWB
resolver is not so fast as default el resolvers, common usage is put it
at bottom of resolvers chain with OpenWebBeansELResolverComparator. Then
resolving must go thru all ELresolvers in chain (12 or more resolvers)
to find a @Named bean.
How to improve this? One thing can be use custom implicit object for
this
1) create ImplicitObjectsProvider SPI interface in myfaces
2) CDI and CDI extension will add own implementation of myfaces
ImlicitObject, for example #{codiWindowScope} from CODI
3) the resolved value from implicit object can mimic the map interfaces
(for example WindowScopeMap) to preserve behaviour of servlet scopes and
to use MapELResolver
WDYT? Any other ideas?
Regards,
Kočičák
[1] https://cwiki.apache.org/MYFACES/elresolver-ordering.html
Re: [core] performance: custom implicit objects
Hi,
the OWB el-resolver itself is fast enough, thats not the problem. The
problem is when you use CDI managed bean in big ELResolver chain. For
example, consider this chain:
ImplicitObjectResolver
MapELResolver
ResourceResolver
CompositeComponentELResolver
VariableResolverToELResolver
PropertyResolverToELResolver
FlashELResolver
ManagedBeanResolver
ResourceBundleELResolver
ResourceBundleResolver
ListELResolver
ArrayListResolver
org.apache.webbeans.el.WebBeansELResolver
SkinPropertiesELResolver
ResourceParametrELResolver
javax.el.BeanELResolver
then when resolving #{cdiScopeBean} EL impl must call first 12 resolvers
and none of them sets elContext.setPropertyResolved(true)
Old JSF style can shorten it with #{sessionScope.sessionScopedBean} for
example and then resolving takes only first two resolvers because
MapELResolver sets propertyResolved(true)
so I'm looking for a solution how to minimize void usage of
ELresolvers and how to say directly that this is CDI bean and use CDI
ELResolver for it
Gerhard Petracek píše v Po 08. 08. 2011 v 15:50 +0200:
hi martin,
the real overhead (after our recent improvements) is the overhead of
the proxy itself.
in owb we have a cache in the el-resolver as well as in
some implementations of InterceptorHandler. the upcoming version of
owb will allow to use such special caches also for custom scopes.
e.g. there is a scope-boost add-on [1] for codi. so you get contextual
instances which are cached in a thread-local and the add-on also has
to do the reset of the cache (as soon as it is needed - that depends
on the concrete scope).
since we already have two caches in place and the real overhead is in
the proxy implementation, i'm not sure if we really get more
performance with such a spi.
(mark also implemented a cache for methods which aren't intercepted. i
already tested it and depending on the constellation the increase in
performance is about 5%.)
regards,
gerhard
[1] http://os890.blogspot.com/2011/08/benchmark-boost-myfaces-codi-scopes.html
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/8/8 Martin Koci martin.kocicak.k...@gmail.com
Hi,
if user uses plain old JSF style with managed beans like:
#{sessionScope.mySessionScopedBean} or
#{requestScope.myRequestScopedBean} or
#{requestScope.varFromDataTable.property}
it can achieve excellent performance during render response
phase,
because every EL resolution takes only two steps:
1) o.a.m.ImplicitObjectResolver resolves sessionScope or
requestScope to
java.util.Map
2) javax.el.MapELResolver reads map.get(mySessionScopedBean)
and sets
elContext.setPropertyResolved
(at first access ManagedBeanResolver must create bean instance
but we
can ignore it for simplicity).
Specially if user uses EL resolvers ordering [1] and creates
chain of
(ImlicitObjectResolver,MapELResolver, other resolvers) then
resolving
takes only two first resolvers.
Now compare it with situation where CDI is used. Because
CDI/OWB
resolver is not so fast as default el resolvers, common usage
is put it
at bottom of resolvers chain with
OpenWebBeansELResolverComparator. Then
resolving must go thru all ELresolvers in chain (12 or more
resolvers)
to find a @Named bean.
How to improve this? One thing can be use custom implicit
object for
this
1) create ImplicitObjectsProvider SPI interface in myfaces
2) CDI and CDI extension will add own implementation of
myfaces
ImlicitObject, for example #{codiWindowScope} from CODI
3) the resolved value from implicit object can mimic the map
interfaces
(for example WindowScopeMap) to preserve behaviour of servlet
scopes and
to use MapELResolver
WDYT? Any other ideas?
Regards,
Kočičák
[1] https://cwiki.apache.org/MYFACES/elresolver-ordering.html
Re: [core] performance: custom implicit objects
Gerhard Petracek píše v Po 08. 08. 2011 v 16:36 +0200:
hi martin,
i think most users will be fine with the
OpenWebBeansELResolverComparator [1]
yes, this comparator moves OWB resolver to the last posititon. Thas good
because most of the EL expression nodes are generally not cdi beans
names. Custom implicit object was only proposition how to specify that
following node in expression is CDI bean.
and a custom InterceptorHandler (btw. an add-on like the scope-boost
for codi).
I'll take a look at it.
(esp. because an implicit variable would also break e.g. ide support.)
yes, that is a disadvantage. But generally IDEs must support something
like that, because custom scopes are possible in JSF 2.0
however, if you have concrete numbers, we could start a vote about it.
with 100 000 and more invocation of CompositeELResolver.getValue during
one render response is improvement noticeable, especially if every EL
expression is #{someCDIBean.someProperty}
But I incorrectly mixed together two problems:
1) posibility of custom implicit objects for myfaces core, independent
from usage.
2) example of usage : CDI/CODI integration.
regards,
gerhard
[1] https://cwiki.apache.org/confluence/display/MYFACES/ELResolver
+ordering
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/8/8 Martin Koci martin.kocicak.k...@gmail.com
Hi,
the OWB el-resolver itself is fast enough, thats not the
problem. The
problem is when you use CDI managed bean in big ELResolver
chain. For
example, consider this chain:
ImplicitObjectResolver
MapELResolver
ResourceResolver
CompositeComponentELResolver
VariableResolverToELResolver
PropertyResolverToELResolver
FlashELResolver
ManagedBeanResolver
ResourceBundleELResolver
ResourceBundleResolver
ListELResolver
ArrayListResolver
org.apache.webbeans.el.WebBeansELResolver
SkinPropertiesELResolver
ResourceParametrELResolver
javax.el.BeanELResolver
then when resolving #{cdiScopeBean} EL impl must call first 12
resolvers
and none of them sets elContext.setPropertyResolved(true)
Old JSF style can shorten it with
#{sessionScope.sessionScopedBean} for
example and then resolving takes only first two resolvers
because
MapELResolver sets propertyResolved(true)
so I'm looking for a solution how to minimize void usage of
ELresolvers and how to say directly that this is CDI bean and
use CDI
ELResolver for it
Gerhard Petracek píše v Po 08. 08. 2011 v 15:50 +0200:
hi martin,
the real overhead (after our recent improvements) is the
overhead of
the proxy itself.
in owb we have a cache in the el-resolver as well as in
some implementations of InterceptorHandler. the upcoming
version of
owb will allow to use such special caches also for custom
scopes.
e.g. there is a scope-boost add-on [1] for codi. so you get
contextual
instances which are cached in a thread-local and the add-on
also has
to do the reset of the cache (as soon as it is needed - that
depends
on the concrete scope).
since we already have two caches in place and the real
overhead is in
the proxy implementation, i'm not sure if we really get more
performance with such a spi.
(mark also implemented a cache for methods which aren't
intercepted. i
already tested it and depending on the constellation the
increase in
performance is about 5%.)
regards,
gerhard
[1]
http://os890.blogspot.com/2011/08/benchmark-boost-myfaces-codi-scopes.html
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2011/8/8 Martin Koci martin.kocicak.k...@gmail.com
Hi,
if user uses plain old JSF style with managed beans
like:
#{sessionScope.mySessionScopedBean} or
#{requestScope.myRequestScopedBean} or
#{requestScope.varFromDataTable.property}
it can achieve excellent performance during render
[core] performance: synchronized access for java.beans.PropertyDescriptor.getReadMethod()
Hi, I'm testing a view where hundreds of concurrent users are expected. I noticed that java.beans.PropertyDescriptor.getReadMethod() is sychronized method and many times are other threads blocked with same lock (java.beans.PropertyDescriptor instance). Myfaces use it in _ComponentAttributesMap: BLOCKED java.beans.PropertyDescriptor.getReadMethod - javax.faces.component._ComponentAttributesMap.getComponentProperty(PropertyDescriptor)- javax.faces.component._ComponentAttributesMap.get(Object) All threads share the same java.beans.PropertyDescriptor instance. Very similar problem was reported by a user [1]. For this case, it seems that weblogic thinks that thread is [STUCK] beacuse it was simply blocked for too long. Any ideas hot to improve it? Are Method instances cacheable? For example, Spring [2] cache them under certain circumstances. I don't know this low level of reflection well ... Regards, Kočičák [1] http://www.mail-archive.com/users@myfaces.apache.org/msg57504.html [2] http://javasourcecode.org/html/open-source/spring/spring-3.0.5/org/springframework/beans/CachedIntrospectionResults.java.html
Re: [core] dynamic script before /body (an equivalent for DialogRequest from Trinidad)
I'll try solution with a mock component before /body. Component fetchs all script requests from facesContext.attributes and renders them. Also that component is autoRender=true so it is re-rendered in every partial response. Jakob Korherr píše v St 03. 08. 2011 v 11:10 +0200: Hi, Maybe you can override BodyRenderer to implement this. For normal request: sure. For AJAX requests: whole body re-rendering would be necessary, thus not really usable. Regards, Jakob 2011/8/3 Çağatay Çivici cagatay.civ...@gmail.com: Maybe you can override BodyRenderer to implement this. On Aug 3, 2011, at 11:39 AM, Jakob Korherr wrote: Hi, Nope, I don't think so. Maybe you can achieve it via a javascript event-handler on the client, but I actually don't know for sure. Maybe Werner can help you out! Regards, Jakob 2011/8/2 Martin Koci martin.kocicak.k...@gmail.com: Hi, has JSF an official API to achieve similar functionality as [1] ? Purpose and use case: 1) JSF process partially view 2) JSF artifact creates and queues a request render this script ... before /body 3) new element script is created and rendered before /body this is not same same @Resource(target=body). Also this must work with partial response wihout explicit render=@all Any ideas? Thanks, Kočičák [1] https://svn.apache.org/repos/asf/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/DialogRequest.java -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at Çağatay Çivici Principal Consultant PrimeFaces Lead | JSF EG Member Prime Teknoloji Bilkent Cyberpark, A-303d 06800 Ankara/Turkey Tel: +90 312 265 05 07 http://www.prime.com.tr
[core] dynamic script before /body (an equivalent for DialogRequest from Trinidad)
Hi, has JSF an official API to achieve similar functionality as [1] ? Purpose and use case: 1) JSF process partially view 2) JSF artifact creates and queues a request render this script ... before /body 3) new element script is created and rendered before /body this is not same same @Resource(target=body). Also this must work with partial response wihout explicit render=@all Any ideas? Thanks, Kočičák [1] https://svn.apache.org/repos/asf/myfaces/trinidad/trunk/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/DialogRequest.java
[core] lock profiling results for current myfaces
Hi, I'm doing some profiling for a view, where thousand of concurrent users is planned. Configuration myfaces trunk, juel, tomcat 6.0.26, OWB trunk Here are the top blocking locks: 1) java.util.Collections$SynchronizedMap.get(Object) de.odysseus.el.tree.impl.Cache.get(String) 2)java.beans.PropertyDescriptor.getReadMethod() javax.el.BeanELResolver$BeanProperty.getReadMethod() 3)org.apache.catalina.core.ContainerBase.fireContainerEvent(String, Object) org.apache.myfaces.util.AbstractThreadSafeAttributeMap.put(String, Object)... ... ServerSideStateCacheImpl.saveSerializedViewInServletSession 4)javax.faces.FactoryFinder._getFactory(String) javax.faces.FactoryFinder.getFactory(String) org.apache.myfaces.context.servlet.FacesContextImplBase.getRenderKit() ad 1 and 2) - those come from JUEL. The first one I try to avoid with [1] and second one with [2] as Mark Struberg suggested. ( why JUEL uses SynchronizedMap, not ConcurrentHashMap ?) 3) and 4) are from myfaces - any ideas if they can be avoided? Regards, Kočičák [1] https://issues.apache.org/jira/browse/MYFACES-3160 [2] https://github.com/struberg/juel/commit/da3791b91c3e23c973ee865050846b980399ecff
Re: MyFaces PMC += Martin Kočičák
Hi, thanks Gerhard, but I'm not now sure if this += change is valid because my full (and real) name not Martin Kočičák :) :) but only Martin Kočí (haha). It is explained here: http://www.mail-archive.com/dev@myfaces.apache.org/msg48802.html Kočičák is only nickname, because Martin Kočí is very frequent name in Czech Republic (I know at least four others) Regards, Martin Kočičák Kočí Gerhard Petracek píše v Po 25. 07. 2011 v 19:52 +0200: Dear MyFaces community, please welcome our new MyFaces PMC member Martin Kočičák . Martin is working on several things at Apache MyFaces and became a valuable member of our community. Therefore last week there was a vote to invite him to the MyFaces Project Management Committee (PMC) and fortunately he did accept. @Martin: Please update your status on the site: http://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml Thanks, Gerhard
Re: [core] pushComponentToEL and #{component}
Hi, how can I help to ping EG? It seems that JSF-spec team has own working plan and no time for issues with no vote. About interoperability: I've double checked that mojarra breaks specified behaviour in encodeBegin: pushComponentToEL - isNotRendered - return but in processDecodes the must have specified behaviour: isNotRendered- return; else pushComponentToEL because example example from [1] works as expected = badly = component is rendered but never decoded. Patch for [2] is myfaces internal only. Can you please review it and apply? We can use the new method RenderUtils.isRendered later in renderers where child.isRendered() optimalization is used. Regards, Kočičák [1] http://www.mail-archive.com/dev@myfaces.apache.org/msg53300.html [2] https://issues.apache.org/jira/browse/MYFACES-3126 1. Leonardo Uribe píše v Po 25. 07. 2011 v 11:37 -0500: Hi The problem with these patches is the changes proposed change the default behavior, and we still don't have any response about that from the EG. See: http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1002 I'm afraid the changes could be significant and cause some kind of interoperability issues between MyFaces and Mojarra. In my opinion what patches propose is correct, but we should ping the EG to see what they think about it and if it is valid to apply these changes on 2.0.x / 2.1.x branches. regards, Leonardo Uribe 2011/7/24 Martin Koci martin.kocicak.k...@gmail.com: Hi, please review patches for: https://issues.apache.org/jira/browse/MYFACES-3157 https://issues.apache.org/jira/browse/MYFACES-3126 Thanks, Kočičák
Re: [core] pushComponentToEL and #{component}
In latest mojarra something changed, but problem is still reproducible
with this little trick:
h:form id=formId
a:myComponent id=myComponentId
h:inputText id=testId rendered=#{component.id eq
'testId'} value=#{bean.value}/
/a:myComponent
h:commandButton value=submit /
/h:form
and
in MyComponent.java:
@Override
public boolean getRendersChildren() {
return true;
}
@Override
public void encodeChildren(FacesContext context) throws IOException
{
...
if (getChildCount() 0) {
for (UIComponent child : getChildren()) {
child.encodeBegin(context);
child.encodeEnd(context);
}
}
...
}
- input never updates model (wrong)
when you replace
child.encodeBegin(context);
child.encodeEnd(context);
with
child.encodeAll(context);
- input is not rendered (wrong)
Leonardo Uribe píše v Po 25. 07. 2011 v 14:09 -0500:
Hi
2011/7/25 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
how can I help to ping EG? It seems that JSF-spec team has own working
plan and no time for issues with no vote.
About interoperability: I've double checked that mojarra breaks
specified behaviour in encodeBegin:
pushComponentToEL - isNotRendered - return
but in processDecodes the must have specified behaviour:
isNotRendered- return; else pushComponentToEL
Really? I didn't knew that. That changes things, because if they are
not doing what javadoc says, it is clear we shouldn't follow it too. I
have no objections to commit the patch. Anyway let me review it to
check everything is ok.
I'll send a message to the EG about this one.
because example example from [1] works as expected = badly = component
is rendered but never decoded.
Patch for [2] is myfaces internal only. Can you please review it and
apply? We can use the new method RenderUtils.isRendered later in
renderers where child.isRendered() optimalization is used.
Ok, I'll check it and commit it.
regards,
Leonardo Uribe
Regards,
Kočičák
[1] http://www.mail-archive.com/dev@myfaces.apache.org/msg53300.html
[2] https://issues.apache.org/jira/browse/MYFACES-3126
1. Leonardo Uribe píše v Po 25. 07. 2011 v 11:37 -0500:
Hi
The problem with these patches is the changes proposed change the
default behavior, and we still don't have any response about that from
the EG. See:
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1002
I'm afraid the changes could be significant and cause some kind of
interoperability issues between MyFaces and Mojarra. In my opinion
what patches propose is correct, but we should ping the EG to see what
they think about it and if it is valid to apply these changes on 2.0.x
/ 2.1.x branches.
regards,
Leonardo Uribe
2011/7/24 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
please review patches for:
https://issues.apache.org/jira/browse/MYFACES-3157
https://issues.apache.org/jira/browse/MYFACES-3126
Thanks,
Kočičák
[core] pushComponentToEL and #{component}
Hi, please review patches for: https://issues.apache.org/jira/browse/MYFACES-3157 https://issues.apache.org/jira/browse/MYFACES-3126 Thanks, Kočičák
[core] code in ConverterTagHandlerDelegate.applyAttachedObject
Hi,
I'm doing some logging improvements for f:converter tag and I noticed
folowing weird code - line 157:
Object lv = vh.getLocalValue();
FacesContext faces = faceletContext.getFacesContext();
if (lv instanceof String)
{
vh.setValue(c.getAsObject(faces, parent, (String) lv));
}
What is purpose of this code? Please notice that this is called as part
of VDL.buildView
Regards,
Kočičák
Re: [core] Improve error reporting and logging / General ErrorPage improvements (MYFACES-3213)
Summary of proposed changes for ErrorPage: In header: - viewId, - location of facelet in filesystem - PhaseId In body: - info about component (that triggered the problem) - EL expression being evaluated, it's location, name of attribute/value pair - caused by: output first line of StackTrace (no need to expand stack trace panel) More ideas: -- if exception comes from VDL.buildView (FaceletException), output info about it - it can happen in restore or render phase -- one click navigation to source: I'll try to find how to navigate from error page direct to source. This of course need support from IDE - I'll try it for eclipse. Now it is possible to navigate from java console: if IDE sees stack trace com.foo.bazz.Bean(Bean.java 140) it is possible to click it and IDE opens source file. But I want this feature for myfaces error page (running in embedded browser) and for facelets files too (line/column). Do you know if others IDEs (JDeveloper, NetBeans, IDEA) have such feature? Do you have others ideas how to improve error page? Regards, Kočičák Werner Punz píše v Pá 08. 07. 2011 v 15:08 +0200: Yes +1 from me as well this is awesome. Werner Am 08.07.11 14:56, schrieb Jakob Korherr: Hi, Very nice! +1 on committing that. Regards, Jakob 2011/7/8 Martin Kocimartin.kocicak.k...@gmail.com: Hi, please see attached screenshots at [1] and let me know what you think. What info do you find useful during development (and debugging) ? Thanks, Kočičák [1] https://issues.apache.org/jira/browse/MYFACES-3213
Re: [core] Purpose and usage of AbortProcessingException (MYFACES-3199)
Here is my opinion: the purpose of AbortProcessingException is similar as ValidatorException or ConverterException. These are thrown as a result of normal lifecycle processing. With AbortProcessingExpcetion it is (or should be) possible to achieve this: h:commandButton f:actionListener ... !-- may throw a exception - if it does it will be queued for exception handling; but broadcasting continues -- f:actionListener ... !-- This one throws AbortProcessingExpcetion -- f:actionListener ... !-- not executed if previous throws AbortProcessingExpcetion; but independent from the first one -- /h:commandButton That is a classic isolation of listeners in observer pattern. Where is the problem? Specification works with APE inconsistently. First it says that APE must be propagated to ExceptionHandler: All other Exception cases must not be swallowed, and must be allowed to flow up to the Lifecycle.execute (6.2 ExceptionHandler) but continues in 6.2.1 Default ExceptionHandler implementation: Upon encountering the first such Exception that is NOT an instance of javax.faces.event.AbortProcessingException. So - APE is queued but ignored in exception handler! Spec says that APE the Exception must be logged and not re-thrown. - but why propagate APE to exception handler if the only result is log? Secondly, Application.publishEvent - If the act of invoking the processListener method causes an AbortProcessingException to be thrown, processing of the listeners must be aborted, no further processing of the listeners for this event must take place, and the exception must be logged with Level.SEVERE - no words about exception handler. And third problem is described as MYFACES-3199. My proposition is to work with APE as follows (if TCK allows it): 1) AbortProcessingException is 'expected' exception and users can throw it from listener in same manner as they can throw ConverterExpcetion from converters and ValidatorException from validators 2) Isolate listeners and work with APE with algorithm suggested in MYFACES-3199 3) Unify working with APE in myfaces code: we can introduce new param rethrowEveryListenerExceptionAsAPE to preserve current behaviour. Martin Koci píše v Čt 07. 07. 2011 v 14:10 +0200: Hi, what is purpose of AbortProcessingException in JSF API? Please see https://issues.apache.org/jira/browse/MYFACES-3199 Currently specification and myfaces work with it unconsistently. Do you have example of usage in your JSF applications? Regards, Kočičák
[core] Improve error reporting and logging / General ErrorPage improvements (MYFACES-3213)
Hi, please see attached screenshots at [1] and let me know what you think. What info do you find useful during development (and debugging) ? Thanks, Kočičák [1] https://issues.apache.org/jira/browse/MYFACES-3213
[core] Purpose and usage of AbortProcessingException (MYFACES-3199)
Hi, what is purpose of AbortProcessingException in JSF API? Please see https://issues.apache.org/jira/browse/MYFACES-3199 Currently specification and myfaces work with it unconsistently. Do you have example of usage in your JSF applications? Regards, Kočičák
Re: [core] three issues with ViewExpiredException navigation
Leonardo Uribe píše v Út 28. 06. 2011 v 16:11 -0500:
Hi
2011/6/28 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
to make things not so easy:
https://issues.apache.org/jira/browse/MYFACES-3191
Maybe it is related, maybe not, but now it is not possible to perform
navigation in RENDER_RESPONSE.
Yes, it it not possible to do navigation in RENDER_RESPONSE, because
render response phase already happen, so there exists navigation but
there is no rendering. So, a redirect is the only way to trigger a
navigation in this case, but this means debug information must be
saved somewhere. All that is responsible of the ExceptionHandler used.
About infinite loop: similar problem (not hadled with spec) is in
broadcastEvents - listener can queue the same event again. Please see
code in javax.faces.component.UIViewRoot.broadcastEvents(FacesContext,
PhaseId). Situation in exception handler is similar: throwing a
exception again leads to queue new ExceptionQueuedEvent.
Maybe we should think about this problem (inifinite queuing) generally,
extract the code from UIViewRoot.broadcastEvents and solve it everywhere
in code base for all queue operations.
I don't see any problems with the algorithm proposed related to
infinite loops from a theorical point of view, because after all, if
the exception handler call UIViewRoot.broadcastEvents, it is
responsibility of the exception handler to deal with this gracefully.
From the point of view of the spec and the algorithm on section 12.3,
jsf implementation should not do anything.
Anyway, I have seen some problems in our current error handling
algorithm. Technically it comply with the spec, but note the spec
unfortunately is very poor in this part. There is some code dealing
with ajax exceptions, that is on ErrorPageWriter that should not be
there, because if myfaces error handling is disabled, this code is not
executed too, and ErrorPageWriter should be called from our
ExceptionHandler implementation in MyFaces, instead use a try {} catch
{} block, even if errors on ResourceHandler implementation could not
be handled (or maybe the ExceptionHandler should do its own stuff
here?). Additionally, our wiki page to handling errors must be
updated, but first we need to check in deep this feature.
Hi,
I did something for MYFACES-3053 - Improve error reporting and logging.
If you have some time, please take a look at subtasks of that issue -
some of them are related to current error handling algorithm.
Regards,
Kočičák
regards,
Leonardo Uribe
Regards,
Kočičák
Leonardo Uribe píše v Po 27. 06. 2011 v 18:02 -0500:
Hi
I investigated more about this problem and from a theorical point of
view we can't call handle() like proposed. Why? in JSF we have the
following phases by default:
RESTORE_VIEW
APPLY_REQUEST_VALUES
PROCESS_VALIDATIONS
UPDATE_MODEL_VALUES
INVOKE_APPLICATION
RENDER_RESPONSE
and we have these methods on FacesContext:
renderResponse();
getRenderResponse();
responseComplete();
getResponseComplete();
If a ViewExpiredException is thrown on RESTORE_VIEW, and a call to
handle() occur, everything that happens inside the ExceptionHandler is
its responsibility. If handleNavigation() is called inside the
handler, that handler should check for a view set or
getResponseComplete return true and deal with it. Now, if the handler
does not do anything, the following phases:
APPLY_REQUEST_VALUES
PROCESS_VALIDATIONS
UPDATE_MODEL_VALUES
INVOKE_APPLICATION
RENDER_RESPONSE
By definition, these phases should check always if there is a view and
if it is not, just throw ViewNotFoundException, aborting the current
phase. Note it is responsibility of the phase to do the check. In that
way the ExceptionHandler could have the chance to handle it.
I tried do something different, but it is not possible because is
inconsistent with the intention of ExceptionHandler. How can an
ExceptionHandler handle exceptions thrown by itself without the risk
of get stuck in a loop?
regards,
Leonardo Uribe
2011/6/27 Leonardo Uribe lu4...@gmail.com:
Hi
2011/6/27 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
Leonardo Uribe píše v Ne 26. 06. 2011 v 21:29 -0500:
Hi
I have checked all issues and this is what I think about:
- MYFACES-3189 and MYFACES-3188 : I don't see any difference between
both of them.
Yes, those are caused by same problem, but I reported it separately
because MYFACES-3188 suggest only improvement in robustness area,
MYFACES-3189 is about navigation algorithm.
Ok, now I get it. I believe one patch will fix MYFACES-3188 and
MYFACES-3189 should be closed as invalid, because we can really do
anything on the navigation algorithm.
The navigation algorithm is ok. I think with just log a
warning message before render response phase saying the view is null
is ok. I
Re: [core] three issues with ViewExpiredException navigation
Hi, to make things not so easy: https://issues.apache.org/jira/browse/MYFACES-3191 Maybe it is related, maybe not, but now it is not possible to perform navigation in RENDER_RESPONSE. About infinite loop: similar problem (not hadled with spec) is in broadcastEvents - listener can queue the same event again. Please see code in javax.faces.component.UIViewRoot.broadcastEvents(FacesContext, PhaseId). Situation in exception handler is similar: throwing a exception again leads to queue new ExceptionQueuedEvent. Maybe we should think about this problem (inifinite queuing) generally, extract the code from UIViewRoot.broadcastEvents and solve it everywhere in code base for all queue operations. Regards, Kočičák Leonardo Uribe píše v Po 27. 06. 2011 v 18:02 -0500: Hi I investigated more about this problem and from a theorical point of view we can't call handle() like proposed. Why? in JSF we have the following phases by default: RESTORE_VIEW APPLY_REQUEST_VALUES PROCESS_VALIDATIONS UPDATE_MODEL_VALUES INVOKE_APPLICATION RENDER_RESPONSE and we have these methods on FacesContext: renderResponse(); getRenderResponse(); responseComplete(); getResponseComplete(); If a ViewExpiredException is thrown on RESTORE_VIEW, and a call to handle() occur, everything that happens inside the ExceptionHandler is its responsibility. If handleNavigation() is called inside the handler, that handler should check for a view set or getResponseComplete return true and deal with it. Now, if the handler does not do anything, the following phases: APPLY_REQUEST_VALUES PROCESS_VALIDATIONS UPDATE_MODEL_VALUES INVOKE_APPLICATION RENDER_RESPONSE By definition, these phases should check always if there is a view and if it is not, just throw ViewNotFoundException, aborting the current phase. Note it is responsibility of the phase to do the check. In that way the ExceptionHandler could have the chance to handle it. I tried do something different, but it is not possible because is inconsistent with the intention of ExceptionHandler. How can an ExceptionHandler handle exceptions thrown by itself without the risk of get stuck in a loop? regards, Leonardo Uribe 2011/6/27 Leonardo Uribe lu4...@gmail.com: Hi 2011/6/27 Martin Koci martin.kocicak.k...@gmail.com: Hi, Leonardo Uribe píše v Ne 26. 06. 2011 v 21:29 -0500: Hi I have checked all issues and this is what I think about: - MYFACES-3189 and MYFACES-3188 : I don't see any difference between both of them. Yes, those are caused by same problem, but I reported it separately because MYFACES-3188 suggest only improvement in robustness area, MYFACES-3189 is about navigation algorithm. Ok, now I get it. I believe one patch will fix MYFACES-3188 and MYFACES-3189 should be closed as invalid, because we can really do anything on the navigation algorithm. The navigation algorithm is ok. I think with just log a warning message before render response phase saying the view is null is ok. I think it is reasonable to throw a custom myfaces exception here because is viewRoot is null on this point, there is no way render response phase could work. Maybe a ViewNotFoundException? I don't see any incompatibility with the spec, but at least we should notify the EG about this possible problem, because the exception class should be on javax.faces.application, and the algorithm should be clear about this. Exception: can be this exception also handled with custom exception handler? For example: two views (ViewExpired.xhtml and NiceErrorView.xhtml) packaged in a .jar. For some reason this archive will no be deployed. Then if ViewExpired occurs: -- exception handler navigates to ViewExpired.xhtml - ViewNotFoundException -- exception handler handles ViewNotFoundException and navigates to NiceErrorView.xhtml - new ViewNotFoundException is throw. Good idea!. The only thing here is we need some special logic to deal with this. The most difficult problem is we can't keep track of the view navigations that cause ViewNotFoundException on the same request, but we can set a limit of how many ViewNotFoundException can be handled before jump to the default error page writer. This looks each time more like something to be included on the spec. regards, Leonardo - MYFACES-3105 : Checked and fixed. Fortunately, there is no errors on the algorithm, but anyway we can expect more reports about ViewExpiredException in the future, because it is a common exception that occur in typical scenarios. regards, Leonardo Uribe 2011/6/26 Martin Koci martin.kocicak.k...@gmail.com: Hi, MYFACES-3189 and MYFACES-3188 are reproducible : please see comment at MYFACES-3189. The mojara example works ok, thats not the problem. The problem is when you makes a typo in name of view for handleNavigation method. MYFACES-3105 seems
Re: [core] three issues with ViewExpiredException navigation
Hi, Leonardo Uribe píše v Ne 26. 06. 2011 v 21:29 -0500: Hi I have checked all issues and this is what I think about: - MYFACES-3189 and MYFACES-3188 : I don't see any difference between both of them. Yes, those are caused by same problem, but I reported it separately because MYFACES-3188 suggest only improvement in robustness area, MYFACES-3189 is about navigation algorithm. The navigation algorithm is ok. I think with just log a warning message before render response phase saying the view is null is ok. I think it is reasonable to throw a custom myfaces exception here because is viewRoot is null on this point, there is no way render response phase could work. Maybe a ViewNotFoundException? I don't see any incompatibility with the spec, but at least we should notify the EG about this possible problem, because the exception class should be on javax.faces.application, and the algorithm should be clear about this. Exception: can be this exception also handled with custom exception handler? For example: two views (ViewExpired.xhtml and NiceErrorView.xhtml) packaged in a .jar. For some reason this archive will no be deployed. Then if ViewExpired occurs: -- exception handler navigates to ViewExpired.xhtml - ViewNotFoundException -- exception handler handles ViewNotFoundException and navigates to NiceErrorView.xhtml - new ViewNotFoundException is throw. - MYFACES-3105 : Checked and fixed. Fortunately, there is no errors on the algorithm, but anyway we can expect more reports about ViewExpiredException in the future, because it is a common exception that occur in typical scenarios. regards, Leonardo Uribe 2011/6/26 Martin Koci martin.kocicak.k...@gmail.com: Hi, MYFACES-3189 and MYFACES-3188 are reproducible : please see comment at MYFACES-3189. The mojara example works ok, thats not the problem. The problem is when you makes a typo in name of view for handleNavigation method. MYFACES-3105 seems fixed in current 2.1.2-SNAPSHOT Regards, Kočičák Leonardo Uribe píše v So 25. 06. 2011 v 11:49 -0500: Hi I have tried to reproduce them without success. I know the navigation code and everything seems to be correct. Do you have a test case for this one? I tried the bundled sample from mojarra and it works. regards, Leonardo Uribe 2011/6/25 Martin Koci martin.kocicak.k...@gmail.com Hi, please take a look at: https://issues.apache.org/jira/browse/MYFACES-3189 https://issues.apache.org/jira/browse/MYFACES-3188 https://issues.apache.org/jira/browse/MYFACES-3105 I'm not very familiar with navigation implementation - I cannot provide meaningful patches here. Thanks, Kočičák
[core] h:form in h:form detection
Hi, common problem: in multilevel templating developer losts context easily and puts a new h:form into exiting one. T thought that was already solved in myfaces codebase with some warning but I cannot find in now. Can you point me to the right direction? Thanks, Kočičák
Re: [core] three issues with ViewExpiredException navigation
Hi, MYFACES-3189 and MYFACES-3188 are reproducible : please see comment at MYFACES-3189. The mojara example works ok, thats not the problem. The problem is when you makes a typo in name of view for handleNavigation method. MYFACES-3105 seems fixed in current 2.1.2-SNAPSHOT Regards, Kočičák Leonardo Uribe píše v So 25. 06. 2011 v 11:49 -0500: Hi I have tried to reproduce them without success. I know the navigation code and everything seems to be correct. Do you have a test case for this one? I tried the bundled sample from mojarra and it works. regards, Leonardo Uribe 2011/6/25 Martin Koci martin.kocicak.k...@gmail.com Hi, please take a look at: https://issues.apache.org/jira/browse/MYFACES-3189 https://issues.apache.org/jira/browse/MYFACES-3188 https://issues.apache.org/jira/browse/MYFACES-3105 I'm not very familiar with navigation implementation - I cannot provide meaningful patches here. Thanks, Kočičák
[core] three issues with ViewExpiredException navigation
Hi, please take a look at: https://issues.apache.org/jira/browse/MYFACES-3189 https://issues.apache.org/jira/browse/MYFACES-3188 https://issues.apache.org/jira/browse/MYFACES-3105 I'm not very familiar with navigation implementation - I cannot provide meaningful patches here. Thanks, Kočičák
Re: [core] Firefox 4 - script in XHR executed 2x?
Hi, ok, I'll investigate it more; I'll try isolate the problem in small reproducible example, if possible. Most likely is problem in my code. Thanks, Kočičák Werner Punz píše v Po 20. 06. 2011 v 22:33 +0200: Am 20.06.11 21:18, schrieb Martin Koci: Hi, I'm not very familiar with JavaScript, so I ask first if it is bug or not: Ifscript element is in XHR response, who is responsible for execute that script? I found [1] so I suppose that runScripts function does it in MyFaces. With Firefox 4 it seems thatscript is executed 2x: first time when DOM is replaced and second time from runScripts function. But I didn't debug it much ... problem can be anywhere else. I don't have this problem with Firefox 3.6. Thanks, Kočičák [1] http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-724 Ok this is strange because it actually should not happen due to two reasons. a) Firefox does not do any auto eval post 3.6 b) I have auto eval detection code which is browser independend by adding a small inline script post load which sets a global variable. This is actually one of my standard testcases and firefox 4 one of my testing targets so this should have been crawled up at my last testing cycle. I will investigate this issue this week nevertheless, which platform do you get the double eval and which exact Firefox version? Werner
[core] Firefox 4 - script in XHR executed 2x?
Hi, I'm not very familiar with JavaScript, so I ask first if it is bug or not: If script element is in XHR response, who is responsible for execute that script? I found [1] so I suppose that runScripts function does it in MyFaces. With Firefox 4 it seems that script is executed 2x: first time when DOM is replaced and second time from runScripts function. But I didn't debug it much ... problem can be anywhere else. I don't have this problem with Firefox 3.6. Thanks, Kočičák [1] http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-724
Re: [core] implicit object 'component' in rendered expression (myfaces and spec bug)
Hi,
can you review patch for this issue - MYFACES-3157 - please?
Regards,
Kočičák
Hi,
more info about this problem:
1) I did some testing of mojarra and they do the same in encodeBegin as
myfaces:
pushComponentToEL
. if (!isRendered())
despite of the specification.
2) Specification does not mention pushComponentToEL for encodeAll(),
only says If this component returns true from isRendered(), take the
following action ... Render this component and all its children
3) pushComponentToEL and double push:
component.pushComponentToEL(context, null);
component.pushComponentToEL(context, null);
Will be the same component pushed twice on stack?
Regards,
Kočičák
Martin Koci píše v St 25. 05. 2011 v 22:12 +0200:
Hi,
there are such cases but not many of them: in myfaces code after quick
search I guess about 10 such cases. The main is in
UIComponentBase.encodeChildren and in RendererUtils.renderChild (well,
there was, but I removed it incorrectly as part of MYFACES-3126)
This affects all attributes of component, not only rendered. If renderer
encodes children, then must set up context if reads something from
child. Consider:
a:tabbedPane
a:navigationItem style=#{component.something eq 'b'} /
if tabbedPaneRenderer iterates over children directly and reads 'style'
property, then it must guarantee that 'component' resolves to
navigationItem otherwise it is incosistent with situation, where
navigationItem encodes itself.
This will affects complex structures like dataTable and panelGrid, I
think.
Regards,
Kočičák
Blake Sullivan píše v St 25. 05. 2011 v 12:42 -0700:
I suspect that there are many cases where parent components are looking
at rendered on their children before deciding to traverse into these
children. If EL-binding rendered to the component is supported, then
the parent is either going to need to stop performing this optimization,
or it is going to have to ensure that the context is setup and torn down
around each call to isRendered.
-- Blake Sullivan
On 5/25/11 11:27 AM, Martin Koci wrote:
Hi,
for spec I've created bug few days ago:
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1002
but I didn't realize how deep impact this bug have: I did a training
about JSF implicit objects in our company and now practically every
coder uses #{component.something} :)
For myfaces:
https://issues.apache.org/jira/browse/MYFACES-3157
Leonardo Uribe píše v St 25. 05. 2011 v 12:36 -0500:
Hi
I have seen that. The problem is in spec javadoc, the behavior for
UIComponent.process*
and encode* is clear about the ordering.
In theory, pushComponentToEL should be called before any call to
isRendered, but after
isTransient. Look on MyFaces UIComponentBase.processRestoreState. It has
this
public void processRestoreState(FacesContext context, Object state)
{
if (context == null)
{
throw new NullPointerException(context);
}
Object[] stateValues = (Object[]) state;
try
{
// Call
UIComponent.pushComponentToEL(javax.faces.context.FacesContext,
javax.faces.component.UIComponent)
pushComponentToEL(context, this);
// Call the restoreState() method of this component.
restoreState(context, stateValues[0]);
The spec javadoc says the opposite, restoreState should be called
before
pushComponentToEL but in practice that breaks
UIComponent.EventListenerWrapper.
I reported the bug long time ago, but it wasn't fixed (I don't know why).
This case is similar. This should be fixed on the spec, but I don't
see a reason why we shouldn't commit that into myfaces code, because
after all, nobody relies on the buggy behavior.
I think we should open a new issue on the spec issue tracker:
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC
but fix it on myfaces code.
regards,
Leonardo Uribe
2011/5/25 Martin Kocimartin.kocicak.k...@gmail.com:
Hi,
h:form
h:panelGroup
h:inputText id=testId
rendered=#{component.id eq 'testId'}
value=#{bean.value} /
/h:panelGroup
/h:form
please notice the expression:
rendered=#{component.id eq 'testId'}
that is clearly true.
But that does not work as expected: inputText is rendered, but never
updates model value.
Problem 1.
from specification, methods UIComponent.process* and encode*
1) If the rendered property of this {@link UIComponent}
false, skip further processing
2) Call {@link #pushComponentToEL}
- #{component} resolves in rendered=#{} to parent!
Problem 2.
MyFaces implement that (pointless) requirement
[core] performance: preinitialize facelets and analyze views (during startup)
Hi, Can we find a way how to pre-initialize all .xhtml (Facelet instances) during startup? I think that can bring many improvements, for example: -- Minimize sychronized: populate all cached Value|MethodExpression on TagAttributeImpl (MYFACES-3160) - than we can remove volatile keyword populate cache in JUEL/EL: JUEL has own cache for expressions based on ConcurrentHashMap - we can use plain HashMap without lock -- Syntax-check (precompilation) - is syntactically ok? Currently the only way how to check all views in app is perform a request to each one. -- Statistics about views: usage of c: (build-time) tags in view analyze structure, for example for common mistakes (like f:viewParam in template) Then we can try VLD.buildView with InitFacesContext and provide some useful statistic data: provide hints for user (for example analyze structure of h:dataTable and if it contains no EditableValueHolder, provide readOnly hint ) WDYT? Regards, Kočičák
Re: [core] best way for editable table
Hi,
thanks all for answers.
After more thinking about it what I need is probably custom
rowStatePreserver.
JSF already mandates working with states for each row in UIdata. There
are two modes:
1) rowStatePreserved = false (old one): only editableValueHolder and its
submittedValue, localValue, value and submittedValue are preserved
2) rowStatePreserved = true: full state of component per-row is
preserved
What can make editable dataTable very easy is possibility to plug-in
custom behaviour to row state iteration. Internally myfaces use in
UIData MapclientId,States) for row states. If you want to switch
different row to different modes, you must also provide such map:
MapString id, State where State = {required=true,
displayValueOnly=false} etc.
Example of possible APIs:
a:dataTable rowStatePreserver=#{myStatePreserver}
MyRowStatePreserver extends javax.faces...DefaultRowStatePreserver
RowKeySet rowsInEditableMode;
States states;
public void setRowState(Object rowKey, UIComponent c) {
super.setRowState(rowKey, c)
if (rowsInEditableMode.contains(rowKey) {
State state = states.get(c.getId());
c.setRequired(state.isRequired)
c.setDisplayValueOnly(state.isDisplayValueOnly)
}
}
What do you think about it?
Regards,
Kočičák
Çağatay Çivici píše v St 08. 06. 2011 v 10:01 +0300:
I have implemented something similar in PrimeFaces via cellEditor
component which can take any editable component as a child;
http://www.primefaces.org/showcase-labs/ui/datatableEditing.jsf
On Jun 7, 2011, at 11:05 PM, Werner Punz wrote:
I opted for approach 1 in one project i have on github, speed is not
really an issue since you display only a handful of datasets anyway,
but I tried to keep the editable information outside of the
lifecycle
to avoid unnecessary saves and restores.
Werner
Am 07.06.11 21:29, schrieb Martin Koci:
Hi,
how to do editable table in JSF? Not with all rows/cell in
editable
state, only with those ones which user switch with icon to update
state.
Example:
a:column id=emailColumn
a:inputText id=email value=#{rowData.email} /
/a:column
a:column
h:commandButton value=Switch to update
actionListener=#{rowData.switchToUpdate} /
/a:column
Solution 1:
add ValueExpression to attribute determines state of component:
a:inputText id=email value=#{suser.email}
displayValueOnly=#{!
rowData.editableState}/
This solution has serious disadvantages:
-- you must add expression to each component
-- for required additional expression is needed:
required=#{rowData.required}
-- evaluation of VEs for each row is very slow
Solution 2:
use DataModelListener
Use o implementation of DataModelListener and when UIData scrolls
to
row, set property of component directly:
uiComponent.setDisplayValueOnly(true|false)
Disadvantages:
-- dependency on DataModel as value for UIData
-- cannot be done from plain XHTML
What do you think about this problem? Do you know any elegant
solution
for this?
Thanks,
Kočičák
Çağatay Çivici
Principal Consultant
PrimeFaces Lead | JSF EG Member
Prime Teknoloji
Bilkent Cyberpark, A-303d
06800 Ankara/Turkey
Tel: +90 312 265 05 07
http://www.prime.com.tr
Re: [VOTE] release for myfaces core 2.1.1
+1 Gerhard Petracek píše v St 08. 06. 2011 v 11:30 +0200: +1 regards, gerhard 2011/6/8, Werner Punz werner.p...@gmail.com: +1 Am 08.06.11 08:04, schrieb Leonardo Uribe: Hi, I was running the needed tasks to get the 2.1.1 release of Apache MyFaces core out. This is a quick bug-fix release for the following issues. * [MYFACES-3161] - UIData.restoreDescendantComponentStates fails when empty datatable is used and a new row is created * [MYFACES-3162] - AJAX Broken when State Caching Mechanics turned off * [MYFACES-3165] - UIData.broadcast does not push composite component on EL stack The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.core v2.1.1 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.1.1 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-055/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces211binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316463
Re: Problem with Trinidad's uploads
forward from us...@myfaces.apache.org: Hi, I tried you project and: 1) faces-config.xml is wrong, it needs faces-config as root element, not root 2) trinidad-config is wrong, it has filter element - this one belongs to web.xml and element uploaded-file-processor-settings with children does not exist: see http://myfaces.apache.org/trinidad/devguide/fileUpload.html Please notice that in console you can see a lots and warnings like: 8.6.2011 20:25:04 org.apache.myfaces.trinidadinternal.config.ConfigParser$Handler endElement WARNING: Element upload-max-memory is not understandable After correction of 1 and 2): 3) I created /tmp/TrinidadUpload and increased org.apache.myfaces.trinidad.UPLOAD_MAX_DISK_SPACE to 10 and it uploads 1GB file without problem. Regards, Kočičák jitechno píše v Čt 02. 06. 2011 v 03:14 -0700: Joachim, I put entire project (without jaftrinidad's jars) http://old.nabble.com/Re%3A-Problem-with-Trinidad%27s-uploads-p31748075.html on this thread. If you have time to look, thanks a lot. This is the same version, what I use to test. Oleg
Re: Upload of folder content
I think upload of folder is not possible with HTML4, so you must zip it. With HTML5 there will be some support for folder upload (I hope) and dragdrop upload. You can try also Cagatay's excellent primefaces - they have multiple Flash-based upload I think. Regards, Kočíčák jitechno píše v So 04. 06. 2011 v 07:46 -0700: Hello, can anybody point me to example, how upload all files inside selected folder, using Trinidad / Tomahawk? preferrable, for first one.. Thanks in advance Jitechno
[core] best way for editable table
Hi,
how to do editable table in JSF? Not with all rows/cell in editable
state, only with those ones which user switch with icon to update
state.
Example:
a:column id=emailColumn
a:inputText id=email value=#{rowData.email} /
/a:column
a:column
h:commandButton value=Switch to update
actionListener=#{rowData.switchToUpdate} /
/a:column
Solution 1:
add ValueExpression to attribute determines state of component:
a:inputText id=email value=#{suser.email} displayValueOnly=#{!
rowData.editableState}/
This solution has serious disadvantages:
-- you must add expression to each component
-- for required additional expression is needed:
required=#{rowData.required}
-- evaluation of VEs for each row is very slow
Solution 2:
use DataModelListener
Use o implementation of DataModelListener and when UIData scrolls to
row, set property of component directly:
uiComponent.setDisplayValueOnly(true|false)
Disadvantages:
-- dependency on DataModel as value for UIData
-- cannot be done from plain XHTML
What do you think about this problem? Do you know any elegant solution
for this?
Thanks,
Kočičák
Re: [core] best way for editable table
Hi, yes I use 1. for small tables, but consider table 200 x 200. Then you must have required, displayValueOnly, disabled etc for each component - that means 200x200x3 evaluated expression during *one* JSF phase. Regards, Kočičák Werner Punz píše v Út 07. 06. 2011 v 22:05 +0200: opted
Re: [core] performance: avoid wrapped EL Expressions
Hi,
Leonardo Uribe píše v Pá 03. 06. 2011 v 15:38 -0500:
Hi
2011/6/3 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
the idea seems very good - but when is decided that expression does not
uses some variable resolved by VariableResolver?
Inside VariableMapperWrapper.resolveVariable. If it returns a not null
value, a variable has been resolved.
TagAttributeImpl.getValue/MethodExpression methods are called in
VDL.buildView - how is the check done? String parsing? Yes, I didn't
look in the patch, its friday :)
No parsing is necessary.
I didn't realize that ExpressionFactory.createValueExpression calls
VariableMapper.resolveVariable. But it have to, because (from JavaDoc)
The object returned must access the same variable mappings regardless of
whether the mappings in the provided FunctionMapper and VariableMapper
instances change between calling
ExpressionFactory.createValueExpression() and any method on
ValueExpression
I tried that patch and it is very effective: it reduces response time
significantly, in one test case even about ~350ms. +1 for this solution.
Regards,
Kočičák
Another idea: during VLD.buildView handler calls
TagAttribute.getMethodExpression and populates UIComponent with it. But
with partial lifecycle you don't need them all: with execute=@this and
render=something others components are untouched during lifecycle. Can
we create and use some kind o LazyValueExpression which parses and
initializes expression at first access?
The problem here is the context. As soon as facelets has built the
view, VariableMapper info is lost, so on such LazyValueExpression you
need to store that information (how?). Other problem is
FunctionMapper, because it is setup per page so as soon as the page
is processed, that context is lost. I don't think it could work. I
think the strategy proposed here is better, because all Value/Method
expressions are on Facelets Abstract Syntax Tree (AST), so once
created it lives as long as that Facelet lives (see
javax.faces.FACELETS_REFRESH_PERIOD). So, ajax operations will not
recreate EL expressions if is not necessary.
regards,
Leonardo
Regards,
Kočičák
Leonardo Uribe píše v Čt 02. 06. 2011 v 21:10 -0500:
Hi
I have attached another patch to MYFACES-3160. This one has the
ability to detect if the expression uses some variable resolved by
facelets VariableMapper wrappers and if so, indicate the expression
cannot be cached.
This solution will work better, because it only creates Value/Method
expressions when it is necessary. This is a great optimization,
because in practice most expressions are bound to managed beans, so in
practice it will make pages render faster (because EL parsing is only
done once and a lot of objects will not be created) and the memory
usage will be lower (less instances means gc works less).
The only part this does not have any effect is when there is a
ValueExpression directly on the markup. In this case, I think since
org.apache.myfaces.view.facelets.compiler.UIInstructionHandler is
final (that means it is inmutable), put a volatile variable for cache
such cases will make it a mutable class, so it cannot take advantage
of some compiler optimizations. Maybe we can create two classes, one
to handle markup without EL and other with EL. Anyway, the most
critical point is expressions on attributes (changes on facelets
compiler has to be done very carefully).
JK I would really like to see some prototyping work for JSF 2.2 in this
JK area directly in a MyFaces core branch!
The patch proposed on MYFACES-3160 is for MyFaces 2.0 and 2.1. After
the latest patch I think we don't really need some work on a EL
implementation (see explanations below).
MK
MK we need to avoid unnecessary ValueExpression instances.
Yes, sure!. I know this optimization will be very useful, and it will
do better use of available resource (memory and cpu).
MK
MK Here is one idea: because we cannot wait for JCP (or I don't want to),
MK prototype some improvements in sandbox, for example:
MK
MK 1) we can create MyFacesExpressionFactory with methods
MK createTagValueExpression, createLocationValueExpression,
MK createResourceLocationValueExpression
MK
The problem here is the hacks required to make #{cc} and resource
this are too myfaces specific, and are too coupled to myfaces impl.
MK 2) In myfaces-core-impl then create default implementation with same
MK code as TagAttributeImpl.getValueExpression(FaceletContext, Class) has
MK currently.
MK
It could be good to have a factory pattern applied to that part.
MK 3) create new module myfaces-integration with additional
implementations
MK of MyFacesExpressionFactory. For example
JUELOWBMyFacesExpressionFactory
MK - create* methods of such implementation will create not wrapped
MK expression but one instance of JUELCODIValueExpression
Re: [core] performance: avoid wrapped EL Expressions
Hi,
what problem is it? I know about excessive rendered evaluation:
JAVASERVERFACES_SPEC_PUBLIC-941. value at EditableValueHolder can be
evaluated 2x during one request/response.
If it is another problem, can you create a jira issue, please?
Thanks,
Kočičák
Kito Mann píše v Pá 03. 06. 2011 v 17:58 -0400:
Leonardo, would this reduce the number of calls to getters during
request processing?
---
Kito D. Mann | twitter: kito99 | Author, JSF in Action
Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and
consulting
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info |
twitter: jsfcentral
+1 203-404-4848 x3
* Listen to the latest headlines in the JSF and Java EE
newscast: http://blogs.jsfcentral.com/roller/editorsdesk/category/JSF
+and+Java+EE+Newscast
* See you at JAX and JSF Summit 2011 June 20-23rd in San
Jose: http://jaxconf.com/
On Thu, Jun 2, 2011 at 10:10 PM, Leonardo Uribe lu4...@gmail.com
wrote:
Hi
I have attached another patch to MYFACES-3160. This one has
the
ability to detect if the expression uses some variable
resolved by
facelets VariableMapper wrappers and if so, indicate the
expression
cannot be cached.
This solution will work better, because it only creates
Value/Method
expressions when it is necessary. This is a great
optimization,
because in practice most expressions are bound to managed
beans, so in
practice it will make pages render faster (because EL parsing
is only
done once and a lot of objects will not be created) and the
memory
usage will be lower (less instances means gc works less).
The only part this does not have any effect is when there is a
ValueExpression directly on the markup. In this case, I think
since
org.apache.myfaces.view.facelets.compiler.UIInstructionHandler
is
final (that means it is inmutable), put a volatile variable
for cache
such cases will make it a mutable class, so it cannot take
advantage
of some compiler optimizations. Maybe we can create two
classes, one
to handle markup without EL and other with EL. Anyway, the
most
critical point is expressions on attributes (changes on
facelets
compiler has to be done very carefully).
JK I would really like to see some prototyping work for JSF
2.2 in this
JK area directly in a MyFaces core branch!
The patch proposed on MYFACES-3160 is for MyFaces 2.0 and 2.1.
After
the latest patch I think we don't really need some work on a
EL
implementation (see explanations below).
MK
MK we need to avoid unnecessary ValueExpression instances.
Yes, sure!. I know this optimization will be very useful, and
it will
do better use of available resource (memory and cpu).
MK
MK Here is one idea: because we cannot wait for JCP (or I
don't want to),
MK prototype some improvements in sandbox, for example:
MK
MK 1) we can create MyFacesExpressionFactory with methods
MK createTagValueExpression, createLocationValueExpression,
MK createResourceLocationValueExpression
MK
The problem here is the hacks required to make #{cc} and
resource
this are too myfaces specific, and are too coupled to
myfaces impl.
MK 2) In myfaces-core-impl then create default
implementation with same
MK code as
TagAttributeImpl.getValueExpression(FaceletContext, Class) has
MK currently.
MK
It could be good to have a factory pattern applied to that
part.
MK 3) create new module myfaces-integration with additional
implementations
MK of MyFacesExpressionFactory. For example
JUELOWBMyFacesExpressionFactory
MK - create* methods of such implementation will create not
wrapped
MK expression but one instance of JUELCODIValueExpression.
MK JUELCODIValueExpression will use inheritance from JUEL
internal API (and
MK some code from OWB).
MK
MK Of course it will need cooperation with JUEL/OWB
developers (for example
MK because de.odysseus.el.TreeValueExpression from JUEL is
final class).
MK Solution with inheritance is proposal only, I didn't try
it yet. User
MK must be sure that no other library wants to wrap
ValueExpression.
MK
In my mind this only works as a last resource.
VariableMapper usage
[core] EL improvements - summary
Hi, summary of ExpressionLanguage-related improvements (done or in progress) 1) ELResolvers sorting: https://cwiki.apache.org/MYFACES/elresolver-ordering.htm 2) EL Resolvers filtering: MYFACES-3075 3) Disable JSP (and javax.faces.el) support: MYFACES-3078 4) cache ELExpressions: MYFACES-3160 disscussed: an optimal ELResolvers chain for POJO-based apps Do you have any other ideas for improvements in this area? Bwt. any volunteer for adapting http://www.jtict.com/blog/rails-wicket-grails-play-lift-jsp/ for JSF/myfaces? Result can be very motivative Regards, Kočičák
Re: [core] performance: avoid wrapped EL Expressions
Hi,
the idea seems very good - but when is decided that expression does not
uses some variable resolved by VariableResolver?
TagAttributeImpl.getValue/MethodExpression methods are called in
VDL.buildView - how is the check done? String parsing? Yes, I didn't
look in the patch, its friday :)
Another idea: during VLD.buildView handler calls
TagAttribute.getMethodExpression and populates UIComponent with it. But
with partial lifecycle you don't need them all: with execute=@this and
render=something others components are untouched during lifecycle. Can
we create and use some kind o LazyValueExpression which parses and
initializes expression at first access?
Regards,
Kočičák
Leonardo Uribe píše v Čt 02. 06. 2011 v 21:10 -0500:
Hi
I have attached another patch to MYFACES-3160. This one has the
ability to detect if the expression uses some variable resolved by
facelets VariableMapper wrappers and if so, indicate the expression
cannot be cached.
This solution will work better, because it only creates Value/Method
expressions when it is necessary. This is a great optimization,
because in practice most expressions are bound to managed beans, so in
practice it will make pages render faster (because EL parsing is only
done once and a lot of objects will not be created) and the memory
usage will be lower (less instances means gc works less).
The only part this does not have any effect is when there is a
ValueExpression directly on the markup. In this case, I think since
org.apache.myfaces.view.facelets.compiler.UIInstructionHandler is
final (that means it is inmutable), put a volatile variable for cache
such cases will make it a mutable class, so it cannot take advantage
of some compiler optimizations. Maybe we can create two classes, one
to handle markup without EL and other with EL. Anyway, the most
critical point is expressions on attributes (changes on facelets
compiler has to be done very carefully).
JK I would really like to see some prototyping work for JSF 2.2 in this
JK area directly in a MyFaces core branch!
The patch proposed on MYFACES-3160 is for MyFaces 2.0 and 2.1. After
the latest patch I think we don't really need some work on a EL
implementation (see explanations below).
MK
MK we need to avoid unnecessary ValueExpression instances.
Yes, sure!. I know this optimization will be very useful, and it will
do better use of available resource (memory and cpu).
MK
MK Here is one idea: because we cannot wait for JCP (or I don't want to),
MK prototype some improvements in sandbox, for example:
MK
MK 1) we can create MyFacesExpressionFactory with methods
MK createTagValueExpression, createLocationValueExpression,
MK createResourceLocationValueExpression
MK
The problem here is the hacks required to make #{cc} and resource
this are too myfaces specific, and are too coupled to myfaces impl.
MK 2) In myfaces-core-impl then create default implementation with same
MK code as TagAttributeImpl.getValueExpression(FaceletContext, Class) has
MK currently.
MK
It could be good to have a factory pattern applied to that part.
MK 3) create new module myfaces-integration with additional implementations
MK of MyFacesExpressionFactory. For example JUELOWBMyFacesExpressionFactory
MK - create* methods of such implementation will create not wrapped
MK expression but one instance of JUELCODIValueExpression.
MK JUELCODIValueExpression will use inheritance from JUEL internal API (and
MK some code from OWB).
MK
MK Of course it will need cooperation with JUEL/OWB developers (for example
MK because de.odysseus.el.TreeValueExpression from JUEL is final class).
MK Solution with inheritance is proposal only, I didn't try it yet. User
MK must be sure that no other library wants to wrap ValueExpression.
MK
In my mind this only works as a last resource. VariableMapper usage
is only a concern inside facelets, because its usage is bound to the
context the expression is created.
Anyway, I would like to know first if it is really necessary to create
such factories. We need concrete use cases that support that. For now,
I'll be happy with the solution proposed. It still requires a deep
review (because the code affected is very critical) and some junit
tests, so it will take some time before finish it.
regards,
Leonardo Uribe
[core] performance: avoid wrapped EL Expressions
Hi, as discussed here: http://markmail.org/message/kca64ojdvb6em367?q=[core]+performance: +TagAttributeImpl+part+II:+object+allocations#query:[core]%20performance %3A%20TagAttributeImpl%20part%20II%3A%20object%20allocations+page:1 +mid:kca64ojdvb6em367+state:results and here: http://markmail.org/search/?q=TagAttributeImpl+part+II%3A+object +allocations+%28cache+ELExpressions%29#query:TagAttributeImpl%20part% 20II%3A%20object%20allocations%20%28cache%20ELExpressions%29%20from%3A% 22Leonardo%20Uribe%22+page:1+mid:pmurllp3w73q6c6s+state:results we need to avoid unnecessary ValueExpression instances. Here is one idea: because we cannot wait for JCP (or I don't want to), prototype some improvements in sandbox, for example: 1) we can create MyFacesExpressionFactory with methods createTagValueExpression, createLocationValueExpression, createResourceLocationValueExpression 2) In myfaces-core-impl then create default implementation with same code as TagAttributeImpl.getValueExpression(FaceletContext, Class) has currently. 3) create new module myfaces-integration with additional implementations of MyFacesExpressionFactory. For example JUELOWBMyFacesExpressionFactory - create* methods of such implementation will create not wrapped expression but one instance of JUELCODIValueExpression. JUELCODIValueExpression will use inheritance from JUEL internal API (and some code from OWB). Of course it will need cooperation with JUEL/OWB developers (for example because de.odysseus.el.TreeValueExpression from JUEL is final class). Solution with inheritance is proposal only, I didn't try it yet. User must be sure that no other library wants to wrap ValueExpression. WDYT? Kočičák
Re: [core] TagAttributeImpl part II: object allocations (cache ELExpressions)
Hi, thanks for implementing it. There are some thoughts (about EL generally): 1) Many big views (where creation of expressions costs nonnegligible time) use ui:param (or other tag for variable mapping) thus optimization there is not possible. It depends on style of programming but I checked about 30 most important views in our company and variablemapper always contains a mapping so no cache is used there. 2) Cache of precompiled expression is resposibility of EL-impl (container). JUEL does it and it is good performance improvement; about other implementations I'm not sure. 3) summary of problem: for one attribute in xhtml, myfaces create : * one instance of valueExpression with EpressionFactory.createValueExpression * one instance of TagValueExpression/TagValueExpressionUEL (wrapper) * optionally one instance of LocationValueExpression (wrapper for composite component) * lifespan of those instances is request, so they immediatelly GCed. * performance of createValueExpression is unknown and depends on implementaion of EL. 4) summary of requirements: * reduce number of objects created for one attribute expression (ideally to zero) * minimize dependency on methods with unknown performance (like createValueExpression) * preserve functionality of VariableMapping The main problem for implementation of such requirements is that EL spec. does not allow fine grained operations. For example we cannot provide own implementation is some factory method; We can fill issue against EL spec and wait for years for fix (like null - 0 coercion problem waits for it's solution). Or we can cooperate with one EL-implementation to prototype some improvements (like how to avoid decorator pattern for expressions). Regards, Kočičák Leonardo Uribe píše v Po 30. 05. 2011 v 16:00 -0500: Hi There is a patch proposed (after many months thinking about it), according to the discussion on: http://markmail.org/message/kca64ojdvb6em367?q=%5Bcore%5D+performance:+TagAttributeImpl+part+II:+object+allocations here: https://issues.apache.org/jira/browse/MYFACES-3160 The idea is cache ValueExpressions when necessary to reduce unnecessary object allocations and increase speed, because EL parsing is also avoided when necessary. I think it is a nice optimization. The idea is detect when the VariableMapper has a value and if so, do not cache any expression. Additionally, use a volatile variable to store expressions. The patch adds a new web config param called org.apache.myfaces.CACHE_EL_EXPRESSIONS to enable/disable this feature. @Martin Koci: since you was the one proposing this optimization, it could be good if you can check if it is worth or not (I'm 99% sure, so any help to reach 100% is welcome!) . If that so, I'll commit the proposed code. regards, Leonardo Uribe
Re: Clear Input Values
Hi,
javax.faces.component.EditableValueHolder.resetValue() and/or listener
like
http://myfaces.apache.org/trinidad/trinidad-api/tagdoc/tr_resetActionListener.html
does not solve it?
Kočičák
Mark Struberg píše v Po 30. 05. 2011 v 13:19 +0100:
Sounds like a good idea.
But shouldn't that be handled via the JSF EG?
Such a behaviour would need to be written in the spec to be reliable, isn't?
LieGrue,
strub
--- On Mon, 5/30/11, Cagatay Civici cagatay.civ...@gmail.com wrote:
From: Cagatay Civici cagatay.civ...@gmail.com
Subject: Clear Input Values
To: MyFaces Development dev@myfaces.apache.org
Date: Monday, May 30, 2011, 8:12 AM
Hi all,
I'd like to discuss something I've been thinking about
lately. How to clear forms easily when validation fails?
Consider this simple case;
h:form
h:messages /
h:inputText value=#{pprBean.firstname}
required=true/
h:inputText value=#{pprBean.surname}
required=true/
h:commandButton value=Save
f:ajax render=@form
execute=@form/
/h:commandButton
h:commandButton value=Reset
actionListener=#{pprBean.reset}
f:ajax render=@form
execute=@this/
/h:commandButton
h:outputText value=#{pprBean.firstname} id=display
/
/h:form
Bean;
private String firstname, surname;
public void reset() {
firstname = null;
surname = null;
}
So when you run this, if one of the field is empty and the
other is not, validations fails and message is displayed.
Problem happens when reset button is clicked to reset the
form values. At processValidations phase UIInput saves the
converted value at state
and since validation failed, update model is not executed
so local value is never cleared. Clicking reset, clears the
bean's values but inputText will not use the bound value and
use the one kept in state as well ending up a confusing
behavior. I've seen this in many forums.
I know wiki's like this;
http://wiki.apache.org/myfaces/ClearInputComponents
But I mean shouldn't this work as expected? Proposed
solutions seem way too hard just to clear form values.
(component binding and calling resetValue(), new view,
javascript etc.)
If at processValidations phase, local value is not stored
in state, I think that will make the code above work, but
I'm not sure if there will be any side effects. Does anyone
know why converted local value is kept at state by calling
setValue().
Cagatay
[core] support implicit object 'component' in renderers where getRendersChildren is true
Hi, problem described in MYFACES-3157 applies for all cases where renderer reads property from child component. I think that only correct way in push child to EL before: child.pushComponentToEL() Object value = child.getValue(); String style = child.getStyle(); child.popComponentFromEL() Is that ok? This affects about 8 renderers in myfaces-impl/shared Kočičák
Re: [core] implicit object 'component' in rendered expression (myfaces and spec bug)
Hi,
more info about this problem:
1) I did some testing of mojarra and they do the same in encodeBegin as
myfaces:
pushComponentToEL
if (!isRendered())
despite of the specification.
2) Specification does not mention pushComponentToEL for encodeAll(),
only says If this component returns true from isRendered(), take the
following action ... Render this component and all its children
3) pushComponentToEL and double push:
component.pushComponentToEL(context, null);
component.pushComponentToEL(context, null);
Will be the same component pushed twice on stack?
Regards,
Kočičák
Martin Koci píše v St 25. 05. 2011 v 22:12 +0200:
Hi,
there are such cases but not many of them: in myfaces code after quick
search I guess about 10 such cases. The main is in
UIComponentBase.encodeChildren and in RendererUtils.renderChild (well,
there was, but I removed it incorrectly as part of MYFACES-3126)
This affects all attributes of component, not only rendered. If renderer
encodes children, then must set up context if reads something from
child. Consider:
a:tabbedPane
a:navigationItem style=#{component.something eq 'b'} /
if tabbedPaneRenderer iterates over children directly and reads 'style'
property, then it must guarantee that 'component' resolves to
navigationItem otherwise it is incosistent with situation, where
navigationItem encodes itself.
This will affects complex structures like dataTable and panelGrid, I
think.
Regards,
Kočičák
Blake Sullivan píše v St 25. 05. 2011 v 12:42 -0700:
I suspect that there are many cases where parent components are looking
at rendered on their children before deciding to traverse into these
children. If EL-binding rendered to the component is supported, then
the parent is either going to need to stop performing this optimization,
or it is going to have to ensure that the context is setup and torn down
around each call to isRendered.
-- Blake Sullivan
On 5/25/11 11:27 AM, Martin Koci wrote:
Hi,
for spec I've created bug few days ago:
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1002
but I didn't realize how deep impact this bug have: I did a training
about JSF implicit objects in our company and now practically every
coder uses #{component.something} :)
For myfaces:
https://issues.apache.org/jira/browse/MYFACES-3157
Leonardo Uribe píše v St 25. 05. 2011 v 12:36 -0500:
Hi
I have seen that. The problem is in spec javadoc, the behavior for
UIComponent.process*
and encode* is clear about the ordering.
In theory, pushComponentToEL should be called before any call to
isRendered, but after
isTransient. Look on MyFaces UIComponentBase.processRestoreState. It has
this
public void processRestoreState(FacesContext context, Object state)
{
if (context == null)
{
throw new NullPointerException(context);
}
Object[] stateValues = (Object[]) state;
try
{
// Call
UIComponent.pushComponentToEL(javax.faces.context.FacesContext,
javax.faces.component.UIComponent)
pushComponentToEL(context, this);
// Call the restoreState() method of this component.
restoreState(context, stateValues[0]);
The spec javadoc says the opposite, restoreState should be called
before
pushComponentToEL but in practice that breaks
UIComponent.EventListenerWrapper.
I reported the bug long time ago, but it wasn't fixed (I don't know why).
This case is similar. This should be fixed on the spec, but I don't
see a reason why we shouldn't commit that into myfaces code, because
after all, nobody relies on the buggy behavior.
I think we should open a new issue on the spec issue tracker:
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC
but fix it on myfaces code.
regards,
Leonardo Uribe
2011/5/25 Martin Kocimartin.kocicak.k...@gmail.com:
Hi,
h:form
h:panelGroup
h:inputText id=testId
rendered=#{component.id eq 'testId'}
value=#{bean.value} /
/h:panelGroup
/h:form
please notice the expression:
rendered=#{component.id eq 'testId'}
that is clearly true.
But that does not work as expected: inputText is rendered, but never
updates model value.
Problem 1.
from specification, methods UIComponent.process* and encode*
1) If the rendered property of this {@link UIComponent}
false, skip further processing
2) Call {@link #pushComponentToEL}
- #{component} resolves in rendered=#{} to parent!
Problem 2.
MyFaces implement that (pointless) requirement inconsistently: from
UIComponentBase.process*:
(!isRendered())
return;
pushComponentToEL(context
[core] implicit object 'component' in rendered expression (myfaces and spec bug)
Hi,
h:form
h:panelGroup
h:inputText id=testId
rendered=#{component.id eq 'testId'}
value=#{bean.value} /
/h:panelGroup
/h:form
please notice the expression:
rendered=#{component.id eq 'testId'}
that is clearly true.
But that does not work as expected: inputText is rendered, but never
updates model value.
Problem 1.
from specification, methods UIComponent.process* and encode*
1) If the rendered property of this {@link UIComponent}
false, skip further processing
2) Call {@link #pushComponentToEL}
- #{component} resolves in rendered=#{} to parent!
Problem 2.
MyFaces implement that (pointless) requirement inconsistently: from
UIComponentBase.process*:
(!isRendered())
return;
pushComponentToEL(context, this)
and from UIComponentBase.encodeBegin*
pushComponentToEL(context, this);
if (isRendered())
causes that example above renderes inputText, but never updates model.
Problem 3.
RendererUtils.renderChild(FacesContext, UIComponent):
in this method it is unappropriate to use following code:
if (!child.isRendered()) {
return;
}
child.encodeBegin(facesContext);
because:
1) it does not take into account pushComponentToEL ( #{component}
resolves to parent)
2) behaviour is incosistent with UIComponent.encodeBegin : you'll get
random rendering - depends if parent of component renders it's
children or not! For this case I've created MYFACES-3126, but I'll
reopen it now, because simple remove of 'if (!child.isRendered())' does
not solve that problem and causes another problem if component
getRendersChildren = false;
What do yout think about this problem?
Regards,
Kočičák
Re: [core] implicit object 'component' in rendered expression (myfaces and spec bug)
Hi,
for spec I've created bug few days ago:
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1002
but I didn't realize how deep impact this bug have: I did a training
about JSF implicit objects in our company and now practically every
coder uses #{component.something} :)
For myfaces:
https://issues.apache.org/jira/browse/MYFACES-3157
Leonardo Uribe píše v St 25. 05. 2011 v 12:36 -0500:
Hi
I have seen that. The problem is in spec javadoc, the behavior for
UIComponent.process*
and encode* is clear about the ordering.
In theory, pushComponentToEL should be called before any call to
isRendered, but after
isTransient. Look on MyFaces UIComponentBase.processRestoreState. It has this
public void processRestoreState(FacesContext context, Object state)
{
if (context == null)
{
throw new NullPointerException(context);
}
Object[] stateValues = (Object[]) state;
try
{
// Call
UIComponent.pushComponentToEL(javax.faces.context.FacesContext,
javax.faces.component.UIComponent)
pushComponentToEL(context, this);
// Call the restoreState() method of this component.
restoreState(context, stateValues[0]);
The spec javadoc says the opposite, restoreState should be called before
pushComponentToEL but in practice that breaks
UIComponent.EventListenerWrapper.
I reported the bug long time ago, but it wasn't fixed (I don't know why).
This case is similar. This should be fixed on the spec, but I don't
see a reason why we shouldn't commit that into myfaces code, because
after all, nobody relies on the buggy behavior.
I think we should open a new issue on the spec issue tracker:
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC
but fix it on myfaces code.
regards,
Leonardo Uribe
2011/5/25 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
h:form
h:panelGroup
h:inputText id=testId
rendered=#{component.id eq 'testId'}
value=#{bean.value} /
/h:panelGroup
/h:form
please notice the expression:
rendered=#{component.id eq 'testId'}
that is clearly true.
But that does not work as expected: inputText is rendered, but never
updates model value.
Problem 1.
from specification, methods UIComponent.process* and encode*
1) If the rendered property of this {@link UIComponent}
false, skip further processing
2) Call {@link #pushComponentToEL}
- #{component} resolves in rendered=#{} to parent!
Problem 2.
MyFaces implement that (pointless) requirement inconsistently: from
UIComponentBase.process*:
(!isRendered())
return;
pushComponentToEL(context, this)
and from UIComponentBase.encodeBegin*
pushComponentToEL(context, this);
if (isRendered())
causes that example above renderes inputText, but never updates model.
Problem 3.
RendererUtils.renderChild(FacesContext, UIComponent):
in this method it is unappropriate to use following code:
if (!child.isRendered()) {
return;
}
child.encodeBegin(facesContext);
because:
1) it does not take into account pushComponentToEL ( #{component}
resolves to parent)
2) behaviour is incosistent with UIComponent.encodeBegin : you'll get
random rendering - depends if parent of component renders it's
children or not! For this case I've created MYFACES-3126, but I'll
reopen it now, because simple remove of 'if (!child.isRendered())' does
not solve that problem and causes another problem if component
getRendersChildren = false;
What do yout think about this problem?
Regards,
Kočičák
Re: [core] implicit object 'component' in rendered expression (myfaces and spec bug)
Hi,
there are such cases but not many of them: in myfaces code after quick
search I guess about 10 such cases. The main is in
UIComponentBase.encodeChildren and in RendererUtils.renderChild (well,
there was, but I removed it incorrectly as part of MYFACES-3126)
This affects all attributes of component, not only rendered. If renderer
encodes children, then must set up context if reads something from
child. Consider:
a:tabbedPane
a:navigationItem style=#{component.something eq 'b'} /
if tabbedPaneRenderer iterates over children directly and reads 'style'
property, then it must guarantee that 'component' resolves to
navigationItem otherwise it is incosistent with situation, where
navigationItem encodes itself.
This will affects complex structures like dataTable and panelGrid, I
think.
Regards,
Kočičák
Blake Sullivan píše v St 25. 05. 2011 v 12:42 -0700:
I suspect that there are many cases where parent components are looking
at rendered on their children before deciding to traverse into these
children. If EL-binding rendered to the component is supported, then
the parent is either going to need to stop performing this optimization,
or it is going to have to ensure that the context is setup and torn down
around each call to isRendered.
-- Blake Sullivan
On 5/25/11 11:27 AM, Martin Koci wrote:
Hi,
for spec I've created bug few days ago:
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1002
but I didn't realize how deep impact this bug have: I did a training
about JSF implicit objects in our company and now practically every
coder uses #{component.something} :)
For myfaces:
https://issues.apache.org/jira/browse/MYFACES-3157
Leonardo Uribe píše v St 25. 05. 2011 v 12:36 -0500:
Hi
I have seen that. The problem is in spec javadoc, the behavior for
UIComponent.process*
and encode* is clear about the ordering.
In theory, pushComponentToEL should be called before any call to
isRendered, but after
isTransient. Look on MyFaces UIComponentBase.processRestoreState. It has
this
public void processRestoreState(FacesContext context, Object state)
{
if (context == null)
{
throw new NullPointerException(context);
}
Object[] stateValues = (Object[]) state;
try
{
// Call
UIComponent.pushComponentToEL(javax.faces.context.FacesContext,
javax.faces.component.UIComponent)
pushComponentToEL(context, this);
// Call the restoreState() method of this component.
restoreState(context, stateValues[0]);
The spec javadoc says the opposite, restoreState should be called before
pushComponentToEL but in practice that breaks
UIComponent.EventListenerWrapper.
I reported the bug long time ago, but it wasn't fixed (I don't know why).
This case is similar. This should be fixed on the spec, but I don't
see a reason why we shouldn't commit that into myfaces code, because
after all, nobody relies on the buggy behavior.
I think we should open a new issue on the spec issue tracker:
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC
but fix it on myfaces code.
regards,
Leonardo Uribe
2011/5/25 Martin Kocimartin.kocicak.k...@gmail.com:
Hi,
h:form
h:panelGroup
h:inputText id=testId
rendered=#{component.id eq 'testId'}
value=#{bean.value} /
/h:panelGroup
/h:form
please notice the expression:
rendered=#{component.id eq 'testId'}
that is clearly true.
But that does not work as expected: inputText is rendered, but never
updates model value.
Problem 1.
from specification, methods UIComponent.process* and encode*
1) If the rendered property of this {@link UIComponent}
false, skip further processing
2) Call {@link #pushComponentToEL}
- #{component} resolves in rendered=#{} to parent!
Problem 2.
MyFaces implement that (pointless) requirement inconsistently: from
UIComponentBase.process*:
(!isRendered())
return;
pushComponentToEL(context, this)
and from UIComponentBase.encodeBegin*
pushComponentToEL(context, this);
if (isRendered())
causes that example above renderes inputText, but never updates model.
Problem 3.
RendererUtils.renderChild(FacesContext, UIComponent):
in this method it is unappropriate to use following code:
if (!child.isRendered()) {
return;
}
child.encodeBegin(facesContext);
because:
1) it does not take into account pushComponentToEL ( #{component}
resolves to parent)
2) behaviour is incosistent with UIComponent.encodeBegin : you'll get
random rendering - depends if parent of component renders it's
children or not! For this case I've created MYFACES-3126, but I'll
reopen it now, because simple remove of 'if (!child.isRendered
Re: [VOTE] release for myfaces core 2.1.0
+1 Leonardo Uribe píše v Út 24. 05. 2011 v 13:29 -0500: +1 2011/5/24 Leonardo Uribe lu4...@gmail.com: Hi, I was running the needed tasks to get the 2.1.0 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.1.0 [1] 2. Maven artifact group org.apache.myfaces.core v2.1.0 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.1.0 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-003/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces210binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12315190
Re: [core] do not check for duplicate ids when saving view on production stage
org.apache.myfaces.CHECK_ID_IN_PRODUCTION (default true) and when false: 1) skip duplicate id check 2) skip id validity check (in UIComponent.setId) 3) ... (something we found later) ... WDYT? Jakob Korherr píše v So 14. 05. 2011 v 12:26 +0200: +1 for a MyFaces specific parameter. Regards, Jakob 2011/5/11 Martin Koci martin.kocicak.k...@gmail.com: +1 for specific parameter (in one project I build view dynamically from DB and want this ids check) Gerhard Petracek píše v St 11. 05. 2011 v 07:52 +0200: hi, i would combine it - +1 for a myfaces specific parameter which gets evaluated in case of project-stage production. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/5/11 Leonardo Uribe lu4...@gmail.com Hi Checking the state saving algorithm I have seen that every time StateManager.saveView is called, it checks for duplicate ids, scanning the whole component tree. The documentation of StateManager.saveView says this: ...This method must also enforce the rule that, for components with non-null ids, all components that are descendants of the same nearest NamingContainer must have unique identifiers. Yes, that's right, but a possible optimization could be do not do it if project stage is production, or maybe just add a param that disable that stuff. Does that sounds good? Any objections? regards, Leonardo Uribe
Re: [myfaces] ideas and things to do
Gerhard Petracek píše v Út 17. 05. 2011 v 11:59 +0200: hi, imo we should prototype some jsf 2.2 features (at least in a branch). that would help the eg to specify some of the new features (like the window-id) easily and we can get the feedback of the whole community and we would have the basic implementation quite early. so we increase the chance that the new features won't have to be deprecated in the next version (see the target attribute of composite-components). 1 ! JSF need feedback from real usage before features are specified (as final), not after. Only that way leads to framework with real useability. since html5 is planned as a part of jsf 2.2, we should do the same here. @lightweight component framework that might fit to tomahawk. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/5/17 Mark Struberg strub...@yahoo.de +1 Especially the advanced resource handler is a great goodie. Currently it is not easily possible to deliver those resources with a cache header. Of course there should be some additional work in the JSF EG, but I think Jakob pinged Ed already on this topic, right? The HTML-5 components from Ali are really great stuff too, but might take some time to be widely supported. But anyway, being a step ahead is always a good thing! Also Tomahawk still contains a few features which might be interesting in JSF-2 (Marcus Büttner is using those) * file upload * table sorting * table autosuggest * isUserInRole (would be great in conjunction with CODI manages Voters?) There is still no really lightweight component framework for JSF-2. We could of course possibly drop all the 'basic' components like t:inputText and stuff. LieGrue, strub --- On Tue, 5/17/11, Leonardo Uribe lu4...@gmail.com wrote: From: Leonardo Uribe lu4...@gmail.com Subject: [myfaces] ideas and things to do To: MyFaces Development dev@myfaces.apache.org Date: Tuesday, May 17, 2011, 3:48 AM Hi Thinking about how can we do MyFaces even better, I think we should focus on these areas in the short term: 1. HTML 5 project: there is some code in this area, so it is only necessary a bit of effort to get it out. 2. Enhanced Resource Handler: again we have some code. 3. Agent detection support: again, there is some code extracted from trinidad long time ago, but now with JSF2 we can do some cleanup/update over this project. Any suggestions? Leonardo Uribe
[core] Can UIComponent.rendererType be ValueExpression ? (MYFACES-3136)
Hi, two questions : 1) can UIComponent.rendererType be ValueExpression? If yes, in which situation is useful to use it? 2) should be rendereType saved during state saving? Each component has setRendererType(com.foo.renderer) in constructor and/or VDL calls setRendererType() after calling Application.createComponent() Please see MYFACES-3136 for details Thanks, Kočičák
Re: [core] Can UIComponent.rendererType be ValueExpression ? (MYFACES-3136)
Hi,
from spec:
.. Because the components themselves store only a rendererType property
(a logical identifier of a particular Renderer) ..
rendererType = Identifier of the Renderer instance (from the set of
Renderer rendererType String instances supported by the RenderKit
associated with the component tree we are processing.
The default value of the rendererType property must be set to ...
(always String in spec)
JavaDoc: setRendererType - rendererType = Logical identifier of the type
of Renderer to use, or null for components that render themselves
It seems to me that rendererType is String-only, not ValueExpression.
Similar attributes are componentType and componentFamily -those are
String-only I think.
Internally in code I don't see
component.setValueExpression(rendererType, ve).
a:component rendererType=#{bean.getRendererType} / is not possible.
About state saving and rendererType I found nothing.
Jakob Korherr píše v Pá 13. 05. 2011 v 16:11 +0200:
Hi Martin,
Have you checked the JSF 2.1 and 2.0 specs yet?
Regards,
Jakob
2011/5/13 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
two questions :
1) can UIComponent.rendererType be ValueExpression? If yes, in which
situation is useful to use it?
2) should be rendereType saved during state saving? Each component has
setRendererType(com.foo.renderer) in constructor and/or VDL calls
setRendererType() after calling Application.createComponent()
Please see MYFACES-3136 for details
Thanks,
Kočičák
Re: [core] Can UIComponent.rendererType be ValueExpression ? (MYFACES-3136)
Hi,
trinidad caches Renderer instance in UIXComponentBase so they at least
suppose that rendererType cannot change during one render/response and
no need for evaluate it in every getRendererType() call - see
MYFACES-3144.
Other libs I'll check.
Regards,
Kočičák
Jakob Korherr píše v Pá 13. 05. 2011 v 16:44 +0200:
Hmm, ok.
I also can't think of a scenario where you would use something like
this right now. But I'll think of it and do some research..
Martin, could you take a look at some of the prominent JSF component
libs (like Primefaces, Trinidad, Tomahawk, Tobago, RichFaces,
IceFaces) and search in their code for something like this? If you
don't find anything there, then it should be pretty safe to remove the
ValueExpression support from rendererType!
Regards,
Jakob
2011/5/13 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
from spec:
.. Because the components themselves store only a rendererType property
(a logical identifier of a particular Renderer) ..
rendererType = Identifier of the Renderer instance (from the set of
Renderer rendererType String instances supported by the RenderKit
associated with the component tree we are processing.
The default value of the rendererType property must be set to ...
(always String in spec)
JavaDoc: setRendererType - rendererType = Logical identifier of the type
of Renderer to use, or null for components that render themselves
It seems to me that rendererType is String-only, not ValueExpression.
Similar attributes are componentType and componentFamily -those are
String-only I think.
Internally in code I don't see
component.setValueExpression(rendererType, ve).
a:component rendererType=#{bean.getRendererType} / is not possible.
About state saving and rendererType I found nothing.
Jakob Korherr píše v Pá 13. 05. 2011 v 16:11 +0200:
Hi Martin,
Have you checked the JSF 2.1 and 2.0 specs yet?
Regards,
Jakob
2011/5/13 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
two questions :
1) can UIComponent.rendererType be ValueExpression? If yes, in which
situation is useful to use it?
2) should be rendereType saved during state saving? Each component has
setRendererType(com.foo.renderer) in constructor and/or VDL calls
setRendererType() after calling Application.createComponent()
Please see MYFACES-3136 for details
Thanks,
Kočičák
Re: [core] Can UIComponent.rendererType be ValueExpression ? (MYFACES-3136)
Leonardo Uribe píše v Pá 13. 05. 2011 v 14:59 -0500:
Hi
+1 to both changes.
That means: replace StateHelper with attribute as MYFACES-3136 suggests,
right?
I agree with you about rendererType is always an
String, there is not any mention on the spec saying rendererType could
receive EL expressions. If someone wants to change a renderer, it uses
a RenderKit wrapper or just define another RenderKitId to be used for
the current application.
Please note this description of UIViewRoot.getRenderKitId :
... Return the render kit identifier of the RenderKit associated with
this view. Unless explicitly set, as in
ViewHandler.createView(javax.faces.context.FacesContext,
java.lang.String), the returned value will be null. ...
and setRenderKitId:
... Set the render kit identifier of the RenderKit associated with
this view. This method may be called at any time between the end of
Apply Request Values phase of the request processing lifecycle (i.e.
when events are being broadcast) and the beginning of the Render
Response phase. ...
So any caching must preserve this behavior.
Thats very interesting, with this behaviour it is possible to change
renderkit in actionListener for example. But it also means that renderer
cannot be be cached UIComponentBase:
1) UIComponent.decode - caches renderer
2) INVOKE_APPLICATION - changes renderKit
3) UIComponent.encodeBegin - uses old cached renderer
but caching is valid for all encode* method then. Any ideas how to
detect this component will be rendered in this lifecycle and cache
renderer even for getClientId? stateManagement calls getClientId
(checkIds) before component.encodeBegin. Can we use visitTree method for
that?
Kočičák
regards,
Leonardo
2011/5/13 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
trinidad caches Renderer instance in UIXComponentBase so they at least
suppose that rendererType cannot change during one render/response and
no need for evaluate it in every getRendererType() call - see
MYFACES-3144.
Other libs I'll check.
Regards,
Kočičák
Jakob Korherr píše v Pá 13. 05. 2011 v 16:44 +0200:
Hmm, ok.
I also can't think of a scenario where you would use something like
this right now. But I'll think of it and do some research..
Martin, could you take a look at some of the prominent JSF component
libs (like Primefaces, Trinidad, Tomahawk, Tobago, RichFaces,
IceFaces) and search in their code for something like this? If you
don't find anything there, then it should be pretty safe to remove the
ValueExpression support from rendererType!
Regards,
Jakob
2011/5/13 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
from spec:
.. Because the components themselves store only a rendererType property
(a logical identifier of a particular Renderer) ..
rendererType = Identifier of the Renderer instance (from the set of
Renderer rendererType String instances supported by the RenderKit
associated with the component tree we are processing.
The default value of the rendererType property must be set to ...
(always String in spec)
JavaDoc: setRendererType - rendererType = Logical identifier of the type
of Renderer to use, or null for components that render themselves
It seems to me that rendererType is String-only, not ValueExpression.
Similar attributes are componentType and componentFamily -those are
String-only I think.
Internally in code I don't see
component.setValueExpression(rendererType, ve).
a:component rendererType=#{bean.getRendererType} / is not possible.
About state saving and rendererType I found nothing.
Jakob Korherr píše v Pá 13. 05. 2011 v 16:11 +0200:
Hi Martin,
Have you checked the JSF 2.1 and 2.0 specs yet?
Regards,
Jakob
2011/5/13 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
two questions :
1) can UIComponent.rendererType be ValueExpression? If yes, in which
situation is useful to use it?
2) should be rendereType saved during state saving? Each component has
setRendererType(com.foo.renderer) in constructor and/or VDL calls
setRendererType() after calling Application.createComponent()
Please see MYFACES-3136 for details
Thanks,
Kočičák
Re: [core] Can UIComponent.rendererType be ValueExpression ? (MYFACES-3136)
One more question: UIComponent.getClientId() uses Renderer.convertClientId 1) INVOKE_APPLICATION - action listener calls component.getClient() - component generates client id with renderer1 + as next step actionListener changes renderKitId 2) RENDER_RESPOSE: renderer2 from new renderkit renders component with clientId from renderer1! Is that ok? Leonardo Uribe píše v Pá 13. 05. 2011 v 15:45 -0500: Hi 2011/5/13 Martin Koci martin.kocicak.k...@gmail.com: Leonardo Uribe píše v Pá 13. 05. 2011 v 14:59 -0500: Hi +1 to both changes. That means: replace StateHelper with attribute as MYFACES-3136 suggests, right? That means change StateHelper.eval to StateHelper.get in UIComponentBase.getRendererType() The point 3 it is not really necessary, because this property is part of the full state, not the delta, which is the one that consume space on server side state saving. I prefer keep using StateHelper but get instead eval. I agree with you about rendererType is always an String, there is not any mention on the spec saying rendererType could receive EL expressions. If someone wants to change a renderer, it uses a RenderKit wrapper or just define another RenderKitId to be used for the current application. Please note this description of UIViewRoot.getRenderKitId : ... Return the render kit identifier of the RenderKit associated with this view. Unless explicitly set, as in ViewHandler.createView(javax.faces.context.FacesContext, java.lang.String), the returned value will be null. ... and setRenderKitId: ... Set the render kit identifier of the RenderKit associated with this view. This method may be called at any time between the end of Apply Request Values phase of the request processing lifecycle (i.e. when events are being broadcast) and the beginning of the Render Response phase. ... So any caching must preserve this behavior. Thats very interesting, with this behaviour it is possible to change renderkit in actionListener for example. But it also means that renderer cannot be be cached UIComponentBase: 1) UIComponent.decode - caches renderer 2) INVOKE_APPLICATION - changes renderKit 3) UIComponent.encodeBegin - uses old cached renderer but caching is valid for all encode* method then. Any ideas how to detect this component will be rendered in this lifecycle and cache renderer even for getClientId? stateManagement calls getClientId (checkIds) before component.encodeBegin. Can we use visitTree method for that? Cache as soon as you do the lookup, but clean it inside encodeAll call. Note some code is necessary here if encodeAll is called multiple times over the same instance (datatable or datalist case). Use a simple variable to do the trick. Leonardo
Re: [core] do not check for duplicate ids when saving view on production stage
+1 for specific parameter (in one project I build view dynamically from DB and want this ids check) Gerhard Petracek píše v St 11. 05. 2011 v 07:52 +0200: hi, i would combine it - +1 for a myfaces specific parameter which gets evaluated in case of project-stage production. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/5/11 Leonardo Uribe lu4...@gmail.com Hi Checking the state saving algorithm I have seen that every time StateManager.saveView is called, it checks for duplicate ids, scanning the whole component tree. The documentation of StateManager.saveView says this: ...This method must also enforce the rule that, for components with non-null ids, all components that are descendants of the same nearest NamingContainer must have unique identifiers. Yes, that's right, but a possible optimization could be do not do it if project stage is production, or maybe just add a param that disable that stuff. Does that sounds good? Any objections? regards, Leonardo Uribe
[core] performance: use indices instead of iterator (MYFACES-3130)
Hi, in current codebase, myfaces use mostly enhanced loop for iterating over chidren: for (UIComponent child: getChildren()) that creates new instance of iterator. After change to plain old indices: for (i = 0; i childCount; i++) child = getChildren().get(i); I achieved following results in my test case: 1) number of AbstractList$Itr from ~ 100 000 down to ~1500 instances per one render/response 2) time for one render/response from ~1500ms down to ~900ms please see https://issues.apache.org/jira/browse/MYFACES-3130 for more details. We know that getChildren() is type of ArrayList (javax.faces.component._ComponentChildrenList) - in this situation is index-based loop safe change. But custom component can override implementation of getChildren() and provide own implementation which can be slower: I know about Trinidad: uses ArrayList too, so no risk here (org.apache.myfaces.trinidad.component.ChildArrayList) I use RichFaces and PrimeFaces too and don't see custom implementation of children in their codebase. What do you think about this problem? The performance gain is pretty big but also risky. Regards, Kočičák
Re: [core] performance: use indices instead of iterator (MYFACES-3130)
Hi, yes, every List support indexes, but it dependes on implementation if that index-based access is fast or not. For example, ArrayList is fast, because it uses array internally; and also flags that with interface java.util.RandomAccess But LinkedList for example just iterates the list until it reaches the index you specified - there is the dangerous problem. Mike Kienenberger píše v Út 10. 05. 2011 v 16:17 -0400: If getChildren() is always of type List, then it really doesn't matter if it's ArrayList or ChildArrayList or some other kind of list. You can use indexes for any type of List. On Tue, May 10, 2011 at 4:11 PM, Martin Koci martin.kocicak.k...@gmail.com wrote: Hi, in current codebase, myfaces use mostly enhanced loop for iterating over chidren: for (UIComponent child: getChildren()) that creates new instance of iterator. After change to plain old indices: for (i = 0; i childCount; i++) child = getChildren().get(i); I achieved following results in my test case: 1) number of AbstractList$Itr from ~ 100 000 down to ~1500 instances per one render/response 2) time for one render/response from ~1500ms down to ~900ms please see https://issues.apache.org/jira/browse/MYFACES-3130 for more details. We know that getChildren() is type of ArrayList (javax.faces.component._ComponentChildrenList) - in this situation is index-based loop safe change. But custom component can override implementation of getChildren() and provide own implementation which can be slower: I know about Trinidad: uses ArrayList too, so no risk here (org.apache.myfaces.trinidad.component.ChildArrayList) I use RichFaces and PrimeFaces too and don't see custom implementation of children in their codebase. What do you think about this problem? The performance gain is pretty big but also risky. Regards, Kočičák
Re: [core] tasks for release myfaces core 2.0.6 and 2.1.0-rc
Hi, I see one big issue: https://issues.apache.org/jira/browse/MYFACES-3117 That may require a change in server state management, so I suggest solve it before first 2.1 release Another one is a big performance improvement: https://issues.apache.org/jira/browse/MYFACES-3130 that needs discussion. Regards, Kočičák Leonardo Uribe píše v Pá 06. 05. 2011 v 11:48 -0500: Hi It could be good to do a release of myfaces core 2.0.5 and 2.1.0-rc in 1 or 2 weeks. The code for myfaces core 2.1.x (actually in trunk) is ready, all features specified by the spec were implemented. So to keep things moving and get some feedback, I think it could be good to do a release, so people can give a try. After that, it could be good to do a release of tomahawk too (1.1.11). Most of the issues planned for this release were already solved, and the only thing left is do a cleanup for sandbox for jsf 2.0. If you have some issues that needs to be included in these releases, it is a good time to say it. best regards, Leonardo Uribe
Re: [core] performance: performance hints
Hi,
Leonardo Uribe píše v Po 25. 04. 2011 v 12:45 +0200:
Hi
2011/4/19 Martin Koci martin.kocicak.k...@gmail.com
Hi,
is it possible to introduce performance hints in myfaces-core?
Hints
similar to javax.faces.component.visit.VisitHint but related
to
performance improvements. Example:
For dataTable like:
a:dataTable
a:column
#{aExpression}
it's completely unnecessary to save per-row state. Currently
there is no
elegant way how to do read-only table (state per-row is always
maintained). If user wants (fast) readOnly table, he/she must
extend
UIData and re-implemenent setRowIndex method. But hint say
org.apache.myfaces.core.UIData.saveRowState=false can solve
it
elegantly - if present (in component.getAttributes()) UIData
skips
row-state-saving and restoring methods entirely.
Unfortunately, we can't do anything like that on default UIData
implementation
(it could breaks backwards behavior). I think we could include a
property
on tomahawk t:dataTable called readOnly, that just skip all that
code
related to save/restore for rows. That could be better, and it has
sense to
put in tomahawk, because after all that is the right location for
extend
default jsf components.
Yes, this is one point of view and I agree with that custom behaviour
belongs into custom component. I did exactly the same for my component.
But there are other topics to consider:
0) simple presence of performance hints in core does not break the
compatibility : the *usage* of that hint can break the compatibility -
so as usual, user must know what that parameter means and what it can
cause.
1) I think JSF implementation can break the specified functionality:
myfaces did it already with elResolvers sorting for example. But the
default must be always false for 100% compatibility with JSF
specification.
2) The hint technique is very common : another example from Java EE is
world JPA Query.setHint
3) Hints are a simple way to realize something this should be in core
but because of slow specification release cycle, you must wait a year or
two to get it officially specified in public API.
4) Ease of usage: for example, if you have only one readonly table in
whole project, creation of custom component for that purpose is an
overkill: simple f:attribute name=oam.readOnly value=true / is
much easier.
5) Internet is full of JSF is slow. Although I know that is completely
untrue, hinting the core for more performance is a easy way which
allows users to express all they need without additional dependencies.
So, do you think we really can't put this feature in core? I mean the
hints feature generally, not readonly UIData - that was only an
example.
Regards,
Kočičák
Anyway, I think it is possible to do some work on UIData to make it
perform
faster and better.
Lifespan of those hints can be request
(faceContext.attributes) or view
(component.attributes)
I don't think in this case it applies, but any configuration param for
a view
should be on a tag like f:view or something similar.
regards,
Leonardo
WDYT?
Regards,
Kočičák
See https://issues.apache.org/jira/browse/MYFACES-3111 too.
[core] performance: performance hints
Hi,
is it possible to introduce performance hints in myfaces-core? Hints
similar to javax.faces.component.visit.VisitHint but related to
performance improvements. Example:
For dataTable like:
a:dataTable
a:column
#{aExpression}
it's completely unnecessary to save per-row state. Currently there is no
elegant way how to do read-only table (state per-row is always
maintained). If user wants (fast) readOnly table, he/she must extend
UIData and re-implemenent setRowIndex method. But hint say
org.apache.myfaces.core.UIData.saveRowState=false can solve it
elegantly - if present (in component.getAttributes()) UIData skips
row-state-saving and restoring methods entirely.
Lifespan of those hints can be request (faceContext.attributes) or view
(component.attributes)
WDYT?
Regards,
Kočičák
See https://issues.apache.org/jira/browse/MYFACES-3111 too.
Re: [VOTE] release for myfaces core 2.0.5
+1 Regards, Kočičák Leonardo Uribe píše v Út 05. 04. 2011 v 01:02 -0500: +1 2011/4/5 Leonardo Uribe lu4...@gmail.com Hi, I was running the needed tasks to get the 2.0.5 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.0.6 [1] 2. Maven artifact group org.apache.myfaces.core v2.0.5 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.0.5 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-044/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces205binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316346
Re: [core] performance: ELResolvers filtering
Hi, suggested patch is here: https://issues.apache.org/jira/browse/MYFACES-3078 can you please review it and apply if is it proper? Regards, Kočičák Hi Add a param to disable JSP support looks like a good idea. With such param we could solve this issue raised recently: https://issues.apache.org/jira/browse/MYFACES-3104 MyFaces 2 with EL ? 2.2 in Websphere 7 regards, Leonardo Uribe 2011/3/17 Martin Koci martin.kocicak.k...@gmail.com This approach cannot filter two resolvers: 1. org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver 2. org.apache.myfaces.el.unified.resolver.ScopedAttributeResolver 1) the first one is instance of CompositeELResolver and serves as container for sorted/filtered list of others ELResolvers. Currently does something for JSP, so I suggest to introduce: o.a.m.SUPPORT_JSP = true|false content-param as mentioned in original mail thread performance: disabling old technologies and if this false, myfaces will not install FacesCompositeELResolver, but plain javax.el.CompositeELResolver as parent. 2) org.apache.myfaces.el.unified.resolver.ScopedAttributeResolver is the last one in chain and always calls setPropertyResolved(true); (JSF 2.1: 5.6.2.9 ScopedAttribute ELResolver) and pick up anything stored in the request, viewScope, session, or application scopes by name. In strictly CDI-based application with no direct modification of servlet scopes or view scope this resolver will never resolve a property. What to do with this one I don't know. Possibly we can use ELResolver transforming :) org.apache.commons.collections.Transformer and allow replace one resolver with another, for example: o.a.m.el.unified.resolver.ScopedAttributeResolver - MyNotResovingResolverWhichCallsSetPropertyResolvedTrue el.ResourceBundleELResolver - SpringMessageSourceResolver (we don't use ResourceBundle) el.BeanELResolver - MemoryLeakFreeBeanELResolver Of course this functionality can be achieved by filtering out the unwanted resolver with predicate and adding own in faces-config (and sort it to proper position in chain) Regards, Kočičák Martin Koci píše v St 16. 03. 2011 v 11:29 +0100: Hi, after few months I have time to do some performance optimalization for myfaces. This one is related to topic http://www.mail-archive.com/dev@myfaces.apache.org/msg49177.html Problem: how to disable ELResolver smartly? Adding a context-param for each is an overkill. But we have https://cwiki.apache.org/MYFACES/elresolver-ordering.html in codebase already. I propose to add new feature ELResolver filtering and new context-param: context-param param-nameorg.apache.myfaces.EL_RESOLVER_PREDICATE/param-name param-valueorg.foo.bazz.ELResolverPredicate/param-value /context-param Filter is simple instance of org.apache.commons.collections.Predicate. For application where no ManagedBean(Resolver) is used or no Flash, user can simply return false from Predicate.evaluate and ELResolver won't be installed. WDYT? Regards, Kočičák
Re: [core] performance: an optimal ELResolvers chain for POJO-based apps
Hi,
the only solution which comes to my mind is update MYFACES-3075 to
support transforming (replacing one resover with another) and with some
sort of supplier support (when user wants provide own list of EL
reolvers). That will allow complete maninulation of el resolvers chain:
custom chain,sort,filter and transform.
Then we can provide a lenient BeanELResolver implementation with
behaviour: if base does not have the property returns null and allows
next resolver to take charge of getValue.
WDYT?
Kočičák
Martin Koci píše v Po 28. 03. 2011 v 20:50 +0200:
Hi,
I'm optimizing render response on a large view (takes over 3 secs to
render) and below you can see results of unsorted and unfiltered
ELResolvers chain. The most important info is that BeanELResolver
resolves property over 4x from 64000 invocations. The second place
belongs to ImplicitObjectResolver with over 2 resolved properties.
The reason why BeanElResolver is so successful is because majority of
expressions looks like
{requestScope.pojoObject.propertyOne.propertyTwo}.
The obvious optimalization would be move the BeanELResolver to top. But
you cannot: EL spec 2.2 javax.el.BeanELResolver: If the property is not
found or is not readable, a PropertyNotFoundException is thrown. So
UEL spec. mandates that BeanELResolver must be last one which resolves
not-null base and a property on that base.
Do you know the reason for that? Do you have any ideas how to move
BeanELResolver to top and avoid thousands of empty geValue
invocations?
Thanks,
Kočičák
Results:
ImplicitObjectResolver:
getValue invocations: 64452 getValue hits: 21018
org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver:
getValue invocations: 64336 getValue hits: 30
org.richfaces.skin.SkinPropertiesELResolver
getValue invocations: 64306 getValue hits: 0
org.richfaces.resource.ResourceParameterELResolver
getValue invocations: 64306 getValue hits: 0
org.jboss.weld.environment.servlet.jsf.WeldApplication
$LazyBeanManagerIntegrationELResolver
getValue invocations: 64306 getValue hits: 975
org.apache.myfaces.el.unified.resolver.ManagedBeanResolver
getValue invocations: 63331 getValue hits: 0
org.apache.myfaces.el.unified.resolver.ResourceResolver
getValue invocations: 63331 getValue hits: 64
javax.el.ResourceBundleELResolver
getValue invocations: 63267 getValue hits: 3
org.apache.myfaces.el.unified.resolver.ResourceBundleResolver
getValue invocations: 63264 getValue hits: 3
javax.el.MapELResolver:
getValue invocations: 63261 getValue hits: 1069
javax.el.ListELResolver:
getValue invocations: 62192 getValue hits: 0
javax.el.ArrayELResolver:
getValue invocations: 62192 getValue hits: 0
javax.el.BeanELResolver:
getValue invocations: 62192 getValue hits: 40563
org.apache.myfaces.el.unified.resolver.ScopedAttributeResolver
getValue invocations: 21629 getValue hits: 582
[core] performance: an optimal ELResolvers chain for POJO-based apps
Hi,
I'm optimizing render response on a large view (takes over 3 secs to
render) and below you can see results of unsorted and unfiltered
ELResolvers chain. The most important info is that BeanELResolver
resolves property over 4x from 64000 invocations. The second place
belongs to ImplicitObjectResolver with over 2 resolved properties.
The reason why BeanElResolver is so successful is because majority of
expressions looks like
{requestScope.pojoObject.propertyOne.propertyTwo}.
The obvious optimalization would be move the BeanELResolver to top. But
you cannot: EL spec 2.2 javax.el.BeanELResolver: If the property is not
found or is not readable, a PropertyNotFoundException is thrown. So
UEL spec. mandates that BeanELResolver must be last one which resolves
not-null base and a property on that base.
Do you know the reason for that? Do you have any ideas how to move
BeanELResolver to top and avoid thousands of empty geValue
invocations?
Thanks,
Kočičák
Results:
ImplicitObjectResolver:
getValue invocations: 64452 getValue hits: 21018
org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver:
getValue invocations: 64336 getValue hits: 30
org.richfaces.skin.SkinPropertiesELResolver
getValue invocations: 64306 getValue hits: 0
org.richfaces.resource.ResourceParameterELResolver
getValue invocations: 64306 getValue hits: 0
org.jboss.weld.environment.servlet.jsf.WeldApplication
$LazyBeanManagerIntegrationELResolver
getValue invocations: 64306 getValue hits: 975
org.apache.myfaces.el.unified.resolver.ManagedBeanResolver
getValue invocations: 63331 getValue hits: 0
org.apache.myfaces.el.unified.resolver.ResourceResolver
getValue invocations: 63331 getValue hits: 64
javax.el.ResourceBundleELResolver
getValue invocations: 63267 getValue hits: 3
org.apache.myfaces.el.unified.resolver.ResourceBundleResolver
getValue invocations: 63264 getValue hits: 3
javax.el.MapELResolver:
getValue invocations: 63261 getValue hits: 1069
javax.el.ListELResolver:
getValue invocations: 62192 getValue hits: 0
javax.el.ArrayELResolver:
getValue invocations: 62192 getValue hits: 0
javax.el.BeanELResolver:
getValue invocations: 62192 getValue hits: 40563
org.apache.myfaces.el.unified.resolver.ScopedAttributeResolver
getValue invocations: 21629 getValue hits: 582
Re: [core] performance: an optimal ELResolvers chain for POJO-based apps
Hi Mark,
I don't understand your question fully. There are no JSF managed beans
involved:
org.apache.myfaces.el.unified.resolver.ManagedBeanResolver
getValue invocations: 63331 getValue hits: 0
getValue hits is zero - it means that resolver doesn't not resolve
property with context.setPropertyResolved(true).
The view is composed from two lagre tables and those tables are origin
for variable in request scope :
h:dataTable var=pojoObject
h:column
#{requestScope.pojoObject.property1.property2}
If you remove the requestScope implicit object from expression it
changes only the number for ImplicitObjectResolver, not for
BeanELResolver.
Regards,
Kočičák
Mark Struberg píše v Po 28. 03. 2011 v 19:57 +0100:
your numbers imply that one uses JSF @ManagedBeans, isn't?
LieGrue,
strub
--- On Mon, 3/28/11, Martin Koci martin.kocicak.k...@gmail.com wrote:
From: Martin Koci martin.kocicak.k...@gmail.com
Subject: [core] performance: an optimal ELResolvers chain for POJO-based
apps
To: dev@myfaces.apache.org
Date: Monday, March 28, 2011, 6:50 PM
Hi,
I'm optimizing render response on a large view (takes over
3 secs to
render) and below you can see results of unsorted and
unfiltered
ELResolvers chain. The most important info is that
BeanELResolver
resolves property over 4x from 64000 invocations. The
second place
belongs to ImplicitObjectResolver with over 2 resolved
properties.
The reason why BeanElResolver is so successful is because
majority of
expressions looks like
{requestScope.pojoObject.propertyOne.propertyTwo}.
The obvious optimalization would be move the BeanELResolver
to top. But
you cannot: EL spec 2.2 javax.el.BeanELResolver: If the
property is not
found or is not readable, a PropertyNotFoundException is
thrown. So
UEL spec. mandates that BeanELResolver must be last one
which resolves
not-null base and a property on that base.
Do you know the reason for that? Do you have any ideas how
to move
BeanELResolver to top and avoid thousands of empty
geValue
invocations?
Thanks,
Kočičák
Results:
ImplicitObjectResolver:
getValue invocations: 64452 getValue hits: 21018
org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver:
getValue invocations: 64336 getValue hits: 30
org.richfaces.skin.SkinPropertiesELResolver
getValue invocations: 64306 getValue hits: 0
org.richfaces.resource.ResourceParameterELResolver
getValue invocations: 64306 getValue hits: 0
org.jboss.weld.environment.servlet.jsf.WeldApplication
$LazyBeanManagerIntegrationELResolver
getValue invocations: 64306 getValue hits: 975
org.apache.myfaces.el.unified.resolver.ManagedBeanResolver
getValue invocations: 63331 getValue hits: 0
org.apache.myfaces.el.unified.resolver.ResourceResolver
getValue invocations: 63331 getValue hits: 64
javax.el.ResourceBundleELResolver
getValue invocations: 63267 getValue hits: 3
org.apache.myfaces.el.unified.resolver.ResourceBundleResolver
getValue invocations: 63264 getValue hits: 3
javax.el.MapELResolver:
getValue invocations: 63261 getValue hits: 1069
javax.el.ListELResolver:
getValue invocations: 62192 getValue hits: 0
javax.el.ArrayELResolver:
getValue invocations: 62192 getValue hits: 0
javax.el.BeanELResolver:
getValue invocations: 62192 getValue hits: 40563
org.apache.myfaces.el.unified.resolver.ScopedAttributeResolver
getValue invocations: 21629 getValue hits: 582
Re: [core] performance: ELResolvers filtering
This approach cannot filter two resolvers: 1. org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver 2. org.apache.myfaces.el.unified.resolver.ScopedAttributeResolver 1) the first one is instance of CompositeELResolver and serves as container for sorted/filtered list of others ELResolvers. Currently does something for JSP, so I suggest to introduce: o.a.m.SUPPORT_JSP = true|false content-param as mentioned in original mail thread performance: disabling old technologies and if this false, myfaces will not install FacesCompositeELResolver, but plain javax.el.CompositeELResolver as parent. 2) org.apache.myfaces.el.unified.resolver.ScopedAttributeResolver is the last one in chain and always calls setPropertyResolved(true); (JSF 2.1: 5.6.2.9 ScopedAttribute ELResolver) and pick up anything stored in the request, viewScope, session, or application scopes by name. In strictly CDI-based application with no direct modification of servlet scopes or view scope this resolver will never resolve a property. What to do with this one I don't know. Possibly we can use ELResolver transforming :) org.apache.commons.collections.Transformer and allow replace one resolver with another, for example: o.a.m.el.unified.resolver.ScopedAttributeResolver - MyNotResovingResolverWhichCallsSetPropertyResolvedTrue el.ResourceBundleELResolver - SpringMessageSourceResolver (we don't use ResourceBundle) el.BeanELResolver - MemoryLeakFreeBeanELResolver Of course this functionality can be achieved by filtering out the unwanted resolver with predicate and adding own in faces-config (and sort it to proper position in chain) Regards, Kočičák Martin Koci píše v St 16. 03. 2011 v 11:29 +0100: Hi, after few months I have time to do some performance optimalization for myfaces. This one is related to topic http://www.mail-archive.com/dev@myfaces.apache.org/msg49177.html Problem: how to disable ELResolver smartly? Adding a context-param for each is an overkill. But we have https://cwiki.apache.org/MYFACES/elresolver-ordering.html in codebase already. I propose to add new feature ELResolver filtering and new context-param: context-param param-nameorg.apache.myfaces.EL_RESOLVER_PREDICATE/param-name param-valueorg.foo.bazz.ELResolverPredicate/param-value /context-param Filter is simple instance of org.apache.commons.collections.Predicate. For application where no ManagedBean(Resolver) is used or no Flash, user can simply return false from Predicate.evaluate and ELResolver won't be installed. WDYT? Regards, Kočičák
[core] performance: ELResolvers filtering
Hi, after few months I have time to do some performance optimalization for myfaces. This one is related to topic http://www.mail-archive.com/dev@myfaces.apache.org/msg49177.html Problem: how to disable ELResolver smartly? Adding a context-param for each is an overkill. But we have https://cwiki.apache.org/MYFACES/elresolver-ordering.html in codebase already. I propose to add new feature ELResolver filtering and new context-param: context-param param-nameorg.apache.myfaces.EL_RESOLVER_PREDICATE/param-name param-valueorg.foo.bazz.ELResolverPredicate/param-value /context-param Filter is simple instance of org.apache.commons.collections.Predicate. For application where no ManagedBean(Resolver) is used or no Flash, user can simply return false from Predicate.evaluate and ELResolver won't be installed. WDYT? Regards, Kočičák
Re: [core] performance: ELResolvers filtering
Hi, see https://issues.apache.org/jira/browse/MYFACES-3075 for first version of patch. @Mark, CDI/OWB manage scopes on their own, they don't use externalContext.getSessionMap(), applicationMap, .. is it true? If yes, then should be possible to disable org.apache.myfaces.el.unified.resolver.ScopedAttributeResolver ? This one is not in filtered list, because of code in: org.apache.myfaces.el.unified.ResolverBuilderForFaces.build(CompositeELResolver) // the ScopedAttributeResolver has to be the last one in every // case, because it always sets propertyResolved to true (per the spec) compositeElResolver.add(new ScopedAttributeResolver()); Regards, Kočičák Mark Struberg píše v St 16. 03. 2011 v 12:10 +: h hot ;) fat +1 Lets allow to switch off all that stuff which no one needs if running on a modern stack with facelets and CDI. LieGrue, strub --- On Wed, 3/16/11, Martin Koci martin.kocicak.k...@gmail.com wrote: From: Martin Koci martin.kocicak.k...@gmail.com Subject: [core] performance: ELResolvers filtering To: dev@myfaces.apache.org Date: Wednesday, March 16, 2011, 10:29 AM Hi, after few months I have time to do some performance optimalization for myfaces. This one is related to topic http://www.mail-archive.com/dev@myfaces.apache.org/msg49177.html Problem: how to disable ELResolver smartly? Adding a context-param for each is an overkill. But we have https://cwiki.apache.org/MYFACES/elresolver-ordering.html in codebase already. I propose to add new feature ELResolver filtering and new context-param: context-param param-nameorg.apache.myfaces.EL_RESOLVER_PREDICATE/param-name param-valueorg.foo.bazz.ELResolverPredicate/param-value /context-param Filter is simple instance of org.apache.commons.collections.Predicate. For application where no ManagedBean(Resolver) is used or no Flash, user can simply return false from Predicate.evaluate and ELResolver won't be installed. WDYT? Regards, Kočičák
Re: submittedValue vs. Converter.getAsObject
Hi, is there any progress in this area? As I can see, there was no official response to this problem at jsr-314-open. Should we create request for JSF 2.2? Full thread: http://www.mail-archive.com/dev@myfaces.apache.org/msg48796.html I found another scenario where generic Object - Object conversion is useful: rowKey concept. Many renderkits use rowKey (Object) as replacement of indices (int) (DataModel.getRowKey instead of DataModel.getRowIndex). But a elegant type responsible for Object - rowKey (Object) is not available now. In my use cases, I need two different conversion chains: 1) for non-String based client: Object (a @Entity mostly) - rowKey (Object) and back. 2) HTML client: Object (@Entity) - rowKey (Object) (serves as key in trinidad CollectionModel for example) and then rowKey (Object) - clientRowKey (String) for HTML. In the second case, responsible types are: A) javax.faces.convert.Converter : Object (@Entity) - clientRowKey (String) B) org.apache.myfaces.trinidad.render.ClientRowKeyManager: rowKey (Object) - clientRowKey (String) C) ... this is the missing Object - Object conversion type. type A) - Converter can delegate it's resposibility to chain of C)s and one B). WDYT? Kočičák Hi Ok, good to know that. Anyway, I think a full solution should something like the proposed solution. Let's see what happen, and if it is not included maybe we could include it on a project in myfaces (myfaces commons or tomahawk maybe). regards, Leonardo Uribe Martin Koci píše v Čt 23. 09. 2010 v 21:40 +0200: Hi, I've just read Leonardo's post at jsr-314-open about this problem. FYI: I have finished prototype of JSF server side solution with non-String communication. It's based on custom renderkit and ResponseWriter implementation. I found only one major problem: this one discussed in this mail thread. Minor thing is string-based naming and meaning of ResponseWriter methods, because ResponseWriter is an abstract class describing an adapter to an underlying output mechanism for *character*-based output (from javadoc), but fortunately all methods accept Object as value. Regards, Kočičák Leonardo Uribe píše v St 08. 09. 2010 v 10:34 -0500: Hi Martin 2010/9/8 Martin Marinschek mmarinsc...@apache.org Hi Leo, Yes, to solve the problem with t:inputCalendar and t:inputDate it was clear an interface like that was necessary but it is tied to java.util.Date in this case: We could open an issue to make this more generic - and have an infrastructure in the impl where we can register such converters. Then we could use them for such use-cases as we have, and also for Martin's use-cases. Ok, I'll check in deep what trinidad does and why and later I'll open an issue for this one on the jsf spec issue tracker. best regards, Leonardo best regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: [VOTE] Release of Extensions CDI (CODI) 0.9.3
+1 Regards, Martin Kočí Gerhard Petracek píše v Po 28. 02. 2011 v 14:22 +0100: Hi, I was running the needed tasks to get the 4th release of Apache MyFaces Extensions CDI (aka MyFaces CODI) out. The artifacts are deployed to Nexus [1] (and [2]). The release contains the following modules: - CODI Core - CODI JSF Module (for 1.2 and 2.0 and 2.1) - CODI JPA Module - CODI BV Module - CODI I18N-Message Module - CODI Scripting Module - CODI Trinidad Support Module - CODI Distribution Modules - CODI Examples Please take a look at the 0.9.3 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Gerhard [1] https://repository.apache.org/content/repositories/orgapachemyfaces-063 [2] https://repository.apache.org/content/repositories/orgapachemyfaces-063/org/apache/myfaces/extensions/cdi/myfaces-extcdi-parent/0.9.3/myfaces-extcdi-parent-0.9.3-source-release.zip [3] http://www.apache.org/foundation/voting.html#ReleaseVotes
Re: [VOTE] release for myfaces core 2.0.4
+1 Leonardo Uribe píše v St 09. 02. 2011 v 01:07 -0500: Hi, I was running the needed tasks to get the 2.0.4 release of Apache MyFaces core out. The artifacts passed all TCK tests. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.shared v4.0.5 [1] 2. Maven artifact group org.apache.myfaces.core v2.0.4 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Also the clirr test does not show binary incompatibilities with myfaces-api. Please take a look at the 2.0.4 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-044/org/apache/myfaces/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfaces204binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10600version=12316153
Re: [core] ajax @this with non trivial component
Hi Andy, thank you for explanation. Myfaces do only the first part: (1) This value will (or, well, should) be passed in as thefirst argument to jsf.ajax.request() but the second (2) and used as the replacement for @this targets. in not implemented yet: https://issues.apache.org/jira/browse/MYFACES-3018 Also if that situation occurs problem is not easy to find: https://issues.apache.org/jira/browse/MYFACES-3019 Regards, Martin Andy Schwartz píše v St 19. 01. 2011 v 08:56 -0500: Hi Martin - I was worried about this case as well when we were working on the Ajax/ClientBehavior APIs. Many Trinidad/ADF Faces components use similar markup to what you describe. To support this case, we added the ClientBehaviorContext.getSourceId() API: http://download.oracle.com/javaee/6/api/javax/faces/component/behavior/ClientBehaviorContext.html#getSourceId() This allows renderers that attach client behaviors to non-root DOM elements to explicitly specify the id that corresponds to the component. This value will (or, well, should) be passed in as the first argument to jsf.ajax.request() and used as the replacement for @this targets. Andy
[core] ajax @this with non trivial component
Hi,
if component is represented on client like:
span id=clientId
label id=clientId_label for=clientId_input a Label /label
input id=clientId_input onchange=jsf.ajax.request(...execute:
'@this' ...)
/span
what will be in HTTP reuqest? execute = clientId_input - but this is
only internal part of the component, not id of component on the server
so no component is executed.
What I need is :
input id=clientId_input onchange=jsf.ajax.request(...execute:
'cliendId' ...)
= clientId of component in execute. But if I use f:ajax like this:
mkk:mySuperComponent
f:ajax execute=@this /
/mkk:mySuperComponent
ajax behaviour renderer renders '@this' as pass thru value. What I
really need is:
if (@this.equals(executeItem)) {
executeItem = clientBehaviorContext.getComponent().getCliendId()
}
Similar for render attribute.
Spec. says: @this = The element that triggered the request. Thats very
unclear: specification uses 'element' word in two contexts: DOM element
and XHTML element.
Mojarra 2.0.3 renders '@this' as pass through too.
WDYT ?
Kočičák
Re: [core] Improve error reporting and logging
Hi, I will do it for Czech and Slovak: MYFACES-3014. Not very frequent languages, though - but 10 491 492 (CZ) + approx 5 mil (SK) inhabitants (samt Kindern und Rentnern) of Czech + Slovak Republic will appreciate it :) Werner Punz píše v Út 11. 01. 2011 v 15:13 +0100: Btw. I did some work in this area for the client. We now have localized ajax error messages, for now only english and german, anyone willing to step in for other languages? Werner Am 11.01.11 14:00, schrieb Martin Marinschek: I am always for better error reporting! best regards, Martin On 1/10/11, Jakob Korherrjakob.korh...@gmail.com wrote: Hi Kocicak, 1 Regards, Jakob 2011/1/10 Martin Kocimartin.kocicak.k...@gmail.com: Hi, the most wanted feature which our coders want is more consistent and human-readable error reporting and logging. Here is a example: If user specifies f:ajax without eventName for a component without defaultEventName, myfaces throw a execption: Now (myfaces 2.0.3): eventName could not be defined for f:ajax tag with no wrap mode. Improved (example only; from my copy of myfaces): MF0345: Your ajax tag does not specify eventName and component com.foo.Bazz does not provide the default one. Please use one from available: [change, blur, focus ...]; Tag location: XYZ.xhtml line 56 column 23,f:ajax . / Component: id: componentId, class: com.foo.BazzInput, component type: org.renderkit.Input ViewId: YYZ.xhml, located in file system as: /tmp/deploy/weabpp/XYZ.xhtml PhaseId: RENDER_RESPONSE Details: ... a detailed description of this problem + suggestions, example of code. References: # Click for problem MF0345 in MYFACES knowledge database (hypertext link) # Contact your technology team : m...@to.me # If you think this a bug report it: jira.project.org What do you think about this idea? (I'll describe our requirements and what I found so far in next emails) Regards, Kočičák -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [core] Improve error reporting and logging
Here are some requirements and additional description: -- identify every error with unique code: If error begins with unique prefix like MF or MYFACES, coder can at first sight recognize framework which is the source of that error/exception. For example Oracle DB throws ORA- or our company stuff throws AR- prefixed codes. Number after that prefix is unique identification of problem. Whole construct can serve as key for query (for bugzilla, WIKi, ...) or as simple abbreviation of the problem. Our programmers often say 999 happens instead of Unexpected failure of data happens :) -- text after error code: Should not only describe what is wrong but also how to solve it. -- details section: This section can contain detailed description of problem. It can have example of f:ajax eventName= /, hyperlink to javaDoc or VDL docs, or a notice that IDEs mostly don't auto-complete this attribute. In can look like overkill but those informations are required over and over again. Especially if I hear the same question like what is eventName and give me an example again (grrr) Of course all information can be found elsewhere but to ease development, every framework should be self-explanatory This section can by also collapsable as is the part for component tree already. -- localization: all human-readable text should be localizable because coders always read and think faster in their mother language. -- references section: links to bugzilla, mail etc. Should be configurable, for example I want provide link from error page to our internal bugzilla, not to myfaces JIRA. Similar case for email address. -- information about location of problem: If Facelets VDL is used it is obvious to provide tag, column and line. But we cannot limit it for facelets only. For example we have one project that uses pure Java API for View creation and very complex logic. Then if UIComponent.setId() throws new IllegalArgumentException(component identifier must not be a zero-length String), is very hard to find the cause, if debugging is not available. Here we can provide information about parent and path to component, phase id etc. Kočičák Werner Punz píše v Út 11. 01. 2011 v 15:12 +0100: ++1 Werner Am 10.01.11 20:06, schrieb Martin Koci: Hi, the most wanted feature which our coders want is more consistent and human-readable error reporting and logging. Here is a example: If user specifies f:ajax without eventName for a component without defaultEventName, myfaces throw a execption: Now (myfaces 2.0.3): eventName could not be defined for f:ajax tag with no wrap mode. Improved (example only; from my copy of myfaces): MF0345: Your ajax tag does not specify eventName and component com.foo.Bazz does not provide the default one. Please use one from available: [change, blur, focus ...]; Tag location: XYZ.xhtml line 56 column 23,f:ajax . / Component: id: componentId, class: com.foo.BazzInput, component type: org.renderkit.Input ViewId: YYZ.xhml, located in file system as: /tmp/deploy/weabpp/XYZ.xhtml PhaseId: RENDER_RESPONSE Details: ... a detailed description of this problem + suggestions, example of code. References: # Click for problem MF0345 in MYFACES knowledge database (hypertext link) # Contact your technology team : m...@to.me # If you think this a bug report it: jira.project.org What do you think about this idea? (I'll describe our requirements and what I found so far in next emails) Regards, Kočičák
[core] Improve error reporting and logging
Hi, the most wanted feature which our coders want is more consistent and human-readable error reporting and logging. Here is a example: If user specifies f:ajax without eventName for a component without defaultEventName, myfaces throw a execption: Now (myfaces 2.0.3): eventName could not be defined for f:ajax tag with no wrap mode. Improved (example only; from my copy of myfaces): MF0345: Your ajax tag does not specify eventName and component com.foo.Bazz does not provide the default one. Please use one from available: [change, blur, focus ...]; Tag location: XYZ.xhtml line 56 column 23, f:ajax . / Component: id: componentId, class: com.foo.BazzInput, component type: org.renderkit.Input ViewId: YYZ.xhml, located in file system as: /tmp/deploy/weabpp/XYZ.xhtml PhaseId: RENDER_RESPONSE Details: ... a detailed description of this problem + suggestions, example of code. References: # Click for problem MF0345 in MYFACES knowledge database (hypertext link) # Contact your technology team : m...@to.me # If you think this a bug report it: jira.project.org What do you think about this idea? (I'll describe our requirements and what I found so far in next emails) Regards, Kočičák
[core] UISelectItem(s) questions
Hi, following things are specified by spec, but maybe someone will know reasons: 1) why UISelectOne/Many classes don't have method like ListSelectItem getSelectItems currently each renderkit has own method with similar purpose but with different quality and bugs :) for example, myfaces have RendererUtils.getSelectItemList(UISelectMany, FacesContext) which outputs warning if f:selectItems value= leads to null, but RichFaces throw an uninformative exception in same situation. For user's view it is inconsistent behaviour. 2) similar question: why UISelectItem/UISelectItems dont have getSelectItem() resp. getSelectItems() method for creating selections they represent? 3) why UISelectItem has method like getItemLabel(), getItemDescription(), but UISelectItems not - it uses only attributes map. Regards, Kočičák
[test] testNG and EL impl in myfaces-test
Hi, two questions: 1) 12 test cases in myfaces-api and myfaces-impl use @Test from org.testng.annotations, 56 test cases use @org.junit.Test. What is the primary test engine for myfaces? I'm trying to provide patch for MYFACES-2882 and UIViewRootTest uses TestNG: how to use org.apache.myfaces.test.base.junit4.AbstractJsfTestCase there? 2) myfaces-test has mock-implementation of expression language API. Is it possible to use real EL implementation instead? Problem: MockExpressionFactory.coerceToType has no Enum support yet; use of very EL implementation makes tests closer to real usage of myfaces. Regards, Kočičák
Re: EL method invocation performance
Hi,
hi martin,
it would be nice to get more details about the juel issues.
Christian fixed them promptly in JUEL's svn:
http://sourceforge.net/tracker/?func=detailaid=3095122group_id=165179atid=834616
http://sourceforge.net/tracker/?func=detailaid=3031783group_id=165179atid=834616
Back to original topic: JUEL caches the ExpressionFactory instance and
thus does not have discussed performance problem.
regards,
gerhard
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/10/19 Martin Koci martin.kocicak.k...@gmail.com
Hi,
some news about EL method invocations:
1) Geronimo EL API implementation has this problem too:
https://issues.apache.org/jira/browse/GERONIMO-5657
2) UEL bug is still open:
https://uel.dev.java.net/issues/show_bug.cgi?id=19
3) JUEL doesn't not work for my test cases, for example it
doesn't find
some public methods so I cannot say if JUEL has this problem
now.
My today's recommedation (which can change tommorow) is: if
you want EL
method invocations without file asscess within
(without /META-INF/services reading):
A) apply GERONIMO-5657 patch to
http://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-el_2.2_spec/
and build this EL-API
B) use impl part from uel.dev.java.net as EL-impl or tomcat's
EL impl
Please note that uel.dev.java.net API suffers from classic
leaking
classloader problem too - it uses Class instance as key in
static Map :
see MYFACES-2942 for details. Maybe we should put a warning
about these
two issues at http://wiki.apache.org/myfaces/HowToEnableEl22 ?
Regards,
Kocicak
Martin Koci píše v St 25. 08. 2010 v 20:52 +0200:
Hi,
I'll try it but not today :) Optimization is my priority
task for next
few months and certainly I'll compare all four (or more?) EL
implementations.
Mark Struberg píše v St 25. 08. 2010 v 17:52 +:
Martin, could you please give juel a quick try? Would be
interested if if also
suffers from this problem.
You can find a slightly tweaked (bugfixed) version of it
on my github page
http://github.com/struberg/juel
The original is on juel.sourceforge.net
LieGrue,
strub
From: Jakob Korherr jakob.korh...@gmail.com
To: MyFaces Development dev@myfaces.apache.org
Sent: Wed, August 25, 2010 5:10:09 PM
Subject: Re: EL method invocation performance
Hi,
Does this really have to happen at every method
invocation or is this an
implementation problem?
If it is an implementation problem and can be circumvent
in any way, I would
contact the Glassfish and Tomcat developers about this ;)
Regards,
Jakob
2010/8/25 Ivan xhh...@gmail.com
How about trying the el api published by Geronimo ? it
caches the
ExpressionFactory to avoid the search action by default.
2010/8/25 Martin Koci martin.k...@aura.cz
Hi,
this problem is not in myfaces but affects performance
especially in
render response phase:
EL 2.2 introduces method invocation but if you try use
it like
rendered=#{bean.getRendered(param)} there is an
unpleasant surprise:
both implementations of BeanELResolver (Glassfish,
Tomcat) use this
construction during method invocation:
ExpressionFactory exprFactory =
ExpressionFactory.newInstance();
That newInstance() always involves FactoryFinder
mechanism, callstack
then looks like :
org.apache.catalina.loader.WebappClassLoader.findResourceInternal
org.apache.catalina.loader.WebappClassLoader.findResource
org.apache.catalina.loader.WebappClassLoader.getResourceAsStream
javax.el.FactoryFinder.find(String, String,
Properties)
javax.el.ExpressionFactory.newInstance(Properties)
javax.el.ExpressionFactory.newInstance
Re: [core] performance: TagAttributeImpl part II: object allocations
Leonardo Uribe píše v Čt 21. 10. 2010 v 20:31 -0500:
Hi
I investigate more if it is possible and unfortunately it is not as
default. ValueExpressions
instances are immutable, but when
ExpressionFactory.createValueExpression is called,
this method uses FunctionMapper and VariableMapper provided by
FaceletContext.
The problem is there is no way to detect if a ValueExpression was
constructed using
FunctionMapper or VariableMapper, and facelets uses them a lot.
But in most cases, FunctionMapper and VariableMapper passed by
facelets does not change,
that means, no new variables of functions are added while facelet is
processing the same page
over and over. So cache them with a optional parameter (default false)
could work.
Yes, especially if view declaration doesn't use build time tags like
c:if, c:choose or some kind of direct manipulation of component
tree/ELContext - then variable mapping should be same for each request.
EL specification directly says that: Expressions are also designed to
be immutable so that only one instance needs to be created for any given
expression String / FunctionMapper. This allows a container to
pre-create expressions and not have to reparse them each time they are
evaluated so the only problem here is really the variable mapping.
Yes, we should test that possible optimization well.
regards,
Leonardo Uribe
2010/10/21 Jakob Korherr jakob.korh...@gmail.com
Looks promising, but are they really considered immutable? If
we do
this change, we should test special scenarios with all
available EL
impls (GlassFish, Tomcat, Geronimo, JUEL) first, because the
behavior
might differ from impl to impl..
Regards,
Jakob
2010/10/22 Leonardo Uribe lu4...@gmail.com:
Hi
In theory it is possible to cache ValueExpression creation
at
TagAttributeImpl level, because ValueExpression instances
are
immutable classes (once initialized does not change its
state)
and Serializable.
Just add a simple variable there could do the job. Just add
a variable
and fill it when getValueExpression(FaceletContext, Class)
or
getMethodExpression(FaceletContext, Class, Class[]) is being
called. If two different threads fill this value at the same
time
it will no matter, because both are the same.
It is a hack very similar to
CompositeComponentDefinitionTagHandler._cachedBeanInfo:
/**
* Cached instance used by this component. Note here we
have a
* racy single-check.If this field is used, it is
supposed
* the object cached by this handler is immutable, and
this is
* granted if all properties not saved as
ValueExpression are
* literal.
**/
What do you think guys?
regards,
Leonardo Uribe
2010/10/21 Jakob Korherr jakob.korh...@gmail.com
Hi Martin,
Yes, I totally agree. This is really a big performance
problem.
The main problem here is that we have no real control about
the
creation of the ValueExpressions, because the EL
implementation
provides them for us, thus the wrapper approach.
The first wrapper, TagValueExpression, (which is actually
used for
every facelet attribute ValueExpression, right?) might not
really be
necessary, I guess. The class comes directly from the
facelets-codebase, so we actually don't know why it was
introduced. I
haven't looked at it yet, but I don't think it has any
further sence.
Maybe we can get rid of this wrapper...
The second wrapper is a must, otherwise composite component
EL
expressions (#{cc}) won't work as expected, because the
resolution
mechanism has to use the composite component from the xhtml
site on
which the ValueExpression is defined. However, those
ValueExpressions
are not used that much, I guess.
Suggestions are welcome!
Regards,
Jakob
2010/10/21 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
another performance related problem in TagAttributeImpl:
ValueExpression
instances.
Consider a facelets view with 3000 attributes. Then
during buildView
method TagAttributeImpl.getValueExpression allocates:
1) one instance
[core] performance: TagAttributeImpl part II: object allocations
Hi, another performance related problem in TagAttributeImpl: ValueExpression instances. Consider a facelets view with 3000 attributes. Then during buildView method TagAttributeImpl.getValueExpression allocates: 1) one instance of ValueExpression via ExpressionFactory.createValueExpression 2) one instance of ValueExpression as TagValueExpression 3) if TagAttribute is inside composite component then allocates another instance of LocationValueExpression. In this test case buildView creates at least 6 000 instances of ValueExpression. This is not problem because instances are cheap and allocation doesn't affect CPU consumption. Problem appears if more threads do the same: for 100 threads/requests it is 600 000 instances; consider it for 1000 concurrent requests. All those instances are very short-lived and practically never leave HotSpot's Young Generation space and triggers GC excessively; GC management it the main problem : after one hour of running stress test is TagAttributeImpl.getValueExpression #1 in hot spot by object count with millions of allocations. At first sight allocations 2) and 3) serves only as a kind of TagAttribute - ValueExpression mapping. Specially the second one holds only one String which serves later for a nicer exception report. It seems that some better kind of TagAttribute - ValueExpression - (String, Localtion) relation reprezentation without using wrapper pattern can solve this problem. Any ideas how to do it? Regards, Kočičák
[core] performance: TagAttributeImpl and composite component EL detection
Hi,
a issue to consider in
org.apache.myfaces.view.facelets.tag.TagAttributeImpl:
Methods
TagAttributeImpl.getMethodExpression and
TagAttributeImpl.getValueExpression use
CompositeComponentELUtils.isCompositeComponentXYZ methods to detect if
current #{} contains cc expression. But consider following: if user
migrates from facelets 1.2 to 2.0, this new cc detection slows down
build view process. In one my test case VDL.buildView calls
CompositeComponentELUtils.isCompositeComponentXYZ approx 3000 times per
build view with no match. isCompositeComponentXYZ is not cheap method
because it uses Pattern.matches().
Are there possibilities to avoid this? For example is possible have some
kind of isProcessingCompositeComponent method and skip
Pattern.matches() if false? We are in VDL.buildView here and no
components are available yet, no use of methods like
UIComponent.isCompositeComponent(UIComponent) is possible.
Any ideas?
Regards,
Kočičák
Re: [core] performance: TagAttributeImpl and composite component EL detection
hehe, I was writing something similar: in production stage
TagAttributeImpl is only created once and then facelets cache mechanism
keep this instance alive as part of Facelet memory structure. Thus if
user did request to all Facelet instances (all *xhtml) in JSF
application, it creates forest of Facelet instances, Facelet instances
are trees, those trees have nodes (Tag instances) with leafs =
TagAttribute instances. It this is true and if I remember well graph
theory long time ago at university, each TagAttribute instance is unique
and there exists only on path to it -
why is ValueExpression evaluated new on every request?
In short (I must go home now ...) : ValueExpression can differ in
expected type and facelets context. But can those values be really
diffirent for same TagAttribute instance? If they are always same can ve
cache ValueExpression instance forever?
Leonardo Uribe píše v St 20. 10. 2010 v 15:45 -0500:
Hi
I have an idea: why don't evaluate that condition on construction
time?
In that case, EL will be scanned only once (when the Facelet or
Abstract Syntax Tree (AST) is build) and
not when the view is build, like is happening now.
I have created an issue
https://issues.apache.org/jira/browse/MYFACES-2951
and committed the code in trunk.
Suggestions are welcome.
Leonardo Uribe
2010/10/20 Jakob Korherr jakob.korh...@gmail.com
Hi Kočičák,
There might be some ways to improve this, but we have to be
very
careful in making changes to that area, because the whole
composite
components + EL domain is not that easy.
Actually the CompositeComponentELUtils.isCompositeComponentXYZ
methods
were introduced by myself when fixing the #{cc} issues we
encountered
in some MyFaces 2 alpha versions. Unfortunately I currently
don't
really have time to think about improvements here, sorry. But
I really
think that there is some room for improvements!
Also I really like your idea of
isProcessingCompositeComponent. This
might be a good way, because if this is false we can skip the
#{cc}
check, because such expressions will certainly not occur
outside of a
composite component. If you have some spare time, a patch
would be
really great :) :) - otherwise please just open a JIRA issue
for this
one so that we don't loose sight of it. Thanks!
Regards,
Jakob
2010/10/20 Werner Punz werner.p...@gmail.com:
Just my 2c without looking into the code, but I assume speed
improvements
already can be gained by replacing the pattern matches, if
possible with a
direct ll comparison.
Regexps often are heavier than simple parsing or string
operations.
Another thing might be that we add some caching mechanism on
this level
which caches per request if possible. But I have not looked
into the code,
so I am making wild assumptions here.
I assume also that some speed still can be gained in this
area by better
utilization of the improved tree walking api jsf2 provides.
Werner
Am 20.10.10 15:54, schrieb Martin Koci:
Hi,
a issue to consider in
org.apache.myfaces.view.facelets.tag.TagAttributeImpl:
Methods
TagAttributeImpl.getMethodExpression and
TagAttributeImpl.getValueExpression use
CompositeComponentELUtils.isCompositeComponentXYZ methods
to detect if
current #{} contains cc expression. But consider following:
if user
migrates from facelets 1.2 to 2.0, this new cc detection
slows down
build view process. In one my test case VDL.buildView calls
CompositeComponentELUtils.isCompositeComponentXYZ approx
3000 times per
build view with no match. isCompositeComponentXYZ is not
cheap method
because it uses Pattern.matches().
Are there possibilities to avoid this? For example is
possible have some
kind of isProcessingCompositeComponent method and skip
Pattern.matches() if false? We are in VDL.buildView here
and no
components are available yet, no use of methods like
UIComponent.isCompositeComponent(UIComponent) is possible.
Any ideas?
Regards,
Kočičák
Re: EL method invocation performance
Hi,
some news about EL method invocations:
1) Geronimo EL API implementation has this problem too:
https://issues.apache.org/jira/browse/GERONIMO-5657
2) UEL bug is still open:
https://uel.dev.java.net/issues/show_bug.cgi?id=19
3) JUEL doesn't not work for my test cases, for example it doesn't find
some public methods so I cannot say if JUEL has this problem now.
My today's recommedation (which can change tommorow) is: if you want EL
method invocations without file asscess within
(without /META-INF/services reading):
A) apply GERONIMO-5657 patch to
http://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-el_2.2_spec/ and
build this EL-API
B) use impl part from uel.dev.java.net as EL-impl or tomcat's EL impl
Please note that uel.dev.java.net API suffers from classic leaking
classloader problem too - it uses Class instance as key in static Map :
see MYFACES-2942 for details. Maybe we should put a warning about these
two issues at http://wiki.apache.org/myfaces/HowToEnableEl22 ?
Regards,
Kocicak
Martin Koci píše v St 25. 08. 2010 v 20:52 +0200:
Hi,
I'll try it but not today :) Optimization is my priority task for next
few months and certainly I'll compare all four (or more?) EL
implementations.
Mark Struberg píše v St 25. 08. 2010 v 17:52 +:
Martin, could you please give juel a quick try? Would be interested if if
also
suffers from this problem.
You can find a slightly tweaked (bugfixed) version of it on my github page
http://github.com/struberg/juel
The original is on juel.sourceforge.net
LieGrue,
strub
From: Jakob Korherr jakob.korh...@gmail.com
To: MyFaces Development dev@myfaces.apache.org
Sent: Wed, August 25, 2010 5:10:09 PM
Subject: Re: EL method invocation performance
Hi,
Does this really have to happen at every method invocation or is this an
implementation problem?
If it is an implementation problem and can be circumvent in any way, I
would
contact the Glassfish and Tomcat developers about this ;)
Regards,
Jakob
2010/8/25 Ivan xhh...@gmail.com
How about trying the el api published by Geronimo ? it caches the
ExpressionFactory to avoid the search action by default.
2010/8/25 Martin Koci martin.k...@aura.cz
Hi,
this problem is not in myfaces but affects performance especially in
render response phase:
EL 2.2 introduces method invocation but if you try use it like
rendered=#{bean.getRendered(param)} there is an unpleasant surprise:
both implementations of BeanELResolver (Glassfish, Tomcat) use this
construction during method invocation:
ExpressionFactory exprFactory = ExpressionFactory.newInstance();
That newInstance() always involves FactoryFinder mechanism, callstack
then looks like :
org.apache.catalina.loader.WebappClassLoader.findResourceInternal
org.apache.catalina.loader.WebappClassLoader.findResource
org.apache.catalina.loader.WebappClassLoader.getResourceAsStream
javax.el.FactoryFinder.find(String, String, Properties)
javax.el.ExpressionFactory.newInstance(Properties)
javax.el.ExpressionFactory.newInstance()
javax.el.BeanELResolver.invokeMethod(Method, Object, Object[])
Always tries to locale factory implementation, that
means /META-INF/services reading! This is not problem in myfaces, but
users don't distinguish between JSF and EL well.
Any ideas?
Regards,
Martin Kočí
https://uel.dev.java.net/svn/uel/trunk/api/src/main/java/javax/el/BeanELResolver.java
http://svn.apache.org/viewvc/tomcat/trunk/java/javax/el/BeanELResolver.java
--
Ivan
--
Jakob Korherr
blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at
Re: Myfaces vs. mojarra restore view performance
Hi,
Leonardo, can you please review :
https://issues.apache.org/jira/browse/MYFACES-2922
https://issues.apache.org/jira/browse/MYFACES-2862
and apply them if they are suitable?
Thanks,
Kočičák
Martin Koci píše v Út 14. 09. 2010 v 23:05 +0200:
Hi,
please review https://issues.apache.org/jira/browse/MYFACES-2922 and
apply if possible.
Thanks,
Kočičák
Leonardo Uribe píše v Pá 06. 08. 2010 v 13:07 -0500:
Hi
2010/8/6 Martin Koci martin.k...@aura.cz
Hi,
is it possible to cache inspected classes in
RequestViewContext? I did
something like that:
if (isProduction !
requestViewContext.isAlreadyInspected(inspectedClass)) {
_handleListenerForAnnotations(context, inspected,
inspectedClass, component, isProduction);
_handleResourceDependencyAnnotations(context,
inspectedClass, component, isProduction);
requestViewContext.setAsProcessed(inspectedClass);
}
in _handleAnnotations and it reduces restore view time to
30-40 ms.
It is necessary to apply @ListenerFor annotations on every component
that has registered
it in the view. The reason why we can cache @ResourceDependency is
this annotation
cause a component resource to be added, and that one will be always
the same.
regards,
Leonardo
regards,
Martin Kočí
Leonardo Uribe píše v Čt 05. 08. 2010 v 15:56 -0500:
Hi
Ok, good to know that. I closed MYFACES-2854. Maybe on
MYFACES-2862 we
can use FacesContext.isProjectStage(ProjectStage).
regards,
Leonardo
2010/8/5 Martin Koci martin.k...@aura.cz
Hi,
success!
myfaces + MYFACES-2854-2.patch + MYFACES-2862 = ~ 70
ms in
restore view
phase. It was *750 ms* before.
Thanks,
Martin Kočí
Leonardo Uribe píše v St 04. 08. 2010 v 22:09 -0500:
Hi
I implemented a proposal for this one on
MYFACES-2854-2.patch using
the suggestion
proposed (do not apply ResourceDependency if it
was already
processed). I hope that
patch solve the problem.
regards,
Leonardo
[core] FacesEL vs. UEL vs. UEL 2.2
Hi, there is a disorder in Expression Lauguage names in myfaces core. Currently myfaces (method javax.faces.validator._ExternalSpecifications.isUnifiedELAvailable() for example) output a log: MyFaces Unified EL support enabled But this is a little misleading: there should be Unified EL 2.2 support enabled because it tests presence of EL 2.2. Unified EL support enabled does not make sence at all because JSF use Unified EL as core technology and that cannot be disabled. There are three major versions of ELs: 1) javax.faces.el - old and depreceated 2) javax.el 2.0, 2.1 (from JSP 2.0, 2.1) 3) javax.el 2.2 from JSP 2.2, part of Java EE 6, EL with method invocations Suggestions: Rename isUnifiedELAvailable to isUnifiedEL22Available, TagValueExpressionUEL to TagValueExpressionUEL22 and so on. For EL 2.3 (not released yet) we can add similar methods/classes. Change log to MyFaces Unified EL 2.2 support enabled (method invocations are available). I'll add similiar log MyFaces Faces EL (javax.faces.el) support disabled as part of disabling old technologies WDYT ? Kočičák
[core] performance: disabling old technologies
Hi, since JSF 2.0 JSP support and managed-bean are deprecated. Since 1.2 same for javax.faces.el. For performace reasons I suggest find a way how disable following: 1) Managed Bean support (o.a.m.SUPPORT_MANAGED_BEANS=false) if this flag is false, myfaces will not install ManagedBeanResolver and will skip managed beans processing during startup (or outputs a warning if managed bean is found and this flag is false). 2) VariableResolver and PropertyResolver (o.a.m.SUPPORT_JAVAX_FACES_EL=false) myfaces will not install VariableResolverImpl and VariableResolverToELResolver and PropertyResolver implementations 3) (o.a.m.SUPPORT_JSP=false) if this flag is false myfaces will not install FacesCompositeELResolver and will skip JSP initializer during startup. FacesCompositeELResolver is related to VariableResolverImpl, maybe this can be one paramater. Those are only suggestions. I did some initial profiling and when old technogies are disabled myfaces gain significant performance boost, especially in render response phase. Another solution for ELResolvers only is use of comparator but this does not allow skip certain parts of code. WDYT? Kočičák
Re: submittedValue vs. Converter.getAsObject
Hi, I've just read Leonardo's post at jsr-314-open about this problem. FYI: I have finished prototype of JSF server side solution with non-String communication. It's based on custom renderkit and ResponseWriter implementation. I found only one major problem: this one discussed in this mail thread. Minor thing is string-based naming and meaning of ResponseWriter methods, because ResponseWriter is an abstract class describing an adapter to an underlying output mechanism for *character*-based output (from javadoc), but fortunately all methods accept Object as value. Regards, Kočičák Leonardo Uribe píše v St 08. 09. 2010 v 10:34 -0500: Hi Martin 2010/9/8 Martin Marinschek mmarinsc...@apache.org Hi Leo, Yes, to solve the problem with t:inputCalendar and t:inputDate it was clear an interface like that was necessary but it is tied to java.util.Date in this case: We could open an issue to make this more generic - and have an infrastructure in the impl where we can register such converters. Then we could use them for such use-cases as we have, and also for Martin's use-cases. Ok, I'll check in deep what trinidad does and why and later I'll open an issue for this one on the jsf spec issue tracker. best regards, Leonardo best regards, Martin -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
