December 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-7776) maven archetype-subsytem not available

by Teresa Miyar (JIRA)

[ https://issues.jboss.org/browse/WFLY-7776?page=com.atlassian.jira.plugin.... ] Teresa Miyar updated WFLY-7776: ------------------------------- > maven archetype-subsytem not available > -------------------------------------- > > Key: WFLY-7776 > URL: https://issues.jboss.org/browse/WFLY-7776 > Project: WildFly > Issue Type: Bug > Components: Documentation > Affects Versions: 10.0.0.Final > Reporter: Teresa Miyar > > This page needs update since there is no archetype for this version and is misleading for users > https://docs.jboss.org/author/display/WFLY10/Example+subsystem -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1380) Add JPA 2.1 support for kie-aries-blueprint

by Petr Široký (JIRA)

Petr Široký created DROOLS-1380: ----------------------------------- Summary: Add JPA 2.1 support for kie-aries-blueprint Key: DROOLS-1380 URL: https://issues.jboss.org/browse/DROOLS-1380 Project: Drools Issue Type: Bug Reporter: Petr Široký Assignee: Petr Široký Priority: Critical {{kie-aries-blueprint}} does not support JPA 2.1. It seems that even upstream Aries project does not yet support this as it still depending on 2.0 spec jars: https://github.com/apache/aries/blob/trunk/jpa/jpa-api/pom.xml#L41 The corresponding test {{KieBlueprintjBPMPersistenceKarafIntegrationTest}} was @Ignored for now. We need to either drop support for persistence using Aries Blueprint or fix the integration. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2114) [Deployment overlay] Missing explanation what deployment overlay is in 'deployment-overlay --help'

by Jean-Francois Denise (JIRA)

Jean-Francois Denise created WFCORE-2114: -------------------------------------------- Summary: [Deployment overlay] Missing explanation what deployment overlay is in 'deployment-overlay --help' Key: WFCORE-2114 URL: https://issues.jboss.org/browse/WFCORE-2114 Project: WildFly Core Issue Type: Enhancement Components: CLI Reporter: Jean-Francois Denise Assignee: Jean-Francois Denise -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7786) Server startup hanging in InboundBridgeRecoveryTestCase#testCrashAfterPrepareInParticipantResource

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/WFLY-7786?page=com.atlassian.jira.plugin.... ] Tom Jenkinson moved JBTM-2817 to WFLY-7786: ------------------------------------------- Project: WildFly (was: JBoss Transaction Manager) Key: WFLY-7786 (was: JBTM-2817) Component/s: REST (was: REST) Fix Version/s: (was: 5.next) > Server startup hanging in InboundBridgeRecoveryTestCase#testCrashAfterPrepareInParticipantResource > -------------------------------------------------------------------------------------------------- > > Key: WFLY-7786 > URL: https://issues.jboss.org/browse/WFLY-7786 > Project: WildFly > Issue Type: Bug > Components: REST > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Priority: Blocker > > Since WFLY-6493 - WildFly won't respond to HTTP calls during startup now causing hang in recovery in bridge: > {code} > I have this from the debugger hanging: > "MSC service thread 1-8@2725" prio=5 tid=0x1a nid=NA runnable > java.lang.Thread.State: RUNNABLE > at java.net.SocketInputStream.socketRead0(SocketInputStream.java:-1) > at java.net.SocketInputStream.socketRead(SocketInputStream.java:116) > at java.net.SocketInputStream.read(SocketInputStream.java:170) > at java.net.SocketInputStream.read(SocketInputStream.java:141) > at org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:139) > at org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:155) > at org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:284) > at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140) > at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57) > at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261) > at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165) > at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272) > at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124) > at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271) > at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184) > at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88) > at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) > at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184) > at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) > at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55) > at org.jboss.resteasy.client.jaxrs.engines.ApacheHttpClient4Engine.invoke(ApacheHttpClient4Engine.java:285) > at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.invoke(ClientInvocation.java:454) > at org.jboss.resteasy.client.jaxrs.internal.ClientInvocationBuilder.put(ClientInvocationBuilder.java:175) > at org.jboss.narayana.rest.integration.RecoveryManager.synchronizeParticipantUrlWithCoordinator(RecoveryManager.java:244) > at org.jboss.narayana.rest.integration.RecoveryManager.recreateParticipantInformation(RecoveryManager.java:202) > at org.jboss.narayana.rest.integration.RecoveryManager.recoverParticipants(RecoveryManager.java:153) > at org.jboss.narayana.rest.integration.RecoveryManager.registerDeserializer(RecoveryManager.java:62) > at org.jboss.narayana.rest.integration.ParticipantsManagerImpl.registerDeserializer(ParticipantsManagerImpl.java:105) > at org.jboss.narayana.rest.bridge.inbound.InboundBridgeManager.<init>(InboundBridgeManager.java:60) > at org.jboss.narayana.rest.bridge.inbound.InboundBridgeManager.getInstance(InboundBridgeManager.java:50) > - locked <0x2aba> (a java.lang.Class) > at org.wildfly.extension.rts.service.InboundBridgeService.start(InboundBridgeService.java:53) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2113) ResourceAdapter#endpointActivation called twice because of SuspendController activation

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2113?page=com.atlassian.jira.plugi... ] Ondra Chaloupka reassigned WFCORE-2113: --------------------------------------- Assignee: Stuart Douglas (was: Jason Greene) > ResourceAdapter#endpointActivation called twice because of SuspendController activation > --------------------------------------------------------------------------------------- > > Key: WFCORE-2113 > URL: https://issues.jboss.org/browse/WFCORE-2113 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 3.0.0.Alpha13 > Reporter: Ondra Chaloupka > Assignee: Stuart Douglas > > I do experience that call of my implementation {{ResourceAdapter#endpointActivation}} is called twice. Which is difference against behavior before (<=7.1.0.DR8) and I think that that method should be called just once. My RAR implementation uses the method {{endpointActivation}} for opening a socket and second call then causes a {{ResourceException}} being thrown and ERROR log message appears in server log > {code} > ERROR [org.jboss.as.server] (ServerService Thread Pool -- 66) WFLYSRV0215: Failed to resume activity org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent$1@43ab957d. To resume normal operation it is recommended that you restart the server. > {code} > By my investigation it's caused by the fact that {{SuspendController}} launches {{resume}} method of {{ServerActivity serverActivity}} at {{org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent}}. > I think it's caused because method {{SuspendController#setStartSuspended}} sets state to {{SUSPENDED}} regardless of boolean parameter value. > https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/... > I tried to do a small fix (I'm not sure if it's correct one) and that way the endpoint activation is launched just once as I expect. > https://github.com/ochaloup/wildfly-core/commit/4d6ac5777414088c9f39605e9... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2113) ResourceAdapter#endpointActivation called twice because of SuspendController activation

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2113?page=com.atlassian.jira.plugi... ] Ondra Chaloupka updated WFCORE-2113: ------------------------------------ Affects Version/s: 3.0.0.Alpha13 > ResourceAdapter#endpointActivation called twice because of SuspendController activation > --------------------------------------------------------------------------------------- > > Key: WFCORE-2113 > URL: https://issues.jboss.org/browse/WFCORE-2113 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 3.0.0.Alpha13 > Reporter: Ondra Chaloupka > Assignee: Stuart Douglas > > I do experience that call of my implementation {{ResourceAdapter#endpointActivation}} is called twice. Which is difference against behavior before (<=7.1.0.DR8) and I think that that method should be called just once. My RAR implementation uses the method {{endpointActivation}} for opening a socket and second call then causes a {{ResourceException}} being thrown and ERROR log message appears in server log > {code} > ERROR [org.jboss.as.server] (ServerService Thread Pool -- 66) WFLYSRV0215: Failed to resume activity org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent$1@43ab957d. To resume normal operation it is recommended that you restart the server. > {code} > By my investigation it's caused by the fact that {{SuspendController}} launches {{resume}} method of {{ServerActivity serverActivity}} at {{org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent}}. > I think it's caused because method {{SuspendController#setStartSuspended}} sets state to {{SUSPENDED}} regardless of boolean parameter value. > https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/... > I tried to do a small fix (I'm not sure if it's correct one) and that way the endpoint activation is launched just once as I expect. > https://github.com/ochaloup/wildfly-core/commit/4d6ac5777414088c9f39605e9... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2113) ResourceAdapter#endpointActivation called twice because of SuspendController activation

