[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
10 years, 9 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
10 years, 9 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
10 years, 9 months
[JBoss JIRA] (WFLY-1804) Ensure Subject of remote user is associated with the AccessControContext handling the request.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-1804?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse moved REMJMX-61 to WFLY-1804:
----------------------------------------------
Project: WildFly (was: Remoting JMX)
Key: WFLY-1804 (was: REMJMX-61)
Workflow: GIT Pull Request workflow (was: jira)
Component/s: JMX
Remoting
Security
(was: Security)
Fix Version/s: 8.0.0.Alpha4
(was: 1.1.1.CR1)
(was: 2.0.0.Beta2)
> Ensure Subject of remote user is associated with the AccessControContext handling the request.
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-1804
> URL: https://issues.jboss.org/browse/WFLY-1804
> Project: WildFly
> Issue Type: Task
> Components: JMX, Remoting, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 8.0.0.Alpha4
>
>
> WildFly is being updated to add support for authorization checks, this is based on the Subject most recently associated with the AccessControlContext.
> As Remoting JMX is handling remote client requests the Subject of the remote client needs associating with the AccessControlContext.
> No ThreadLocals are in use so at least don't need to worry about those but do need to worry about dispatching to different threads.
> This will need to apply to all versions of the protocol - this is specifically a server side change but the remote side of the connection may be using the older protocol versions.
--
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
10 years, 9 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 updated JASSIST-205:
---------------------------------
Attachment: PowerMockTest.javap
> "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
10 years, 9 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 updated JASSIST-205:
---------------------------------
Attachment: powermockdemoDEBUG.txt
> "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
>
>
> 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
10 years, 9 months
[JBoss JIRA] (WFLY-1803) Failure to undo a patching process which fails
by Jan Martiska (JIRA)
Jan Martiska created WFLY-1803:
----------------------------------
Summary: Failure to undo a patching process which fails
Key: WFLY-1803
URL: https://issues.jboss.org/browse/WFLY-1803
Project: WildFly
Issue Type: Bug
Reporter: Jan Martiska
Assignee: Emanuel Muckenhuber
Scenario:
A patch tries to modify a misc file, but the process doesn't have write permissions for it (or some other kind of exception occurs, I can imagine an IOException when writing to files)
In this case, the patching process fails and is unable to recover - it leaves files which were patched successfully and doesn't revert them to original.
Suppose a patch modifies files f1 and f2. f1 comes first, and is patched successfully. f2 fails because of lack of permissions (by the way, the exception which causes this should appear in the log somewhere, but it doesn't!!).. f1 is not reverted back, because:
{noformat}
15:00:18,525 WARN [org.jboss.as.patching] (management-handler-thread - 4) failed to undo change (org.jboss.as.patching.metadata.ContentModification@1e5bcf80): java.io.FileNotFoundException: /home/jmartisk/Workspace/jboss-eap/testsuite/integration/patching/target/jbossas/.installation/patches/aed03246-56a7-406b-9dd5-add81779d951/misc/f1 (No such file or directory)
at java.io.FileInputStream.open(Native Method) [rt.jar:1.7.0_25]
at java.io.FileInputStream.<init>(FileInputStream.java:138) [rt.jar:1.7.0_25]
at org.jboss.as.patching.runner.PatchContentLoader.openContentStream(PatchContentLoader.java:71) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.patching.runner.AbstractFileTask.apply(AbstractFileTask.java:91) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.patching.runner.AbstractPatchingTask.execute(AbstractPatchingTask.java:139) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.patching.runner.IdentityPatchContext.undoChanges(IdentityPatchContext.java:300) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.patching.runner.IdentityPatchContext.undoChanges(IdentityPatchContext.java:278) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.patching.runner.IdentityPatchContext.cleanup(IdentityPatchContext.java:142) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.patching.runner.IdentityPatchRunner.applyPatch(IdentityPatchRunner.java:86) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.patching.runner.PatchToolImpl.execute(PatchToolImpl.java:205) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.patching.runner.PatchToolImpl.applyPatch(PatchToolImpl.java:154) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.patching.management.LocalPatchOperationStepHandler.execute(LocalPatchOperationStepHandler.java:69) [wildfly-patching-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:440) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:322) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:229) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:224) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:235) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:124) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:148) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:97) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:114) [wildfly-controller-8.0.0.Alpha4-SNAPSHOT.jar:8.0.0.Alpha4-SNAPSHOT]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296)
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518)
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)
{noformat}
Test for this created as NonStandardSituationsTestCase#testWritePermissionDenied
--
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
10 years, 9 months