February 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-2859) Treating all JAX-RS components as CDI Beans has some negative consequences

by Matt Drees (JIRA)

[ https://issues.jboss.org/browse/WFLY-2859?page=com.atlassian.jira.plugin.... ] Matt Drees commented on WFLY-2859: ---------------------------------- Note: In my case, setting [require-bean-descriptor="true"|https://docs.jboss.org/author/display/WFLY8/CDI+Reference#CDIReference-Suppressingimplicitbeanarchives] worked around the problem. > Treating all JAX-RS components as CDI Beans has some negative consequences > -------------------------------------------------------------------------- > > Key: WFLY-2859 > URL: https://issues.jboss.org/browse/WFLY-2859 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld, REST > Affects Versions: 8.0.0.CR1 > Reporter: Matt Drees > Assignee: Stuart Douglas > > It seems that wildfly is now treating all jax-rs Providers and Resources as CDI Beans. This is probably fine most of the time, but there are some Provider classes that cause UnproxyableResolutionException (WELD-001437) errors, due to the fact that resteasy-cdi attempts to get bean reference whose type is identical to the bean class. > See the forum link for a specific instance of this. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2859) Treating all JAX-RS components as CDI Beans has some negative consequences

by Matt Drees (JIRA)

Matt Drees created WFLY-2859: -------------------------------- Summary: Treating all JAX-RS components as CDI Beans has some negative consequences Key: WFLY-2859 URL: https://issues.jboss.org/browse/WFLY-2859 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: CDI / Weld, REST Affects Versions: 8.0.0.CR1 Reporter: Matt Drees Assignee: Stuart Douglas It seems that wildfly is now treating all jax-rs Providers and Resources as CDI Beans. This is probably fine most of the time, but there are some Provider classes that cause UnproxyableResolutionException (WELD-001437) errors, due to the fact that resteasy-cdi attempts to get bean reference whose type is identical to the bean class. See the forum link for a specific instance of this. -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1786) DefaultTimeScheduler: unit test fails

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1786?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1786: -------------------------------- I could replace {{Thread.sleep()}} with {{Util.sleep()}} which clears the interrupt bit, but that would mask the real failure. Assuming the sleeping thread is not spuriously interrupted, I'd like to find out who's interrupting the sleeping thread. Is this reproducible ? I have never seen this test fail, neither on Linux nor on Mac OS... > DefaultTimeScheduler: unit test fails > ------------------------------------- > > Key: JGRP-1786 > URL: https://issues.jboss.org/browse/JGRP-1786 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.13 > Environment: RHEL 5 x86_64 > Windows x86_64 > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Fix For: 3.5 > > > The test case starts off by scheduling a timer task using the DefaultTimeScheduler and then sleeping, waiting for the task to execute > Instead of the task being executed, the call to sleep is interrupted and the test case fails with an interrupted exception. Catching this interrupted exception shows that the task has not had a chance to execute before the sleep was interrupted. > The same test case passes with the other two TimeScheduler implementations: TimeScheduler2 and HashedTimingWheel. > -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-944) Connection manager not available during shutdown

by Piotr Findeisen (JIRA)

[ https://issues.jboss.org/browse/WFLY-944?page=com.atlassian.jira.plugin.s... ] Piotr Findeisen commented on WFLY-944: -------------------------------------- I'm deploying single WAR and using Spring's {{<jee:jndi-lookup/>}} to access the datasource as a Spring bean. During application udneployment, I get a lot of those: {code} Caused by: javax.resource.ResourceException: IJ000451: The connection manager is shutdown: java:jboss/datasources/MyDS at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:321) at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:368) at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:464) at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:139) ... 52 more {code} No matter whether I configure datasource in {{standalone.xml}} or as a separate {{my-ds.xml}} in {{deployments/}}. Is it possible to workaround this without using EJBs? If not, wow can I add one EJB to my WAR without having JBoss scan all my classes. Normally, in my case it is Spring who handles {{@Resource}} annotation. > Connection manager not available during shutdown > ------------------------------------------------ > > Key: WFLY-944 > URL: https://issues.jboss.org/browse/WFLY-944 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Server > Reporter: Ori Kremer > Attachments: TestEAR.zip > > > The problem occurs when trying to access the database during the shutdown phase. > It looks like when our shutdown code tries to access the database - it is no longer available. > Our application is deployed as an EAR that has a SAR module to handle startup and shutdown. > We add our application specific startup and shutdown code in the corresponding MBean hooks. > In JBoss 7.0.2 and 7.1.1 we're encountering an error when the shutdown code is attempting to access the database and is failing due to the fact that the connection manager is closed: > 13:08:37,975 ERROR [org.jboss.as.service] JBAS017200: Failed to execute legacy service stop() method: java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_01] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_01] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_01] > at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_01] > at org.jboss.as.service.AbstractService.invokeLifecycleMethod(AbstractService.java:52) [jboss-as-sar-7.1.1.Final.jar:7.1.1.Final] > at org.jboss.as.service.StartStopService.stop(StartStopService.java:66) [jboss-as-sar-7.1.1.Final.jar:7.1.1.Final] > at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1911) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] > at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1874) [jboss-msc-1.0.2.GA.jar:1.0.2.GA] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_01] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_01] > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_01] > Caused by: java.sql.SQLException: javax.resource.ResourceException: IJ000451: The connection manager is shutdown: java:/org.test.NonSecureDS > at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:137) > at org.test.StartupService.updateStatus(StartupService.java:37) > at org.test.StartupService.stop(StartupService.java:56) > ... 11 more > Caused by: javax.resource.ResourceException: IJ000451: The connection manager is shutdown: java:/org.test.NonSecureDS > at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:321) > at org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:368) > at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:464) > at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:129) > ... 13 more -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2858) JPA doesn't parse for "urn:jboss:jpa" namespace in jboss-all.xml

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-2858?page=com.atlassian.jira.plugin.... ] Radoslav Husar commented on WFLY-2858: -------------------------------------- https://issues.jboss.org/browse/WFLY-943?focusedCommentId=12940782&page=c... > JPA doesn't parse for "urn:jboss:jpa" namespace in jboss-all.xml > ---------------------------------------------------------------- > > Key: WFLY-2858 > URL: https://issues.jboss.org/browse/WFLY-2858 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JPA / Hibernate > Affects Versions: 8.0.0.CR1 > Reporter: Radoslav Husar > Assignee: Scott Marlow > Priority: Minor > Fix For: 9.0.0.CR1 > > > Looks like the parser is only parsing for "http://www.jboss.com/xml/ns/javaee" and never for "urn:jboss:jpa". This makes the schema less useful. > https://github.com/wildfly/wildfly/blob/master/build/src/main/resources/d... > Example file: > https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basi... -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1786) DefaultTimeScheduler: unit test fails

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1786?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1786: -------------------------------- Richard, why would {{Thread.sleep()}} get interrupted ? The test is single threaded, so this can only be TestNG stopping it... > DefaultTimeScheduler: unit test fails > ------------------------------------- > > Key: JGRP-1786 > URL: https://issues.jboss.org/browse/JGRP-1786 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.13 > Environment: RHEL 5 x86_64 > Windows x86_64 > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Fix For: 3.5 > > > The test case starts off by scheduling a timer task using the DefaultTimeScheduler and then sleeping, waiting for the task to execute > Instead of the task being executed, the call to sleep is interrupted and the test case fails with an interrupted exception. Catching this interrupted exception shows that the task has not had a chance to execute before the sleep was interrupted. > The same test case passes with the other two TimeScheduler implementations: TimeScheduler2 and HashedTimingWheel. > -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2858) JPA doesn't parse for "urn:jboss:jpa" namespace in jboss-all.xml

by Radoslav Husar (JIRA)

Radoslav Husar created WFLY-2858: ------------------------------------ Summary: JPA doesn't parse for "urn:jboss:jpa" namespace in jboss-all.xml Key: WFLY-2858 URL: https://issues.jboss.org/browse/WFLY-2858 Project: WildFly Issue Type: Bug Security Level: Public (Everyone can see) Components: JPA / Hibernate Affects Versions: 8.0.0.CR1 Reporter: Radoslav Husar Assignee: Scott Marlow Priority: Minor Fix For: 9.0.0.CR1 Looks like the parser is only parsing for "http://www.jboss.com/xml/ns/javaee" and never for "urn:jboss:jpa". This makes the schema less useful. https://github.com/wildfly/wildfly/blob/master/build/src/main/resources/d... Example file: https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basi... -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1786) DefaultTimeScheduler: unit test fails

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1786?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1786: --------------------------- Comment: was deleted (was: craps ! Do you remember the original subject ?) > DefaultTimeScheduler: unit test fails > ------------------------------------- > > Key: JGRP-1786 > URL: https://issues.jboss.org/browse/JGRP-1786 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.13 > Environment: RHEL 5 x86_64 > Windows x86_64 > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Fix For: 3.5 > > > The test case starts off by scheduling a timer task using the DefaultTimeScheduler and then sleeping, waiting for the task to execute > Instead of the task being executed, the call to sleep is interrupted and the test case fails with an interrupted exception. Catching this interrupted exception shows that the task has not had a chance to execute before the sleep was interrupted. > The same test case passes with the other two TimeScheduler implementations: TimeScheduler2 and HashedTimingWheel. > -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1786) DefaultTimeScheduler: unit test fails

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1786?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1786: -------------------------------- OK, DefaultTimeScheduler *is* used by default in 3.2. > DefaultTimeScheduler: unit test fails > ------------------------------------- > > Key: JGRP-1786 > URL: https://issues.jboss.org/browse/JGRP-1786 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.13 > Environment: RHEL 5 x86_64 > Windows x86_64 > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Fix For: 3.5 > > > The test case starts off by scheduling a timer task using the DefaultTimeScheduler and then sleeping, waiting for the task to execute > Instead of the task being executed, the call to sleep is interrupted and the test case fails with an interrupted exception. Catching this interrupted exception shows that the task has not had a chance to execute before the sleep was interrupted. > The same test case passes with the other two TimeScheduler implementations: TimeScheduler2 and HashedTimingWheel. > -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1786) DefaultTimeScheduler: unit test fails

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1786?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1786: --------------------------- Comment: was deleted (was: Bela, did you intend to change the subject to 3.5? I assume it was an accident!) > DefaultTimeScheduler: unit test fails > ------------------------------------- > > Key: JGRP-1786 > URL: https://issues.jboss.org/browse/JGRP-1786 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.13 > Environment: RHEL 5 x86_64 > Windows x86_64 > Reporter: Richard Achmatowicz > Assignee: Bela Ban > Fix For: 3.5 > > > The test case starts off by scheduling a timer task using the DefaultTimeScheduler and then sleeping, waiting for the task to execute > Instead of the task being executed, the call to sleep is interrupted and the test case fails with an interrupted exception. Catching this interrupted exception shows that the task has not had a chance to execute before the sleep was interrupted. > The same test case passes with the other two TimeScheduler implementations: TimeScheduler2 and HashedTimingWheel. > -- 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, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira February 2014