by Ondra Chaloupka (JIRA)

Ondra Chaloupka created WFCORE-2113: --------------------------------------- Summary: ResourceAdapter#endpointActivation called twice because of SuspendController activation Key: WFCORE-2113 URL: https://issues.jboss.org/browse/WFCORE-2113 Project: WildFly Core Issue Type: Bug Components: Server Reporter: Ondra Chaloupka Assignee: Jason Greene I do experience that call of my implementation {{ResourceAdapter#endpointActivation}} is called twice. Which is difference against behavior before (<=7.1.0.DR8) and I think that that method should be called just once. My RAR implementation uses the method {{endpointActivation}} for opening a socket and second call then causes a {{ResourceException}} being thrown and ERROR log message appears in server log {code} ERROR [org.jboss.as.server] (ServerService Thread Pool -- 66) WFLYSRV0215: Failed to resume activity org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent$1@43ab957d. To resume normal operation it is recommended that you restart the server. {code} By my investigation it's caused by the fact that {{SuspendController}} launches {{resume}} method of {{ServerActivity serverActivity}} at {{org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent}}. I think it's caused because method {{SuspendController#setStartSuspended}} sets state to {{SUSPENDED}} regardless of boolean parameter value. https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/... I tried to do a small fix (I'm not sure if it's correct one) and that way the endpoint activation is launched just once as I expect. https://github.com/ochaloup/wildfly-core/commit/4d6ac5777414088c9f39605e9... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1379) Extend OOPath test coverage

