[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> made a comment on [bug 952277|https://bugzilla.redhat.com/show_bug.cgi?id=952277]
Verified with EAP 6.2.0.ER7
> 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
[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> changed the Status of [bug 952277|https://bugzilla.redhat.com/show_bug.cgi?id=952277] from ON_QA to VERIFIED
> 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-2387) CDI injection in entity listeners failing
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/WFLY-2387?page=com.atlassian.jira.plugin.... ]
Jozef Hartinger commented on WFLY-2387:
---------------------------------------
Yes, we can use that. It's only in Weld 2.1 but we use that version of Weld already anyway.
> 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: Stuart Douglas
> 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-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 commented on WFLY-2387:
--------------------------------------
I know. There are other problems as well, I am going to investigate more fully today. BTW, is there any reason we are not using the weld 2.0 contextId API so the TCCL is no longer required to be set?
> 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: Stuart Douglas
> 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-2387) CDI injection in entity listeners failing
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/WFLY-2387?page=com.atlassian.jira.plugin.... ]
Jozef Hartinger commented on WFLY-2387:
---------------------------------------
The problem is that although TCCL is set in PersistenceUnitServiceImpl, ClassLoaderServiceImpl [replaces|https://github.com/hibernate/hibernate-orm/blob/master/hibernate...] the TCCL with aggregated classloader which Weld is unable to use to identify the application.
> 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: Stuart Douglas
> 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-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:
-----------------------------------------------
Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 952277|https://bugzilla.redhat.com/show_bug.cgi?id=952277] from MODIFIED to ON_QA
> 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
[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:
-----------------------------------------------
Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 952277|https://bugzilla.redhat.com/show_bug.cgi?id=952277] from MODIFIED to ON_QA
> 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