[JBoss JIRA] (WFLY-2387) CDI injection in entity listeners failing
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2387?page=com.atlassian.jira.plugin.... ]
Stuart Douglas reassigned WFLY-2387:
------------------------------------
Assignee: Scott Marlow (was: Stuart Douglas)
I have submitted a PR that fixes the Class Loader problem:
https://github.com/wildfly/wildfly/pull/5400
It is not possible to inject the BeanManager, but injection of beans will fail because weld has not fully started yet. This is a JPA problem, it *must* create the listener lazily if weld injection is to work properly, as weld cannot fully start without JPA having already started.
For the most obvious case of why this is required according to the spec it should be possible to inject the EntityManager into the listener. Obviously if the listener is being created before hibernate has finished starting there is absolutely no way we can accomplish this.
> CDI injection in entity listeners failing
> -----------------------------------------
>
> Key: WFLY-2387
> URL: https://issues.jboss.org/browse/WFLY-2387
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, Class Loading, JPA / Hibernate
> Affects Versions: 8.0.0.Beta1
> Reporter: Emond Papegaaij
> Assignee: Scott Marlow
> Fix For: 8.0.0.CR1
>
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2317) Trying to remove a server group as a server-group-scoped role leaks information
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2317?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2317:
-----------------------------------------------
Ladislav Thon <lthon(a)redhat.com> changed the Status of [bug 1019784|https://bugzilla.redhat.com/show_bug.cgi?id=1019784] from ON_QA to VERIFIED
> Trying to remove a server group as a server-group-scoped role leaks information
> -------------------------------------------------------------------------------
>
> Key: WFLY-2317
> URL: https://issues.jboss.org/browse/WFLY-2317
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Ladislav Thon
> Assignee: Brian Stansberry
> Labels: rbac-filed-by-qa
> Fix For: 8.0.0.CR1
>
>
> When writing a small test case for WFLY-2190, I stumbled upon a problem: trying to remove an existing server group by a server-group-scoped user that does NOT have permissions to that server group leaks information. On a freshly built WildFly with added {{admin}} user into {{domain/configuration/mgmt-users.properties}}, it can be reproduced like this:
> {code}
> [1] ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c
> /core-service=management/access=authorization/server-group-scoped-role=NewRole:add(base-role=administrator, server-groups=[main-server-group])
> /core-service=management/access=authorization/role-mapping=NewRole:add
> /core-service=management/access=authorization/role-mapping=NewRole/include=user-admin:add(name=admin, type=user)
> /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
> exit
> [1] ^C
> ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c --user=admin --password=XXX
> /server-group=other-server-group:read-resource
> /server-group=other-server-group:remove
> {code}
> What does that mean? The {{NewRole}} is scoped to the {{main-server-group}} server group and can't see {{other-server-group}}. When doing {{/server-group=other-server-group:read-resource}}, this is correctly enforced and the output looks like this:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"other-server-group\")]' not found",
> "rolled-back" => true
> }
> {code}
> However, trying to do {{/server-group=other-server-group:remove}}, which is only a different operation _on the same resource_, I get a different error message:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {"domain-failure-description" => "JBAS013456: Unauthorized to execute operation 'remove' for resource '[(\"server-group\" => \"other-server-group\")]' -- \"JBAS013475: Permission denied\""},
> "rolled-back" => true
> }
> {code}
> I expect the error message to be completely the same as in previous case, not leaking any information that the {{other-server-group}} actually exists.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2317) Trying to remove a server group as a server-group-scoped role leaks information
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2317?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2317:
-----------------------------------------------
Ladislav Thon <lthon(a)redhat.com> made a comment on [bug 1019784|https://bugzilla.redhat.com/show_bug.cgi?id=1019784]
Verified with EAP 6.2.0.ER7.
> Trying to remove a server group as a server-group-scoped role leaks information
> -------------------------------------------------------------------------------
>
> Key: WFLY-2317
> URL: https://issues.jboss.org/browse/WFLY-2317
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Ladislav Thon
> Assignee: Brian Stansberry
> Labels: rbac-filed-by-qa
> Fix For: 8.0.0.CR1
>
>
> When writing a small test case for WFLY-2190, I stumbled upon a problem: trying to remove an existing server group by a server-group-scoped user that does NOT have permissions to that server group leaks information. On a freshly built WildFly with added {{admin}} user into {{domain/configuration/mgmt-users.properties}}, it can be reproduced like this:
> {code}
> [1] ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c
> /core-service=management/access=authorization/server-group-scoped-role=NewRole:add(base-role=administrator, server-groups=[main-server-group])
> /core-service=management/access=authorization/role-mapping=NewRole:add
> /core-service=management/access=authorization/role-mapping=NewRole/include=user-admin:add(name=admin, type=user)
> /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
> exit
> [1] ^C
> ./bin/domain.sh
> [2] ./bin/jboss-cli.sh -c --user=admin --password=XXX
> /server-group=other-server-group:read-resource
> /server-group=other-server-group:remove
> {code}
> What does that mean? The {{NewRole}} is scoped to the {{main-server-group}} server group and can't see {{other-server-group}}. When doing {{/server-group=other-server-group:read-resource}}, this is correctly enforced and the output looks like this:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014807: Management resource '[(\"server-group\" => \"other-server-group\")]' not found",
> "rolled-back" => true
> }
> {code}
> However, trying to do {{/server-group=other-server-group:remove}}, which is only a different operation _on the same resource_, I get a different error message:
> {code}
> {
> "outcome" => "failed",
> "failure-description" => {"domain-failure-description" => "JBAS013456: Unauthorized to execute operation 'remove' for resource '[(\"server-group\" => \"other-server-group\")]' -- \"JBAS013475: Permission denied\""},
> "rolled-back" => true
> }
> {code}
> I expect the error message to be completely the same as in previous case, not leaking any information that the {{other-server-group}} actually exists.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-1893) Restarting server with a disabled DS enables the DS
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1893?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1893:
-----------------------------------------------
Radim Hatlapatka <rhatlapa(a)redhat.com> made a comment on [bug 952277|https://bugzilla.redhat.com/show_bug.cgi?id=952277]
Verified with EAP 6.2.0.ER7
> Restarting server with a disabled DS enables the DS
> ---------------------------------------------------
>
> Key: WFLY-1893
> URL: https://issues.jboss.org/browse/WFLY-1893
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA
> Reporter: Kabir Khan
> Assignee: Stefano Maestri
>
> See https://issues.jboss.org/browse/WFLY-1874
> If you add a datasource with
> subsystem=datasources/data-source=Test:add(jndi-name=java:/Test,jta=false,use-ccm=false,connection-url=url,driver-class=org.h2.Driver,driver-name=h2,user-name=user,password=pass,validate-on-match=false,background-validation=false,share-prepared-statements=false)
> it shows up as not enabled/undefined:
> {code}
> [standalone@localhost:9990 /] /subsystem=datasources/data-source=Test:read-resource{ "outcome" => "success",
> "result" => {
> ...
> "enabled" => false,
> {code}
> {code}
> [standalone@localhost:9990 /] /subsystem=datasources/data-source=Test:read-resource(include-defaults=false)
> {
> "outcome" => "success",
> "result" => {
> ... "enabled" => undefined,
> {code}
> This is persisted as
> {code}
> <datasource jta="false" jndi-name="java:/Test" pool-name="Test" enabled="false" use-ccm="false">
> <connection-url>url</connection-url>
> <driver-class>org.h2.Driver</driver-class>
> <driver>h2</driver>
> <security>
> <user-name>user</user-name>
> <password>pass</password>
> </security>
> <validation>
> <validate-on-match>false</validate-on-match>
> <background-validation>false</background-validation>
> </validation>
> <statement>
> <share-prepared-statements>false</share-prepared-statements>
> </statement>
> </datasource>
> {code}
> Now if you stop and start the server again you end up with enabled=true.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-1933) Disabled data-source without explicit enabled="false" in configuration xml file is re-enabled again after server reload
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1933?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1933:
-----------------------------------------------
Radim Hatlapatka <rhatlapa(a)redhat.com> changed the Status of [bug 952277|https://bugzilla.redhat.com/show_bug.cgi?id=952277] from ON_QA to VERIFIED
> Disabled data-source without explicit enabled="false" in configuration xml file is re-enabled again after server reload
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1933
> URL: https://issues.jboss.org/browse/WFLY-1933
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA
> Affects Versions: 8.0.0.Alpha4
> Reporter: Ivo Studensky
> Assignee: Ivo Studensky
>
> The server automatically re-enables a data-source which was disabled before and which lost {{enabled="false"}} in the configuration XML file.
> There is a discrepancy between the default value of the {{enabled}} attribute in XSD and the same attribute definition in org.jboss.as.connector.subsystems.datasources.Constants. From my POV any data-source that has been disabled before should stay in that state unless it is explicitly enabled again. See https://bugzilla.redhat.com/show_bug.cgi?id=952277 for a reproducer.
> The culprit seems to be
> {code:java|title=org.jboss.as.connector.subsystems.datasources.DsParser}
> ...
> private void parseDataSource(final XMLExtendedStreamReader reader, final List<ModelNode> list, final ModelNode parentAddress) throws XMLStreamException, ParserException,
> ValidateException {
> ...
> ==> boolean enabled = Defaults.ENABLED.booleanValue();
> ...
> private void parseXADataSource(XMLExtendedStreamReader reader, final List<ModelNode> list, final ModelNode parentAddress) throws XMLStreamException, ParserException,
> ValidateException {
> ...
> ==> boolean enabled = Defaults.ENABLED.booleanValue();
> ...
> {code}
> Though it looks like a bug, I am not sure we can change the default value in XSD for EAP.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months