[JBoss JIRA] (WFLY-2387) CDI injection in entity listeners failing
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-2387?page=com.atlassian.jira.plugin.... ]
Scott Marlow closed WFLY-2387.
------------------------------
> CDI injection in entity listeners failing
> -----------------------------------------
>
> Key: WFLY-2387
> URL: https://issues.jboss.org/browse/WFLY-2387
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Class Loading, JPA / Hibernate
> Affects Versions: 8.0.0.Beta1
> Reporter: Emond Papegaaij
> Assignee: Scott Marlow
> Fix For: 11.0.0.Alpha1
>
> Attachments: TEST-org.jboss.as.test.integration.ee.injection.support.jpa.EntityListenerInjectionSupportTestCase.xml
>
>
> When trying to use CDI injection in JPA entity listeners, deployment fails with the following exception:
> {code}
> 16:16:37,448 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 15) MSC000001: Failed to start service jboss.persistenceunit."inject-ear.ear#primary": org.jboss.msc.service.StartException in service jboss.persistenceunit."inject-ear.ear#primary": java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader@4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:169)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_25]
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:463) [wildfly-security-manager-1.0.0.Beta3.jar:1.0.0.Beta3]
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:178)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> Caused by: java.lang.IllegalStateException: JBAS016071: Singleton not set for org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl$AggregatedClassLoader@4eeb95dc. This means that you are trying to access a weld deployment with a Thread Context ClassLoader that is not associated with the deployment.
> at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:75)
> at org.jboss.as.weld.services.ModuleGroupSingletonProvider$TCCLSingleton.get(ModuleGroupSingletonProvider.java:128)
> at org.jboss.weld.Container.instance(Container.java:65)
> at org.jboss.weld.manager.BeanManagerImpl.getBeans(BeanManagerImpl.java:563)
> at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:90)
> at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358)
> at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369)
> at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
> at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60)
> at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
> at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
> at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:82)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory$BeanMetaData.<init>(BeanManagerListenerFactory.java:71)
> at org.hibernate.jpa.event.internal.jpa.BeanManagerListenerFactory.buildListener(BeanManagerListenerFactory.java:57)
> at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.resolveCallbacks(LegacyCallbackProcessor.java:168)
> at org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor.processCallbacksForEntity(LegacyCallbackProcessor.java:71)
> at org.hibernate.jpa.event.spi.JpaIntegrator.integrate(JpaIntegrator.java:150)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:310)
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1837)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:854)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl$4.perform(EntityManagerFactoryBuilderImpl.java:847)
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.withTccl(ClassLoaderServiceImpl.java:396)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:846)
> at org.jboss.as.jpa.hibernate4.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:151)
> ... 8 more
> {code}
> I've created a small showcase of the problem: https://github.com/papegaaij/listener-injection
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (WFLY-7754) WELD o.j.w.e.IllegalStateException after saved session does not auto-recover
by Darryl Miles (JIRA)
Darryl Miles created WFLY-7754:
----------------------------------
Summary: WELD o.j.w.e.IllegalStateException after saved session does not auto-recover
Key: WFLY-7754
URL: https://issues.jboss.org/browse/WFLY-7754
Project: WildFly
Issue Type: Bug
Components: CDI / Weld, Web (Undertow)
Affects Versions: 10.0.0.Final
Reporter: Darryl Miles
Assignee: Stuart Douglas
When modifying the WELD bean profile between starting/stopping WildFly with persistent session cookies over restart enabled.
It is possible to get an unrecoverable o.j.w.e.IllegalStateException.
What I mean by this is that if the AS knows the HTTP session cookie is a valid ID, but is unable to recover it from the persistence serialization over a restart (due to a change in the WELD BeanIdentifer instances changing to allow the optimization to work in this area). What the AS should do is simply log the problem and invalidate the session cookie completely. All this should happen in a transparent way to the WebApp, so it gets a null return or a brand new HttpSession.
This will automatically allow the HTTP client to recover, by forcing the application to generate a new HTTP session as necessary / or force logout, etc..
This is unrecoverable since the exception seems to be thrown at a level before it hits any WebApp application code. So it doesn't seem possible for the WebApp developer to correct the problem from the exception. Which makes sense since you need a HttpSession object to invoke #invalidate() on and it is recovering that that is.
Everytime the user refreshes all they get is the error and a HTTP/500 Internal Server Error and the user has to either delete their cookie, or the WildFly admin shutdown and remove any persistent session cookie data.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (WFCORE-1556) Poor handling of 'required', 'nillable' and 'alternatives' in AttributeDefinition
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1556?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1556:
------------------------------------------
Were "group-address", "group-port", "local-bind-address", "local-bind-port" ever part of subsystem=messaging-activemq? If not, transformation is not involved.
Transformation is only about different versions of the same subsystem (or kernel) API. subsystem=messaging and subsystem=messaging-activemq are distinct things and a DC managing a /profile=x/subsystem=messaging-activemq resource will make no attempt to make that resource look like /profile=x/subsystem=messaging for a legacy HC.
> Poor handling of 'required', 'nillable' and 'alternatives' in AttributeDefinition
> ---------------------------------------------------------------------------------
>
> Key: WFCORE-1556
> URL: https://issues.jboss.org/browse/WFCORE-1556
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha13
>
>
> The handling of the notions of 'required' and 'nillable' don't comply with the specs in https://docs.jboss.org/author/display/WFLY/Description+of+the+Management+..., particularly the "Description of an Attribute" part, where the 'required' and 'alternatives' fields are well described, with their relationship spelled out, while 'nillable' doesn't appear at all. Then in "Description of an Operation Parameter or Return Value" nillable is specified, although I think those descriptions could be tightened up in general.
> The read-resource-description output for an attribute doesn't show "required" at all.
> After a fair bit of thinking, I've finally recalled why the two separate notions of "required" and "nillable" exist in the first place.
> The "required" and "alternatives" pieces go together. Is something required? And then if it is required, an alternative satisfies. So you can have two attributes/params, both required, but they are alternatives so one is defined and the other is not. And this is an ok thing.
> And then 'nillable' comes in to help clients understand in a simple way whether they need to account for the possibility an undefined value. Basically:
> nillable = !required || alternatives != null
> Right now, nillable is implemented as
> nillable = !required
> There are a number of problems I see with AttributeDefinition:
> 1) We don't output the 'required' metadata unless it's an operation param being described. This is contrary to spec. However we shouldn't fix this unless we can have meaningful values for 'required', ones where the value can be true but the attribute/param can still have an undefined value, due to an alternative being present. If we can't fix that, there's no point outputting required as it's just redundant with what we output for 'nillable'.
> 2) We do output the 'nillable' metadata, even for attribute descriptions, where it isn't in the spec. But in this case I think we change the spec, as dropping nillable would be an incompatible change.
> 3) We don't properly validate the "required but has alternatives case." This can't be validated solely with ParameterValidator impls as those only see a single attribute value and don't have contextual information about other attributes/params. To get around this limitation, devs are saying that attributes with alternatives "allowNull" which is equivalent to saying they are not required. But they are required! So I think a fix for this will require AttributeDefinition itself to validate the overall resource model or operation object, and skip calling the ParameterValidator if the attribute/param is undefined and an alternative is defined.
> 4) AttributeDefinition and AbstractAttributeDefinitionBuilder unfortunately have a getter/setter/constructor param for property "allowNull" instead of a property named "required". This is unfortunate because "allowNull" intuitively maps to "nillable", but "required" is a much more useful thing to set. The value of "nillable" can be derived from a "required" setting and an "alternatives" setting, but the value of required cannot be so derived.
> I think a fix for this would probably start from 4), deprecating setAllowNull, adding get/setRequired and changing the meaning of the AD(Builder) constructor param to "required". The effect of this would be that all current code setting "allowNull" would now be setting a new "required" field. This should be a non-breaking change as in current code that's the effect anyway.
> Next would be to fix 3), by changing how AD validates.
> Next would be to change the metadata we output, such that "required" is always present and the "nillable" value is !required || alternatives != null. And change the spec accordingly.
> Last, in a separate task, would be to find attributes that were configuring "allowNull = true" solely to allow validation to pass when alternatives are present, and fix them to say "required=false".
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (WFLY-7753) Clustering XML readers are loaded eagerly
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-7753:
------------------------------------
Summary: Clustering XML readers are loaded eagerly
Key: WFLY-7753
URL: https://issues.jboss.org/browse/WFLY-7753
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.1.0.Final
Reporter: Radoslav Husar
Assignee: Radoslav Husar
[5:02 PM] Radoslav Husar: org.jboss.as.controller.parsing.ExtensionParsingContext#setSubsystemXmlMapping(java.lang.String, java.lang.String, java.util.function.Supplier<org.jboss.staxmapper.XMLElementReader<java.util.List<org.jboss.dmr.ModelNode>>>)
[5:02 PM] Radoslav Husar: I mean we want to be using^
[5:02 PM] Radoslav Husar: but we are using org.jboss.as.controller.parsing.ExtensionParsingContext#setSubsystemXmlMapping(java.lang.String, java.lang.String, org.jboss.staxmapper.XMLElementReader<java.util.List<org.jboss.dmr.ModelNode>>)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (WFLY-7746) Upgrade to a version of Infinispan that depends on JBoss Marshalling 2.0.0.Beta3
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7746?page=com.atlassian.jira.plugin.... ]
Farah Juma updated WFLY-7746:
-----------------------------
Attachment: org.jboss.as.test.clustering.cluster.sso.ClusteredSingleSignOnTestCase-SYNC-tcp-output.txt
> Upgrade to a version of Infinispan that depends on JBoss Marshalling 2.0.0.Beta3
> --------------------------------------------------------------------------------
>
> Key: WFLY-7746
> URL: https://issues.jboss.org/browse/WFLY-7746
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Clustering
> Reporter: Farah Juma
> Assignee: Paul Ferraro
> Attachments: org.jboss.as.test.clustering.cluster.sso.ClusteredSingleSignOnTestCase-SYNC-tcp-output.txt
>
>
> As part of the wildfly-naming-client integration work, we need to upgrade to JBoss Marshalling 2.0.0.Beta3 (see WFCORE-2044 and WFLY-7675). This upgrade currently results in testsuite failures in {{org.jboss.as.test.clustering.cluster.sso.ClusteredSingleSignOnTestCase}} since Infinispan is still on JBoss Marshalling 1.4.x.
> ISPN-3391 was created a while back to upgrade Infinispan to JBoss Marshalling 2.0.0 but it seems this issue was waiting on a JBoss Marshalling release that adds back some classes that had previously been removed. JBoss Marshalling 2.0.0.Beta3 contains these classes so it should be possible now to upgrade Infinispan to this new version.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (WFLY-7746) Upgrade to a version of Infinispan that depends on JBoss Marshalling 2.0.0.Beta3
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7746?page=com.atlassian.jira.plugin.... ]
Farah Juma commented on WFLY-7746:
----------------------------------
[~pferraro] The tests in ClusteredSingleSignOnTestCase fail with the following error:
{code}
java.lang.AssertionError: Should see HTTP_MOVED_TEMP. Got 200
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.jboss.as.test.integration.web.sso.SSOTestBase.executeFormLogin(SSOTestBase.java:257)
at org.jboss.as.test.integration.web.sso.SSOTestBase.executeFormAuthSSOTimeoutTest(SSOTestBase.java:190)
at org.jboss.as.test.clustering.cluster.sso.ClusteredSingleSignOnTestCase.testSessionTimeoutDestroysSSO(ClusteredSingleSignOnTestCase.java:148)
{code}
The test output file shows the following issue that occurs during un-marshalling (I've also attached the full test output):
{code}
[11:42:08,249] WARN [org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher] (thread-19,ee,node-1) IS
PN000220: Problems un-marshalling remote command from byte buffer: java.lang.AbstractMethodError: org.infinispan.commons.marsh
all.jboss.JBossExternalizerAdapter.createExternal(Ljava/lang/Class;Ljava/io/ObjectInput;)Ljava/lang/Object;
{code}
Note that we'll need a fix for these tests for WildFly 11 since the JBoss Marshalling upgrade is part of the Elytron-related integration work.
> Upgrade to a version of Infinispan that depends on JBoss Marshalling 2.0.0.Beta3
> --------------------------------------------------------------------------------
>
> Key: WFLY-7746
> URL: https://issues.jboss.org/browse/WFLY-7746
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Clustering
> Reporter: Farah Juma
> Assignee: Paul Ferraro
> Attachments: org.jboss.as.test.clustering.cluster.sso.ClusteredSingleSignOnTestCase-SYNC-tcp-output.txt
>
>
> As part of the wildfly-naming-client integration work, we need to upgrade to JBoss Marshalling 2.0.0.Beta3 (see WFCORE-2044 and WFLY-7675). This upgrade currently results in testsuite failures in {{org.jboss.as.test.clustering.cluster.sso.ClusteredSingleSignOnTestCase}} since Infinispan is still on JBoss Marshalling 1.4.x.
> ISPN-3391 was created a while back to upgrade Infinispan to JBoss Marshalling 2.0.0 but it seems this issue was waiting on a JBoss Marshalling release that adds back some classes that had previously been removed. JBoss Marshalling 2.0.0.Beta3 contains these classes so it should be possible now to upgrade Infinispan to this new version.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (WFLY-7746) Upgrade to a version of Infinispan that depends on JBoss Marshalling 2.0.0.Beta3
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7746?page=com.atlassian.jira.plugin.... ]
Farah Juma updated WFLY-7746:
-----------------------------
Attachment: org.jboss.as.test.clustering.cluster.sso.ClusteredSingleSignOnTestCase-SYNC-tcp.txt
> Upgrade to a version of Infinispan that depends on JBoss Marshalling 2.0.0.Beta3
> --------------------------------------------------------------------------------
>
> Key: WFLY-7746
> URL: https://issues.jboss.org/browse/WFLY-7746
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Clustering
> Reporter: Farah Juma
> Assignee: Paul Ferraro
>
> As part of the wildfly-naming-client integration work, we need to upgrade to JBoss Marshalling 2.0.0.Beta3 (see WFCORE-2044 and WFLY-7675). This upgrade currently results in testsuite failures in {{org.jboss.as.test.clustering.cluster.sso.ClusteredSingleSignOnTestCase}} since Infinispan is still on JBoss Marshalling 1.4.x.
> ISPN-3391 was created a while back to upgrade Infinispan to JBoss Marshalling 2.0.0 but it seems this issue was waiting on a JBoss Marshalling release that adds back some classes that had previously been removed. JBoss Marshalling 2.0.0.Beta3 contains these classes so it should be possible now to upgrade Infinispan to this new version.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months
[JBoss JIRA] (WFLY-7746) Upgrade to a version of Infinispan that depends on JBoss Marshalling 2.0.0.Beta3
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7746?page=com.atlassian.jira.plugin.... ]
Farah Juma updated WFLY-7746:
-----------------------------
Attachment: (was: org.jboss.as.test.clustering.cluster.sso.ClusteredSingleSignOnTestCase-SYNC-tcp.txt)
> Upgrade to a version of Infinispan that depends on JBoss Marshalling 2.0.0.Beta3
> --------------------------------------------------------------------------------
>
> Key: WFLY-7746
> URL: https://issues.jboss.org/browse/WFLY-7746
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Clustering
> Reporter: Farah Juma
> Assignee: Paul Ferraro
>
> As part of the wildfly-naming-client integration work, we need to upgrade to JBoss Marshalling 2.0.0.Beta3 (see WFCORE-2044 and WFLY-7675). This upgrade currently results in testsuite failures in {{org.jboss.as.test.clustering.cluster.sso.ClusteredSingleSignOnTestCase}} since Infinispan is still on JBoss Marshalling 1.4.x.
> ISPN-3391 was created a while back to upgrade Infinispan to JBoss Marshalling 2.0.0 but it seems this issue was waiting on a JBoss Marshalling release that adds back some classes that had previously been removed. JBoss Marshalling 2.0.0.Beta3 contains these classes so it should be possible now to upgrade Infinispan to this new version.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 7 months