[jira] [Created] (TOBAGO-1083) Improve extendability of LabelRenderer
Improve extendability of LabelRenderer -- Key: TOBAGO-1083 URL: https://issues.apache.org/jira/browse/TOBAGO-1083 Project: MyFaces Tobago Issue Type: Improvement Components: Themes Affects Versions: 1.5.2 Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Priority: Minor The rendering of the content text of a label should be in a protected method, so it is easier to write an own renderer based to that one of Scarborough. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TOBAGO-950) tc:link still occupies some space, when rendered is set to false
[ https://issues.apache.org/jira/browse/TOBAGO-950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13193743#comment-13193743 ] Dom W. commented on TOBAGO-950: --- This issue prevails in the recent 1.0.38 version (and Firefox 9.0.1). Could anyone please have a look at it? When looking at the generated HTML source code, I can see that there are tr-tags created for the hidden tc:links: trtd style=width: 283px; class=tobago-gridLayout-cell-tddiv style=width: 283px; class=tobago-gridLayout-default tobago-gridLayout-first-column/div/td/tr Happy to hear about any comments ... tc:link still occupies some space, when rendered is set to false -- Key: TOBAGO-950 URL: https://issues.apache.org/jira/browse/TOBAGO-950 Project: MyFaces Tobago Issue Type: Bug Affects Versions: 1.0.31 Environment: Firefox 3.6.12, Ubuntu 10.04 64bit Reporter: Dom W. Priority: Minor Attachments: tc-link-rendered.png Even though the rendered attribute is set to false, the tc:link is not fully hidden, i.e. it still uses up some space (a few pixels) . This creates additional empty space, which gets more and more apparent, the more hidden links you have. Example code: tc:panel f:facet name=layout tc:gridLayout rows=fixed;fixed;fixed;fixed;fixed;fixed;fixed;*/ /f:facet tc:label value=tc:link rendered/ tc:link label=Test 1 rendered=false / tc:link label=Test 2 rendered=false / tc:link label=Test 3 rendered=false / tc:link label=Test 4 rendered=true / tc:link label=Test 5 rendered=false / tc:link label=Test 6 rendered=false / tc:link label=Test 7 rendered=true / tc:link label=Test 8 rendered=true / /tc:panel Expected result: There should be as much space between the tc:label and the first visible tc:link, and also between tc:link 4 and 7, as there is between tc:link 7 and 8. Actual result: There is a big gap between the tc:label and the first visible tc:link, and also between tc:link 4 and 7. Please also see the attached image. Greetings, dom -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3452) Log managed bean creation in LifecycleProvider instances with finest level
Log managed bean creation in LifecycleProvider instances with finest level -- Key: MYFACES-3452 URL: https://issues.apache.org/jira/browse/MYFACES-3452 Project: MyFaces Core Issue Type: Improvement Reporter: Leonardo Uribe Assignee: Leonardo Uribe Priority: Trivial TomcatAnnotationLifecycleProvider and Tomcat7AnnotationLifecycleProvider log all managed bean creation with info level, filling the log with unnecessary data. It is better to log such informantion if the level is finest (or trace in commons-logging). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MYFACES-3452) Log managed bean creation in LifecycleProvider instances with finest level
[ https://issues.apache.org/jira/browse/MYFACES-3452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3452. - Resolution: Fixed Fix Version/s: 2.1.6 2.0.12 Log managed bean creation in LifecycleProvider instances with finest level -- Key: MYFACES-3452 URL: https://issues.apache.org/jira/browse/MYFACES-3452 Project: MyFaces Core Issue Type: Improvement Reporter: Leonardo Uribe Assignee: Leonardo Uribe Priority: Trivial Fix For: 2.0.12, 2.1.6 TomcatAnnotationLifecycleProvider and Tomcat7AnnotationLifecycleProvider log all managed bean creation with info level, filling the log with unnecessary data. It is better to log such informantion if the level is finest (or trace in commons-logging). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MYFACES-3451) [core] Improve PSS algorithm when a dynamic view (use of c:if or ui:include src=#{...}) is used
[
https://issues.apache.org/jira/browse/MYFACES-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe updated MYFACES-3451:
Resolution: Fixed
Fix Version/s: 2.1.6
2.0.12
Status: Resolved (was: Patch Available)
[core] Improve PSS algorithm when a dynamic view (use of c:if or ui:include
src=#{...}) is used
---
Key: MYFACES-3451
URL: https://issues.apache.org/jira/browse/MYFACES-3451
Project: MyFaces Core
Issue Type: Improvement
Components: JSR-314
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
Fix For: 2.0.12, 2.1.6
Attachments: MYFACES-3451-1.patch
Implement change according to mail sent about it to dev list under the name:
[core] Improve PSS algorithm when a dynamic view (use of c:if or ui:include
src=#{...}) is used
In the last months I have been working on a solution to improve Partial State
Saving (PSS) performance in cases where the view is updated dynamically by
effect of a facelet tags like:
- c:if ...
- c:when
- ui:include src=#{...}
- ui:decorate template=#{...}
In simple words, any use of the previous tags in a page causes all components
inside them to be saved and restored fully. The side effect is the overall
state gets bigger. With the introduction of PSS in JSF 2.0, instead save an
array of properties, a key/value pairs are used, so usually this effect is
difficult to notice, but it is relevant specially when ui:include
src=#{...} is used to update content dynamically. It is quite simple to
find examples with a search engine on the internet.
I'll explain in detail what's going on.
Let's see what happen when c:if is used:
c:if test=#{condition}
h:outputText value=Some text/
/c:if
The first time the view is rendered, if the condition is false, the component
is not added, but later in a postback if the condition changes from false to
true, the component is added. Here the algorithm have two options:
1. Ignore it.
2. Mark the component or branch to be restored fully.
Most of the time ignore (1) is ok, but in some complex cases the state synch
is lost, because test=#{condition} is evaluated every time the view is
restored, with different results. The users usually have reported this as
state get lost or ClassCastException problems. To deal with such cases, a
special mode was added in MyFaces to implement (2) with a web config param
called org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS.
But what happen if the algorithm save c:if condition the first time the
view is rendered? With that, PSS algorithm will always restore the initial
view as expected. Recently in 2.0.10 / 2.1.4, this improvement (MYFACES-3329)
was added so it is no longer necessary to enable the web config param. Great!
But note this does not solve the state gets bigger problem.
Now consider what happen if c:if condition is saved every time it change
(before render response). If the condition is false and changes to true, the
initial state will now be restored including the
component, so if it is called markInitialState() over the component, and then
the delta is saved, the state size will be smaller and finally it will be
saved more efficently, because the initial state is the one who gets bigger,
instead the part that is saved as delta.
This solution can be applied to c:if ..., c:when, ui:include
src=#{...} and ui:decorate template=#{...}, which is enough because
c:forEach can be replaced with h:dataTable rowStatePreserved=true ... or
a similar component like the ones available in Tomahawk or any other variant.
It is interesting to note the solution also fix the problem when h:dataTable
rowStatePreserved=true ... is used inside a dynamic part.
Fortunately, the spec doesn't say anything about how markInitialState() is
called, and let it as an implementation detail. Also,
javax.faces.IS_BUILDING_INITIAL_STATE description is so general that even
with the change there is no need to change the javadoc. After considering all
history behind PSS algorithm, it seems reasonable to activate
markInitialState() call and set javax.faces.IS_BUILDING_INITIAL_STATE to true
when a dynamic update in a component tree is done by a facelet tag, and
deactivate it as soon as the code process the content.
At the end, applications using the previous tags will have a really huge
improvement into its state. But anyway, since it is a extension of the
initial intention of the flag, I consider desirable to mention it. It is
difficult to measure the impact, because it depends of the view structure
itself, but it sounds like a very promising change.
Suggestions, opinions and what you do want to say about this
[jira] [Updated] (MYFACES-3432) [perf] [mem] UIViewRoot.saveState(FacesContext) unnecessary saves empty view scope
[
https://issues.apache.org/jira/browse/MYFACES-3432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe updated MYFACES-3432:
Resolution: Fixed
Fix Version/s: 2.1.6-SNAPSHOT
2.0.12
Status: Resolved (was: Patch Available)
Thanks to Martin Koci for provide this patch.
[perf] [mem] UIViewRoot.saveState(FacesContext) unnecessary saves empty view
scope
--
Key: MYFACES-3432
URL: https://issues.apache.org/jira/browse/MYFACES-3432
Project: MyFaces Core
Issue Type: Improvement
Components: General
Affects Versions: 2.1.6-SNAPSHOT
Environment: myfaces core trunk
Reporter: Martin Kočí
Assignee: Martin Kočí
Priority: Trivial
Fix For: 2.0.12, 2.1.6-SNAPSHOT
Attachments: MYFACES-3432.patch
z.B.
#{viewScope['myfaces'] == null}
initializes empty view scope map at UIViewRoot and method saveState saves
this empty map with an extra ArrayList instance
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3435) [perf] _DeltaList: use ArrayList as parent
[ https://issues.apache.org/jira/browse/MYFACES-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13193903#comment-13193903 ] Leonardo Uribe commented on MYFACES-3435: - After study this issue, the problem about extend from ArrayList is it force us to implement all methods, because we can't assume the parent is implemented in some specific way. Things are different for classes extending AbstractList, because the contract specify that it is just required to implementing some methods. I did a draft for _ComponentChildrenList but I would like to think this change more carefully. My first impression is sometimes performance improvements can ruin you code and make it difficult to read. Is it worth to do it? suggestions are welcome. [perf] _DeltaList: use ArrayList as parent -- Key: MYFACES-3435 URL: https://issues.apache.org/jira/browse/MYFACES-3435 Project: MyFaces Core Issue Type: Improvement Components: General Affects Versions: 2.0.12-SNAPSHOT, 2.1.6-SNAPSHOT Reporter: Martin Kočí Assignee: Martin Kočí Priority: Minor Attachments: MYFACES-3435.patch, _ComponentChildrenList2.java Two internal classes _DeltaList in API: 1) now use delegation pattern, but are always initialized with an ArrayList instance - use inheritance and ArrayList as parent - improvement in memory area, reduces number of GCed object in one request/response of (_DeltaList instances/2) 2) initialize expected size of _DeltaList (for example, number of validators per one component is perhaps never 10, use: new _DeltaList(5)) 3) use indexes in 'for' instead of iterator (java.util.RandomAccess) - improvement in performance -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MYFACES-3418) [perf] do not check for duplicate ids when saving view on production stage
[ https://issues.apache.org/jira/browse/MYFACES-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated MYFACES-3418: Resolution: Fixed Fix Version/s: 2.1.6 2.0.12 Status: Resolved (was: Patch Available) [perf] do not check for duplicate ids when saving view on production stage -- Key: MYFACES-3418 URL: https://issues.apache.org/jira/browse/MYFACES-3418 Project: MyFaces Core Issue Type: New Feature Environment: myfaces trunk Reporter: Martin Kočí Assignee: Martin Kočí Priority: Minor Fix For: 2.0.12, 2.1.6 Attachments: MYFACES-3418-alternative-1.patch, MYFACES-3418-final-1.patch, MYFACES-3418.patch see discussion here: http://www.mail-archive.com/dev@myfaces.apache.org/msg52995.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MYFACES-3433) PhaseListenerManager throws NPE if pre-phase action was unsuccessful
[ https://issues.apache.org/jira/browse/MYFACES-3433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated MYFACES-3433: Resolution: Fixed Fix Version/s: 2.1.6 2.0.12 Status: Resolved (was: Patch Available) Thanks to Martin Koci for provide this patch PhaseListenerManager throws NPE if pre-phase action was unsuccessful Key: MYFACES-3433 URL: https://issues.apache.org/jira/browse/MYFACES-3433 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.0.12-SNAPSHOT, 2.1.6-SNAPSHOT Reporter: Martin Kočí Assignee: Martin Kočí Priority: Minor Fix For: 2.0.12, 2.1.6 Attachments: MYFACES-3433.patch NPE at line 103 in PhaseListenerManager.informPhaseListenersAfter: if( beforePhaseSuccess[i]) can occur if LifecycleImpl.executePhase was unsuccessful and didn't call phaseListenerMgr.informPhaseListenersBefore(currentPhaseId) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3453) CLONE - org.apache.myfaces.shared.resource. ResourceImpl: PushbackInputStream delegate is not closed
CLONE - org.apache.myfaces.shared.resource. ResourceImpl: PushbackInputStream
delegate is not closed
Key: MYFACES-3453
URL: https://issues.apache.org/jira/browse/MYFACES-3453
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.0.0-beta-3, 2.0.11, 2.1.0, 2.1.5
Environment: WebSphere v7.0.19 on Linux (Red Hat)
Reporter: Seppo Sutinen
ALL VERSIONS.
PushbackInputStream delegate is not closed, so we get too many open files on
Linux -platform.
Our Total File Descriptors For System is 8000.
PushbackInputStream delegate is used when reading stylesheet files (.css -files
text/css -content type).
Used in JSF2 h:outputStylesheet/ -tag.
ADD Stream closing...
private class ValueExpressionFilterInputStream extends InputStream
{
...
/**
* PushbackInputStream delegate MUST BE CLOSED or you will get too
many open files on Linux-platform
*/
@Override
public void close( ) throws IOException {
delegate.close();
//System.out.println( EYECATCHER. + getClass(
).getSimpleName( ) + .close called );
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MFCOMMONS-46) CLONE - org.apache.myfaces.shared.resource. ResourceImpl: PushbackInputStream delegate is not closed
[
https://issues.apache.org/jira/browse/MFCOMMONS-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved MFCOMMONS-46.
-
Resolution: Fixed
Fix Version/s: 1.0.2.1
Assignee: Leonardo Uribe
CLONE - org.apache.myfaces.shared.resource. ResourceImpl: PushbackInputStream
delegate is not closed
Key: MFCOMMONS-46
URL: https://issues.apache.org/jira/browse/MFCOMMONS-46
Project: MyFaces Commons
Issue Type: Bug
Components: myfaces-commons-resourcehandler
Environment: WebSphere v7.0.19 on Linux (Red Hat)
Reporter: Seppo Sutinen
Assignee: Leonardo Uribe
Fix For: 1.0.2.1
Original Estimate: 1m
Remaining Estimate: 1m
ALL VERSIONS.
PushbackInputStream delegate is not closed, so we get too many open files
on Linux -platform.
Our Total File Descriptors For System is 8000.
PushbackInputStream delegate is used when reading stylesheet files (.css
-files text/css -content type).
Used in JSF2 h:outputStylesheet/ -tag.
ADD Stream closing...
private class ValueExpressionFilterInputStream extends InputStream
{
...
/**
* PushbackInputStream delegate MUST BE CLOSED or you will get too
many open files on Linux-platform
*/
@Override
public void close( ) throws IOException {
delegate.close();
//System.out.println( EYECATCHER. + getClass(
).getSimpleName( ) + .close called );
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MYFACES-3430) org.apache.myfaces.shared.resource. ResourceImpl: PushbackInputStream delegate is not closed
[
https://issues.apache.org/jira/browse/MYFACES-3430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe resolved MYFACES-3430.
-
Resolution: Fixed
Fix Version/s: 2.1.6
2.0.12
Assignee: Leonardo Uribe
Thanks to Seppo Sutinen for provide this patch
org.apache.myfaces.shared.resource. ResourceImpl: PushbackInputStream
delegate is not closed
Key: MYFACES-3430
URL: https://issues.apache.org/jira/browse/MYFACES-3430
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.0.0-beta-3, 2.0.11, 2.1.0, 2.1.5
Environment: WebSphere v7.0.19 on Linux (Red Hat)
Reporter: Seppo Sutinen
Assignee: Leonardo Uribe
Fix For: 2.0.12, 2.1.6
Original Estimate: 1m
Remaining Estimate: 1m
ALL VERSIONS.
PushbackInputStream delegate is not closed, so we get too many open files
on Linux -platform.
Our Total File Descriptors For System is 8000.
PushbackInputStream delegate is used when reading stylesheet files (.css
-files text/css -content type).
Used in JSF2 h:outputStylesheet/ -tag.
ADD Stream closing...
private class ValueExpressionFilterInputStream extends InputStream
{
...
/**
* PushbackInputStream delegate MUST BE CLOSED or you will get too
many open files on Linux-platform
*/
@Override
public void close( ) throws IOException {
delegate.close();
//System.out.println( EYECATCHER. + getClass(
).getSimpleName( ) + .close called );
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MYFACES-3424) call popComponentFromEL from right instance when broadcast
[ https://issues.apache.org/jira/browse/MYFACES-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3424. - Resolution: Fixed Fix Version/s: 2.1.6 2.0.12 call popComponentFromEL from right instance when broadcast -- Key: MYFACES-3424 URL: https://issues.apache.org/jira/browse/MYFACES-3424 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Priority: Trivial Fix For: 2.0.12, 2.1.6 Checking MYFACES-3423 I notice some methods that invoke broadcast doesn't call popComponentFromEL on the right instance. Fortunately this does not cause any problem at all, but it is better to be strict in this part and call push/pop in the right sequence. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3438) jsf.js: error handling output improvement
[ https://issues.apache.org/jira/browse/MYFACES-3438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13193946#comment-13193946 ] Keith Wong commented on MYFACES-3438: - Will the translation be accepted? jsf.js: error handling output improvement - Key: MYFACES-3438 URL: https://issues.apache.org/jira/browse/MYFACES-3438 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.0.12-SNAPSHOT, 2.1.6-SNAPSHOT Reporter: Werner Punz Assignee: Werner Punz Priority: Minor Fix For: 2.0.12-SNAPSHOT, 2.1.6-SNAPSHOT Attachments: myfaces-1229093.patch While we already have improved the error reporting a lot. We still have room for improvement. For instance the error alert could need some room for improvement, we should also report the faulty http codes in case of a http error etc... Also we should discuss whether we really should use the alert if there is a console present. (would make more sense to push error reports into the console on newer browsers if present) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3435) [perf] _DeltaList: use ArrayList as parent
[
https://issues.apache.org/jira/browse/MYFACES-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13193948#comment-13193948
]
Martin Kočí commented on MYFACES-3435:
--
because we can't assume the parent is implemented in some specific way ...
I don't understand that fully: current code uses delegation pattern with
ArrayList : it already assumes, that ArrayList implements methods in fashion we
need. But I agree, that delegation pattern is elegant, but inheritance is
sometimes worth too.
Ad performance improvement: small if views are small and concurrency low. But
consider this example:
a view with 500 component + 500 concurrent request:
500 component=
with for example 200 leafs = 300 ComponentChildrenList instances + 300
ArrayList instances
200 leafs (for example UIInput with a validator): 200 _DeltaList instances +
200 ArrayList instances
= 1000 instances
1000 x 500 concurrent request = 500 000 instances, very short lived, normally
under 500 ms. Those instances come only from VLD.buildView pseudo phase and
represent very short lived memory representation of components tree (other part
of code like state saving produce other amount of short lived instances)
Garbage collector must for each instance compute if it is GCable or not (or
something like that) : it takes very small time in modern JVM but this time is
noticeable if the amout of object is enormous.
Then, if user will perform a simple ajax request/response in such view with 500
components like:
h:inputText value=#{someBean}
f:ajax render=@this execute=@this /
takes the garbage collecting more time that the render response phase. Yes, it
depends on GC algorithm and normally does not block the http request/response
thread. I tested it on HotSpot from JVM 6.0.30 with all server-side suitable
GCs and with JRockit 4.1 Generational Parallel Mark Sweep.
But this issue is clearly not very important right now: the performace gain is
not so big as in other improvement which I'm going to propose (as String's id
caching in ComponentTagHandler or isRenderedSet() method)
[perf] _DeltaList: use ArrayList as parent
--
Key: MYFACES-3435
URL: https://issues.apache.org/jira/browse/MYFACES-3435
Project: MyFaces Core
Issue Type: Improvement
Components: General
Affects Versions: 2.0.12-SNAPSHOT, 2.1.6-SNAPSHOT
Reporter: Martin Kočí
Assignee: Martin Kočí
Priority: Minor
Attachments: MYFACES-3435.patch, _ComponentChildrenList2.java
Two internal classes _DeltaList in API:
1) now use delegation pattern, but are always initialized with an ArrayList
instance - use inheritance and ArrayList as parent - improvement in memory
area, reduces number of GCed object in one request/response of (_DeltaList
instances/2)
2) initialize expected size of _DeltaList (for example, number of validators
per one component is perhaps never 10, use: new _DeltaList(5))
3) use indexes in 'for' instead of iterator (java.util.RandomAccess) -
improvement in performance
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3435) [perf] _DeltaList: use ArrayList as parent
[ https://issues.apache.org/jira/browse/MYFACES-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13194003#comment-13194003 ] Leonardo Uribe commented on MYFACES-3435: - Ok, let's let this change for the next release cycle. Note a change in that part needs to be checked fully to prevent introduce bugs. [perf] _DeltaList: use ArrayList as parent -- Key: MYFACES-3435 URL: https://issues.apache.org/jira/browse/MYFACES-3435 Project: MyFaces Core Issue Type: Improvement Components: General Affects Versions: 2.0.12-SNAPSHOT, 2.1.6-SNAPSHOT Reporter: Martin Kočí Assignee: Martin Kočí Priority: Minor Attachments: MYFACES-3435.patch, _ComponentChildrenList2.java Two internal classes _DeltaList in API: 1) now use delegation pattern, but are always initialized with an ArrayList instance - use inheritance and ArrayList as parent - improvement in memory area, reduces number of GCed object in one request/response of (_DeltaList instances/2) 2) initialize expected size of _DeltaList (for example, number of validators per one component is perhaps never 10, use: new _DeltaList(5)) 3) use indexes in 'for' instead of iterator (java.util.RandomAccess) - improvement in performance -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Commented] (MYFACES-3438) jsf.js: error handling output improvement
Hi Keith of course ist will but given that I am currently in the hospital it will take until the weekend unless someone else does it. Werner Von meinem iPad gesendet Am 26. Jän 2555 BE um 17:32 schrieb Keith Wong (Commented) (JIRA) dev@myfaces.apache.org: [ https://issues.apache.org/jira/browse/MYFACES-3438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13193946#comment-13193946 ] Keith Wong commented on MYFACES-3438: - Will the translation be accepted? jsf.js: error handling output improvement - Key: MYFACES-3438 URL: https://issues.apache.org/jira/browse/MYFACES-3438 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.0.12-SNAPSHOT, 2.1.6-SNAPSHOT Reporter: Werner Punz Assignee: Werner Punz Priority: Minor Fix For: 2.0.12-SNAPSHOT, 2.1.6-SNAPSHOT Attachments: myfaces-1229093.patch While we already have improved the error reporting a lot. We still have room for improvement. For instance the error alert could need some room for improvement, we should also report the faulty http codes in case of a http error etc... Also we should discuss whether we really should use the alert if there is a console present. (would make more sense to push error reports into the console on newer browsers if present) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Commented] (MYFACES-3438) jsf.js: error handling output improvement
Hi Ok, I have committed the patch. Thanks for the hint. regards, Leonardo Uribe 2012/1/26 Werner Punz werner.p...@gmail.com Hi Keith of course ist will but given that I am currently in the hospital it will take until the weekend unless someone else does it. Werner Von meinem iPad gesendet Am 26. Jän 2555 BE um 17:32 schrieb Keith Wong (Commented) (JIRA) dev@myfaces.apache.org: [ https://issues.apache.org/jira/browse/MYFACES-3438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13193946#comment-13193946] Keith Wong commented on MYFACES-3438: - Will the translation be accepted? jsf.js: error handling output improvement - Key: MYFACES-3438 URL: https://issues.apache.org/jira/browse/MYFACES-3438 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.0.12-SNAPSHOT, 2.1.6-SNAPSHOT Reporter: Werner Punz Assignee: Werner Punz Priority: Minor Fix For: 2.0.12-SNAPSHOT, 2.1.6-SNAPSHOT Attachments: myfaces-1229093.patch While we already have improved the error reporting a lot. We still have room for improvement. For instance the error alert could need some room for improvement, we should also report the faulty http codes in case of a http error etc... Also we should discuss whether we really should use the alert if there is a console present. (would make more sense to push error reports into the console on newer browsers if present) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3438) jsf.js: error handling output improvement
[ https://issues.apache.org/jira/browse/MYFACES-3438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13194123#comment-13194123 ] Leonardo Uribe commented on MYFACES-3438: - Translation committed on 2.1.x and 2.0.x branches jsf.js: error handling output improvement - Key: MYFACES-3438 URL: https://issues.apache.org/jira/browse/MYFACES-3438 Project: MyFaces Core Issue Type: Improvement Affects Versions: 2.0.12-SNAPSHOT, 2.1.6-SNAPSHOT Reporter: Werner Punz Assignee: Werner Punz Priority: Minor Fix For: 2.0.12-SNAPSHOT, 2.1.6-SNAPSHOT Attachments: myfaces-1229093.patch While we already have improved the error reporting a lot. We still have room for improvement. For instance the error alert could need some room for improvement, we should also report the faulty http codes in case of a http error etc... Also we should discuss whether we really should use the alert if there is a console present. (would make more sense to push error reports into the console on newer browsers if present) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2209) Provide ChangeManager APIs to remove and restore changes to components in a subtree
Provide ChangeManager APIs to remove and restore changes to components in a subtree --- Key: TRINIDAD-2209 URL: https://issues.apache.org/jira/browse/TRINIDAD-2209 Project: MyFaces Trinidad Issue Type: Improvement Components: Components, Infrastructure Affects Versions: 2.0.2-core Environment: n/a Reporter: Prakash Udupa There are frequent changes to attributes of components due to end user interaction. For example the 'displayIndex' value of a custom 'column' component changes whenever user reorders the column in a table. SessionChangeManager records such changes on certain attributes of certain components and restores it as 'preference' / 'personalization' for that user for future 'GET' requests on the page. While this is generally desirable, it sometimes could interfere with expectations of other components. For example a custom 'query' component may choose to allow users to save keyed by a 'name' the 'search criteria', and then additionally the 'layout' of the results area, which most likely is a table. The changes on the table (or any other component on results area) that the SessionChangeManager frequently saves and restores interferes with the component's feature to save and restore the layout of the results area / table. We need some ChangeManager API to reduce this interference. This proposal is to add APIs to ChangeManager that components can call to: 1. Remove the ChangeManager changes for the result area subtree when it switches to a saved search that includes layout. 2. Add back the ChangeManager changes for the result area subtree when user switches to a saved search that does not include a layout. Specifically proposing the following new APIs (two public methods) on ChangeManager class: /** * Removes all changes that the ChangeManager holds for components in a subtree. * Note that the ChangeManager would still continue to record any new changes on the * components in the subtree. * @param subTreeRoot The UIComponent that is the root of the component subtree for which the *changes are to be removed. Note that if the viewroot is suplied, the *changes for the entire view are removed. * @return Object a Serializable Object of all the component changes for the subtree that was *just removed. This value can be passed back to *restoreComponentChangesForSubtree() to restore the changes. */ public Object removeComponentChangesForSubtree(FacesContext context, UIComponent subTreeRoot) /** * Restores the component changes to the ChangeManager for components in a subtree. * Before adding the changes, if there are existing changes to the subtree it will be removed. * @param changes The Serializable Object of the component changes as returned by *removeComponentChangesForSubtree() */ public void restoreComponentChangesForSubtree(FacesContext context, Object changes) These methods will be implemented in SessionChangeManager, and will be a no-op in the document based ChangeManager implementations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
