May 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13501) Add Galleon channels for WF 21 / WF Core 13

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-13501?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-13501: ------------------------------------ Fix Version/s: 21.0.0.Beta1 (was: 20.0.0.Beta1) > Add Galleon channels for WF 21 / WF Core 13 > ------------------------------------------- > > Key: WFLY-13501 > URL: https://issues.redhat.com/browse/WFLY-13501 > Project: WildFly > Issue Type: Task > Components: Build System > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Blocker > Fix For: 21.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13500) Add Galleon channels for WF 20 / WF Core 12

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-13500: --------------------------------------- Summary: Add Galleon channels for WF 20 / WF Core 12 Key: WFLY-13500 URL: https://issues.redhat.com/browse/WFLY-13500 Project: WildFly Issue Type: Task Components: Build System Reporter: Brian Stansberry Assignee: Brian Stansberry -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1968) Update error message returned by AcmeClientSpi#getLocation

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1968?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1968: ---------------------------- Description: The {{AcmeClientSpi#getLocation}} method returns the value of the "Location" header field if non-null. Otherwise, an exception is thrown. Currently, the error message is specific to accounts, i.e., the error message "No account location URL provided by ACME server" is returned. However, the {{AcmeClientSpi#getLocation}} method is actually called to retrieve the "Location" header field in other cases as well, like when obtaining the URL for orders and authorizations. This should be updated so that the exception that is thrown has an appropriate error message depending on the location URL that could not be retrieved (i.e., the error message should reference the "account location URL", the "order location URL", or the "authorization location URL" as appropriate). (was: The `AcmeClientSpi#getLocation` method returns the value of the "Location" header field if non-null. Otherwise, an exception is thrown. Currently, the error message is specific to accounts, i.e., the error message "No account location URL provided by ACME server" is returned. However, the `AcmeClientSpi#getLocation` method is actually called to retrieve the "Location" header field in other cases as well, like when obtaining the URL for orders and authorizations. This should be updated so that the exception that is thrown has an appropriate error message depending on the location URL that could not be retrieved (i.e., the error message should reference the "account location URL", the "order location URL", or the "authorization location URL" as appropriate).) > Update error message returned by AcmeClientSpi#getLocation > ---------------------------------------------------------- > > Key: ELY-1968 > URL: https://issues.redhat.com/browse/ELY-1968 > Project: WildFly Elytron > Issue Type: Bug > Components: API / SPI > Reporter: Farah Juma > Assignee: Sonia Zaldana > Priority: Minor > > The {{AcmeClientSpi#getLocation}} method returns the value of the "Location" header field if non-null. Otherwise, an exception is thrown. Currently, the error message is specific to accounts, i.e., the error message "No account location URL provided by ACME server" is returned. However, the {{AcmeClientSpi#getLocation}} method is actually called to retrieve the "Location" header field in other cases as well, like when obtaining the URL for orders and authorizations. This should be updated so that the exception that is thrown has an appropriate error message depending on the location URL that could not be retrieved (i.e., the error message should reference the "account location URL", the "order location URL", or the "authorization location URL" as appropriate). -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1968) Update error message returned by AcmeClientSpi#getLocation

by Farah Juma (Jira)

Farah Juma created ELY-1968: ------------------------------- Summary: Update error message returned by AcmeClientSpi#getLocation Key: ELY-1968 URL: https://issues.redhat.com/browse/ELY-1968 Project: WildFly Elytron Issue Type: Bug Components: API / SPI Reporter: Farah Juma Assignee: Sonia Zaldana The `AcmeClientSpi#getLocation` method returns the value of the "Location" header field if non-null. Otherwise, an exception is thrown. Currently, the error message is specific to accounts, i.e., the error message "No account location URL provided by ACME server" is returned. However, the `AcmeClientSpi#getLocation` method is actually called to retrieve the "Location" header field in other cases as well, like when obtaining the URL for orders and authorizations. This should be updated so that the exception that is thrown has an appropriate error message depending on the location URL that could not be retrieved (i.e., the error message should reference the "account location URL", the "order location URL", or the "authorization location URL" as appropriate). -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13249) WebSecurityCERTTestCase fails on IBM JDK when elytron is enabled

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/WFLY-13249?page=com.atlassian.jira.plugi... ] Farah Juma reassigned WFLY-13249: --------------------------------- Assignee: Sonia Zaldana > WebSecurityCERTTestCase fails on IBM JDK when elytron is enabled > ---------------------------------------------------------------- > > Key: WFLY-13249 > URL: https://issues.redhat.com/browse/WFLY-13249 > Project: WildFly > Issue Type: Bug > Components: Security, Test Suite > Reporter: Fabio Burzigotti > Assignee: Sonia Zaldana > Priority: Major > > The WebSecurityCERTTestCase fails only on IBM JDK, due to the following root cause: > {code} > Caused by: java.security.NoSuchAlgorithmException: SunX509 TrustManagerFactory not available > {code} > which in turn is due to the fact that the used algorithm is not available on IMB JDK, see for instance https://www-01.ibm.com/support/docview.wss?uid=swg1IT04505 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-10173) EjbInvocationStatisticsTestCase fails on Windows: wait-time=0

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFLY-10173?page=com.atlassian.jira.plugi... ] Cheng Fang reassigned WFLY-10173: --------------------------------- Assignee: Cheng Fang (was: Lukas Vydra) > EjbInvocationStatisticsTestCase fails on Windows: wait-time=0 > ------------------------------------------------------------- > > Key: WFLY-10173 > URL: https://issues.redhat.com/browse/WFLY-10173 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 12.0.0.Final > Reporter: Jan Kalina > Assignee: Cheng Fang > Priority: Major > Fix For: 20.0.0.Final > > > Sometime, when running EjbInvocationStatisticsTestCase on Windows, assertion fails, as wait-time is 0 (verified it is 0 by adding debug message). > For me it fails allTests in most of cases, but when running test standalone, it fails only in 1 of 4 cases. > I suppose it is because of too short sleep in AbstractManagedBean. (in test is called 4 times, each invocation include 50ms sleep, so I consider probable the wait-time is 0 - need to use longer sleeps to fulfill the test) > {code} > [ERROR] Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.078 s <<< FAILURE! - in org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase > [ERROR] testSingletonWaitTime(org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase) Time elapsed: 0.438 s <<< FAILURE! > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertTrue(Assert.java:52) > at org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase.validateWaitTimeStatistic(EjbInvocationStatisticsTestCase.java:179) > at org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase.testSingletonWaitTime(EjbInvocationStatisticsTestCase.java:148) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:564) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:379) > ... > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5341) ExecutionResultImpl not properly serialized in JSon Response

