[JBoss JIRA] (WFLY-4839) annotation must be scanned regardless of the version of web.xml unless metadata-complete is explicitly set to true
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-4839?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-4839:
-----------------------------------------------
Radim Hatlapatka <rhatlapa(a)redhat.com> changed the Status of [bug 1235627|https://bugzilla.redhat.com/show_bug.cgi?id=1235627] from ON_QA to VERIFIED
> annotation must be scanned regardless of the version of web.xml unless metadata-complete is explicitly set to true
> ------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4839
> URL: https://issues.jboss.org/browse/WFLY-4839
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Alpha4
> Reporter: Chao Wang
> Assignee: Chao Wang
> Fix For: 10.0.0.Beta2
>
>
> {noformat}
> ### Description of problem:
> Annotation must be scanned regardless of the version of web.xml unless metadata-complete is explicitly set to true.
> Note that Servlet 3.0 specification clearly states the following:
> ~~~
> 1.6.2 Processing annotations
> In Servlet 2.5, metadata-complete only affected the scanning of annotations at
> deployment time. The notion of web-fragments did not exist in servlet 2.5. However
> in servlet 3.0 metadata-complete affects scanning of all annotations and web-
> fragments at deployment time. The version of the descriptor MUST not affect which
> annotations you scan for in a web application. An implementation of a particular
> version of the specification MUST scan for all annotations supported in that
> configuration, unless metadata-complete is specified.
> ~~~
> ### How reproducible:
> Anytime
> ### Steps to Reproduce:
> 1. Create a library jar which contains a servlet filter using @WebFilter
> 2. Put the jar under WEB-INF/lib of the web application which web.xml version is 2.3 or 2.4
> 3. Start JBoss EAP 6
> 4. Access the web application and see if the servlet filter works
> ### Actual results:
> The servlet filter is not invoked
> ### Expected results:
> The servlet filter is invoked
> ### Additional info:
> It works when the version of web.xml is 2.5 or 3.0
> [reply] [−]
> Private
> Comment 1 Masafumi Miura 2015-06-25 07:18:17 EDT
> RED HAT CONFIDENTIAL
> It looks metadata-complete is always set to true when the version of web.xml is 2.3 or 2.4 at the line 96 of web/src/main/java/org/jboss/as/web/deployment/WarMetaDataProcessor.java.
> Though Servlet 2.3/2.3 specification does not have metadata-complete attribute, Servlet 3.0 specification states the following. I think it means that the metadata-complete attribute default to false if it is not specified.
> ~~~
> 8.1 Annotations and pluggability
> if the metadata-complete attribute is not specified or is set to "false", the
> deployment tool must examine the class files of the application for annotations, and
> scan for web fragments.
> ~~~
> * web/src/main/java/org/jboss/as/web/deployment/WarMetaDataProcessor.java
> 76 public class WarMetaDataProcessor implements DeploymentUnitProcessor {
> 77
> 78 @Override
> 79 public void deploy(DeploymentPhaseContext phaseContext) throws DeploymentUnitProcessingException {
> ...
> 87 boolean isComplete = false;
> 88 WebMetaData specMetaData = warMetaData.getWebMetaData();
> 89 if (specMetaData != null) {
> 90 if (specMetaData instanceof Web25MetaData) {
> 91 isComplete |= ((Web25MetaData) specMetaData).isMetadataComplete();
> 92 } else if (specMetaData instanceof Web30MetaData) {
> 93 isComplete |= ((Web30MetaData) specMetaData).isMetadataComplete();
> 94 } else {
> 95 // Any web.xml 2.4 or earlier deployment is metadata complete
> 96 isComplete = true;
> 97 }
> 98 }
> 99
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5932) Invalidating a session of an SSO on a different node than where the session was created does not logout the user
by Richard Janík (JIRA)
[ https://issues.jboss.org/browse/WFLY-5932?page=com.atlassian.jira.plugin.... ]
Richard Janík commented on WFLY-5932:
-------------------------------------
Since this is a duplicate of WFLY-5473 (blocker), which is now closed, I'll raise the priority of this issue to blocker too (the last line from description is now irrelevant).
> Invalidating a session of an SSO on a different node than where the session was created does not logout the user
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5932
> URL: https://issues.jboss.org/browse/WFLY-5932
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.CR5
> Reporter: Richard Janík
> Assignee: Stuart Douglas
> Priority: Blocker
>
> See steps to reproduce for description. Additional scenario with a failover where we don't need to authenticate with the last request (but where we should be required to authenticate):
> * Access A1, authenticate, fail A1 (e.g. shutdown the server), access A2, invalidate session on A2, access A2
> Scenarios where the SSO context is destroyed (where we need to authenticate with the last request as expected):
> * Access A1, authenticate, invalidate session on A1, access A1
> * Access A1, authenticate, access A2, invalidate session on A1, access A1
> Possibly related to JBEAP-1228, JBEAP-1282. Note that we always only have a single session bound to an SSO. I'm not flagging this as a blocker, since the issue usually doesn't manifest thanks to sticky sessions on a load balancer.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5932) Invalidating a session of an SSO on a different node than where the session was created does not logout the user
by Richard Janík (JIRA)
[ https://issues.jboss.org/browse/WFLY-5932?page=com.atlassian.jira.plugin.... ]
Richard Janík updated WFLY-5932:
--------------------------------
Priority: Blocker (was: Critical)
> Invalidating a session of an SSO on a different node than where the session was created does not logout the user
> ----------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5932
> URL: https://issues.jboss.org/browse/WFLY-5932
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.CR5
> Reporter: Richard Janík
> Assignee: Stuart Douglas
> Priority: Blocker
>
> See steps to reproduce for description. Additional scenario with a failover where we don't need to authenticate with the last request (but where we should be required to authenticate):
> * Access A1, authenticate, fail A1 (e.g. shutdown the server), access A2, invalidate session on A2, access A2
> Scenarios where the SSO context is destroyed (where we need to authenticate with the last request as expected):
> * Access A1, authenticate, invalidate session on A1, access A1
> * Access A1, authenticate, access A2, invalidate session on A1, access A1
> Possibly related to JBEAP-1228, JBEAP-1282. Note that we always only have a single session bound to an SSO. I'm not flagging this as a blocker, since the issue usually doesn't manifest thanks to sticky sessions on a load balancer.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-2717) Exceptions returnd from remote ejb calls create ClassCastException
by Panagiotis Sotiropoulos (JIRA)
[ https://issues.jboss.org/browse/WFLY-2717?page=com.atlassian.jira.plugin.... ]
Panagiotis Sotiropoulos commented on WFLY-2717:
-----------------------------------------------
Thank you for the workaround. I will start checking it probably tomorrow.
> Exceptions returnd from remote ejb calls create ClassCastException
> ------------------------------------------------------------------
>
> Key: WFLY-2717
> URL: https://issues.jboss.org/browse/WFLY-2717
> Project: WildFly
> Issue Type: Bug
> Components: Remoting
> Affects Versions: 8.0.0.CR1, 8.1.0.Final
> Environment: Windows, Java 1.7.0_40
> Reporter: Dirk Weil
> Assignee: Panagiotis Sotiropoulos
>
> An exception thrown by an ejb is not marshalled correctly to the calling remote client. Instead a ClassCastException is raised.
> Stack trace on client:
> {noformat}
> java.lang.AssertionError:
> Expected: class java.lang.UnsupportedOperationException as (in)directly causing exception
> but: was <java.lang.ClassCastException: java.lang.Class cannot be cast to java.lang.String>
> Stacktrace was: java.lang.ClassCastException: java.lang.Class cannot be cast to java.lang.String
> at org.jboss.ejb.client.remoting.ProtocolMessageHandler.readAttachments(ProtocolMessageHandler.java:55)
> at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:82)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:272)
> at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocationResult(EJBObjectInterceptor.java:64)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
> at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocationResult(EJBHomeInterceptor.java:88)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
> at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:129)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:262)
> at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:437)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:202)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
> at com.sun.proxy.$Proxy6.getException(Unknown Source)
> at de.gedoplan.beantrial.wildflyejbremote.DemoTest.testGetException(DemoTest.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:168)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
> 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)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
> at org.junit.Assert.assertThat(Assert.java:865)
> at org.junit.Assert.assertThat(Assert.java:832)
> at org.junit.rules.ExpectedException.handleException(ExpectedException.java:198)
> at org.junit.rules.ExpectedException.access$500(ExpectedException.java:85)
> at org.junit.rules.ExpectedException$ExpectedExceptionStatement.evaluate(ExpectedException.java:177)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
> 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)
> {noformat}
> Stack trace on server:
> {noformat}
> 14:50:47,688 ERROR [org.jboss.as.ejb3.invocation] (EJB default - 3) JBAS014134: EJB Invocation failed on component DemoBean for method public abstract void de.gedoplan.beantrial.wi
> ldflyejbremote.Demo.getException(): javax.ejb.EJBException: java.lang.UnsupportedOperationException: Not implemented
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:190) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:340) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:79) [wildfly-ejb3-8.0.0.CR1.jar:8.0
> .0.CR1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [wildfly-ejb3-8.0.0.CR1.jar:8
> .0.0.CR1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:95) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:437)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:325)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:185)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:329) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:70) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:203) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_40]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_40]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> Caused by: java.lang.UnsupportedOperationException: Not implemented
> at de.gedoplan.beantrial.wildflyejbremote.DemoBean.getException(DemoBean.java:17) [wildfly-ejbremote-demo.jar:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_40]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_40]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_40]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_40]
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
> at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
> at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:406)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:55) [weld-core-impl-2.1.1.Final.jar:2013-1
> 2-03 09:59]
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:84) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) [wildfly-ee-8.0.0.CR1.jar:8.0.0.CR1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:309)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:273) [wildfly-ejb3-8.0.0.CR1.jar:8.0.0.CR1]
> ... 39 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFBUILD-12) mvn test fails with 'Failed to process feature pack'
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFBUILD-12?page=com.atlassian.jira.plugin... ]
Ken Wills commented on WFBUILD-12:
----------------------------------
[~ctomc] It happens with mvn clean test, but not 100% of the time.
> mvn test fails with 'Failed to process feature pack'
> ----------------------------------------------------
>
> Key: WFBUILD-12
> URL: https://issues.jboss.org/browse/WFBUILD-12
> Project: WildFly Build Tools
> Issue Type: Bug
> Reporter: Stian Thorgersen
> Assignee: Stuart Douglas
>
> Running 'mvn test' on [wildfly|https://github.com/wildfly/wildfly] fails with:
> {code}
> [ERROR] Failed to execute goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.1.0.Beta1:build (server-provisioning) on project wildfly-build: Execution server-provisioning of goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.1.0.Beta1:build failed: java.lang.RuntimeException: java.lang.RuntimeException: Failed to process feature pack /home/st/.m2/repository/org/wildfly/wildfly-feature-pack/10.0.0.Alpha6-SNAPSHOT/wildfly-feature-pack-10.0.0.Alpha6-SNAPSHOT.zip modules: Could not extract resources from org.wildfly:wildfly-embedded: /home/st/tmp/wildfly/embedded/target/classes (Is a directory) -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFBUILD-12) mvn test fails with 'Failed to process feature pack'
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFBUILD-12?page=com.atlassian.jira.plugin... ]
Tomaz Cerar commented on WFBUILD-12:
------------------------------------
but if you run mvn clean before other tasks.
like mvn clean test, does it work?
> mvn test fails with 'Failed to process feature pack'
> ----------------------------------------------------
>
> Key: WFBUILD-12
> URL: https://issues.jboss.org/browse/WFBUILD-12
> Project: WildFly Build Tools
> Issue Type: Bug
> Reporter: Stian Thorgersen
> Assignee: Stuart Douglas
>
> Running 'mvn test' on [wildfly|https://github.com/wildfly/wildfly] fails with:
> {code}
> [ERROR] Failed to execute goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.1.0.Beta1:build (server-provisioning) on project wildfly-build: Execution server-provisioning of goal org.wildfly.build:wildfly-server-provisioning-maven-plugin:1.1.0.Beta1:build failed: java.lang.RuntimeException: java.lang.RuntimeException: Failed to process feature pack /home/st/.m2/repository/org/wildfly/wildfly-feature-pack/10.0.0.Alpha6-SNAPSHOT/wildfly-feature-pack-10.0.0.Alpha6-SNAPSHOT.zip modules: Could not extract resources from org.wildfly:wildfly-embedded: /home/st/tmp/wildfly/embedded/target/classes (Is a directory) -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5596) MessageDrivenComponent startDelivery/stopDelivery is not thread safe
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-5596?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-5596:
-----------------------------------------------
Ondrej Chaloupka <ochaloup(a)redhat.com> changed the Status of [bug 1282661|https://bugzilla.redhat.com/show_bug.cgi?id=1282661] from ON_QA to VERIFIED
> MessageDrivenComponent startDelivery/stopDelivery is not thread safe
> --------------------------------------------------------------------
>
> Key: WFLY-5596
> URL: https://issues.jboss.org/browse/WFLY-5596
> Project: WildFly
> Issue Type: Bug
> Components: EJB, JMS
> Affects Versions: 10.0.0.CR4
> Reporter: James Livingston
> Assignee: Jeff Mesnil
> Fix For: 10.0.0.CR5
>
>
> WFLY-4470 made a change to prevent MDBs being activated or deactivated multiple times, but it is not thread safe. A volatile boolean is used for the flag, but there is no protection against multiple threads invoking the methods simultaneously.
> Possible effects include:
> * activating the endpoint twice, with (probably) only one deactivation later, leading to not de-registering XA resources from the recovery manager properly
> * activate() and deactivate() running in the wrong order if done by separate threads
> Several simple solutions probably will not work correctly. Using an AtomicBoolean would stop multiple activations/deactivations from concurrent calls, but would mean that startDelivery() could return before the activation was one. Using a synchronized block or other exclusive lock would work, however since it involves invoking non-container code (the resource adapter), there could potentially be a deadlock risk if that invoked some related container functionality.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months