[JBoss JIRA] (RF-12619) @ViewScoped (CDI-managed) beans lost with a4j:command* and dynamic form
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-12619?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč edited comment on RF-12619 at 12/7/12 10:03 AM:
-----------------------------------------------------------
Hey Fab, I can confirm that this issue will be resolved by RF-12442.
Could you please try with latest snapshots ({{4.3.0-SNAPSHOT}}) and let us know?
was (Author: lfryc):
Hey Fab, I can confirm that this issue will be resolved by RF-12442.
Could you please try with latest snapshots ({{4.3.0-SNAPSHOT}} and let us know?
> @ViewScoped (CDI-managed) beans lost with a4j:command* and dynamic form
> -----------------------------------------------------------------------
>
> Key: RF-12619
> URL: https://issues.jboss.org/browse/RF-12619
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core
> Affects Versions: 4.3.0.M2
> Environment: Windows, JDK 1.7.0_09, Glassfish 3.1.2.2 with Mojarra 2.1.14 (at least >= 2.1.8), RF 4.3.0 M2 (also on RF 4.2.x), Weld 1.1.8 and SeamFaces 3.1.0.
> Reporter: Fab Mars
> Assignee: Lukáš Fryč
> Labels: a4j:commandbutton, cdi, facelets, seamfaces, viewscoped
> Attachments: TestViewScope.zip
>
>
> Here is a weird case I found after updating a project of mine from JSF 1.2 & RF 3.x to JSF 2.1 and RF 4.2.3/4.3.0M2. See attached project.
> On a part of the page which is into a Facelets insert, I can click on a <a4j:commandButton/> to trigger the creation of some entity instance and dynamically display another form associated to that entity in another part of the page. So, there are 2 forms on the screen, one for the creation button, another one to edit the entity, both are always displayed but the content of the latter isn't rendered until the entity exists. The page actions are held by some backing bean which also contains the form.
> From the second form, I can submit the entity once updated. The buttons are <h:commandButton/> this time and the action returns null so I can stay on the same view and keep on working.
> Back with RF 3.x, I used the keepAlive tag to maintain the page's backing bean along the page life. All worked fine. After JSF 2.1 and RF 4 and CDI were released, I intended on using @ViewScoped instead. Naturally I had to add SeamFaces so my @ViewScoped beans were actually CDI-managed, and I updated my whole codebase.
> Well, now, when the a4j creation button is used, the form dynamically displays all right BUT when I try to submit the second form, my @ViewScoped bean vanishes (pbly the viewMap vanishes entirely).
> However, if I use <h:commandButton><f:ajax/></h:commandButton> for the creation instead, everything works fine. Which leads me to believe there is a bug/regression from RF3.3 on a4j:command* components (maybe a4j:ajax/a4j:poll, didn't check) when used in a full CDI environment.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (RF-12619) @ViewScoped (CDI-managed) beans lost with a4j:command* and dynamic form
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-12619?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč updated RF-12619:
----------------------------
Labels: a4j:commandbutton cdi facelets seamfaces viewscoped waiting_on_user (was: a4j:commandbutton cdi facelets seamfaces viewscoped)
> @ViewScoped (CDI-managed) beans lost with a4j:command* and dynamic form
> -----------------------------------------------------------------------
>
> Key: RF-12619
> URL: https://issues.jboss.org/browse/RF-12619
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core
> Affects Versions: 4.3.0.M2
> Environment: Windows, JDK 1.7.0_09, Glassfish 3.1.2.2 with Mojarra 2.1.14 (at least >= 2.1.8), RF 4.3.0 M2 (also on RF 4.2.x), Weld 1.1.8 and SeamFaces 3.1.0.
> Reporter: Fab Mars
> Assignee: Lukáš Fryč
> Labels: a4j:commandbutton, cdi, facelets, seamfaces, viewscoped, waiting_on_user
> Attachments: TestViewScope.zip
>
>
> Here is a weird case I found after updating a project of mine from JSF 1.2 & RF 3.x to JSF 2.1 and RF 4.2.3/4.3.0M2. See attached project.
> On a part of the page which is into a Facelets insert, I can click on a <a4j:commandButton/> to trigger the creation of some entity instance and dynamically display another form associated to that entity in another part of the page. So, there are 2 forms on the screen, one for the creation button, another one to edit the entity, both are always displayed but the content of the latter isn't rendered until the entity exists. The page actions are held by some backing bean which also contains the form.
> From the second form, I can submit the entity once updated. The buttons are <h:commandButton/> this time and the action returns null so I can stay on the same view and keep on working.
> Back with RF 3.x, I used the keepAlive tag to maintain the page's backing bean along the page life. All worked fine. After JSF 2.1 and RF 4 and CDI were released, I intended on using @ViewScoped instead. Naturally I had to add SeamFaces so my @ViewScoped beans were actually CDI-managed, and I updated my whole codebase.
> Well, now, when the a4j creation button is used, the form dynamically displays all right BUT when I try to submit the second form, my @ViewScoped bean vanishes (pbly the viewMap vanishes entirely).
> However, if I use <h:commandButton><f:ajax/></h:commandButton> for the creation instead, everything works fine. Which leads me to believe there is a bug/regression from RF3.3 on a4j:command* components (maybe a4j:ajax/a4j:poll, didn't check) when used in a full CDI environment.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (RF-12619) @ViewScoped (CDI-managed) beans lost with a4j:command* and dynamic form
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-12619?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on RF-12619:
---------------------------------
Hey Fab, I can confirm that this issue will be resolved by RF-12442.
Could you please try with latest snapshots ({{4.3.0-SNAPSHOT}} and let us know?
> @ViewScoped (CDI-managed) beans lost with a4j:command* and dynamic form
> -----------------------------------------------------------------------
>
> Key: RF-12619
> URL: https://issues.jboss.org/browse/RF-12619
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core
> Affects Versions: 4.3.0.M2
> Environment: Windows, JDK 1.7.0_09, Glassfish 3.1.2.2 with Mojarra 2.1.14 (at least >= 2.1.8), RF 4.3.0 M2 (also on RF 4.2.x), Weld 1.1.8 and SeamFaces 3.1.0.
> Reporter: Fab Mars
> Assignee: Lukáš Fryč
> Labels: a4j:commandbutton, cdi, facelets, seamfaces, viewscoped
> Attachments: TestViewScope.zip
>
>
> Here is a weird case I found after updating a project of mine from JSF 1.2 & RF 3.x to JSF 2.1 and RF 4.2.3/4.3.0M2. See attached project.
> On a part of the page which is into a Facelets insert, I can click on a <a4j:commandButton/> to trigger the creation of some entity instance and dynamically display another form associated to that entity in another part of the page. So, there are 2 forms on the screen, one for the creation button, another one to edit the entity, both are always displayed but the content of the latter isn't rendered until the entity exists. The page actions are held by some backing bean which also contains the form.
> From the second form, I can submit the entity once updated. The buttons are <h:commandButton/> this time and the action returns null so I can stay on the same view and keep on working.
> Back with RF 3.x, I used the keepAlive tag to maintain the page's backing bean along the page life. All worked fine. After JSF 2.1 and RF 4 and CDI were released, I intended on using @ViewScoped instead. Naturally I had to add SeamFaces so my @ViewScoped beans were actually CDI-managed, and I updated my whole codebase.
> Well, now, when the a4j creation button is used, the form dynamically displays all right BUT when I try to submit the second form, my @ViewScoped bean vanishes (pbly the viewMap vanishes entirely).
> However, if I use <h:commandButton><f:ajax/></h:commandButton> for the creation instead, everything works fine. Which leads me to believe there is a bug/regression from RF3.3 on a4j:command* components (maybe a4j:ajax/a4j:poll, didn't check) when used in a full CDI environment.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (RF-12637) Zip exception when deploying RichFaces app with JSF 2.2 to JBoss AS 7.2
by Pavol Pitonak (JIRA)
[ https://issues.jboss.org/browse/RF-12637?page=com.atlassian.jira.plugin.s... ]
Pavol Pitonak commented on RF-12637:
------------------------------------
Hi Stan,
I build JBoss AS myself with your patch from AS7-6089 and created module for Mojarra 2.2.0-SNAPSHOT (because RF don't work with 2.2.0-m06) but then I saw an exception during the deployment. This can be solved by adding mojarra slot to all Weld modules as described in https://community.jboss.org/message/748354#748354
> Zip exception when deploying RichFaces app with JSF 2.2 to JBoss AS 7.2
> -----------------------------------------------------------------------
>
> Key: RF-12637
> URL: https://issues.jboss.org/browse/RF-12637
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: compatibility
> Affects Versions: 4.3.0.M2
> Environment: JBoss AS 7.2.0.Alpha1-SNAPSHOT (from 3 Dec 2012)
> Mojarra 2.2.0-SNAPSHOT (after 2.2.0-m06)
> RichFaces 4.3.0-SNAPSHOT
> Reporter: Pavol Pitonak
> Assignee: Stan Silvert
> Labels: jsf22
> Attachments: jsf22.zip
>
>
> # extract jsf22.zip
> # open directory and build project with {{mvn clean package -Prelease}}
> # download latest JBoss AS 7.2.0.Alpha1 from https://ci.jboss.org/jenkins/job/JBoss-AS-7.x-latest/
> # add Mojarra 2.2.0-SNAPSHOT to JBoss AS as described in https://community.jboss.org/wiki/DesignOfAS7Multi-JSFFeature
> # deploy jsf22-jee6.war
> result:
> {quote}
> 15:49:31,425 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015876: Starting deployment of "jsf22-jee6.war"
> 15:49:32,644 WARN [org.jboss.weld.deployer] (MSC service thread 1-3) JBAS016012: Deployment deployment "jsf22-jee6.war" contains CDI annotations but beans.xml was not found.
> 15:49:32,681 INFO [org.jboss.web] (ServerService Thread Pool -- 10) JBAS018210: Register web context: /jsf22-jee6
> 15:49:32,755 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 10) Initializing Mojarra 2.2.0 (-SNAPSHOT 20121204-0807 https://svn.java.net/svn/mojarra~svn/trunk@11125) for context '/jsf22-jee6'
> 15:49:34,438 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 10) Unable to process annotations for url, vfs:/content/jsf22-jee6.war/WEB-INF/lib/richfaces-components-ui-4.3.0-20121203.111732-232.jar/META-INF/faces-config.xml. Reason: java.util.zip.ZipException: zip file is empty
> 15:49:34,439 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 10) : java.util.zip.ZipException: zip file is empty
> 2.0-SNAPSHOT]
> :2.2.0-SNAPSHOT]
> OT]
> ]
> OT]
> 15:49:34,445 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 10) Unable to process annotations for url, vfs:/content/jsf22-jee6.war/WEB-INF/lib/richfaces-core-impl-4.3.0-20121203.205629-130.jar/META-INF/faces-config.xml. Reason: java.util.zip.ZipException: zip file is empty
> 15:49:34,445 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 10) : java.util.zip.ZipException: zip file is empty
> at java.util.zip.ZipFile.open(Native Method) [rt.jar:1.7.0_09-icedtea]
> at java.util.zip.ZipFile.<init>(ZipFile.java:214) [rt.jar:1.7.0_09-icedtea]
> at java.util.zip.ZipFile.<init>(ZipFile.java:144) [rt.jar:1.7.0_09-icedtea]
> at java.util.jar.JarFile.<init>(JarFile.java:152) [rt.jar:1.7.0_09-icedtea]
> at sun.net.www.protocol.jar.URLJarFile.<init>(URLJarFile.java:88) [rt.jar:1.7.0_09-icedtea]
> at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:221) [rt.jar:1.7.0_09-icedtea]
> at sun.net.www.protocol.jar.URLJarFile$1.run(URLJarFile.java:216) [rt.jar:1.7.0_09-icedtea]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_09-icedtea]
> at sun.net.www.protocol.jar.URLJarFile.retrieve(URLJarFile.java:215) [rt.jar:1.7.0_09-icedtea]
> at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:71) [rt.jar:1.7.0_09-icedtea]
> at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:73) [rt.jar:1.7.0_09-icedtea]
> at sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122) [rt.jar:1.7.0_09-icedtea]
> at sun.net.www.protocol.jar.JarURLConnection.getJarFile(JarURLConnection.java:89) [rt.jar:1.7.0_09-icedtea]
> at com.sun.faces.config.JavaClassScanningAnnotationScanner.processClasspath(JavaClassScanningAnnotationScanner.java:166) [jsf-impl-2.2.0-SNAPSHOT.jar:2.2.0-SNAPSHOT]
> at com.sun.faces.config.JavaClassScanningAnnotationScanner.getAnnotatedClasses(JavaClassScanningAnnotationScanner.java:125) [jsf-impl-2.2.0-SNAPSHOT.jar:2.2.0-SNAPSHOT]
> at com.sun.faces.config.DelegatingAnnotationProvider.getAnnotatedClasses(DelegatingAnnotationProvider.java:85) [jsf-impl-2.2.0-SNAPSHOT.jar:2.2.0-SNAPSHOT]
> at com.sun.faces.config.ConfigManager$AnnotationScanTask.call(ConfigManager.java:879) [jsf-impl-2.2.0-SNAPSHOT.jar:2.2.0-SNAPSHOT]
> at com.sun.faces.config.ConfigManager$AnnotationScanTask.call(ConfigManager.java:831) [jsf-impl-2.2.0-SNAPSHOT.jar:2.2.0-SNAPSHOT]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_09-icedtea]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_09-icedtea]
> at com.sun.faces.config.ConfigManager.initialize(ConfigManager.java:370) [jsf-impl-2.2.0-SNAPSHOT.jar:2.2.0-SNAPSHOT]
> at com.sun.faces.config.ConfigureListener.contextInitialized(ConfigureListener.java:224) [jsf-impl-2.2.0-SNAPSHOT.jar:2.2.0-SNAPSHOT]
> at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3339) [jbossweb-7.2.0.Alpha5.jar:7.2.0.Alpha5]
> at org.apache.catalina.core.StandardContext.start(StandardContext.java:3777) [jbossweb-7.2.0.Alpha5.jar:7.2.0.Alpha5]
> at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:156) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:60) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:93) [jboss-as-web-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_09-icedtea]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_09-icedtea]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_09-icedtea]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_09-icedtea]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_09-icedtea]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09-icedtea]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> 15:49:34,613 INFO [org.hibernate.validator.util.Version] (ServerService Thread Pool -- 10) Hibernate Validator 4.2.0.Final
> 15:49:35,235 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 10) Monitoring jndi:/default-host/jsf22-jee6/WEB-INF/faces-config.xml for modifications
> 15:49:35,418 INFO [org.richfaces.log.Cache] (ServerService Thread Pool -- 10) Selected fallback cache factory
> 15:49:35,420 INFO [org.richfaces.log.Cache] (ServerService Thread Pool -- 10) Creating LRUMap cache instance using parameters: {org.jboss.jbossfaces.JSF_CONFIG_NAME=mojarra-2.2.0-SNAPSHOT, org.richfaces.resourceMapping.enabled=true, javax.faces.PROJECT_STAGE=Development, javax.faces.SKIP_COMMENTS=true, org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL=false}
> 15:49:35,429 INFO [org.richfaces.log.Cache] (ServerService Thread Pool -- 10) Creating LRUMap cache instance of 512 items capacity
> 15:49:35,446 INFO [org.richfaces.log.Application] (ServerService Thread Pool -- 10) RichFaces Core Implementation by JBoss by Red Hat, version 4.3.0-SNAPSHOT
> 15:49:35,512 WARNING [org.richfaces.log.Application] (ServerService Thread Pool -- 10) JMS API was found on the classpath; if you want to enable RichFaces Push JMS integration, set context-param 'org.richfaces.push.jms.enabled' in web.xml
> 15:49:35,650 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "jsf22-jee6.war"
> {quote}
> * richfaces-components-ui-4.3.0-20121203.111732-232.jar is definitely *not empty*
> * application works fine with Tomcat 7.0.32
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (RF-12644) Improve CoreUtils/JSEncoder performance by character escape improvements
by Darius Ski (JIRA)
[ https://issues.jboss.org/browse/RF-12644?page=com.atlassian.jira.plugin.s... ]
Darius Ski reassigned RF-12644:
-------------------------------
Assignee: Lukáš Fryč (was: Darius Ski)
> Improve CoreUtils/JSEncoder performance by character escape improvements
> ------------------------------------------------------------------------
>
> Key: RF-12644
> URL: https://issues.jboss.org/browse/RF-12644
> Project: RichFaces
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.3.0.M2
> Reporter: Darius Ski
> Assignee: Lukáš Fryč
> Priority: Minor
> Fix For: 4.3.0.M3
>
>
> In JSUtils, character escaping is done a char at a time. Also in JSEncoder there is opportunity to add encode method that operates with CharBuffer constants and making encode/compile methods static.
> Improves partial rendering performance, when large Strings are coming from user beans (for example custom generated JSON), that need escaping.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (RF-12645) rich:autoComplete's valueChangeListener property doesn't fire
by Valdir Mendes Junior (JIRA)
Valdir Mendes Junior created RF-12645:
-----------------------------------------
Summary: rich:autoComplete's valueChangeListener property doesn't fire
Key: RF-12645
URL: https://issues.jboss.org/browse/RF-12645
Project: RichFaces
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: Google Chrome Version 21.0.1180.89;
Debian wheezy/sid
Richfaces 4.2.2
Reporter: Valdir Mendes Junior
After made the search, I select the option and expected the valueChangeListener method to be called, but it' doesn't.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (RF-12638) Selecting a tree node with ajax, will delete any viewParam to the view
by Arne Plöse (JIRA)
[ https://issues.jboss.org/browse/RF-12638?page=com.atlassian.jira.plugin.s... ]
Arne Plöse updated RF-12638:
----------------------------
Summary: Selecting a tree node with ajax, will delete any viewParam to the view (was: Selecting a trree node with ajax, will delete any viewParam to the view)
Workaround Description:
place the a4j:outputPanel inside the h:form.
> Selecting a tree node with ajax, will delete any viewParam to the view
> ----------------------------------------------------------------------
>
> Key: RF-12638
> URL: https://issues.jboss.org/browse/RF-12638
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.2.3.Final
> Environment: tomcat 7, OpenJDK7
> Reporter: Arne Plöse
> Labels: richfaces
>
> Having a tree in one h:form and using a h:form within a4j:outputPanel will set a viewParam to null if the tree was selected and the form is submitted.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months
[JBoss JIRA] (RF-12644) Improve CoreUtils/JSEncoder performance by character escape improvements
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-12644?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč updated RF-12644:
----------------------------
Assignee: Darius Ski
> Improve CoreUtils/JSEncoder performance by character escape improvements
> ------------------------------------------------------------------------
>
> Key: RF-12644
> URL: https://issues.jboss.org/browse/RF-12644
> Project: RichFaces
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.3.0.M2
> Reporter: Darius Ski
> Assignee: Darius Ski
> Priority: Minor
> Fix For: 4.3.0.M3
>
>
> In JSUtils, character escaping is done a char at a time. Also in JSEncoder there is opportunity to add encode method that operates with CharBuffer constants and making encode/compile methods static.
> Improves partial rendering performance, when large Strings are coming from user beans (for example custom generated JSON), that need escaping.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 5 months