September 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AG-147) Add SpringBoot starter

by Luis Barreiro (Jira)

Luis Barreiro created AG-147: -------------------------------- Summary: Add SpringBoot starter Key: AG-147 URL: https://issues.redhat.com/browse/AG-147 Project: Agroal Issue Type: Bug Components: spring Affects Versions: 1.8 Reporter: Luis Barreiro Assignee: Luis Barreiro Fix For: 1.9 A SpringBoot starter project will allow SpringBoot applications to use Agroal as the connection provider. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-347) Bootable JAR - No context is registered on server if packaging is left on default

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFWIP-347?page=com.atlassian.jira.plugin... ] Darran Lofthouse commented on WFWIP-347: ---------------------------------------- The current behaviour sounds reasonable, I think it is a minimal requirement that the pom is correctly configured for the type of the deployment before the addition of our plug-in. > Bootable JAR - No context is registered on server if packaging is left on default > --------------------------------------------------------------------------------- > > Key: WFWIP-347 > URL: https://issues.redhat.com/browse/WFWIP-347 > Project: WildFly WIP > Issue Type: Bug > Reporter: Jan Kasik > Assignee: Jean Francois Denise > Priority: Major > > When default packaging for app is selected (meaning no {{<packaging>}}), the app deploys but no web context is registered. {{war}} must be set as value of {{<packaging>}} in order to register web context. > Since setting of packaging is not a part of plugin configuration I find it confusing. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-347) Bootable JAR - No context is registered on server if packaging is left on default

by Jean Francois Denise (Jira)

