[JBoss JIRA] (RF-13625) org.ajax4jsf.model.SequenceRange is not serializable
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13625?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13625:
-------------------------------
Description:
{code}
Caused by: org.infinispan.marshall.NotSerializableException: org.ajax4jsf.model.SequenceRange
Caused by: an exception which occurred:
in field cachedRange
in field bean
in object java.util.HashMap@0
in object org.jboss.as.clustering.SimpleMarshalledValue@0
in object org.infinispan.atomic.PutOperation@0
in object java.util.LinkedList@0
in object org.infinispan.atomic.AtomicHashMapDelta@3e01b8
in object org.infinispan.commands.write.PutKeyValueCommand@514bdbf9
in object org.infinispan.commands.tx.PrepareCommand@8bb71fb
{code}
was:
Caused by: org.infinispan.marshall.NotSerializableException: org.ajax4jsf.model.SequenceRange
Caused by: an exception which occurred:
in field cachedRange
in field bean
in object java.util.HashMap@0
in object org.jboss.as.clustering.SimpleMarshalledValue@0
in object org.infinispan.atomic.PutOperation@0
in object java.util.LinkedList@0
in object org.infinispan.atomic.AtomicHashMapDelta@3e01b8
in object org.infinispan.commands.write.PutKeyValueCommand@514bdbf9
in object org.infinispan.commands.tx.PrepareCommand@8bb71fb
> org.ajax4jsf.model.SequenceRange is not serializable
> ----------------------------------------------------
>
> Key: RF-13625
> URL: https://issues.jboss.org/browse/RF-13625
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.3.6
> Reporter: Marco Rossi
> Labels: waiting_on_user
>
> {code}
> Caused by: org.infinispan.marshall.NotSerializableException: org.ajax4jsf.model.SequenceRange
> Caused by: an exception which occurred:
> in field cachedRange
> in field bean
> in object java.util.HashMap@0
> in object org.jboss.as.clustering.SimpleMarshalledValue@0
> in object org.infinispan.atomic.PutOperation@0
> in object java.util.LinkedList@0
> in object org.infinispan.atomic.AtomicHashMapDelta@3e01b8
> in object org.infinispan.commands.write.PutKeyValueCommand@514bdbf9
> in object org.infinispan.commands.tx.PrepareCommand@8bb71fb
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 10 months
[JBoss JIRA] (RF-13611) RichFaces 5.0.0.Alpha3 doesn't work with Weld 2.2.0.Final
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13611?page=com.atlassian.jira.plugin.s... ]
Brian Leathem reassigned RF-13611:
----------------------------------
Assignee: Pavol Pitonak
QE, please verify this with RichFaces 4.5
> RichFaces 5.0.0.Alpha3 doesn't work with Weld 2.2.0.Final
> ---------------------------------------------------------
>
> Key: RF-13611
> URL: https://issues.jboss.org/browse/RF-13611
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-push/poll
> Affects Versions: 5.0.0.Alpha3
> Reporter: Juergen Zimmermann
> Assignee: Pavol Pitonak
> Fix For: 4.5.0.Alpha3
>
>
> I'm using WildFly 8.0.0.CR1 and Weld 2.2.0.Final (via the WildFly patch mechanism). However, I'm getting the stacktrace below. When I patch WildFly 8.0.0.CR1 with the predecessor version Weld 2.2.0.CR2, then the issue is gone.
> {code}
> ERROR [org.jboss.msc.service.fail] MSC000001: Failed to start service jboss.deployment.unit."shop.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."shop.war".WeldStartService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0]
> Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:
> Exception 0 :
> org.jboss.weld.exceptions.DefinitionException: WELD-000412: ObserverMethod.getReception() returned null for org.richfaces.push.cdi.PushCDIExtension$PushObserverMethod@31e23242
> at org.jboss.weld.util.Observers.validateObserverMethod(Observers.java:118)
> at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.addObserverMethod(AfterBeanDiscoveryImpl.java:158)
> at org.richfaces.push.cdi.PushCDIExtension.afterBeanDiscovery(PushCDIExtension.java:99)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:90)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:271)
> at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:121)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:258)
> at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:237)
> at org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:174)
> at org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:133)
> at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:107)
> at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:54)
> at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:42)
> at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:59)
> at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:393)
> at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83)
> at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:92)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:744)
> at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:44)
> at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:59)
> at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:393)
> at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83)
> at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:92)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> ... 3 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 10 months
[JBoss JIRA] (RF-13611) RichFaces 5.0.0.Alpha3 doesn't work with Weld 2.2.0.Final
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13611?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13611:
-------------------------------
Fix Version/s: 4.5.0.Alpha3
(was: 4.5-Tracking)
> RichFaces 5.0.0.Alpha3 doesn't work with Weld 2.2.0.Final
> ---------------------------------------------------------
>
> Key: RF-13611
> URL: https://issues.jboss.org/browse/RF-13611
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-push/poll
> Affects Versions: 5.0.0.Alpha3
> Reporter: Juergen Zimmermann
> Fix For: 4.5.0.Alpha3
>
>
> I'm using WildFly 8.0.0.CR1 and Weld 2.2.0.Final (via the WildFly patch mechanism). However, I'm getting the stacktrace below. When I patch WildFly 8.0.0.CR1 with the predecessor version Weld 2.2.0.CR2, then the issue is gone.
> {code}
> ERROR [org.jboss.msc.service.fail] MSC000001: Failed to start service jboss.deployment.unit."shop.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."shop.war".WeldStartService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0]
> Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:
> Exception 0 :
> org.jboss.weld.exceptions.DefinitionException: WELD-000412: ObserverMethod.getReception() returned null for org.richfaces.push.cdi.PushCDIExtension$PushObserverMethod@31e23242
> at org.jboss.weld.util.Observers.validateObserverMethod(Observers.java:118)
> at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.addObserverMethod(AfterBeanDiscoveryImpl.java:158)
> at org.richfaces.push.cdi.PushCDIExtension.afterBeanDiscovery(PushCDIExtension.java:99)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:90)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:271)
> at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:121)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:258)
> at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:237)
> at org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:174)
> at org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:133)
> at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:107)
> at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:54)
> at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:42)
> at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:59)
> at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:393)
> at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83)
> at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:92)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:744)
> at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:44)
> at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:59)
> at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:393)
> at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83)
> at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:92)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> ... 3 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 10 months
[JBoss JIRA] (RF-13626) Rename the BOM artifact
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13626?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13626:
-------------------------------
Description:
I'd like to rename the BOM. Currently the BOM manages the following Dependency versions:
{code}
<dependencyManagement>
<dependencies>
<!-- Optional cache dependencies -->
<dependency>
<groupId>opensymphony</groupId>
<artifactId>oscache</artifactId>
<version>${version.oscache}</version>
</dependency>
<dependency>
<groupId>org.jboss.cache</groupId>
<artifactId>jbosscache-core</artifactId>
<version>${version.jbosscache}</version>
</dependency>
<dependency>
<groupId>net.sf.ehcache</groupId>
<artifactId>ehcache</artifactId>
<version>${version.ehcache}</version>
</dependency>
</dependencies>
</dependencyManagement>
{code}
Since only the cache-dependencies are managed, we could rename the BOM to {{richfaces-cache-bom}}.
was:
I'd like to rename the BOM as part of this issue. Currently the BOM manages the following Dependency versions:
{code}
<dependencyManagement>
<dependencies>
<!-- Optional cache dependencies -->
<dependency>
<groupId>opensymphony</groupId>
<artifactId>oscache</artifactId>
<version>${version.oscache}</version>
</dependency>
<dependency>
<groupId>org.jboss.cache</groupId>
<artifactId>jbosscache-core</artifactId>
<version>${version.jbosscache}</version>
</dependency>
<dependency>
<groupId>net.sf.ehcache</groupId>
<artifactId>ehcache</artifactId>
<version>${version.ehcache}</version>
</dependency>
</dependencies>
</dependencyManagement>
{code}
Since only the cache-dependencies are managed, we could rename the BOM to {{richfaces-cache-bom}}.
> Rename the BOM artifact
> -----------------------
>
> Key: RF-13626
> URL: https://issues.jboss.org/browse/RF-13626
> Project: RichFaces
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Brian Leathem
> Assignee: Brian Leathem
> Fix For: 4.5.0.Alpha3
>
> Original Estimate: 15 minutes
> Remaining Estimate: 15 minutes
>
> I'd like to rename the BOM. Currently the BOM manages the following Dependency versions:
> {code}
> <dependencyManagement>
> <dependencies>
> <!-- Optional cache dependencies -->
> <dependency>
> <groupId>opensymphony</groupId>
> <artifactId>oscache</artifactId>
> <version>${version.oscache}</version>
> </dependency>
> <dependency>
> <groupId>org.jboss.cache</groupId>
> <artifactId>jbosscache-core</artifactId>
> <version>${version.jbosscache}</version>
> </dependency>
> <dependency>
> <groupId>net.sf.ehcache</groupId>
> <artifactId>ehcache</artifactId>
> <version>${version.ehcache}</version>
> </dependency>
> </dependencies>
> </dependencyManagement>
> {code}
> Since only the cache-dependencies are managed, we could rename the BOM to {{richfaces-cache-bom}}.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 10 months
[JBoss JIRA] (RF-13626) Rename the BOM artifact
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13626?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13626:
-------------------------------
Description:
I'd like to rename the BOM as part of this issue. Currently the BOM manages the following Dependency versions:
{code}
<dependencyManagement>
<dependencies>
<!-- Optional cache dependencies -->
<dependency>
<groupId>opensymphony</groupId>
<artifactId>oscache</artifactId>
<version>${version.oscache}</version>
</dependency>
<dependency>
<groupId>org.jboss.cache</groupId>
<artifactId>jbosscache-core</artifactId>
<version>${version.jbosscache}</version>
</dependency>
<dependency>
<groupId>net.sf.ehcache</groupId>
<artifactId>ehcache</artifactId>
<version>${version.ehcache}</version>
</dependency>
</dependencies>
</dependencyManagement>
{code}
Since only the cache-dependencies are managed, we could rename the BOM to {{richfaces-cache-bom}}.
was:
I've implemented these changes here:
https://github.com/richfaces/richfaces/tree/RF-13608-artifact-rename
I'd also like to rename the BOM as part of this issue. Currently the BOM manages the following Dependency versions:
{code}
<dependencyManagement>
<dependencies>
<!-- Optional cache dependencies -->
<dependency>
<groupId>opensymphony</groupId>
<artifactId>oscache</artifactId>
<version>${version.oscache}</version>
</dependency>
<dependency>
<groupId>org.jboss.cache</groupId>
<artifactId>jbosscache-core</artifactId>
<version>${version.jbosscache}</version>
</dependency>
<dependency>
<groupId>net.sf.ehcache</groupId>
<artifactId>ehcache</artifactId>
<version>${version.ehcache}</version>
</dependency>
</dependencies>
</dependencyManagement>
{code}
Since only the cache-dependencies are managed, we could rename the BOM to {{richfaces-cache-bom}}.
> Rename the BOM artifact
> -----------------------
>
> Key: RF-13626
> URL: https://issues.jboss.org/browse/RF-13626
> Project: RichFaces
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Reporter: Brian Leathem
> Assignee: Brian Leathem
> Fix For: 4.5.0.Alpha3
>
> Original Estimate: 15 minutes
> Remaining Estimate: 15 minutes
>
> I'd like to rename the BOM as part of this issue. Currently the BOM manages the following Dependency versions:
> {code}
> <dependencyManagement>
> <dependencies>
> <!-- Optional cache dependencies -->
> <dependency>
> <groupId>opensymphony</groupId>
> <artifactId>oscache</artifactId>
> <version>${version.oscache}</version>
> </dependency>
> <dependency>
> <groupId>org.jboss.cache</groupId>
> <artifactId>jbosscache-core</artifactId>
> <version>${version.jbosscache}</version>
> </dependency>
> <dependency>
> <groupId>net.sf.ehcache</groupId>
> <artifactId>ehcache</artifactId>
> <version>${version.ehcache}</version>
> </dependency>
> </dependencies>
> </dependencyManagement>
> {code}
> Since only the cache-dependencies are managed, we could rename the BOM to {{richfaces-cache-bom}}.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 10 months
[JBoss JIRA] (RF-11741) ECSS parser is too aggressive when encountering non-standard CSS properties: selector omitted entirely
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-11741?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-11741:
-------------------------------
Fix Version/s: 4.5.0.Alpha3
(was: 5-Tracking)
> ECSS parser is too aggressive when encountering non-standard CSS properties: selector omitted entirely
> ------------------------------------------------------------------------------------------------------
>
> Key: RF-11741
> URL: https://issues.jboss.org/browse/RF-11741
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: skinning
> Affects Versions: 4.1.0.CR1
> Reporter: Karsten Wutzke
> Labels: ecss, parsing, skinning
> Fix For: 4.5.0.Alpha3
>
>
> When defining rules like
> {code}
> .shadow
> {
> -webkit-box-shadow: 4px 4px 5px '#{richSkin.additionalBackgroundColor}';
> -moz-box-shadow: 4px 4px 5px '#{richSkin.additionalBackgroundColor}';
> box-shadow: 4px 4px 5px '#{richSkin.additionalBackgroundColor}';
> }
> {code}
> in an ECSS file to create skin-dependent drop shadows, RF 4 will omit the above rule entirely and no shadows will be rendered. BTW it would be better to just omit the invalid properties instead of the entire selector (box-shadow: ... alone works).
> Most browsers don't support the box-shadow yet, so defining proprietary properties *must* be possible. Note, this applies to a lot more properties than the above.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 10 months
[JBoss JIRA] (RF-13505) Refactor custom tree traversal logic in EPVCI in order to leverage VisitContextFactory (blocked by Mojarra issue)
by Juraj Húska (JIRA)
[ https://issues.jboss.org/browse/RF-13505?page=com.atlassian.jira.plugin.s... ]
Juraj Húska commented on RF-13505:
----------------------------------
Here are the results of *testing #2*:
There are unfortunatelly still some issues. *First one* in {{r:outputPanel}} and its {{ajaxRendered}} attribute. Rerendering of the panel seems to not update the component. It is updated only after full page refresh. It seems to be a regression (did not occur in the first round of testing). Steps to reproduce:
# deploy Metamer and load: http://localhost:8080/metamer/faces/components/a4jOutputPanel/simple.xhtml
# set {{ajaxRendered}} to false
# click twice on the button Increase Counter
# see that component is not rerendered (correct)
# click on the Rerender All button
# see that the counter is still 0 (incorrect - should be 2)
*Second one*, this is the issue which was reproducible in the first round of the testing as well. {{fileUpload}} - after successful uploading it does not rerender {{r:outputPanel}}, which has set {{ajaxRerender}} to true. Steps to reproduce:
# deploy Metamer, and load http://localhost:8080/metamer/faces/components/richFileUpload/simple.xhtml
# try to upload e.g. .png picture
# see that after successful upload the r:outputPanel with list of uploaded files is not rerendered
Issues seems to relate to each other.
> Refactor custom tree traversal logic in EPVCI in order to leverage VisitContextFactory (blocked by Mojarra issue)
> -----------------------------------------------------------------------------------------------------------------
>
> Key: RF-13505
> URL: https://issues.jboss.org/browse/RF-13505
> Project: RichFaces
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Affects Versions: 5.0.0.Alpha3
> Reporter: Lukáš Fryč
> Assignee: Juraj Húska
> Priority: Critical
> Fix For: 4.5.0.Alpha3
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> Mojarra issue: https://java.net/jira/browse/JAVASERVERFACES-3151
> We will still need to use some:
> * resolve values in runtime
> * add IDs for execution of AjaxOutput's
> * collect list of meta-components to render
> * wrap PartialResponseWriter#endDocument() for RichFaces extensions and JavascriptService
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
11 years, 10 months