[jira] [Created] (MYFACES-3815) Lazy instantiation of Renderer classes
Leonardo Uribe created MYFACES-3815: --- Summary: Lazy instantiation of Renderer classes Key: MYFACES-3815 URL: https://issues.apache.org/jira/browse/MYFACES-3815 Project: MyFaces Core Issue Type: Improvement Components: JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe The initialization algorithm create all Renderer instances at startup time. The side effect is a lot of classes are loaded into permgen memory without need. With a clever trick we can avoid that, providing a custom interfaces LazyRenderKit and making html basic renderkit implements it. Then, in the init code we check for that interface and if is present, we use it to register the Renderer in a lazy way, otherwise we use the standard form. Add the required method to RenderKit looks like a good idea for include it in the spec. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3814) Allow ServiceProviderFinder to be initialized at startup
[ https://issues.apache.org/jira/browse/MYFACES-3814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13811368#comment-13811368 ] Leonardo Uribe commented on MYFACES-3814: - I changed the name of the issue, because put that information in FacesConfig does not work very well. The reason is SPI lookup needs to be setup before config code. The idea is add two methods: public Map> calculateKnownServiceProviderMapInfo(ExternalContext ectx, String[] knownServices) public void initKnownServiceProviderMapInfo(ExternalContext ectx, Map> map) At startup, MyFaces calls calculateKnownServiceProviderMapInfo and provide the list of known services used by ServiceProviderFinder. By default it returns null, but the idea is custom implementations can provide the logic that scan the classpath and find the configuration. If the configuration has been serialized somewhere the idea is put there the code that restore that information. Then MyFaces will call initKnownServiceProviderMapInfo and it will pass the map, so the default implementation can grab the map and use it into its logic. > Allow ServiceProviderFinder to be initialized at startup > > > Key: MYFACES-3814 > URL: https://issues.apache.org/jira/browse/MYFACES-3814 > Project: MyFaces Core > Issue Type: Task > Components: JSR-344 >Reporter: Leonardo Uribe >Assignee: Leonardo Uribe > > The code inside ServiceProviderFinder usually involves classpath scanning and > read files from different locations. That code is ok, but it would be great > if we can put that into FacesConfig as a configuration information. > The idea is just list all SPI interfaces we are using in MyFaces Core, and do > the scanning of everything we need right at startup and finally store that > information into FacesConfig, just like it was done for Facelet tag lib > configuration. > If FacesConfig is serialized and deserialized, that scanning will not be > necessary and the startup will be faster. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (MYFACES-3804) Use the same key in server side state saving for ajax requests
[ https://issues.apache.org/jira/browse/MYFACES-3804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13811223#comment-13811223 ] Dora Rajappan commented on MYFACES-3804: Also for for web configuration below the fix is good. javax.faces.STATE_SAVING_METHOD client > Use the same key in server side state saving for ajax requests > -- > > Key: MYFACES-3804 > URL: https://issues.apache.org/jira/browse/MYFACES-3804 > Project: MyFaces Core > Issue Type: Improvement > Components: JSR-344 >Reporter: Leonardo Uribe > Attachments: ajaxviewkey.patch > > > The current code for server side state saving creates one key per request to > store the view state. This is ok, but it is not necessary for ajax requests. > The reason why is not necessary is because you can never go back to a page > when using ajax. If you are on page A and the current request is an ajax > request and it returns to the same page and the view is the same that the one > that has been restored, the key or the token sent does not need to change, > what changes is the internal state of the view. From the client side the page > is the same. We can take advantage of this fact and just update the state > stored in SerializedViewCollection for the view. > The challenge here is detect when this strategy is applicable. For example, > what happen if there is an ajax redirect? It looks is a good idea for > implement in 2.2, because it avoids to store unnecessary information into > session and optimize the use of each view slot. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (TOBAGO-1332) SplitLayout
[ https://issues.apache.org/jira/browse/TOBAGO-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13811216#comment-13811216 ] Hudson commented on TOBAGO-1332: FAILURE: Integrated in tobago-trunk #1151 (See [https://builds.apache.org/job/tobago-trunk/1151/]) TOBAGO-1332 - SplitLayout: respect minimal sizes of inner components, iframe problem (weber: http://svn.apache.org/viewvc/?view=rev&rev=1537890) * /myfaces/tobago/trunk/tobago-extension/tobago-sandbox/src/main/java/org/apache/myfaces/tobago/internal/component/AbstractUISplitLayout.java * /myfaces/tobago/trunk/tobago-extension/tobago-sandbox/src/main/java/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/tag/SplitLayoutRenderer.java * /myfaces/tobago/trunk/tobago-extension/tobago-sandbox/src/main/resources/META-INF/tobago-config.xml * /myfaces/tobago/trunk/tobago-extension/tobago-sandbox/src/main/resources/org/apache/myfaces/tobago/sandbox/html/scarborough/standard/script/tobago.js > SplitLayout > --- > > Key: TOBAGO-1332 > URL: https://issues.apache.org/jira/browse/TOBAGO-1332 > Project: MyFaces Tobago > Issue Type: New Feature > Components: Sandbox, Themes >Reporter: Volker Weber >Assignee: Volker Weber > > Implement a LayoutManager to allow Client-Side resizing like in Swings > SplitPane -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: [jira] [Updated] (MYFACES-3804) Use the same key in server side state saving for ajax requests
unsubscribe 2013/11/1 Dora Rajappan (JIRA) > > [ > https://issues.apache.org/jira/browse/MYFACES-3804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] > > Dora Rajappan updated MYFACES-3804: > --- > > Status: Patch Available (was: Open) > > > Use the same key in server side state saving for ajax requests > > -- > > > > Key: MYFACES-3804 > > URL: https://issues.apache.org/jira/browse/MYFACES-3804 > > Project: MyFaces Core > > Issue Type: Improvement > > Components: JSR-344 > >Reporter: Leonardo Uribe > > > > The current code for server side state saving creates one key per > request to store the view state. This is ok, but it is not necessary for > ajax requests. > > The reason why is not necessary is because you can never go back to a > page when using ajax. If you are on page A and the current request is an > ajax request and it returns to the same page and the view is the same that > the one that has been restored, the key or the token sent does not need to > change, what changes is the internal state of the view. From the client > side the page is the same. We can take advantage of this fact and just > update the state stored in SerializedViewCollection for the view. > > The challenge here is detect when this strategy is applicable. For > example, what happen if there is an ajax redirect? It looks is a good idea > for implement in 2.2, because it avoids to store unnecessary information > into session and optimize the use of each view slot. > > > > -- > This message was sent by Atlassian JIRA > (v6.1#6144) > -- *Flavio Magacho* [image: cid:image001.gif@01C940F0.871FB2A0] Gerênte de Desenvolvimento Diretoria de Tecnologia da Informação +55 (21) 2546-4050 ▪ Ramal: 4082 +55 (21) 98889-1572 *O conteúdo desta mensagem é confidencial e pode ser privilegiado. **É vedada a sua cópia ou divulgação.* *The contents of this message are confidential and may be privileged. Copying or disclosing is prohibited.*
[jira] [Updated] (MYFACES-3804) Use the same key in server side state saving for ajax requests
[ https://issues.apache.org/jira/browse/MYFACES-3804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dora Rajappan updated MYFACES-3804: --- Status: Patch Available (was: Open) > Use the same key in server side state saving for ajax requests > -- > > Key: MYFACES-3804 > URL: https://issues.apache.org/jira/browse/MYFACES-3804 > Project: MyFaces Core > Issue Type: Improvement > Components: JSR-344 >Reporter: Leonardo Uribe > > The current code for server side state saving creates one key per request to > store the view state. This is ok, but it is not necessary for ajax requests. > The reason why is not necessary is because you can never go back to a page > when using ajax. If you are on page A and the current request is an ajax > request and it returns to the same page and the view is the same that the one > that has been restored, the key or the token sent does not need to change, > what changes is the internal state of the view. From the client side the page > is the same. We can take advantage of this fact and just update the state > stored in SerializedViewCollection for the view. > The challenge here is detect when this strategy is applicable. For example, > what happen if there is an ajax redirect? It looks is a good idea for > implement in 2.2, because it avoids to store unnecessary information into > session and optimize the use of each view slot. -- This message was sent by Atlassian JIRA (v6.1#6144)
unsubscribe
unsubscribe -- *Flavio Magacho* [image: cid:image001.gif@01C940F0.871FB2A0] Gerênte de Desenvolvimento Diretoria de Tecnologia da Informação +55 (21) 2546-4050 ▪ Ramal: 4082 +55 (21) 98889-1572 *O conteúdo desta mensagem é confidencial e pode ser privilegiado. **É vedada a sua cópia ou divulgação.* *The contents of this message are confidential and may be privileged. Copying or disclosing is prohibited.*