[ https://issues.redhat.com/browse/WFWIP-347?page=com.atlassian.jira.plugin... ] Jean Francois Denise commented on WFWIP-347: -------------------------------------------- That is expected. If you don't set a packaging, jar is the default. It means that the deployment is not a war, so is not set registered. That is a WildFly behavior, not a Bootable JAR one. > Bootable JAR - No context is registered on server if packaging is left on default > --------------------------------------------------------------------------------- > > Key: WFWIP-347 > URL: https://issues.redhat.com/browse/WFWIP-347 > Project: WildFly WIP > Issue Type: Bug > Reporter: Jan Kasik > Assignee: Jean Francois Denise > Priority: Major > > When default packaging for app is selected (meaning no {{<packaging>}}), the app deploys but no web context is registered. {{war}} must be set as value of {{<packaging>}} in order to register web context. > Since setting of packaging is not a part of plugin configuration I find it confusing. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-347) Bootable JAR - No context is registered on server if packaging is left on default

by Jean Francois Denise (Jira)

[ https://issues.redhat.com/browse/WFWIP-347?page=com.atlassian.jira.plugin... ] Jean Francois Denise edited comment on WFWIP-347 at 9/8/20 9:47 AM: -------------------------------------------------------------------- That is expected. If you don't set a packaging, jar is the default. It means that the deployment is not a war, so is not registered. That is a WildFly behavior, not a Bootable JAR one. was (Author: jdenise): That is expected. If you don't set a packaging, jar is the default. It means that the deployment is not a war, so is not set registered. That is a WildFly behavior, not a Bootable JAR one. > Bootable JAR - No context is registered on server if packaging is left on default > --------------------------------------------------------------------------------- > > Key: WFWIP-347 > URL: https://issues.redhat.com/browse/WFWIP-347 > Project: WildFly WIP > Issue Type: Bug > Reporter: Jan Kasik > Assignee: Jean Francois Denise > Priority: Major > > When default packaging for app is selected (meaning no {{<packaging>}}), the app deploys but no web context is registered. {{war}} must be set as value of {{<packaging>}} in order to register web context. > Since setting of packaging is not a part of plugin configuration I find it confusing. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-347) Bootable JAR - No context is registered on server if packaging is left on default

by Jan Kasik (Jira)

Jan Kasik created WFWIP-347: ------------------------------- Summary: Bootable JAR - No context is registered on server if packaging is left on default Key: WFWIP-347 URL: https://issues.redhat.com/browse/WFWIP-347 Project: WildFly WIP Issue Type: Bug Reporter: Jan Kasik Assignee: Jean Francois Denise When default packaging for app is selected (meaning no {{<packaging>}}), the app deploys but no web context is registered. {{war}} must be set as value of {{<packaging>}} in order to register web context. Since setting of packaging is not a part of plugin configuration I find it confusing. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1217) Fault Injection in Service Actions

by Hayk Hovsepyan (Jira)

Hayk Hovsepyan created SWSQE-1217: ------------------------------------- Summary: Fault Injection in Service Actions Key: SWSQE-1217 URL: https://issues.redhat.com/browse/SWSQE-1217 Project: Kiali QE Issue Type: QE Task Reporter: Hayk Hovsepyan https://github.com/kiali/kiali-ui/pull/1913 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13829) EJB: request are compressed by default if the descriptor is used

by Tomasz Adamski (Jira)

Tomasz Adamski created WFLY-13829: ------------------------------------- Summary: EJB: request are compressed by default if the descriptor is used Key: WFLY-13829 URL: https://issues.redhat.com/browse/WFLY-13829 Project: WildFly Issue Type: Bug Reporter: Tomasz Adamski Assignee: Tomasz Adamski If default compression parameter is not specified not compressing should be the default. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5620) SerializedPackageMergeTwoSteps2Test random failure

by Daniel Rosa (Jira)

[ https://issues.redhat.com/browse/DROOLS-5620?page=com.atlassian.jira.plug... ] Daniel Rosa updated DROOLS-5620: -------------------------------- Sprint: 2020 Week 37-39 (from Sep 7) > SerializedPackageMergeTwoSteps2Test random failure > -------------------------------------------------- > > Key: DROOLS-5620 > URL: https://issues.redhat.com/browse/DROOLS-5620 > Project: Drools > Issue Type: Bug > Reporter: Daniel Rosa > Assignee: Daniel Rosa > Priority: Minor > > org.drools.compiler.integrationtests. > SerializedPackageMergeTwoSteps2Test.testBuildAndSerializePackagesInTwoSteps2 > Failed on [7.39.x daily build #74|https://rhba-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/KIE/job/7.39.x/job/daily-build-prod/job/daily-build-prod-pipeline-7.39.x/74/testReport/junit/org.drools.compiler.integrationtests/SerializedPackageMergeTwoSteps2Test/testBuildAndSerializePackagesInTwoSteps2/] with java.io.EOFException. > The EOFException is raised when the resource files provided by the first step class (SerializedPackageMergeTwoSteps1Test) are not ready for the second class (SerializedPackageMergeTwoSteps2Test) to consume them. > It happened on #74 build that the second class tried to consume the files faster than the first class was able to finish writing them on disk. > The QE community test jobs ([this one for instance|https://rhba-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/BxMS...]) passed for 7.8.1 build. > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5631) Rule evaluation optimization

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5631?page=com.atlassian.jira.plug... ] Toshiya Kobayashi updated DROOLS-5631: -------------------------------------- Description: Motivation: This Story aims at rule evaluation optimization so both Kogito and drools core engine usage will get benefits for overall rule execution. It contains Alpha Node Ordering to maximize sharing and minimize the number of evaluations, Range Indexing (I will file and link later). Other JIRAs may be added later. Goals: Better rule execution performance. For each improvement, add benchmark and measure the performance gain. Impact: Better rule execution performance. It might have overhead during rule build time. Will confirm with benchmark anyway. was: Motivation: This Story aims at rule evaluation optimization so both Kogito and drools core engine usage will get benefits for overall rule execution. It contains Alpha Node Ordering to maximize sharing and minimize the number of evaluations, Range Indexing (may add more). Goals: Better rule execution performance. For each improvement, add benchmark and measure the performance gain. Impact: Better rule execution performance. It might have overhead during rule build time. Will confirm with benchmark anyway. > Rule evaluation optimization > ---------------------------- > > Key: DROOLS-5631 > URL: https://issues.redhat.com/browse/DROOLS-5631 > Project: Drools > Issue Type: Story > Components: core engine > Affects Versions: 7.42.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > Motivation: This Story aims at rule evaluation optimization so both Kogito and drools core engine usage will get benefits for overall rule execution. It contains Alpha Node Ordering to maximize sharing and minimize the number of evaluations, Range Indexing (I will file and link later). Other JIRAs may be added later. > Goals: Better rule execution performance. For each improvement, add benchmark and measure the performance gain. > Impact: Better rule execution performance. It might have overhead during rule build time. Will confirm with benchmark anyway. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13828) remote+tls is not supported by EJBClient and remote-outbound-connection

by Matthias Großmann (Jira)

[ https://issues.redhat.com/browse/WFLY-13828?page=com.atlassian.jira.plugi... ] Matthias Großmann updated WFLY-13828: ------------------------------------- Description: Hi, in our company we would like to use the newest Wildfly together with legacy servers like JBoss AS 7 over SSL. This is possible with the Uri scheme "remote+tls" provided by jboss-remoting https://github.com/jboss-remoting/jboss-remoting/blob/master/src/main/jav... {code:java} final RemoteConnectionProviderFactory remoteConnectionProviderFactory = new RemoteConnectionProviderFactory(); ... endpoint.addConnectionProvider("remote+tls", remoteConnectionProviderFactory, OptionMap.create(Options.SECURE, Boolean.TRUE)); {code} But that uri scheme is not supported by the jboss-ejb-client in current version https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org... {code} public boolean supportsProtocol(final String uriScheme) { switch (uriScheme) { case "remote": case "remote+http": case "remote+https": // compatibility case "remoting": case "http-remoting": case "https-remoting": { return true; } default: { return false; } } } {code} and also the remote-outbound-connection does not allow that protocol: https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/sr... {code} public enum Protocol { REMOTE("remote"), REMOTE_HTTP("remote+http"), HTTP_REMOTING("http-remoting"), HTTPS_REMOTING("https-remoting"), REMOTE_HTTPS("remote+https"); {code} was: Hi, in our company we would like to use the newest Wildfly together with legacy servers like Jboss 7 over SSL. This is possible with the Uri scheme "remote+tls" provided by jboss-remoting https://github.com/jboss-remoting/jboss-remoting/blob/master/src/main/jav... {code:java} final RemoteConnectionProviderFactory remoteConnectionProviderFactory = new RemoteConnectionProviderFactory(); ... endpoint.addConnectionProvider("remote+tls", remoteConnectionProviderFactory, OptionMap.create(Options.SECURE, Boolean.TRUE)); {code} But that uri scheme is not supported by the jboss-ejb-client in current version https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org... {code} public boolean supportsProtocol(final String uriScheme) { switch (uriScheme) { case "remote": case "remote+http": case "remote+https": // compatibility case "remoting": case "http-remoting": case "https-remoting": { return true; } default: { return false; } } } {code} and also the remote-outbound-connection does not allow that protocol: https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/sr... {code} public enum Protocol { REMOTE("remote"), REMOTE_HTTP("remote+http"), HTTP_REMOTING("http-remoting"), HTTPS_REMOTING("https-remoting"), REMOTE_HTTPS("remote+https"); {code} > remote+tls is not supported by EJBClient and remote-outbound-connection > ----------------------------------------------------------------------- > > Key: WFLY-13828 > URL: https://issues.redhat.com/browse/WFLY-13828 > Project: WildFly > Issue Type: Bug > Components: Remoting > Affects Versions: 20.0.1.Final > Reporter: Matthias Großmann > Assignee: Flavia Rainone > Priority: Major > > Hi, > in our company we would like to use the newest Wildfly together with legacy servers like JBoss AS 7 over SSL. > This is possible with the Uri scheme "remote+tls" provided by jboss-remoting > https://github.com/jboss-remoting/jboss-remoting/blob/master/src/main/jav... > {code:java} > final RemoteConnectionProviderFactory remoteConnectionProviderFactory = new RemoteConnectionProviderFactory(); > ... > endpoint.addConnectionProvider("remote+tls", remoteConnectionProviderFactory, OptionMap.create(Options.SECURE, Boolean.TRUE)); > {code} > But that uri scheme is not supported by the jboss-ejb-client in current version > https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org... > {code} > public boolean supportsProtocol(final String uriScheme) { > switch (uriScheme) { > case "remote": > case "remote+http": > case "remote+https": > // compatibility > case "remoting": > case "http-remoting": > case "https-remoting": { > return true; > } > default: { > return false; > } > } > } > {code} > and also the remote-outbound-connection does not allow that protocol: > https://github.com/wildfly/wildfly-core/blob/master/remoting/subsystem/sr... > {code} > public enum Protocol { > REMOTE("remote"), > REMOTE_HTTP("remote+http"), > HTTP_REMOTING("http-remoting"), > HTTPS_REMOTING("https-remoting"), > REMOTE_HTTPS("remote+https"); > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2020