[JBoss JIRA] (JASSIST-205) "VerifyError: Inconsistent stackmap frames" from PowerMock (using Javassist 3.18)
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/JASSIST-205?page=com.atlassian.jira.plugi... ]
Scott Marlow commented on JASSIST-205:
--------------------------------------
Not 100% sure that I'm reading the StackMapTable correctly yet but I think the entry for offset 275 is at offset 263:
{code}
frame_type = 255 /* full_frame */
offset_delta = 6
locals = [ class PowerMockTest, class java/lang/Object, class PowerMockTest$MyClassUnderTest, class java/lang/Object, long, class java/lang/Object, class java/lang/Object, class java/lang/Object ]
stack = []
{code}
> "VerifyError: Inconsistent stackmap frames" from PowerMock (using Javassist 3.18)
> ---------------------------------------------------------------------------------
>
> Key: JASSIST-205
> URL: https://issues.jboss.org/browse/JASSIST-205
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.18.0-GA
> Environment: jdk1.7.0_21, Win8amd64
> Reporter: Ryan Kenney
> Assignee: Shigeru Chiba
> Attachments: PowerMockDemo.zip, powermockdemoDEBUG.txt, PowerMockTest.javap
>
>
> Apologies if this is a duplicate of JASSIST-204. I didn't delve into the actual Javassist APIs used, I'm simply seeing an error in my PowerMock usage. Fortunately, this ticket provides a very simple test case for reproducibility.
> I was prompted to open a Javassist ticket by the following PowerMock ticket: https://code.google.com/p/powermock/issues/detail?id=355
> I'm attaching a very simple maven project with a unit test to demonstrate the problem.
> Here are the guts of the failing unit test:
> {code}
> @RunWith(PowerMockRunner.class)
> @PrepareForTest( {MyClassUnderTest.class} )
> public class PowerMockTest {
> /**************************************************************************
> * Demonstrates an "Inconsistent stackmap frames" exception that results
> * from PowerMock 1.5 and JDK 7.
> *************************************************************************/
> @Test
> public void testWaitForExitMockMonitors() throws InterruptedException {
> resetAll();
>
> Object mockMonitor = createStrictMock(Object.class);
> MyClassUnderTest myClass = new MyClassUnderTest(mockMonitor);
>
> mockMonitor.wait(0);
> mockMonitor.notifyAll();
>
> replayAll();
>
> myClass .run();
>
> verifyAll();
> }
>
> public static class MyClassUnderTest {
> private Object m_monitor;
>
> public MyClassUnderTest(Object monitor) {
> m_monitor = monitor;
> }
>
> public void run() throws InterruptedException {
> m_monitor.wait(0);
> m_monitor.notifyAll();
> }
> }
> }
> {code}
> And here is my error:
> {code}
> java.lang.VerifyError: Inconsistent stackmap frames at branch target 283 in method com.scea.dart.cmd.targetcontrol.target.process.PowerMockTest.testWaitForExitMockMonitors()V at offset 274
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2451)
> at java.lang.Class.privateGetPublicMethods(Class.java:2571)
> at java.lang.Class.getMethods(Class.java:1429)
> at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.getTestMethods(PowerMockJUnit44RunnerDelegateImpl.java:95)
> at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.<init>(PowerMockJUnit44RunnerDelegateImpl.java:71)
> at org.powermock.modules.junit4.internal.impl.PowerMockJUnit49RunnerDelegateImpl.<init>(PowerMockJUnit49RunnerDelegateImpl.java:29)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
> at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.createDelegatorFromClassloader(JUnit4TestSuiteChunkerImpl.java:143)
> at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.createDelegatorFromClassloader(JUnit4TestSuiteChunkerImpl.java:39)
> at org.powermock.tests.utils.impl.AbstractTestSuiteChunkerImpl.createTestDelegators(AbstractTestSuiteChunkerImpl.java:217)
> at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.<init>(JUnit4TestSuiteChunkerImpl.java:59)
> at org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.<init>(AbstractCommonPowerMockRunner.java:32)
> at org.powermock.modules.junit4.PowerMockRunner.<init>(PowerMockRunner.java:33)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
> at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:31)
> at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:24)
> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
> at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
> at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.<init>(JUnit4TestReference.java:33)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestClassReference.<init>(JUnit4TestClassReference.java:25)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.createTest(JUnit4TestLoader.java:48)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.loadTests(JUnit4TestLoader.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:452)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> {code}
--
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, 11 months
[JBoss JIRA] (JASSIST-205) "VerifyError: Inconsistent stackmap frames" from PowerMock (using Javassist 3.18)
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/JASSIST-205?page=com.atlassian.jira.plugi... ]
Scott Marlow commented on JASSIST-205:
--------------------------------------
I am getting a "initializationError(PowerMockTest): Inconsistent stackmap frames at branch target 284 in method PowerMockTest.testWaitForExitMockMonitors()V at offset 275"
The code at offset 275 is:
{code}
275: if_acmpeq 284
{code}
I'm not sure yet what the problem is but will look closer.
> "VerifyError: Inconsistent stackmap frames" from PowerMock (using Javassist 3.18)
> ---------------------------------------------------------------------------------
>
> Key: JASSIST-205
> URL: https://issues.jboss.org/browse/JASSIST-205
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.18.0-GA
> Environment: jdk1.7.0_21, Win8amd64
> Reporter: Ryan Kenney
> Assignee: Shigeru Chiba
> Attachments: PowerMockDemo.zip, powermockdemoDEBUG.txt, PowerMockTest.javap
>
>
> Apologies if this is a duplicate of JASSIST-204. I didn't delve into the actual Javassist APIs used, I'm simply seeing an error in my PowerMock usage. Fortunately, this ticket provides a very simple test case for reproducibility.
> I was prompted to open a Javassist ticket by the following PowerMock ticket: https://code.google.com/p/powermock/issues/detail?id=355
> I'm attaching a very simple maven project with a unit test to demonstrate the problem.
> Here are the guts of the failing unit test:
> {code}
> @RunWith(PowerMockRunner.class)
> @PrepareForTest( {MyClassUnderTest.class} )
> public class PowerMockTest {
> /**************************************************************************
> * Demonstrates an "Inconsistent stackmap frames" exception that results
> * from PowerMock 1.5 and JDK 7.
> *************************************************************************/
> @Test
> public void testWaitForExitMockMonitors() throws InterruptedException {
> resetAll();
>
> Object mockMonitor = createStrictMock(Object.class);
> MyClassUnderTest myClass = new MyClassUnderTest(mockMonitor);
>
> mockMonitor.wait(0);
> mockMonitor.notifyAll();
>
> replayAll();
>
> myClass .run();
>
> verifyAll();
> }
>
> public static class MyClassUnderTest {
> private Object m_monitor;
>
> public MyClassUnderTest(Object monitor) {
> m_monitor = monitor;
> }
>
> public void run() throws InterruptedException {
> m_monitor.wait(0);
> m_monitor.notifyAll();
> }
> }
> }
> {code}
> And here is my error:
> {code}
> java.lang.VerifyError: Inconsistent stackmap frames at branch target 283 in method com.scea.dart.cmd.targetcontrol.target.process.PowerMockTest.testWaitForExitMockMonitors()V at offset 274
> at java.lang.Class.getDeclaredMethods0(Native Method)
> at java.lang.Class.privateGetDeclaredMethods(Class.java:2451)
> at java.lang.Class.privateGetPublicMethods(Class.java:2571)
> at java.lang.Class.getMethods(Class.java:1429)
> at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.getTestMethods(PowerMockJUnit44RunnerDelegateImpl.java:95)
> at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.<init>(PowerMockJUnit44RunnerDelegateImpl.java:71)
> at org.powermock.modules.junit4.internal.impl.PowerMockJUnit49RunnerDelegateImpl.<init>(PowerMockJUnit49RunnerDelegateImpl.java:29)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
> at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.createDelegatorFromClassloader(JUnit4TestSuiteChunkerImpl.java:143)
> at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.createDelegatorFromClassloader(JUnit4TestSuiteChunkerImpl.java:39)
> at org.powermock.tests.utils.impl.AbstractTestSuiteChunkerImpl.createTestDelegators(AbstractTestSuiteChunkerImpl.java:217)
> at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.<init>(JUnit4TestSuiteChunkerImpl.java:59)
> at org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.<init>(AbstractCommonPowerMockRunner.java:32)
> at org.powermock.modules.junit4.PowerMockRunner.<init>(PowerMockRunner.java:33)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
> at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:31)
> at org.junit.internal.builders.AnnotatedBuilder.runnerForClass(AnnotatedBuilder.java:24)
> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
> at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
> at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
> at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.<init>(JUnit4TestReference.java:33)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestClassReference.<init>(JUnit4TestClassReference.java:25)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.createTest(JUnit4TestLoader.java:48)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.loadTests(JUnit4TestLoader.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:452)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> {code}
--
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, 11 months
[JBoss JIRA] (WFLY-1806) Patching: Failures during rollback silently ignored
by Jan Martiska (JIRA)
Jan Martiska created WFLY-1806:
----------------------------------
Summary: Patching: Failures during rollback silently ignored
Key: WFLY-1806
URL: https://issues.jboss.org/browse/WFLY-1806
Project: WildFly
Issue Type: Bug
Reporter: Jan Martiska
Assignee: Emanuel Muckenhuber
Priority: Minor
When you rollback a patch and the process is unable to delete some of the files (eg. an added module's directory is not writable), the files are ignored silently (no exception even in DEBUG level). There should be a notification for the user that something did not succeed and he should clean up manually.
--
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, 11 months
[JBoss JIRA] (WFLY-1752) CDI TCK @WebServiceRef injection tests failing
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-1752?page=com.atlassian.jira.plugin.... ]
Martin Kouba commented on WFLY-1752:
------------------------------------
Actually {{AbstractResourceInjectionServices.validateResourceInjectionPointType()}} is not invoked in case of {{WeldJaxwsInjectionServices}}...
> CDI TCK @WebServiceRef injection tests failing
> ----------------------------------------------
>
> Key: WFLY-1752
> URL: https://issues.jboss.org/browse/WFLY-1752
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Web Services
> Affects Versions: 8.0.0.Alpha3
> Reporter: Jozef Hartinger
> Assignee: Martin Kouba
> Fix For: 8.0.0.Alpha4
>
>
> {noformat}
> org.jboss.arquillian.test.spi.ArquillianProxyException: org.jboss.wsf.spi.WSFException : Cannot create service [Proxied because : Original exception not deserilizable, ClassNotFoundException]
> at org.jboss.wsf.spi.WSFException.rethrow(WSFException.java:55)
> at org.jboss.wsf.stack.cxf.client.serviceref.AbstractServiceObjectFactoryJAXWS.getObjectInstance(AbstractServiceObjectFactoryJAXWS.java:90)
> at org.jboss.wsf.stack.cxf.client.serviceref.CXFServiceRefFactoryImpl.newServiceRef(CXFServiceRefFactoryImpl.java:38)
> at org.jboss.as.webservices.webserviceref.WebServiceManagedReferenceFactory.getReference(WebServiceManagedReferenceFactory.java:37)
> at org.jboss.as.weld.services.bootstrap.ManagedReferenceFactoryToResourceReferenceFactoryAdapter.createResource(ManagedReferenceFactoryToResourceReferenceFactoryAdapter.java:41)
> at org.jboss.weld.injection.AbstractResourceInjection.getResourceReference(AbstractResourceInjection.java:44)
> at org.jboss.weld.injection.AbstractResourceInjection.injectResourceReference(AbstractResourceInjection.java:53)
> at org.jboss.weld.util.Beans.injectEEFields(Beans.java:348)
> at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:59)
> 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:91)
> at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:158)
> at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:69)
> at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:738)
> at org.jboss.weld.injection.producer.AbstractMemberProducer.getReceiver(AbstractMemberProducer.java:110)
> at org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:129)
> at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:189)
> at org.jboss.weld.bean.builtin.ee.EEResourceProducerField.createUnderlying(EEResourceProducerField.java:149)
> at org.jboss.weld.bean.builtin.ee.EEResourceProducerField.access$000(EEResourceProducerField.java:53)
> at org.jboss.weld.bean.builtin.ee.EEResourceProducerField$EEResourceCallable.call(EEResourceProducerField.java:73)
> at org.jboss.weld.bean.builtin.CallableMethodHandler.invoke(CallableMethodHandler.java:45)
> at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:101)
> at org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.SheepWS$-1409013730$Proxy$_$$_Weld$Proxy$.isSheepInjected(Unknown Source)
> at org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.WebServiceResourceTest.testResourceInvocation(WebServiceResourceTest.java:86)
> Caused by: java.lang.InstantiationException: org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.SheepWSEndPointService
> at java.lang.Class.newInstance(Class.java:359)
> at org.jboss.wsf.stack.cxf.client.serviceref.AbstractServiceObjectFactoryJAXWS.instantiateService(AbstractServiceObjectFactoryJAXWS.java:241)
> at org.jboss.wsf.stack.cxf.client.serviceref.AbstractServiceObjectFactoryJAXWS.getObjectInstance(AbstractServiceObjectFactoryJAXWS.java:68)
> ... 128 more
> {noformat}
> The affected CDI TCK tests:
> org.jboss.cdi.tck.tests.implementation.simple.resource.broken.type.ws.ResourceDefinitionWithDifferentTypeTest
> org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.WebServiceResourceTest
--
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, 11 months
[JBoss JIRA] (WFLY-1805) It should be possible to pass objects via invocation context from the server side EJB to the client and read with a via client side interceptor
by Wolf-Dieter Fink (JIRA)
[ https://issues.jboss.org/browse/WFLY-1805?page=com.atlassian.jira.plugin.... ]
Wolf-Dieter Fink updated WFLY-1805:
-----------------------------------
Description:
With former JBoss versions it was possible to pass context beside the method invocation from the client to the server and back. This was done via (AOP) interceptors.
Since AS7 and WildFly the only possibility is to pass such context from the client to the server.
It should also possible to pass serializeable objects from the server side to the client if the invocation returns and have a client side interceptor to read that informations.
This was used to return i.e. tracking or additional usefull informations.
was:
With former EAP versions it was possible to pass context beside the method invocation from the client to the server and back. This was done via (AOP) interceptors.
Since AS7 and WildFly the only possibility is to pass such context from the client to the server.
It should also possible to pass serializeable objects from the server side to the client if the invocation returns and have a client side interceptor to read that informations.
This was used to return i.e. tracking or additional usefull informations.
> It should be possible to pass objects via invocation context from the server side EJB to the client and read with a via client side interceptor
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1805
> URL: https://issues.jboss.org/browse/WFLY-1805
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Reporter: Wolf-Dieter Fink
> Assignee: jaikiran pai
> Labels: ejb
>
> With former JBoss versions it was possible to pass context beside the method invocation from the client to the server and back. This was done via (AOP) interceptors.
> Since AS7 and WildFly the only possibility is to pass such context from the client to the server.
> It should also possible to pass serializeable objects from the server side to the client if the invocation returns and have a client side interceptor to read that informations.
> This was used to return i.e. tracking or additional usefull informations.
--
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, 11 months
[JBoss JIRA] (WFLY-1805) It should be possible to pass objects via invocation context from the server side EJB to the client and read with a via client side interceptor
by Wolf-Dieter Fink (JIRA)
[ https://issues.jboss.org/browse/WFLY-1805?page=com.atlassian.jira.plugin.... ]
Wolf-Dieter Fink moved EJBTHREE-2300 to WFLY-1805:
--------------------------------------------------
Project: WildFly (was: EJB 3.0)
Key: WFLY-1805 (was: EJBTHREE-2300)
Workflow: GIT Pull Request workflow (was: jira)
Component/s: EJB
(was: ejb3)
> It should be possible to pass objects via invocation context from the server side EJB to the client and read with a via client side interceptor
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1805
> URL: https://issues.jboss.org/browse/WFLY-1805
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Reporter: Wolf-Dieter Fink
> Assignee: jaikiran pai
> Labels: ejb
>
> With former EAP versions it was possible to pass context beside the method invocation from the client to the server and back. This was done via (AOP) interceptors.
> Since AS7 and WildFly the only possibility is to pass such context from the client to the server.
> It should also possible to pass serializeable objects from the server side to the client if the invocation returns and have a client side interceptor to read that informations.
> This was used to return i.e. tracking or additional usefull informations.
--
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, 11 months
[JBoss JIRA] (WFLY-1752) CDI TCK @WebServiceRef injection tests failing
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-1752?page=com.atlassian.jira.plugin.... ]
Martin Kouba commented on WFLY-1752:
------------------------------------
First these are two completely different issues. And the stack trace is only related to the second one (WebServiceResourceTest).
h3. ResourceDefinitionWithDifferentTypeTest
The CDI spec "3.7.1 Declaring a resource":
{quote}
If the matching object in the Java EE component environment is not of the same type as the producer field declaration, the container automatically detects the problem and treats it as a definition error.
{quote}
And currently a definition error is not thrown. I guess it's not possible to validate the injection point correctly right now - see {{org.jboss.as.weld.services.bootstrap.AbstractResourceInjectionServices.validateResourceInjectionPointType()}}. Not sure if it's possible to fix it (but GF4 does it somehow ;-).
h3. WebServiceResourceTest
WildFly/CFX is really trying to invoke a no-args constructor the SheepWSEndPointService doesn't declare. When looking at the JAX-WS spec (2.7 Service and Port) I think it should (actually the number of required constructors differs in 2.0 and 2.2 versions). On the other hand the JSR-109 (Web Services for Java EE, Version 1.4), section "4.2.2 javax.xml.ws.WebServiceRef annotation", states:
{quote}
For co-located clients (where the client and the server are in the same Java EE application unit) with generated Service class, the location of the final WSDL document is resolved by comparing the Service name on the @WebServiceClient annotation on the the generated Service to the Service names of all the deployed port components in the Java EE application unit...
{quote}
Also note that test passes on GF4 (as Jozef pointed out).
*The problem is we cannot provide a hard-coded WSDL location for our test.* I tried to fix the SheepWSEndPointService to declare a public no-args constructor and supply some fake WSDL location - does not work.
So we could either mark the assertion as non-testable and disable/delete the test or ask some JAX-WS expert.
> CDI TCK @WebServiceRef injection tests failing
> ----------------------------------------------
>
> Key: WFLY-1752
> URL: https://issues.jboss.org/browse/WFLY-1752
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Web Services
> Affects Versions: 8.0.0.Alpha3
> Reporter: Jozef Hartinger
> Assignee: Martin Kouba
> Fix For: 8.0.0.Alpha4
>
>
> {noformat}
> org.jboss.arquillian.test.spi.ArquillianProxyException: org.jboss.wsf.spi.WSFException : Cannot create service [Proxied because : Original exception not deserilizable, ClassNotFoundException]
> at org.jboss.wsf.spi.WSFException.rethrow(WSFException.java:55)
> at org.jboss.wsf.stack.cxf.client.serviceref.AbstractServiceObjectFactoryJAXWS.getObjectInstance(AbstractServiceObjectFactoryJAXWS.java:90)
> at org.jboss.wsf.stack.cxf.client.serviceref.CXFServiceRefFactoryImpl.newServiceRef(CXFServiceRefFactoryImpl.java:38)
> at org.jboss.as.webservices.webserviceref.WebServiceManagedReferenceFactory.getReference(WebServiceManagedReferenceFactory.java:37)
> at org.jboss.as.weld.services.bootstrap.ManagedReferenceFactoryToResourceReferenceFactoryAdapter.createResource(ManagedReferenceFactoryToResourceReferenceFactoryAdapter.java:41)
> at org.jboss.weld.injection.AbstractResourceInjection.getResourceReference(AbstractResourceInjection.java:44)
> at org.jboss.weld.injection.AbstractResourceInjection.injectResourceReference(AbstractResourceInjection.java:53)
> at org.jboss.weld.util.Beans.injectEEFields(Beans.java:348)
> at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:59)
> 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:91)
> at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:158)
> at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:69)
> at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:738)
> at org.jboss.weld.injection.producer.AbstractMemberProducer.getReceiver(AbstractMemberProducer.java:110)
> at org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:129)
> at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:189)
> at org.jboss.weld.bean.builtin.ee.EEResourceProducerField.createUnderlying(EEResourceProducerField.java:149)
> at org.jboss.weld.bean.builtin.ee.EEResourceProducerField.access$000(EEResourceProducerField.java:53)
> at org.jboss.weld.bean.builtin.ee.EEResourceProducerField$EEResourceCallable.call(EEResourceProducerField.java:73)
> at org.jboss.weld.bean.builtin.CallableMethodHandler.invoke(CallableMethodHandler.java:45)
> at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:101)
> at org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.SheepWS$-1409013730$Proxy$_$$_Weld$Proxy$.isSheepInjected(Unknown Source)
> at org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.WebServiceResourceTest.testResourceInvocation(WebServiceResourceTest.java:86)
> Caused by: java.lang.InstantiationException: org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.SheepWSEndPointService
> at java.lang.Class.newInstance(Class.java:359)
> at org.jboss.wsf.stack.cxf.client.serviceref.AbstractServiceObjectFactoryJAXWS.instantiateService(AbstractServiceObjectFactoryJAXWS.java:241)
> at org.jboss.wsf.stack.cxf.client.serviceref.AbstractServiceObjectFactoryJAXWS.getObjectInstance(AbstractServiceObjectFactoryJAXWS.java:68)
> ... 128 more
> {noformat}
> The affected CDI TCK tests:
> org.jboss.cdi.tck.tests.implementation.simple.resource.broken.type.ws.ResourceDefinitionWithDifferentTypeTest
> org.jboss.cdi.tck.tests.lookup.injection.non.contextual.ws.WebServiceResourceTest
--
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, 11 months