[JBoss JIRA] (WFLY-9597) UndertowSubsystemParser_5_0 could be instantiated twice: once as a reader and once as a writer
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-9597?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-9597:
------------------------------------
If we're concerned about metaspace costs, we should consider eliminating the need for each consumer of PersistentResourceDefinition to create subclasses of PersistentResourceXmlParser per version (since these classes are loaded regardless of whether they are instantiated). Additionally, the PersistentResourceXmlParser subclasses for non-current versions unnecessarily implement XMLElementWriter<ModelNode>, the implementations of which are never used.
Instead, we could create 2 concrete classes, let's call them PersistentResourceXmlReader and PersistentResourceXMLWriter, each constructed with a version specific PersistentResourceXMLDescription (or Supplier<PersistentResourceXMLDescription>). This way the PersistentResourceXMLDescription is still shared across writer and current reader, and we don't need all those extra subclasses per version per subsystem.
> UndertowSubsystemParser_5_0 could be instantiated twice: once as a reader and once as a writer
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-9597
> URL: https://issues.jboss.org/browse/WFLY-9597
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Radoslav Husar
> Assignee: Tomaz Cerar
>
> The org.wildfly.extension.undertow.UndertowSubsystemParser_5_0#xmlDescription could be created twice, the first and last line in the diff should return the same instance or use different approach: https://github.com/rhusar/wildfly/blob/7dbc8bd0c8bcdae5db61ecdff1484a422c...
> Most likely the same issue is in multiple places.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-9074) NPE o.j.a.ejb3.component.stateful.StatefulComponentSessionIdGeneratingInterceptor.processInvocation()
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/WFLY-9074?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski commented on WFLY-9074:
--------------------------------------
OK thanks for info. I just wanted to confirm that the reproducer that I created has the same failure scenario. Anyway, the fix have been merged already and you shouldn't encounter this problem from WildFly 12.
> NPE o.j.a.ejb3.component.stateful.StatefulComponentSessionIdGeneratingInterceptor.processInvocation()
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-9074
> URL: https://issues.jboss.org/browse/WFLY-9074
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Reporter: Darryl Miles
> Assignee: Tomasz Adamski
> Fix For: 12.0.0.Alpha1
>
>
> https://issues.jboss.org/browse/WFLY-6663 (see fix for this other bug, maybe the 1 line wait method is needed somewhere else too?)
> Much more intermittent matter (I guess the time window is smaller).
> 16:14:04,428 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 19) MSC000001: Failed to start service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163)
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:138)
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> ... 6 more
> Caused by: javax.ejb.EJBException: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:83)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:91)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:106)
> at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.singleton.StartupCountDownInterceptor.processInvocation(StartupCountDownInterceptor.java:25)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
> ... 11 more
> Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:319)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:97)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> ... 28 more
> Caused by: javax.naming.NameNotFoundException: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb [Root exception is java.lang.IllegalStateException: WFLYEE0046: Failed to instantiate component view]
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:153)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
> ... 45 more
> Caused by: java.lang.IllegalStateException: WFLYEE0046: Failed to instantiate component view
> at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:58)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143)
> ... 50 more
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ejb3.component.stateful.StatefulComponentSessionIdGeneratingInterceptor.processInvocation(StatefulComponentSessionIdGeneratingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$DefaultViewInstanceFactory.createViewInstance(ViewService.java:305)
> at org.jboss.as.ee.component.ViewService$View.createInstance(ViewService.java:184)
> at org.jboss.as.ee.component.ViewService$View.createInstance(ViewService.java:174)
> at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:56)
> ... 51 more
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-9074) NPE o.j.a.ejb3.component.stateful.StatefulComponentSessionIdGeneratingInterceptor.processInvocation()
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/WFLY-9074?page=com.atlassian.jira.plugin.... ]
Darryl Miles edited comment on WFLY-9074 at 12/5/17 5:30 PM:
-------------------------------------------------------------
[~tomekadamski] Yes there are a number of "@Startup" with "@Singleton" EJBs across the entire application.
Some have non-default "@TransactionManager" and/or "@ConcurrencyManagement" all combinations exist across the application.
was (Author: dlmiles):
[~tomekadamski] Yes there are a number of "@Startup" and "@Singleton" EJBs across the entire application.
> NPE o.j.a.ejb3.component.stateful.StatefulComponentSessionIdGeneratingInterceptor.processInvocation()
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-9074
> URL: https://issues.jboss.org/browse/WFLY-9074
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Reporter: Darryl Miles
> Assignee: Tomasz Adamski
> Fix For: 12.0.0.Alpha1
>
>
> https://issues.jboss.org/browse/WFLY-6663 (see fix for this other bug, maybe the 1 line wait method is needed somewhere else too?)
> Much more intermittent matter (I guess the time window is smaller).
> 16:14:04,428 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 19) MSC000001: Failed to start service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163)
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:138)
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> ... 6 more
> Caused by: javax.ejb.EJBException: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:83)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:91)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:106)
> at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.singleton.StartupCountDownInterceptor.processInvocation(StartupCountDownInterceptor.java:25)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
> ... 11 more
> Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:319)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:97)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> ... 28 more
> Caused by: javax.naming.NameNotFoundException: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb [Root exception is java.lang.IllegalStateException: WFLYEE0046: Failed to instantiate component view]
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:153)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
> ... 45 more
> Caused by: java.lang.IllegalStateException: WFLYEE0046: Failed to instantiate component view
> at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:58)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143)
> ... 50 more
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ejb3.component.stateful.StatefulComponentSessionIdGeneratingInterceptor.processInvocation(StatefulComponentSessionIdGeneratingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$DefaultViewInstanceFactory.createViewInstance(ViewService.java:305)
> at org.jboss.as.ee.component.ViewService$View.createInstance(ViewService.java:184)
> at org.jboss.as.ee.component.ViewService$View.createInstance(ViewService.java:174)
> at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:56)
> ... 51 more
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-9074) NPE o.j.a.ejb3.component.stateful.StatefulComponentSessionIdGeneratingInterceptor.processInvocation()
by Darryl Miles (JIRA)
[ https://issues.jboss.org/browse/WFLY-9074?page=com.atlassian.jira.plugin.... ]
Darryl Miles commented on WFLY-9074:
------------------------------------
[~tomekadamski] Yes there are a number of "@Startup" and "@Singleton" EJBs across the entire application.
> NPE o.j.a.ejb3.component.stateful.StatefulComponentSessionIdGeneratingInterceptor.processInvocation()
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-9074
> URL: https://issues.jboss.org/browse/WFLY-9074
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 10.1.0.Final
> Reporter: Darryl Miles
> Assignee: Tomasz Adamski
> Fix For: 12.0.0.Alpha1
>
>
> https://issues.jboss.org/browse/WFLY-6663 (see fix for this other bug, maybe the 1 line wait method is needed somewhere else too?)
> Much more intermittent matter (I guess the time window is smaller).
> 16:14:04,428 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 19) MSC000001: Failed to start service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: org.jboss.msc.service.StartException in service jboss.deployment.subunit."com.domain.ear-0.0.1-SNAPSHOT.ear"."com-domain-ejb.main-0.0.1-SNAPSHOT.jar".component.MainStartupEjbImpl.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163)
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
> at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:138)
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> ... 6 more
> Caused by: javax.ejb.EJBException: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> at org.jboss.as.ejb3.tx.BMTInterceptor.handleException(BMTInterceptor.java:83)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.checkStatelessDone(EjbBMTInterceptor.java:91)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:106)
> at org.jboss.as.ejb3.tx.BMTInterceptor.processInvocation(BMTInterceptor.java:58)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.singleton.StartupCountDownInterceptor.processInvocation(StartupCountDownInterceptor.java:25)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
> ... 11 more
> Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb
> at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:319)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:97)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.ManagedReferenceFieldInjectionInterceptorFactory$ManagedReferenceFieldInjectionInterceptor.processInvocation(ManagedReferenceFieldInjectionInterceptorFactory.java:107)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.tx.EjbBMTInterceptor.handleInvocation(EjbBMTInterceptor.java:103)
> ... 28 more
> Caused by: javax.naming.NameNotFoundException: env/com.domain.ejb.main.impl.MainStartupEjbImpl/mainEjb [Root exception is java.lang.IllegalStateException: WFLYEE0046: Failed to instantiate component view]
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:153)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:83)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:207)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> at org.jboss.as.naming.deployment.ContextNames$BindInfo$1$1.getReference(ContextNames.java:316)
> ... 45 more
> Caused by: java.lang.IllegalStateException: WFLYEE0046: Failed to instantiate component view
> at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:58)
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:143)
> ... 50 more
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ejb3.component.stateful.StatefulComponentSessionIdGeneratingInterceptor.processInvocation(StatefulComponentSessionIdGeneratingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$DefaultViewInstanceFactory.createViewInstance(ViewService.java:305)
> at org.jboss.as.ee.component.ViewService$View.createInstance(ViewService.java:184)
> at org.jboss.as.ee.component.ViewService$View.createInstance(ViewService.java:174)
> at org.jboss.as.ee.component.ViewManagedReferenceFactory.getReference(ViewManagedReferenceFactory.java:56)
> ... 51 more
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFCORE-3448) Unable to set multiple ssl protocols and ciphers on security-realms using system properties
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3448?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3448:
-------------------------------------
Issue Type: Enhancement (was: Bug)
> Unable to set multiple ssl protocols and ciphers on security-realms using system properties
> -------------------------------------------------------------------------------------------
>
> Key: WFCORE-3448
> URL: https://issues.jboss.org/browse/WFCORE-3448
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Derek Horton
> Assignee: Brian Stansberry
>
> It is not possible to set the ssl protocol and ciphers on a security-realm using system property if multiple protocols and/or ciphers are needed.
> Setting the "enabled-cipher-suites" and "enabled-protocols" using a system property works if the system property value resolves to a single value ("TLSv1.2" for example).
> An error is thrown if the system property has multiple values (-Dtlsversion="TLSv1.1 TLSv1.2"). Here is the error that is generated:
> 13:20:43,315 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.core.management.security.realm.ManagementRealm.ssl-context: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.ManagementRealm.ssl-context: WFLYDM0096: No protocols in common, supported=([SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2]), requested=([TLSv1.1 TLSv1.2])
> at org.jboss.as.domain.management.security.SSLContextService.wrapSslContext(SSLContextService.java:137)
> at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:102)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> 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:745)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFCORE-3448) Unable to set multiple ssl protocols and ciphers on security-realms using system properties
by Derek Horton (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3448?page=com.atlassian.jira.plugi... ]
Derek Horton updated WFCORE-3448:
---------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2972
Steps to Reproduce:
- add a security-realm that has ssl enabled
<security-realm name="CertificateRealm">
<server-identities>
<ssl>
<engine enabled-cipher-suites="${tlscipher}" enabled-protocols="${tlsversion}"/>
<keystore path="/home/dehort/dev/java/jboss-eap-6.4.17/domain/configuration/server.keystore" keystore-password="123456" alias="serverkeys"/>
</ssl>
</server-identities>
</security-realm>
- start JBoss with the required system properties (must use multiple values to reproduce the issue)
./bin/standalone.sh -Dtlscipher="TLS_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA" -Dtlsversion="TLSv1.1 TLSv1.2"
was:
- add a security-realm that has ssl enabled
<security-realm name="CertificateRealm">
<server-identities>
<ssl>
<engine enabled-cipher-suites="${tlscipher}" enabled-protocols="${tlsversion}"/>
<keystore path="/home/dehort/dev/java/jboss-eap-6.4.17/domain/configuration/server.keystore" keystore-password="123456" alias="serverkeys"/>
</ssl>
</server-identities>
</security-realm>
- start JBoss with the required system properties (must use multiple values to reproduce the issue)
./bin/standalone.sh -Dtlscipher="TLS_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA" -Dtlsversion="TLSv1.1 TLSv1.2"
> Unable to set multiple ssl protocols and ciphers on security-realms using system properties
> -------------------------------------------------------------------------------------------
>
> Key: WFCORE-3448
> URL: https://issues.jboss.org/browse/WFCORE-3448
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Derek Horton
> Assignee: Brian Stansberry
>
> It is not possible to set the ssl protocol and ciphers on a security-realm using system property if multiple protocols and/or ciphers are needed.
> Setting the "enabled-cipher-suites" and "enabled-protocols" using a system property works if the system property value resolves to a single value ("TLSv1.2" for example).
> An error is thrown if the system property has multiple values (-Dtlsversion="TLSv1.1 TLSv1.2"). Here is the error that is generated:
> 13:20:43,315 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.core.management.security.realm.ManagementRealm.ssl-context: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.ManagementRealm.ssl-context: WFLYDM0096: No protocols in common, supported=([SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2]), requested=([TLSv1.1 TLSv1.2])
> at org.jboss.as.domain.management.security.SSLContextService.wrapSslContext(SSLContextService.java:137)
> at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:102)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> 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:745)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFCORE-3449) [GSS] (7.x) Unable to set multiple ssl protocols and ciphers on security-realms using system properties
by Derek Horton (JIRA)
Derek Horton created WFCORE-3449:
------------------------------------
Summary: [GSS] (7.x) Unable to set multiple ssl protocols and ciphers on security-realms using system properties
Key: WFCORE-3449
URL: https://issues.jboss.org/browse/WFCORE-3449
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Derek Horton
Assignee: Brian Stansberry
It is not possible to set the ssl protocol and ciphers on a security-realm using system property if multiple protocols and/or ciphers are needed.
Setting the "enabled-cipher-suites" and "enabled-protocols" using a system property works if the system property value resolves to a single value ("TLSv1.2" for example).
An error is thrown if the system property has multiple values (-Dtlsversion="TLSv1.1 TLSv1.2"). Here is the error that is generated:
13:20:43,315 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.core.management.security.realm.ManagementRealm.ssl-context: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.ManagementRealm.ssl-context: WFLYDM0096: No protocols in common, supported=([SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2]), requested=([TLSv1.1 TLSv1.2])
at org.jboss.as.domain.management.security.SSLContextService.wrapSslContext(SSLContextService.java:137)
at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:102)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
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:745)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFCORE-3448) Unable to set multiple ssl protocols and ciphers on security-realms using system properties
by Derek Horton (JIRA)
Derek Horton created WFCORE-3448:
------------------------------------
Summary: Unable to set multiple ssl protocols and ciphers on security-realms using system properties
Key: WFCORE-3448
URL: https://issues.jboss.org/browse/WFCORE-3448
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Derek Horton
Assignee: Brian Stansberry
It is not possible to set the ssl protocol and ciphers on a security-realm using system property if multiple protocols and/or ciphers are needed.
Setting the "enabled-cipher-suites" and "enabled-protocols" using a system property works if the system property value resolves to a single value ("TLSv1.2" for example).
An error is thrown if the system property has multiple values (-Dtlsversion="TLSv1.1 TLSv1.2"). Here is the error that is generated:
13:20:43,315 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service org.wildfly.core.management.security.realm.ManagementRealm.ssl-context: org.jboss.msc.service.StartException in service org.wildfly.core.management.security.realm.ManagementRealm.ssl-context: WFLYDM0096: No protocols in common, supported=([SSLv2Hello, SSLv3, TLSv1, TLSv1.1, TLSv1.2]), requested=([TLSv1.1 TLSv1.2])
at org.jboss.as.domain.management.security.SSLContextService.wrapSslContext(SSLContextService.java:137)
at org.jboss.as.domain.management.security.SSLContextService.start(SSLContextService.java:102)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
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:745)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-9597) UndertowSubsystemParser_5_0 could be instantiated twice: once as a reader and once as a writer
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-9597?page=com.atlassian.jira.plugin.... ]
Brian Stansberry edited comment on WFLY-9597 at 12/5/17 1:14 PM:
-----------------------------------------------------------------
Part of the reason I filed WFCORE-3441 is I wanted consideration of this kind thing before people started just blindly moving to a Supplier in order to make a deprecation warn go away.
There are a number of intersecting factors to balance in all this.
1) If the parsers and marshallers are basically stateless objects, the class space for the Supplier is more than the cost of an object.
2) A PersistentResourceXMLParser implementation may or may not be stateless, depending on how it is coded. Some store the PersistentResourceXMLDescription in a static field (making the class itself somewhat heavy but an instance stateless), some in an instance field, and some calculate it on the fly.
3) For the current version of a parser, it's actually important to boot time that a PersistentResourceXMLDescription be created during Extension.initializeParsers and not deferred to when parsing happens. Extension.initializeParsers is done concurrently while parsing is single threaded, and creating the PersistentResourceXMLDescription ends up being the trigger that loads most of the extension's management model classes, creates AttributeDefinitions etc.
Likely the most efficient way to do this with a PersistentResourceXMLParser is:
{code}
class FooExtension implements Extension {
private volatile PersistentResourceXmlParser currentParserMarshaller;
private PersistentResourceXmlParser getCurrentParserMarshaller() {
PersistentResourceXmlParser result = currentParserMarshaller;
if (result == null) {
result = currentParserMarshaller = new FooParser3_0();
}
return result;
}
public void initializeParsers(ExtensionParsingContext context) {
.... register legacy parsers using the Supplier API
context.setSubsystemXmlMapping("foo", FOO_3_URI, getCurrentParserMarshaller());
}
public void initialize(ExtensionContext context) {
.... do the other stuff
subsystem.registerXMLElementWriter(getCurrentParserMarshaller());
}
}
{code}
The PersistentResourceXmlParser subclass itself would not cache the PersistentResourceXMLDescription, it would create it when asked. The ExtensionRegistry itself triggers a single-use caching of the PersistentResourceXMLDescription if a PersistentResourceXmlParser is passed to context.setSubsystemXmlMapping. It's a single use cache, so when the document is parsed at boot it would be discarded.
All of this is black art, which sucks. But barring a rewrite of Extension etc, which isn't happening for WF 12, I think black art is what we need to do.
was (Author: brian.stansberry):
Part of the reason I filed WFCORE-3441 is I wanted consideration of this kind thing before people started just blindly moving to a Supplier in order to make a deprecation warn go away.
There are a number of intersecting factors to balance in all this.
1) If the parsers and marshallers are basically stateless objects, the class space for the Supplier is more than the cost of an object.
2) A PersistentResourceXMLParser implementation may or may not be stateless, depending on how it is coded. Some store the PersistentResourceXMLDescription in a static field (making the class itself somewhat heavy but an instance stateless), some in an instance field, and some calculate it on the fly.
3) For the current version of a parser, it's actually important to boot time that a PersistentResourceXMLDescription be created during Extension.initializeParsers and not deferred to when parsing happens. Extension.initializeParsers is done concurrently while parsing is single threaded, and creating the PersistentResourceXMLDescription ends up being the trigger that loads most of the extensions management model classes, creates AttributeDefinitions etc.
Likely the most efficient way to do this with a PersistentResourceXMLParser is:
{code}
class FooExtension implements Extension {
private volatile PersistentResourceXmlParser currentParserMarshaller;
private PersistentResourceXmlParser getCurrentParserMarshaller() {
PersistentResourceXmlParser result = currentParserMarshaller;
if (result == null) {
result = currentParserMarshaller = new FooParser3_0();
}
return result;
}
public void initializeParsers(ExtensionParsingContext context) {
.... register legacy parsers using the Supplier API
context.setSubsystemXmlMapping("foo", FOO_3_URI, getCurrentParserMarshaller());
}
public void initialize(ExtensionContext context) {
.... do the other stuff
subsystem.registerXMLElementWriter(getCurrentParserMarshaller());
}
}
{code}
That's kind of fussy code, but oh well.
> UndertowSubsystemParser_5_0 could be instantiated twice: once as a reader and once as a writer
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-9597
> URL: https://issues.jboss.org/browse/WFLY-9597
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Radoslav Husar
> Assignee: Tomaz Cerar
>
> The org.wildfly.extension.undertow.UndertowSubsystemParser_5_0#xmlDescription could be created twice, the first and last line in the diff should return the same instance or use different approach: https://github.com/rhusar/wildfly/blob/7dbc8bd0c8bcdae5db61ecdff1484a422c...
> Most likely the same issue is in multiple places.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months