2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2013

jboss-jira@lists.jboss.org

1 participants
1719 discussions

Start a nNew thread

[JBoss JIRA] (WFLY-2430) App with custom ContainerResponseFilter (JAX-RS) fails deploy

by Rudy De Busscher (JIRA)

Rudy De Busscher created WFLY-2430: -------------------------------------- Summary: App with custom ContainerResponseFilter (JAX-RS) fails deploy Key: WFLY-2430 URL: https://issues.jboss.org/browse/WFLY-2430 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: REST Affects Versions: 8.0.0.Beta1 Environment: Windows 7 Reporter: Rudy De Busscher Assignee: Stuart Douglas Created a simple rest application with a ContainerResponseFilter. The deploy fails with a ClassNotFoundException of javax.ws.rs.container.ContainerResponseFilter. See also https://community.jboss.org/message/844105 -- 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

1
0
0 / 0

[JBoss JIRA] (WFLY-88) Recovery not fully triggered when distributed transaction falls down at prepare phase of 2PC

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-88?page=com.atlassian.jira.plugin.sy... ] RH Bugzilla Integration commented on WFLY-88: --------------------------------------------- Ondrej Chaloupka <ochaloup(a)redhat.com> changed the Status of [bug 952746|https://bugzilla.redhat.com/show_bug.cgi?id=952746] from ON_QA to ASSIGNED > Recovery not fully triggered when distributed transaction falls down at prepare phase of 2PC > -------------------------------------------------------------------------------------------- > > Key: WFLY-88 > URL: https://issues.jboss.org/browse/WFLY-88 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB, Remoting > Reporter: Ivo Studensky > Assignee: jaikiran pai > Fix For: 8.0.0.Alpha1 > > Attachments: logs_prepareHaltClient.tgz > > > It looks like recovery process is not fully triggered on a distributed transaction when the transaction falls down at prepare phase of 2PC. In the new crash recovery tests over propagated transactions only one of two servers recovers from the crash, but the other keeps an unfinished tx in its tx log. > It corresponds to prepareHaltClient and prepareHaltServer test methods of org.jboss.as.test.jbossts.crashrec.txpropagation.TxPropagationCrashRecoveryTestCase, see JBQA-2604 for general description of the new tests. The prepareHaltClient test crashes the server which initiated the transaction, while as the prepareHaltServer test crashes the second server. > The tests are written against EAP6.x branch, so for reproducing this it is needed a built server from the 7.1 branch of AS7. > Steps to reproduce. > 1. git clone -b as7 git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-transactions.git > 2. cd eap-tests-transactions > 3. git checkout tx_propag_crashrec_tests > 4a. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#prepareHaltClient -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT> > or > 4b. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#prepareHaltServer -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT> > The logs of prepareHaltClient run attached to this jira. -- 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

1
0
0 / 0

[JBoss JIRA] (WFLY-88) Recovery not fully triggered when distributed transaction falls down at prepare phase of 2PC

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-88?page=com.atlassian.jira.plugin.sy... ] RH Bugzilla Integration commented on WFLY-88: --------------------------------------------- Ondrej Chaloupka <ochaloup(a)redhat.com> made a comment on [bug 952746|https://bugzilla.redhat.com/show_bug.cgi?id=952746] Hi David, I've checked the current state of the issue (as it's longer time that I've been checking it) and I can say that there is still the problem in the waking up the ejb remote connection when the remote server (remote server which is called from client server - via outbound connection from client server) crashes and then comes up again. Then the client sever (it started the tx) does not know nothing about the remote server is up and that the recovery can be done. This happen just for the distributed JTA transactions. The JTS transactions manage the distributed communication between nodes and the recovery starts without problem. The workaround for the recovery is to call a remote method from the client server to the remote server after the remote server comes back to life. Then the crash recovery will start. The test scenario when this problem occurs look: - transaction is started on the client server - the client server does call via outbound connection to the remote server (tx context is propagated to remote server) - the remote server sends a message to a queue (simulation of some action done during the transaction) - finishing the remote call and the bean method - the transaction started 2PC. The prepare phase is done and the commit phase is started. The remote server crashes at the entry to the commit method - client server is still alive - remote server comes to life - the crash recovery should proceed the commit as all the participant agreed on it I would put here the explanation from Jaikiran: When a connection breaks down between the server and the client, specifically when the client goes down and comes back up again, then the server and the client will not auto communicate with each other. In other words, the server will have no knowledge (in EJB resource sense) that the client has come back up again. That effectively means that the EJB tx recovery process will have no clue of the EJB nodes to communicate with. To deal with that, there should be some communication from the client (which is now up) to the server to reestablish that connection. In a real application, it would be the first invocation from the client to the server. I've checked that the call from the client server to remote one really establishes the connection and recovery starts. B the next call from the client to server could take some time and meanwhile the transaction could be rollbacked because of the timeout. What do you think about this? I think that current behavior is not correct. We agreed on it with Jaikiran before as well but he haven't got a time to fix it (https://bugzilla.redhat.com/show_bug.cgi?id=952746#c15). Thanks Ondra > Recovery not fully triggered when distributed transaction falls down at prepare phase of 2PC > -------------------------------------------------------------------------------------------- > > Key: WFLY-88 > URL: https://issues.jboss.org/browse/WFLY-88 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB, Remoting > Reporter: Ivo Studensky > Assignee: jaikiran pai > Fix For: 8.0.0.Alpha1 > > Attachments: logs_prepareHaltClient.tgz > > > It looks like recovery process is not fully triggered on a distributed transaction when the transaction falls down at prepare phase of 2PC. In the new crash recovery tests over propagated transactions only one of two servers recovers from the crash, but the other keeps an unfinished tx in its tx log. > It corresponds to prepareHaltClient and prepareHaltServer test methods of org.jboss.as.test.jbossts.crashrec.txpropagation.TxPropagationCrashRecoveryTestCase, see JBQA-2604 for general description of the new tests. The prepareHaltClient test crashes the server which initiated the transaction, while as the prepareHaltServer test crashes the second server. > The tests are written against EAP6.x branch, so for reproducing this it is needed a built server from the 7.1 branch of AS7. > Steps to reproduce. > 1. git clone -b as7 git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-transactions.git > 2. cd eap-tests-transactions > 3. git checkout tx_propag_crashrec_tests > 4a. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#prepareHaltClient -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT> > or > 4b. mvn clean verify -Dtest=TxPropagationCrashRecoveryTestCase#prepareHaltServer -Djboss.dist=<path to jboss-as-7.1.3.Final-SNAPSHOT> > The logs of prepareHaltClient run attached to this jira. -- 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

1
0
0 / 0

[JBoss JIRA] (SECURITY-760) Make the JBoss Negotiation dependency on JBoss Web - Provided

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-760?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-760: -------------------------------------------------- FIlip Bogyai <fbogyai(a)redhat.com> made a comment on [bug 1022679|https://bugzilla.redhat.com/show_bug.cgi?id=1022679] Verified in 6.2.0.ER7-quickstarts > Make the JBoss Negotiation dependency on JBoss Web - Provided > ------------------------------------------------------------- > > Key: SECURITY-760 > URL: https://issues.jboss.org/browse/SECURITY-760 > Project: PicketBox > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Negotiation > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: Negotiation_2_2_6 > > -- 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

1
0
0 / 0

[JBoss JIRA] (SECURITY-760) Make the JBoss Negotiation dependency on JBoss Web - Provided

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-760?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-760: -------------------------------------------------- FIlip Bogyai <fbogyai(a)redhat.com> changed the Status of [bug 1022679|https://bugzilla.redhat.com/show_bug.cgi?id=1022679] from ON_QA to VERIFIED > Make the JBoss Negotiation dependency on JBoss Web - Provided > ------------------------------------------------------------- > > Key: SECURITY-760 > URL: https://issues.jboss.org/browse/SECURITY-760 > Project: PicketBox > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Negotiation > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: Negotiation_2_2_6 > > -- 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

1
0
0 / 0

[JBoss JIRA] (WFLY-2373) patching resource does not get registered on slave hosts

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2373?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2373: ----------------------------------------------- Jan Martiska <jmartisk(a)redhat.com> changed the Status of [bug 1022973|https://bugzilla.redhat.com/show_bug.cgi?id=1022973] from ON_QA to VERIFIED > patching resource does not get registered on slave hosts > -------------------------------------------------------- > > Key: WFLY-2373 > URL: https://issues.jboss.org/browse/WFLY-2373 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Patching > Affects Versions: 8.0.0.Beta1 > Reporter: Emanuel Muckenhuber > Assignee: Emanuel Muckenhuber > Fix For: 8.0.0.CR1 > > -- 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

1
0
0 / 0

[JBoss JIRA] (WFLY-2373) patching resource does not get registered on slave hosts

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2373?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2373: ----------------------------------------------- Jan Martiska <jmartisk(a)redhat.com> made a comment on [bug 1022973|https://bugzilla.redhat.com/show_bug.cgi?id=1022973] Verified in ER7. > patching resource does not get registered on slave hosts > -------------------------------------------------------- > > Key: WFLY-2373 > URL: https://issues.jboss.org/browse/WFLY-2373 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Patching > Affects Versions: 8.0.0.Beta1 > Reporter: Emanuel Muckenhuber > Assignee: Emanuel Muckenhuber > Fix For: 8.0.0.CR1 > > -- 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

1
0
0 / 0

[JBoss JIRA] (WFLY-2385) Resource adapter recovery doesn't allow fallback to security credentials

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2385?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2385: ----------------------------------------------- Vladimir Rastseluev <vrastsel(a)redhat.com> changed the Status of [bug 1023446|https://bugzilla.redhat.com/show_bug.cgi?id=1023446] from ON_QA to VERIFIED > Resource adapter recovery doesn't allow fallback to security credentials > ------------------------------------------------------------------------- > > Key: WFLY-2385 > URL: https://issues.jboss.org/browse/WFLY-2385 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Stefano Maestri > Assignee: Stefano Maestri > -- 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

1
0
0 / 0

[JBoss JIRA] (WFLY-2385) Resource adapter recovery doesn't allow fallback to security credentials

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2385?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2385: ----------------------------------------------- Vladimir Rastseluev <vrastsel(a)redhat.com> made a comment on [bug 1023446|https://bugzilla.redhat.com/show_bug.cgi?id=1023446] Verified on EAP 6.2 ER7 > Resource adapter recovery doesn't allow fallback to security credentials > ------------------------------------------------------------------------- > > Key: WFLY-2385 > URL: https://issues.jboss.org/browse/WFLY-2385 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Stefano Maestri > Assignee: Stefano Maestri > -- 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

1
0
0 / 0

[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 reopened WFLY-2387: ---------------------------------- There are still more problems with this. I just fixed the obvious class loader problem and assumed that would fix it, however there are other issues. > 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

1
0
0 / 0

Jump to page: