[JBoss JIRA] (RF-12000) TabPanel - Backing bean initialization when a same bean manages multiple dynamic tabs
by Jean ANDRE (JIRA)
[ https://issues.jboss.org/browse/RF-12000?page=com.atlassian.jira.plugin.s... ]
Jean ANDRE commented on RF-12000:
---------------------------------
Thank you very much.
I've updated the conversation: [Tab Panel backing bean isolation / attach data on tab / Bean initialization?|https://community.jboss.org/message/809305#809305]
We tried to migrate from 4.2.3 to 4.3.1 but we failed because of significant change into 4.3.1. This version is not back compatible and we need to adapt the code and figure out why some links does not perform anymore and so on... We are in production, not the right time to upgrade.
It will be nice for us having this bug solved or having some guide line or recommendations.
- https://java.net/jira/browse/JAVASERVERFACES-2016
- https://issues.jboss.org/browse/RF-12907
We have found clues about the problem, but not enough to understand the whole case. We do not have the time to debug third party stuff.
Is there a migration guide from 4.2.3 to 4.3.1 ? Until the version 4.2.3 we had success in following your continuous upgrade but not this time. Sorry.
> TabPanel - Backing bean initialization when a same bean manages multiple dynamic tabs
> -------------------------------------------------------------------------------------
>
> Key: RF-12000
> URL: https://issues.jboss.org/browse/RF-12000
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: component-panels-layout-themes
> Reporter: Jean ANDRE
>
> See the conversation : https://community.jboss.org/message/718460#718460
> Based on the work done, it is more clear about what we need. When a tabPanel, contains dynamic tabs handle by the same backing-bean (because of the same include xhtml), we need a way, a reliable manner to initialize the backing bean when the user switch from a tab to another tab. It might be a specific tag, as rich:bean init="#{.....initialize(params)}". This tab should be executed first, before any other calls of the backing bean whatever its place inside the xhtml page. If several such tags exist wherever (template, include), they must be executed in their natural order, from the deeper to the top of the page hierarchy.
> So, what we need is a contextual initialization, because the @PostContruct is not well suitable for that situation and also a more simple solution rather trying to do it by the PhaseListener (and what about the context???).
> Related links around of this feature:
> - http://www.coderanch.com/t/213757/JSF/java/initialize-backing-bean-before...
> - http://stackoverflow.com/questions/8132394/backing-bean-initialization
> - http://www.icefaces.org/JForum/posts/list/13260.page
> - http://cagataycivici.wordpress.com/2006/06/06/managed_beans_aware_of_the/
> - http://boardreader.com/thread/how_to_initialize_a_backing_bean_before_w2n...
> Thank you
--
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, 10 months
[JBoss JIRA] (RF-12897) ExtendedPartialViewContextImpl swallows exceptions
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12897?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-12897:
-------------------------------
Priority: Major (was: Critical)
Estimated Difficulty: (was: Low)
> ExtendedPartialViewContextImpl swallows exceptions
> --------------------------------------------------
>
> Key: RF-12897
> URL: https://issues.jboss.org/browse/RF-12897
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.2.2.Final
> Environment: Windows 7, JDK 1.6
> Reporter: Cristian Cerb
> Assignee: Lukáš Fryč
> Labels: richfaces
> Fix For: 5-Tracking
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> Method public VisitResult visit(VisitContext context, UIComponent target) of class ExtendedPartialViewContextImpl swallows exceptions. I think exceptions should be wrapped inside a FaceException and propagated. This class http://java.net/projects/mojarra/sources/svn/content/trunk/jsf-ri/src/mai... seems to have served as a model for the RF one, but the RF class inadvertently chose to swallow exceptions instead of propagating them up. This causes unpredictable behaviour, such as system being stuck in the browser.
> I just found an older version of Sun's Mojarra where they had the same issue, but the newer versions seem to have fixed it. See this taken from jsf 2.1.4:
> {code}
> public VisitResult visit(VisitContext context, UIComponent comp) {
> try {
> if (curPhase == PhaseId.APPLY_REQUEST_VALUES) {
> // RELEASE_PENDING handle immediate request(s)
> // If the user requested an immediate request
> // Make sure to set the immediate flag here.
> comp.processDecodes(ctx);
> } else if (curPhase == PhaseId.PROCESS_VALIDATIONS) {
> comp.processValidators(ctx);
> } else if (curPhase == PhaseId.UPDATE_MODEL_VALUES) {
> comp.processUpdates(ctx);
> } else if (curPhase == PhaseId.RENDER_RESPONSE) {
> PartialResponseWriter writer = ctx.getPartialViewContext().getPartialResponseWriter();
> writer.startUpdate(comp.getClientId(ctx));
> try {
> // do the default behavior...
> comp.encodeAll(ctx);
> }
> catch (Exception ce) {
> if (LOGGER.isLoggable(Level.SEVERE)) {
> LOGGER.severe(ce.toString());
> }
> if (LOGGER.isLoggable(Level.FINE)) {
> LOGGER.log(Level.FINE,
> ce.toString(),
> ce);
> }
> }
> writer.endUpdate();
> }
> else {
> throw new IllegalStateException("I18N: Unexpected " +
> "PhaseId passed to " +
> " PhaseAwareContextCallback: " +
> curPhase.toString());
> }
> }
> catch (IOException ex) {
> ex.printStackTrace();
> }
> // Once we visit a component, there is no need to visit
> // its children, since processDecodes/Validators/Updates and
> // encodeAll() already traverse the subtree. We return
> // VisitResult.REJECT to supress the subtree visit.
> return VisitResult.REJECT;
> }
> }
> {code}
--
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, 10 months
[JBoss JIRA] (RF-12897) ExtendedPartialViewContextImpl swallows exceptions
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12897?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-12897:
-------------------------------
Fix Version/s: 5-Tracking
(was: 4.3.2)
Bumping to 5-Tracking as we work out a proper means of resolving this issue.
> ExtendedPartialViewContextImpl swallows exceptions
> --------------------------------------------------
>
> Key: RF-12897
> URL: https://issues.jboss.org/browse/RF-12897
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.2.2.Final
> Environment: Windows 7, JDK 1.6
> Reporter: Cristian Cerb
> Assignee: Lukáš Fryč
> Priority: Critical
> Labels: richfaces
> Fix For: 5-Tracking
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> Method public VisitResult visit(VisitContext context, UIComponent target) of class ExtendedPartialViewContextImpl swallows exceptions. I think exceptions should be wrapped inside a FaceException and propagated. This class http://java.net/projects/mojarra/sources/svn/content/trunk/jsf-ri/src/mai... seems to have served as a model for the RF one, but the RF class inadvertently chose to swallow exceptions instead of propagating them up. This causes unpredictable behaviour, such as system being stuck in the browser.
> I just found an older version of Sun's Mojarra where they had the same issue, but the newer versions seem to have fixed it. See this taken from jsf 2.1.4:
> {code}
> public VisitResult visit(VisitContext context, UIComponent comp) {
> try {
> if (curPhase == PhaseId.APPLY_REQUEST_VALUES) {
> // RELEASE_PENDING handle immediate request(s)
> // If the user requested an immediate request
> // Make sure to set the immediate flag here.
> comp.processDecodes(ctx);
> } else if (curPhase == PhaseId.PROCESS_VALIDATIONS) {
> comp.processValidators(ctx);
> } else if (curPhase == PhaseId.UPDATE_MODEL_VALUES) {
> comp.processUpdates(ctx);
> } else if (curPhase == PhaseId.RENDER_RESPONSE) {
> PartialResponseWriter writer = ctx.getPartialViewContext().getPartialResponseWriter();
> writer.startUpdate(comp.getClientId(ctx));
> try {
> // do the default behavior...
> comp.encodeAll(ctx);
> }
> catch (Exception ce) {
> if (LOGGER.isLoggable(Level.SEVERE)) {
> LOGGER.severe(ce.toString());
> }
> if (LOGGER.isLoggable(Level.FINE)) {
> LOGGER.log(Level.FINE,
> ce.toString(),
> ce);
> }
> }
> writer.endUpdate();
> }
> else {
> throw new IllegalStateException("I18N: Unexpected " +
> "PhaseId passed to " +
> " PhaseAwareContextCallback: " +
> curPhase.toString());
> }
> }
> catch (IOException ex) {
> ex.printStackTrace();
> }
> // Once we visit a component, there is no need to visit
> // its children, since processDecodes/Validators/Updates and
> // encodeAll() already traverse the subtree. We return
> // VisitResult.REJECT to supress the subtree visit.
> return VisitResult.REJECT;
> }
> }
> {code}
--
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, 10 months
[JBoss JIRA] (RF-12000) TabPanel - Backing bean initialization when a same bean manages multiple dynamic tabs
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12000?page=com.atlassian.jira.plugin.s... ]
Brian Leathem resolved RF-12000.
--------------------------------
Fix Version/s: (was: 5-Tracking)
Resolution: Out of Date
Use a4j:repeat for creating dynamic tabs. See: RF-9443
> TabPanel - Backing bean initialization when a same bean manages multiple dynamic tabs
> -------------------------------------------------------------------------------------
>
> Key: RF-12000
> URL: https://issues.jboss.org/browse/RF-12000
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: component-panels-layout-themes
> Reporter: Jean ANDRE
>
> See the conversation : https://community.jboss.org/message/718460#718460
> Based on the work done, it is more clear about what we need. When a tabPanel, contains dynamic tabs handle by the same backing-bean (because of the same include xhtml), we need a way, a reliable manner to initialize the backing bean when the user switch from a tab to another tab. It might be a specific tag, as rich:bean init="#{.....initialize(params)}". This tab should be executed first, before any other calls of the backing bean whatever its place inside the xhtml page. If several such tags exist wherever (template, include), they must be executed in their natural order, from the deeper to the top of the page hierarchy.
> So, what we need is a contextual initialization, because the @PostContruct is not well suitable for that situation and also a more simple solution rather trying to do it by the PhaseListener (and what about the context???).
> Related links around of this feature:
> - http://www.coderanch.com/t/213757/JSF/java/initialize-backing-bean-before...
> - http://stackoverflow.com/questions/8132394/backing-bean-initialization
> - http://www.icefaces.org/JForum/posts/list/13260.page
> - http://cagataycivici.wordpress.com/2006/06/06/managed_beans_aware_of_the/
> - http://boardreader.com/thread/how_to_initialize_a_backing_bean_before_w2n...
> Thank you
--
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, 10 months
[JBoss JIRA] (RF-12938) Update Shrinkwrap
by Andrew Rubinger (JIRA)
[ https://issues.jboss.org/browse/RF-12938?page=com.atlassian.jira.plugin.s... ]
Andrew Rubinger commented on RF-12938:
--------------------------------------
The issue leading to this error was: https://issues.jboss.org/browse/SHRINKWRAP-279
> Update Shrinkwrap
> -----------------
>
> Key: RF-12938
> URL: https://issues.jboss.org/browse/RF-12938
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: tests - functional
> Reporter: Brian Leathem
> Assignee: Brian Leathem
> Fix For: 4.3.2
>
> Original Estimate: 30 minutes
> Remaining Estimate: 30 minutes
>
> Cancelling tests resulted in a ShrinWrap zip file error when trying to re-run the test:
> {quote}
> WARNING: Exception encountered during export of archive
> org.jboss.shrinkwrap.api.exporter.ArchiveExportException: Failed to write asset to output: /WEB-INF/lib/arquillian-warp.jar
> at org.jboss.shrinkwrap.impl.base.exporter.StreamExporterDelegateBase$3.handle(StreamExporterDelegateBase.java:272)
> at org.jboss.shrinkwrap.impl.base.io.IOUtil.closeOnComplete(IOUtil.java:219)
> at org.jboss.shrinkwrap.impl.base.exporter.StreamExporterDelegateBase.processNode(StreamExporterDelegateBase.java:233)
> at org.jboss.shrinkwrap.impl.base.exporter.AbstractExporterDelegate.processNode(AbstractExporterDelegate.java:105)
> at org.jboss.shrinkwrap.impl.base.exporter.AbstractExporterDelegate.processNode(AbstractExporterDelegate.java:109)
> at org.jboss.shrinkwrap.impl.base.exporter.AbstractExporterDelegate.processNode(AbstractExporterDelegate.java:109)
> at org.jboss.shrinkwrap.impl.base.exporter.AbstractExporterDelegate.doExport(AbstractExporterDelegate.java:95)
> at org.jboss.shrinkwrap.impl.base.exporter.StreamExporterDelegateBase.access$001(StreamExporterDelegateBase.java:50)
> at org.jboss.shrinkwrap.impl.base.exporter.StreamExporterDelegateBase$1.call(StreamExporterDelegateBase.java:121)
> at org.jboss.shrinkwrap.impl.base.exporter.StreamExporterDelegateBase$1.call(StreamExporterDelegateBase.java:116)
> at org.jboss.shrinkwrap.impl.base.exporter.zip.JdkZipExporterDelegate$1.call(JdkZipExporterDelegate.java:124)
> at org.jboss.shrinkwrap.impl.base.exporter.zip.JdkZipExporterDelegate$1.call(JdkZipExporterDelegate.java:118)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.io.IOException: Pipe closed
> at java.io.PipedInputStream.checkStateForReceive(PipedInputStream.java:261)
> at java.io.PipedInputStream.receive(PipedInputStream.java:227)
> at java.io.PipedOutputStream.write(PipedOutputStream.java:149)
> at java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:253)
> at java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:211)
> at java.util.zip.ZipOutputStream.write(ZipOutputStream.java:314)
> at org.jboss.shrinkwrap.impl.base.io.IOUtil.copy(IOUtil.java:139)
> at org.jboss.shrinkwrap.impl.base.exporter.StreamExporterDelegateBase$2.execute(StreamExporterDelegateBase.java:261)
> at org.jboss.shrinkwrap.impl.base.exporter.StreamExporterDelegateBase$2.execute(StreamExporterDelegateBase.java:233)
> at org.jboss.shrinkwrap.impl.base.io.IOUtil.closeOnComplete(IOUtil.java:217)
> ... 15 more
> {quote}
> [~alrubinger] pointed out that our Shrinkwrap version was old and out of date. We need to upgrade to the latest Shrinkwrap to overcome this issue.
--
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, 10 months
[JBoss JIRA] (RF-12928) ExtendedDataTable: columnsOrder doesnt work after changing order
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12928?page=com.atlassian.jira.plugin.s... ]
Brian Leathem resolved RF-12928.
--------------------------------
Assignee: Brian Leathem
Resolution: Done
> ExtendedDataTable: columnsOrder doesnt work after changing order
> ----------------------------------------------------------------
>
> Key: RF-12928
> URL: https://issues.jboss.org/browse/RF-12928
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 4.3.1
> Environment: Tomcat 7, Mojarra 2.1.21
> Reporter: dako ak
> Assignee: Brian Leathem
> Labels: regression
> Fix For: 4.3.2
>
> Attachments: JSF2-RichFaces-Test.zip
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> According to the resolved bug RF-11776 I've tried the attribute "columnsOrder" in ExtendedDataTable.
> I have a simple test case with a data table and an action button. Within the action button method I change the String Array of the attribute columnsOrder but the columns of the data table is rendered in the old order.
> I have appended a test project to reproduce it. In this test project I have an a4j ajax button and a simple button, both arent working.
> Best regards
--
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, 10 months
[JBoss JIRA] (RF-12928) ExtendedDataTable: columnsOrder doesnt work after changing order
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12928?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-12928:
------------------------------------
I wrote a test to verify this behavior:
https://github.com/richfaces/components/blob/master/iteration/ui/src/test...
While not a documented feature, I used the above test to demonstrate that the _columnsOrder_ worked from 4.0.0.Final to 4.2.3.Final. With the 4.3.0.Final release, changes in _columnsOrder_ after the initial render were not reflected in the EDT.
I corrected this issue by evaluating the expression behind the _columnsOrder_ in the EDT renderer, rather than simply using the attribute retrieval.
> ExtendedDataTable: columnsOrder doesnt work after changing order
> ----------------------------------------------------------------
>
> Key: RF-12928
> URL: https://issues.jboss.org/browse/RF-12928
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 4.3.1
> Environment: Tomcat 7, Mojarra 2.1.21
> Reporter: dako ak
> Labels: regression
> Fix For: 4.3.2
>
> Attachments: JSF2-RichFaces-Test.zip
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> According to the resolved bug RF-11776 I've tried the attribute "columnsOrder" in ExtendedDataTable.
> I have a simple test case with a data table and an action button. Within the action button method I change the String Array of the attribute columnsOrder but the columns of the data table is rendered in the old order.
> I have appended a test project to reproduce it. In this test project I have an a4j ajax button and a simple button, both arent working.
> Best regards
--
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, 10 months
[JBoss JIRA] (RF-12928) ExtendedDataTable: columnsOrder doesnt work after changing order
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12928?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-12928:
------------------------------------
The extendedDataTable had no columnsOrder in RichFaces 4.2.2.Final:
http://docs.jboss.org/richfaces/4.2.X/4.2.2.Final/vdldoc/rich/extendedDat...
> ExtendedDataTable: columnsOrder doesnt work after changing order
> ----------------------------------------------------------------
>
> Key: RF-12928
> URL: https://issues.jboss.org/browse/RF-12928
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 4.3.1
> Environment: Tomcat 7, Mojarra 2.1.21
> Reporter: dako ak
> Labels: regression
> Fix For: 4.3.2
>
> Attachments: JSF2-RichFaces-Test.zip
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> According to the resolved bug RF-11776 I've tried the attribute "columnsOrder" in ExtendedDataTable.
> I have a simple test case with a data table and an action button. Within the action button method I change the String Array of the attribute columnsOrder but the columns of the data table is rendered in the old order.
> I have appended a test project to reproduce it. In this test project I have an a4j ajax button and a simple button, both arent working.
> Best regards
--
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, 10 months
[JBoss JIRA] (RF-12897) ExtendedPartialViewContextImpl swallows exceptions
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12897?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-12897:
-------------------------------
Sprint: RF 4.3.2 Sprint 2, 4.3.2 Sprint 2 (was: RF 4.3.2 Sprint 2)
> ExtendedPartialViewContextImpl swallows exceptions
> --------------------------------------------------
>
> Key: RF-12897
> URL: https://issues.jboss.org/browse/RF-12897
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.2.2.Final
> Environment: Windows 7, JDK 1.6
> Reporter: Cristian Cerb
> Assignee: Lukáš Fryč
> Priority: Critical
> Labels: richfaces
> Fix For: 4.3.2
>
> Original Estimate: 4 hours
> Remaining Estimate: 4 hours
>
> Method public VisitResult visit(VisitContext context, UIComponent target) of class ExtendedPartialViewContextImpl swallows exceptions. I think exceptions should be wrapped inside a FaceException and propagated. This class http://java.net/projects/mojarra/sources/svn/content/trunk/jsf-ri/src/mai... seems to have served as a model for the RF one, but the RF class inadvertently chose to swallow exceptions instead of propagating them up. This causes unpredictable behaviour, such as system being stuck in the browser.
> I just found an older version of Sun's Mojarra where they had the same issue, but the newer versions seem to have fixed it. See this taken from jsf 2.1.4:
> {code}
> public VisitResult visit(VisitContext context, UIComponent comp) {
> try {
> if (curPhase == PhaseId.APPLY_REQUEST_VALUES) {
> // RELEASE_PENDING handle immediate request(s)
> // If the user requested an immediate request
> // Make sure to set the immediate flag here.
> comp.processDecodes(ctx);
> } else if (curPhase == PhaseId.PROCESS_VALIDATIONS) {
> comp.processValidators(ctx);
> } else if (curPhase == PhaseId.UPDATE_MODEL_VALUES) {
> comp.processUpdates(ctx);
> } else if (curPhase == PhaseId.RENDER_RESPONSE) {
> PartialResponseWriter writer = ctx.getPartialViewContext().getPartialResponseWriter();
> writer.startUpdate(comp.getClientId(ctx));
> try {
> // do the default behavior...
> comp.encodeAll(ctx);
> }
> catch (Exception ce) {
> if (LOGGER.isLoggable(Level.SEVERE)) {
> LOGGER.severe(ce.toString());
> }
> if (LOGGER.isLoggable(Level.FINE)) {
> LOGGER.log(Level.FINE,
> ce.toString(),
> ce);
> }
> }
> writer.endUpdate();
> }
> else {
> throw new IllegalStateException("I18N: Unexpected " +
> "PhaseId passed to " +
> " PhaseAwareContextCallback: " +
> curPhase.toString());
> }
> }
> catch (IOException ex) {
> ex.printStackTrace();
> }
> // Once we visit a component, there is no need to visit
> // its children, since processDecodes/Validators/Updates and
> // encodeAll() already traverse the subtree. We return
> // VisitResult.REJECT to supress the subtree visit.
> return VisitResult.REJECT;
> }
> }
> {code}
--
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, 10 months