[JBoss JIRA] (RF-13703) Nested UIDataAdaptor restoring stale data because of reentrancy problem
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13703?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13703:
------------------------------------
Thanks for reporting the issue; I've scheduled this issue for tracking. The use case in which the problem sounds like an uncommon use case - it is unlikely we will get to investigate any time soon. Any work you do on providing a test-case or fix will help greatly in seeing this issue resolved.
> Nested UIDataAdaptor restoring stale data because of reentrancy problem
> -----------------------------------------------------------------------
>
> Key: RF-13703
> URL: https://issues.jboss.org/browse/RF-13703
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.3.1
> Environment: (Windows 7. Java 6. Jetty 7.6.9 or Tomcat 6.0.37)
> Reporter: Yannick Valot
> Fix For: 4.5-Tracking
>
>
> I am encountering a reentrancy problem with nested UIDataAdaptor components. For instance something like :
> {code}
> <rich:dataTable id="outer" ...>
> <rich:dataTable id="inner" ...>
> <h:inputText id="myText" ...>
> </rich:dataTable>
> </rich:dataTable>
> {code}
> When a view contains nested UIDataAdaptor components, each UIDataAdaptor component has its own internal store for saving the saved state of child components (saveChildState/restoreChildState). Since "inputText" is included in both tables, each one may save and restore the value of the component in its internal store.
> For instance, when "outer" is on key 0 and inner is on key "2", both "outer" and "inner" may store the state values for myText "outer:0:inner:2:myText" in their "childState" property.
> I guess that most of the time, only "inner" will actually store useful values, because most of calls on "setRowKey" for outer will be done when "inner" has its rowkey set to null. Unfortunately, this is not always the case.
> For instance, if I decide to visit the component tree while processing an event for "myText", outer will perform a setRowKey while inner has its own rowKey to a significant value (for instance, 2), the result being that inner's value will be erased by
> outer's.
> To try and explain with a little more detail... Let's say that we are processing an event on "outer:1:inner:0:myText", and we start a (nested) visit of the tree :
> 1) "outer" will at some point perform a setRowKey(0)
> 2) It will then do a restoreChildState for myText. since "inner" has rowKey set to 0, it will restore "outer's" value for "outer:0:inner:0:myText".
> 3) A bit later on during the visit, inner will do "setRowKey(0)". It will first save the current value for "outer:0:inner:0:myText" (which comes from outer's backup of it, restored on step 2)
> The result of this process is that "outer"'s backup of "outer:0:inner:0:myText" overwrites "inner"'s backup for it. This is problematic because this leads, sometimes, to an old and obsolete backup
> of state taking place of the current value. This may happen several HTTP requests later.
> I've found a solution for this problem by not storing the saved state in the UIDataAdaptor, but in the target component itself. In this manner, there can only be one backup of the data. Such a modification is actually hinted at in UIDataAdaptor's source code : "// TODO - use local map - children save their state themselves using visitors", although my modification is simpler
> (it's still UIDataAdaptor that saves the state, in the same manner, only in a different place).
> This bug is quite complex and extracting a testcase will take some time, but I am willing to do so if requested. I can also offer my patch for the problem once I have finalized it.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months
[JBoss JIRA] (RF-13703) Nested UIDataAdaptor restoring stale data because of reentrancy problem
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13703?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13703:
-------------------------------
Fix Version/s: 4.5-Tracking
> Nested UIDataAdaptor restoring stale data because of reentrancy problem
> -----------------------------------------------------------------------
>
> Key: RF-13703
> URL: https://issues.jboss.org/browse/RF-13703
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.3.1
> Environment: (Windows 7. Java 6. Jetty 7.6.9 or Tomcat 6.0.37)
> Reporter: Yannick Valot
> Fix For: 4.5-Tracking
>
>
> I am encountering a reentrancy problem with nested UIDataAdaptor components. For instance something like :
> {code}
> <rich:dataTable id="outer" ...>
> <rich:dataTable id="inner" ...>
> <h:inputText id="myText" ...>
> </rich:dataTable>
> </rich:dataTable>
> {code}
> When a view contains nested UIDataAdaptor components, each UIDataAdaptor component has its own internal store for saving the saved state of child components (saveChildState/restoreChildState). Since "inputText" is included in both tables, each one may save and restore the value of the component in its internal store.
> For instance, when "outer" is on key 0 and inner is on key "2", both "outer" and "inner" may store the state values for myText "outer:0:inner:2:myText" in their "childState" property.
> I guess that most of the time, only "inner" will actually store useful values, because most of calls on "setRowKey" for outer will be done when "inner" has its rowkey set to null. Unfortunately, this is not always the case.
> For instance, if I decide to visit the component tree while processing an event for "myText", outer will perform a setRowKey while inner has its own rowKey to a significant value (for instance, 2), the result being that inner's value will be erased by
> outer's.
> To try and explain with a little more detail... Let's say that we are processing an event on "outer:1:inner:0:myText", and we start a (nested) visit of the tree :
> 1) "outer" will at some point perform a setRowKey(0)
> 2) It will then do a restoreChildState for myText. since "inner" has rowKey set to 0, it will restore "outer's" value for "outer:0:inner:0:myText".
> 3) A bit later on during the visit, inner will do "setRowKey(0)". It will first save the current value for "outer:0:inner:0:myText" (which comes from outer's backup of it, restored on step 2)
> The result of this process is that "outer"'s backup of "outer:0:inner:0:myText" overwrites "inner"'s backup for it. This is problematic because this leads, sometimes, to an old and obsolete backup
> of state taking place of the current value. This may happen several HTTP requests later.
> I've found a solution for this problem by not storing the saved state in the UIDataAdaptor, but in the target component itself. In this manner, there can only be one backup of the data. Such a modification is actually hinted at in UIDataAdaptor's source code : "// TODO - use local map - children save their state themselves using visitors", although my modification is simpler
> (it's still UIDataAdaptor that saves the state, in the same manner, only in a different place).
> This bug is quite complex and extracting a testcase will take some time, but I am willing to do so if requested. I can also offer my patch for the problem once I have finalized it.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months
[JBoss JIRA] (RF-13703) Nested UIDataAdaptor restoring stale data because of reentrancy problem
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13703?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13703:
-------------------------------
Description:
I am encountering a reentrancy problem with nested UIDataAdaptor components. For instance something like :
{code}
<rich:dataTable id="outer" ...>
<rich:dataTable id="inner" ...>
<h:inputText id="myText" ...>
</rich:dataTable>
</rich:dataTable>
{code}
When a view contains nested UIDataAdaptor components, each UIDataAdaptor component has its own internal store for saving the saved state of child components (saveChildState/restoreChildState). Since "inputText" is included in both tables, each one may save and restore the value of the component in its internal store.
For instance, when "outer" is on key 0 and inner is on key "2", both "outer" and "inner" may store the state values for myText "outer:0:inner:2:myText" in their "childState" property.
I guess that most of the time, only "inner" will actually store useful values, because most of calls on "setRowKey" for outer will be done when "inner" has its rowkey set to null. Unfortunately, this is not always the case.
For instance, if I decide to visit the component tree while processing an event for "myText", outer will perform a setRowKey while inner has its own rowKey to a significant value (for instance, 2), the result being that inner's value will be erased by
outer's.
To try and explain with a little more detail... Let's say that we are processing an event on "outer:1:inner:0:myText", and we start a (nested) visit of the tree :
1) "outer" will at some point perform a setRowKey(0)
2) It will then do a restoreChildState for myText. since "inner" has rowKey set to 0, it will restore "outer's" value for "outer:0:inner:0:myText".
3) A bit later on during the visit, inner will do "setRowKey(0)". It will first save the current value for "outer:0:inner:0:myText" (which comes from outer's backup of it, restored on step 2)
The result of this process is that "outer"'s backup of "outer:0:inner:0:myText" overwrites "inner"'s backup for it. This is problematic because this leads, sometimes, to an old and obsolete backup
of state taking place of the current value. This may happen several HTTP requests later.
I've found a solution for this problem by not storing the saved state in the UIDataAdaptor, but in the target component itself. In this manner, there can only be one backup of the data. Such a modification is actually hinted at in UIDataAdaptor's source code : "// TODO - use local map - children save their state themselves using visitors", although my modification is simpler
(it's still UIDataAdaptor that saves the state, in the same manner, only in a different place).
This bug is quite complex and extracting a testcase will take some time, but I am willing to do so if requested. I can also offer my patch for the problem once I have finalized it.
was:
I am encountering a reentrancy problem with nested UIDataAdaptor components. For instance something like :
<rich:dataTable id="outer" ...>
<rich:dataTable id="inner" ...>
<h:inputText id="myText" ...>
</rich:dataTable>
</rich:dataTable>
When a view contains nested UIDataAdaptor components, each UIDataAdaptor component has its own internal store for saving the saved state of child components (saveChildState/restoreChildState). Since "inputText" is included in both tables, each one may save and restore the value of the component in its internal store.
For instance, when "outer" is on key 0 and inner is on key "2", both "outer" and "inner" may store the state values for myText "outer:0:inner:2:myText" in their "childState" property.
I guess that most of the time, only "inner" will actually store useful values, because most of calls on "setRowKey" for outer will be done when "inner" has its rowkey set to null. Unfortunately, this is not always the case.
For instance, if I decide to visit the component tree while processing an event for "myText", outer will perform a setRowKey while inner has its own rowKey to a significant value (for instance, 2), the result being that inner's value will be erased by
outer's.
To try and explain with a little more detail... Let's say that we are processing an event on "outer:1:inner:0:myText", and we start a (nested) visit of the tree :
1) "outer" will at some point perform a setRowKey(0)
2) It will then do a restoreChildState for myText. since "inner" has rowKey set to 0, it will restore "outer's" value for "outer:0:inner:0:myText".
3) A bit later on during the visit, inner will do "setRowKey(0)". It will first save the current value for "outer:0:inner:0:myText" (which comes from outer's backup of it, restored on step 2)
The result of this process is that "outer"'s backup of "outer:0:inner:0:myText" overwrites "inner"'s backup for it. This is problematic because this leads, sometimes, to an old and obsolete backup
of state taking place of the current value. This may happen several HTTP requests later.
I've found a solution for this problem by not storing the saved state in the UIDataAdaptor, but in the target component itself. In this manner, there can only be one backup of the data. Such a modification is actually hinted at in UIDataAdaptor's source code : "// TODO - use local map - children save their state themselves using visitors", although my modification is simpler
(it's still UIDataAdaptor that saves the state, in the same manner, only in a different place).
This bug is quite complex and extracting a testcase will take some time, but I am willing to do so if requested. I can also offer my patch for the problem once I have finalized it.
> Nested UIDataAdaptor restoring stale data because of reentrancy problem
> -----------------------------------------------------------------------
>
> Key: RF-13703
> URL: https://issues.jboss.org/browse/RF-13703
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.3.1
> Environment: (Windows 7. Java 6. Jetty 7.6.9 or Tomcat 6.0.37)
> Reporter: Yannick Valot
>
> I am encountering a reentrancy problem with nested UIDataAdaptor components. For instance something like :
> {code}
> <rich:dataTable id="outer" ...>
> <rich:dataTable id="inner" ...>
> <h:inputText id="myText" ...>
> </rich:dataTable>
> </rich:dataTable>
> {code}
> When a view contains nested UIDataAdaptor components, each UIDataAdaptor component has its own internal store for saving the saved state of child components (saveChildState/restoreChildState). Since "inputText" is included in both tables, each one may save and restore the value of the component in its internal store.
> For instance, when "outer" is on key 0 and inner is on key "2", both "outer" and "inner" may store the state values for myText "outer:0:inner:2:myText" in their "childState" property.
> I guess that most of the time, only "inner" will actually store useful values, because most of calls on "setRowKey" for outer will be done when "inner" has its rowkey set to null. Unfortunately, this is not always the case.
> For instance, if I decide to visit the component tree while processing an event for "myText", outer will perform a setRowKey while inner has its own rowKey to a significant value (for instance, 2), the result being that inner's value will be erased by
> outer's.
> To try and explain with a little more detail... Let's say that we are processing an event on "outer:1:inner:0:myText", and we start a (nested) visit of the tree :
> 1) "outer" will at some point perform a setRowKey(0)
> 2) It will then do a restoreChildState for myText. since "inner" has rowKey set to 0, it will restore "outer's" value for "outer:0:inner:0:myText".
> 3) A bit later on during the visit, inner will do "setRowKey(0)". It will first save the current value for "outer:0:inner:0:myText" (which comes from outer's backup of it, restored on step 2)
> The result of this process is that "outer"'s backup of "outer:0:inner:0:myText" overwrites "inner"'s backup for it. This is problematic because this leads, sometimes, to an old and obsolete backup
> of state taking place of the current value. This may happen several HTTP requests later.
> I've found a solution for this problem by not storing the saved state in the UIDataAdaptor, but in the target component itself. In this manner, there can only be one backup of the data. Such a modification is actually hinted at in UIDataAdaptor's source code : "// TODO - use local map - children save their state themselves using visitors", although my modification is simpler
> (it's still UIDataAdaptor that saves the state, in the same manner, only in a different place).
> This bug is quite complex and extracting a testcase will take some time, but I am willing to do so if requested. I can also offer my patch for the problem once I have finalized it.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months
[JBoss JIRA] (RF-13694) Update README files for RichFaces 4.5.x
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13694?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13694:
-------------------------------
Fix Version/s: 4.5.0.Alpha3
> Update README files for RichFaces 4.5.x
> ---------------------------------------
>
> Key: RF-13694
> URL: https://issues.jboss.org/browse/RF-13694
> Project: RichFaces
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: doc
> Affects Versions: 4.5.0.Alpha3
> Reporter: Juraj Húska
> Priority: Minor
> Fix For: 4.5.0.Alpha3
>
>
> {{README.md}} and {{dist/src/main/resources/txt/readme.txt}} need to be updated with RichFaces 4.5.x.
> For {{README.md}} e.g.:
> * change of the title to RichFaces 4.5
> * remove "New approach to styling based on LESS"
> * alter "Smooth Migration from RF4 to RF5"
> and other
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months
[JBoss JIRA] (RF-13692) Photoalbum can not be deployed to WildFly 8.0.x or 8.1.x due to Weld exception
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13692?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13692:
-------------------------------
Fix Version/s: 4.5.0.Alpha3
> Photoalbum can not be deployed to WildFly 8.0.x or 8.1.x due to Weld exception
> ------------------------------------------------------------------------------
>
> Key: RF-13692
> URL: https://issues.jboss.org/browse/RF-13692
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: examples
> Affects Versions: 4.5.0.Alpha3
> Reporter: Juraj Húska
> Fix For: 4.5.0.Alpha3
>
>
> There is an error during deployment of Photoalbum example on WildFly 8.1.0.Final or 8.0.0.Final
> {code}
> 09:28:51,675 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."richfaces-photoalbum.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."richfaces-photoalbum.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:1145) [rt.jar:1.7.0_55]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55]
> Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:
> Exception 0 :
> org.jboss.weld.exceptions.IllegalStateException: WELD-001332: BeanManager method getBeans() is not available during application initialization
> at org.jboss.weld.bean.builtin.BeanManagerProxy.checkContainerValidated(BeanManagerProxy.java:159)
> at org.jboss.weld.bean.builtin.BeanManagerProxy.getBeans(BeanManagerProxy.java:91)
> at org.jboss.solder.core.CoreExtension.failIfWeldExtensionsDetected(CoreExtension.java:215)
> at org.jboss.solder.core.CoreExtension.afterBeanDiscovery(CoreExtension.java:208)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:93)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:266)
> at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:253)
> at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:232)
> at org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:169)
> at org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:128)
> at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:102)
> at org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:63)
> at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:35)
> at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:55)
> at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:372)
> at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:79)
> 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:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> at org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:37)
> at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:55)
> at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:372)
> at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:79)
> 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}
> and
> {code}
> JBAS014775: New missing/unsatisfied dependencies:
> service jboss.deployment.unit."richfaces-photoalbum.war".WeldBootstrapService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".WeldInstantiator, service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".WeldInstantiator, service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.WeldInstantiator, service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.WeldInterceptorBindingsService, JBAS014799: ... and 23 more ]
> service jboss.deployment.unit."richfaces-photoalbum.war".WeldStartService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".WeldInstantiator, service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".WeldInstantiator, service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.WeldInstantiator, service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.WeldInterceptorBindingsService, JBAS014799: ... and 22 more ]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.VIEW."org.richfaces.photoalbum.model.actions.IAlbumAction".LOCAL (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.WeldInterceptorBindingsService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.WeldInstantiator]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.VIEW."org.richfaces.photoalbum.model.actions.IEventAction".LOCAL (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.WeldInterceptorBindingsService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.WeldInstantiator]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.VIEW."org.richfaces.photoalbum.model.actions.IImageAction".LOCAL (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.WeldInterceptorBindingsService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.WeldInstantiator]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.VIEW."org.richfaces.photoalbum.search.ISearchAction".LOCAL (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.SearchAction.START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.VIEW."org.richfaces.photoalbum.model.actions.IShelfAction".LOCAL (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.WeldInterceptorBindingsService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.WeldInstantiator]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.ShelfAction.START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.VIEW."org.richfaces.photoalbum.model.actions.IUserAction".LOCAL (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.WeldInterceptorBindingsService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.WeldInstantiator]
> service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.ejb.non-functional-timerservice (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."com.sun.faces.config.ConfigureListener".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."com.sun.faces.config.ConfigureListener".START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."com.sun.faces.config.ConfigureListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."com.sun.faces.config.ConfigureListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."com.sun.faces.config.ConfigureListener".START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.faces.webapp.FacetTag".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.faces.webapp.FacetTag".START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.faces.webapp.FacetTag".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.VersionBean".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.VersionBean".START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.VersionBean".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.VersionBean".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.VersionBean".START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."managed-bean.org.richfaces.skin.SkinBean".START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.resourceLoader.servlet.ResourceListener".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.resourceLoader.servlet.ResourceListener".START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.resourceLoader.servlet.ResourceListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.resourceLoader.servlet.ResourceListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.resourceLoader.servlet.ResourceListener".START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeFilter".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeFilter".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeFilter".START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeListener".START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.exception.CatchExceptionFilter".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.exception.CatchExceptionFilter".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.exception.CatchExceptionFilter".START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldInitialListener".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldInitialListener".START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldInitialListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldInitialListener".START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldTerminalListener".CREATE (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldTerminalListener".START]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldTerminalListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService]
> service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.weld.servlet.WeldTerminalListener".START]
> service jboss.deployment.unit."richfaces-photoalbum.war".ee.ComponentRegistry (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService]
> service jboss.deployment.unit."richfaces-photoalbum.war".jndiDependencyService (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".START, service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START, service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START, service jboss.deployment.unit."richfaces-photoalbum.war".component.UserAction.START, JBAS014799: ... and 16 more ]
> service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformation (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."richfaces-photoalbum.war".component.AlbumAction.START, service jboss.deployment.unit."richfaces-photoalbum.war".component.ImageAction.START, service jboss.deployment.unit."richfaces-photoalbum.war".component.EventAction.START, JBAS014799: ... and 4 more ]
> service jboss.persistenceunit."richfaces-photoalbum.war#photoAlbum" (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".component."org.jboss.solder.servlet.event.ServletEventBridgeServlet".START, service jboss.deployment.unit."richfaces-photoalbum.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START, service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService, JBAS014799: ... and 13 more ]
> service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum (missing) dependents: [service jboss.deployment.unit."richfaces-photoalbum.war".deploymentCompleteService]
> service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum]
> service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.codec (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./richfaces-photoalbum.UndertowDeploymentInfoService]
> {code}
> Note that it *works* on EAP 6.2.3.GA and EAP 6.3.0.ER8
> Both WildFly containers use Weld 2.1.x, so it is not a problem with Weld 2.2.x integration.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
9 years, 10 months