by Steve Davidson (Jira)

[ https://issues.redhat.com/browse/DROOLS-5341?page=com.atlassian.jira.plug... ] Steve Davidson updated DROOLS-5341: ----------------------------------- Sprint: (was: 2020 Week 22-24 (from May 25)) > ExecutionResultImpl not properly serialized in JSon Response > ------------------------------------------------------------ > > Key: DROOLS-5341 > URL: https://issues.redhat.com/browse/DROOLS-5341 > Project: Drools > Issue Type: Bug > Affects Versions: 7.29.0.Final > Reporter: Steve Davidson > Assignee: Mario Fusco > Priority: Major > Labels: drools, kie, kie-server > Attachments: KieIssueDemo.tbz > > > When a Drools Batch command has been processed, the conversion of the Kie ServiceResponse to JSON incorrectly serializes the ExecutionResponseImple. The resulting message looks like: > {code:json} > { > "org.kie.server.api.model.ServiceResponse" : { > "type" : "SUCCESS", > "msg" : "Container Kie Demo: kie-server successfully called.", > "result" : { > "ExecutionResultImpl" : { > "results" : [ ], > "facts" : [ ] > } > } > } > } > {code} > This results in deserialization failure of the client side as the type of the result can not be determined. The correct response should be: > {code:json} > { > "org.kie.server.api.model.ServiceResponse" : { > "type" : "SUCCESS", > "msg" : "Container Kie Demo: kie-server successfully called.", > "result" : { > "execution-results" : { > "results" : [ ], > "facts" : [ ] > } > } > } > } > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5341) ExecutionResultImpl not properly serialized in JSon Response

by Steve Davidson (Jira)

[ https://issues.redhat.com/browse/DROOLS-5341?page=com.atlassian.jira.plug... ] Steve Davidson closed DROOLS-5341. ---------------------------------- QE Status: VERIFIED (was: NEW) Resolution: Explained Side-effect of Gradle configuration in DROOLS-5021. See [DROOLS-5021|https://issues.redhat.com/browse/DROOLS-5021?focusedCommentId...] and [DROOLS-5021|https://issues.redhat.com/browse/DROOLS-5021?focusedCommentId...] for details. > ExecutionResultImpl not properly serialized in JSon Response > ------------------------------------------------------------ > > Key: DROOLS-5341 > URL: https://issues.redhat.com/browse/DROOLS-5341 > Project: Drools > Issue Type: Bug > Affects Versions: 7.29.0.Final > Reporter: Steve Davidson > Assignee: Mario Fusco > Priority: Major > Labels: drools, kie, kie-server > Attachments: KieIssueDemo.tbz > > > When a Drools Batch command has been processed, the conversion of the Kie ServiceResponse to JSON incorrectly serializes the ExecutionResponseImple. The resulting message looks like: > {code:json} > { > "org.kie.server.api.model.ServiceResponse" : { > "type" : "SUCCESS", > "msg" : "Container Kie Demo: kie-server successfully called.", > "result" : { > "ExecutionResultImpl" : { > "results" : [ ], > "facts" : [ ] > } > } > } > } > {code} > This results in deserialization failure of the client side as the type of the result can not be determined. The correct response should be: > {code:json} > { > "org.kie.server.api.model.ServiceResponse" : { > "type" : "SUCCESS", > "msg" : "Container Kie Demo: kie-server successfully called.", > "result" : { > "execution-results" : { > "results" : [ ], > "facts" : [ ] > } > } > } > } > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5309) ServiceResponse is not properly serialized when ExecutionResultImpl

by Steve Davidson (Jira)

[ https://issues.redhat.com/browse/DROOLS-5309?page=com.atlassian.jira.plug... ] Steve Davidson updated DROOLS-5309: ----------------------------------- Sprint: (was: 2020 Week 22-24 (from May 25)) > ServiceResponse is not properly serialized when ExecutionResultImpl > ------------------------------------------------------------------- > > Key: DROOLS-5309 > URL: https://issues.redhat.com/browse/DROOLS-5309 > Project: Drools > Issue Type: Bug > Components: kie server > Affects Versions: 7.29.0.Final, 7.33.0.Final > Reporter: Steve Davidson > Assignee: Mario Fusco > Priority: Major > Labels: drools, kie > Attachments: KieIssueDemo.tbz > > > When a Drools Batch command has been processed, the conversion of the Kie ServiceResponse to JSON wraps the ServiceResponse. The resulting message looks like: > {code:json} > { > "org.kie.server.api.model.ServiceResponse" : { > "type" : "SUCCESS", > "msg" : "Container Kie Demo: kie-server successfully called.", > "result" : { > "ExecutionResultImpl" : { > "results" : [ ], > "facts" : [ ] > } > } > } > } > {code} > A good response doesn't wrap the ServiceResponse: > {code:json} > { > "type" : "SUCCESS", > "msg" : "List of created containers", > "result" : { > "kie-containers" : { > "kie-container" : [ { > "container-id" : "Kie Demo: kie-server", > "release-id" : { > "group-id" : "com.j2eeguys.demo", > "artifact-id" : "KieIssueDemo", > "version" : "0.1.0-SNAPSHOT" > }, > "resolved-release-id" : { > "group-id" : "com.j2eeguys.demo", > "artifact-id" : "KieIssueDemo", > "version" : "0.1.0-SNAPSHOT" > }, > "status" : "STARTED", > "scanner" : { > "status" : "DISPOSED", > "poll-interval" : null > }, > "config-items" : [ ], > "messages" : [ { > "severity" : "INFO", > "timestamp" : { > "java.util.Date" : 1588885337926 > }, > "content" : [ "Container Kie Demo: kie-server successfully created with module com.j2eeguys.demo:KieIssueDemo:0.1.0-SNAPSHOT." ] > } ], > "container-alias" : null > } ] > } > } > } > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5309) ServiceResponse is not properly serialized when ExecutionResultImpl

by Steve Davidson (Jira)

[ https://issues.redhat.com/browse/DROOLS-5309?page=com.atlassian.jira.plug... ] Steve Davidson closed DROOLS-5309. ---------------------------------- Release Notes Text: Side-effect of Gradle configuration in DROOLS-5021. See Resolution: Explained Side-effect of Gradle configuration in DROOLS-5021. See [DROOLS-5021|https://issues.redhat.com/browse/DROOLS-5021?focusedCommentId...] for details. > ServiceResponse is not properly serialized when ExecutionResultImpl > ------------------------------------------------------------------- > > Key: DROOLS-5309 > URL: https://issues.redhat.com/browse/DROOLS-5309 > Project: Drools > Issue Type: Bug > Components: kie server > Affects Versions: 7.29.0.Final, 7.33.0.Final > Reporter: Steve Davidson > Assignee: Mario Fusco > Priority: Major > Labels: drools, kie > Attachments: KieIssueDemo.tbz > > > When a Drools Batch command has been processed, the conversion of the Kie ServiceResponse to JSON wraps the ServiceResponse. The resulting message looks like: > {code:json} > { > "org.kie.server.api.model.ServiceResponse" : { > "type" : "SUCCESS", > "msg" : "Container Kie Demo: kie-server successfully called.", > "result" : { > "ExecutionResultImpl" : { > "results" : [ ], > "facts" : [ ] > } > } > } > } > {code} > A good response doesn't wrap the ServiceResponse: > {code:json} > { > "type" : "SUCCESS", > "msg" : "List of created containers", > "result" : { > "kie-containers" : { > "kie-container" : [ { > "container-id" : "Kie Demo: kie-server", > "release-id" : { > "group-id" : "com.j2eeguys.demo", > "artifact-id" : "KieIssueDemo", > "version" : "0.1.0-SNAPSHOT" > }, > "resolved-release-id" : { > "group-id" : "com.j2eeguys.demo", > "artifact-id" : "KieIssueDemo", > "version" : "0.1.0-SNAPSHOT" > }, > "status" : "STARTED", > "scanner" : { > "status" : "DISPOSED", > "poll-interval" : null > }, > "config-items" : [ ], > "messages" : [ { > "severity" : "INFO", > "timestamp" : { > "java.util.Date" : 1588885337926 > }, > "content" : [ "Container Kie Demo: kie-server successfully created with module com.j2eeguys.demo:KieIssueDemo:0.1.0-SNAPSHOT." ] > } ], > "container-alias" : null > } ] > } > } > } > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 2 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 May 2020