by Marek Winkler (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1379?page=com.atlassian.jira.plugi... ] Marek Winkler commented on DROOLS-1379: --------------------------------------- Created PR \[1] with tests for NPE during OOPath constraint marshalling. \[1] https://github.com/droolsjbpm/drools/pull/1034 > Extend OOPath test coverage > --------------------------- > > Key: DROOLS-1379 > URL: https://issues.jboss.org/browse/DROOLS-1379 > Project: Drools > Issue Type: Task > Components: core engine > Affects Versions: 7.0.0.Beta4 > Reporter: Marek Winkler > Assignee: Marek Winkler > > Add more tests for OOPath feature. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7300) OperationHandlers that register DeploymentProcessor should do it only on boot

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-7300?page=com.atlassian.jira.plugin.... ] Thomas Diesler commented on WFLY-7300: -------------------------------------- Yes, I was using an old batch subsystem config. You can ignore this issue from my side. > OperationHandlers that register DeploymentProcessor should do it only on boot > ----------------------------------------------------------------------------- > > Key: WFLY-7300 > URL: https://issues.jboss.org/browse/WFLY-7300 > Project: WildFly > Issue Type: Bug > Reporter: ehsavoie Hugonnet > Assignee: James Perkins > Fix For: 11.0.0.Alpha1 > > > Registering a DeploymentProcessor is a boot only operation. Thus instead of extends AbstractAddStepHandler they should extend AbstractBoottimeAddStepHandler -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1379) Extend OOPath test coverage

by Marek Winkler (JIRA)

Marek Winkler created DROOLS-1379: ------------------------------------- Summary: Extend OOPath test coverage Key: DROOLS-1379 URL: https://issues.jboss.org/browse/DROOLS-1379 Project: Drools Issue Type: Task Components: core engine Affects Versions: 7.0.0.Beta4 Reporter: Marek Winkler Assignee: Marek Winkler Add more tests for OOPath feature. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 5 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 December 2016