August 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFWIP-337) Bootable JAR - Cloud - Add bindall interface, http(s) bound to bindall itf.

by Jean Francois Denise (Jira)

Jean Francois Denise created WFWIP-337: ------------------------------------------ Summary: Bootable JAR - Cloud - Add bindall interface, http(s) bound to bindall itf. Key: WFWIP-337 URL: https://issues.redhat.com/browse/WFWIP-337 Project: WildFly WIP Issue Type: Bug Reporter: Jean Francois Denise Assignee: Jean Francois Denise In S2i, the http socket binding is bound to 0.0.0.0. Currently in Bootable JAR it is bound to HOSTENV (if defined) and fallback to 127.0.0.1. We should align to S2I builder image by introducing the bindall interface and have http and https to use it. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5604) Implement IsMissing, IsNotMissing inside KiePMMLSimplePRedicate

by Gabriele Cardosi (Jira)

Gabriele Cardosi created DROOLS-5604: ---------------------------------------- Summary: Implement IsMissing, IsNotMissing inside KiePMMLSimplePRedicate Key: DROOLS-5604 URL: https://issues.redhat.com/browse/DROOLS-5604 Project: Drools Issue Type: Task Reporter: Gabriele Cardosi Assignee: Gabriele Cardosi Implement IsMissing/IsNotMissing management inside KiePMMLSimplePredicate -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-336) Bootable JAR - Cloud - Set proxy address forwarding

by Jean Francois Denise (Jira)

Jean Francois Denise created WFWIP-336: ------------------------------------------ Summary: Bootable JAR - Cloud - Set proxy address forwarding Key: WFWIP-336 URL: https://issues.redhat.com/browse/WFWIP-336 Project: WildFly WIP Issue Type: Bug Reporter: Jean Francois Denise Assignee: Jean Francois Denise That is required when running on Openshift, the details in this JIRA: [https://issues.redhat.com/browse/CLOUD-2055|https://www.google.com... -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13793) Attribute enable-amq1-prefix doesn't work (remote artemis)

by Nicolas De Amicis (Jira)

[ https://issues.redhat.com/browse/WFLY-13793?page=com.atlassian.jira.plugi... ] Nicolas De Amicis edited comment on WFLY-13793 at 8/27/20 5:20 AM: ------------------------------------------------------------------- Thanks for the PR and the workaround. The workaround adds to the standalone-full.xml the expected attribute: {quote}{{<pooled-connection-factory name="remote-artemis" entries="java:/jms/artemisConnectionFactory" connectors="remote-artemis" enable-amq1-prefix="false"/>}} {quote} But wildfly is listen always on the wrong queue. In my case, I would like that use the queue named toPrinter, but wildfly is listen on the queue named jms.queue.toPrinter. It's seems that enable-amq1-prefix=false has no effect. The version of my remote ActiveMQ Artemis is 2.10.1 A snippet from my MDB: {quote}{{@MessageDriven(name = "PrinterMDB", activationConfig = {}} @ActivationConfigProperty(propertyName = "destinationLookup", propertyValue = "toPrinter"), @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"), @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge")}) {{@ResourceAdapter(value = "remote-artemis")}} {{public class PrinterMDB implements MessageListener}} {{...}} {quote} And the parameters from my standalone-full.xml about remote-artemis: {quote}{{<remote-connector name="remote-artemis" socket-binding="remote-artemis"/>}} {{<pooled-connection-factory name="remote-artemis" entries="java:/jms/artemisConnectionFactory" connectors="remote-artemis" enable-amq1-prefix="false"/>}} {{<outbound-socket-binding name="remote-artemis">}} {{ <remote-destination host="testserver" port="61616"/>}} {{</outbound-socket-binding>}} {quote} was (Author: deamn): Thanks for the PR and the workaround. The workaround adds to the standalone-full.xml the expected attribute: {quote}{{<pooled-connection-factory name="remote-artemis" entries="java:/jms/artemisConnectionFactory" connectors="remote-artemis" enable-amq1-prefix="false"/>}} {quote} But wildfly is listen always on the wrong queue. In my case, I would like that use the queue named toPrinter, but wildfly is listen on the queue named jms.queue.toPrinter. It's seems that enable-amq1-prefix=false has no effect. The version of my remote ActiveMQ Artemis is 2.10.1 A snippet from my MDB: {quote}{{@MessageDriven(name = "PrinterMDB", activationConfig = {}} {{ @ActivationConfigProperty(propertyName = "destinationLookup", propertyValue = "toPrinter"),}} {{ @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),}} {{ @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge")})}} {{@ResourceAdapter(value = "remote-artemis")}} {{public class PrinterMDB implements MessageListener}} {{...}} {quote} And the parameters from my standalone-full.xml about remote-artemis: {quote}{{<remote-connector name="remote-artemis" socket-binding="remote-artemis"/>}} {{<pooled-connection-factory name="remote-artemis" entries="java:/jms/artemisConnectionFactory" connectors="remote-artemis" enable-amq1-prefix="false"/>}} {{<outbound-socket-binding name="remote-artemis">}} {{ <remote-destination host="testserver" port="61616"/>}} {{</outbound-socket-binding>}} {quote} > Attribute enable-amq1-prefix doesn't work (remote artemis) > ---------------------------------------------------------- > > Key: WFLY-13793 > URL: https://issues.redhat.com/browse/WFLY-13793 > Project: WildFly > Issue Type: Bug > Affects Versions: 17.0.1.Final > Reporter: Nicolas De Amicis > Assignee: Brian Stansberry > Priority: Major > > I need to connect Wildfly 17.0.1 to a remote Artemis server. I follow the doc here: [https://docs.wildfly.org/17/Admin_Guide.html#Messaging_Connect_a_pooled-c...] No problem for point 1 to 3. But when I follow the instruction for disabling the compatibility mode (enable-amq1-prefix) I have this error: > {quote}{{[standalone@localhost:9990 /] /subsystem=messaging-activemq/pooled-connection-factory=remote-artemis:write-attribute(name="enable-amq1-prefix", value="false")}} > \{{{}} > \{{ "outcome" => "failed",}} > \{{ "failure-description" => "WFLYCTL0248: Invalid value false for enable-amq1-prefix; legal values are [XA_GENERIC, GENERIC, XA_T}} > {{OPIC, TOPIC, QUEUE, XA_QUEUE]",}} > \{{ "rolled-back" => true}} > {{}}} > {quote} > If I deploy my MDB that connects to queue myqueue, I see in artemis console my MDB is connected to jms.queue.myqueue. > I also tried to add the attribute manually but it seems it doesn't work: > {quote}{{<pooled-connection-factory name="remote-artemis" entries="java:/}}{{jms/remoteCF}}{{" connectors="remote-artemis" enable-amq1-prefix="false"/>}} > {quote} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13793) Attribute enable-amq1-prefix doesn't work (remote artemis)

by Nicolas De Amicis (Jira)

[ https://issues.redhat.com/browse/WFLY-13793?page=com.atlassian.jira.plugi... ] Nicolas De Amicis commented on WFLY-13793: ------------------------------------------ Thanks for the PR and the workaround. The workaround adds to the standalone-full.xml the expected attribute: {quote}{{<pooled-connection-factory name="remote-artemis" entries="java:/jms/artemisConnectionFactory" connectors="remote-artemis" enable-amq1-prefix="false"/>}} {quote} But wildfly is listen always on the wrong queue. In my case, I would like that use the queue named toPrinter, but wildfly is listen on the queue named jms.queue.toPrinter. It's seems that enable-amq1-prefix=false has no effect. The version of my remote ActiveMQ Artemis is 2.10.1 A snippet from my MDB: {quote}{{@MessageDriven(name = "PrinterMDB", activationConfig = {}} {{ @ActivationConfigProperty(propertyName = "destinationLookup", propertyValue = "toPrinter"),}} {{ @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),}} {{ @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge")})}} {{@ResourceAdapter(value = "remote-artemis")}} {{public class PrinterMDB implements MessageListener}} {{...}} {quote} And the parameters from my standalone-full.xml about remote-artemis: {quote}{{<remote-connector name="remote-artemis" socket-binding="remote-artemis"/>}} {{<pooled-connection-factory name="remote-artemis" entries="java:/jms/artemisConnectionFactory" connectors="remote-artemis" enable-amq1-prefix="false"/>}} {{<outbound-socket-binding name="remote-artemis">}} {{ <remote-destination host="testserver" port="61616"/>}} {{</outbound-socket-binding>}} {quote} > Attribute enable-amq1-prefix doesn't work (remote artemis) > ---------------------------------------------------------- > > Key: WFLY-13793 > URL: https://issues.redhat.com/browse/WFLY-13793 > Project: WildFly > Issue Type: Bug > Affects Versions: 17.0.1.Final > Reporter: Nicolas De Amicis > Assignee: Brian Stansberry > Priority: Major > > I need to connect Wildfly 17.0.1 to a remote Artemis server. I follow the doc here: [https://docs.wildfly.org/17/Admin_Guide.html#Messaging_Connect_a_pooled-c...] No problem for point 1 to 3. But when I follow the instruction for disabling the compatibility mode (enable-amq1-prefix) I have this error: > {quote}{{[standalone@localhost:9990 /] /subsystem=messaging-activemq/pooled-connection-factory=remote-artemis:write-attribute(name="enable-amq1-prefix", value="false")}} > \{{{}} > \{{ "outcome" => "failed",}} > \{{ "failure-description" => "WFLYCTL0248: Invalid value false for enable-amq1-prefix; legal values are [XA_GENERIC, GENERIC, XA_T}} > {{OPIC, TOPIC, QUEUE, XA_QUEUE]",}} > \{{ "rolled-back" => true}} > {{}}} > {quote} > If I deploy my MDB that connects to queue myqueue, I see in artemis console my MDB is connected to jms.queue.myqueue. > I also tried to add the attribute manually but it seems it doesn't work: > {quote}{{<pooled-connection-factory name="remote-artemis" entries="java:/}}{{jms/remoteCF}}{{" connectors="remote-artemis" enable-amq1-prefix="false"/>}} > {quote} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5603) Refactor super invocation setting

by Gabriele Cardosi (Jira)

Gabriele Cardosi created DROOLS-5603: ---------------------------------------- Summary: Refactor super invocation setting Key: DROOLS-5603 URL: https://issues.redhat.com/browse/DROOLS-5603 Project: Drools Issue Type: Task Reporter: Gabriele Cardosi Assignee: Gabriele Cardosi Currently in sources generation the super invocation is managed by field index {code:java} // Some comments here ExplicitConstructorInvocationStmt superStatement = (ExplicitConstructorInvocationStmt) statement; NameExpr algorithmNameExpr = (NameExpr) superStatement.getArgument(2); algorithmNameExpr.setName(String.format("\"%s\"", treeModel.getAlgorithmName())); {code} This must be changed so that field to be set is looked for by name and - if not found, an exception must be thrown (as for the AssignExpr) -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1207) UI Automations - Fix failure tests because of filter

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1207?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan commented on SWSQE-1207: --------------------------------------- https://github.com/kiali/kiali/issues/3156 > UI Automations - Fix failure tests because of filter > ---------------------------------------------------- > > Key: SWSQE-1207 > URL: https://issues.redhat.com/browse/SWSQE-1207 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > > kiali_qe.tests.test_services_page.test_filter_service_by_or_label kiali_qe.tests.test_services_page.test_filter_service_by_and_label kiali_qe.tests.test_applications_page.test_filter_applications_by_and_label -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5104) remoting subsystem's http-connector is missing capability reference

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFCORE-5104?page=com.atlassian.jira.plug... ] Darran Lofthouse commented on WFCORE-5104: ------------------------------------------ We did discuss on the following PR https://github.com/wildfly/wildfly-core/pull/4291 that the remoting layer (not subsystem) needs to move to a feature pack in WildFly, I think that needs to happen before this requirement is added. The remoting layer then needs a dependency on the undertow layer otherwise that capability will not be satisfied so specifying the remoting layer to Galleon could lead to a failed installation / build. > remoting subsystem's http-connector is missing capability reference > ------------------------------------------------------------------- > > Key: WFCORE-5104 > URL: https://issues.redhat.com/browse/WFCORE-5104 > Project: WildFly Core > Issue Type: Bug > Components: Remoting > Reporter: Radoslav Husar > Assignee: Ranabir Chakraborty > Priority: Major > Labels: ux > > http-remoting-connector is missing capability reference to the undertow connector. > {noformat} > [standalone@localhost:9990 /] /subsystem=remoting/http-connector=http-remoting-connector:write-attribute(name=connector-ref,value=foo) > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > {noformat} > results in a cryptic error > {noformat} > 11:33:01,792 INFO [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.remoting.remotingConnectorInfoService.http-remoting-connector (missing) dependents: [service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings, service org.wildfly.ejb.remote] > WFLYCTL0448: 5 additional services are down due to their dependencies being missing or failed > 11:33:15,334 INFO [org.jboss.as.controller] (management-handler-thread - 1) WFLYCTL0183: Service status report > WFLYCTL0185: Newly corrected services: > service jboss.ejb.association (new available) > service jboss.ejb.remoting.connector.client-mappings (new available) > service jboss.remoting.remotingConnectorInfoService.http-remoting-connector (no longer required) > service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings (new available) > service org.wildfly.clustering.cache.registry-factory.ejb.client-mappings (new available) > service org.wildfly.clustering.group.ejb (new available) > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5539) Review dmn examples version in codebase

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-5539?page=com.atlassian.jira.plug... ] Matteo Mortari resolved DROOLS-5539. ------------------------------------ Resolution: Done > Review dmn examples version in codebase > --------------------------------------- > > Key: DROOLS-5539 > URL: https://issues.redhat.com/browse/DROOLS-5539 > Project: Drools > Issue Type: Story > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > Labels: core-team > > *Motivation*: avoid a User might find *_easily_* an outdated version (DMN v1.1) in the examples from our codebase. > *Goal*: review dmn examples version in codebase to make sure there are no "default" v1.1 model to be found, that are properly isolated in specific packages and/or specific test infrastructure. > *Impacts*: kie-dmn codebase in drools.git and downstream repos to be assessed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5539) Review dmn examples version in codebase

by Matteo Mortari (Jira)

[ https://issues.redhat.com/browse/DROOLS-5539?page=com.atlassian.jira.plug... ] Matteo Mortari commented on DROOLS-5539: ---------------------------------------- In conclusion, this required quite some solid work over the course of *+5 weeks+*, but *+18 PRs+* later, I am nearing completion of what was originally requested by dealing with approximately *+595 DMN files+*, either migrating them from v1.1 to v1.2, and/or archiving them in a separate, well-isolated module. This work spanned {{drools}}, {{jbpm}}, {{droolsjbpm-integration}} and {{kogito-runtimes}} repos beyond what mentioned at some point, so a total of 4 repos have been impacted. I haven't found for instance any DMNv1.2 inside {{kogito-examples}} and other example repos. I have not touched "front-end repos" since I assume those will be dealt-with as part of the front-end work itself, but I remain available if my support is still needed. If something still be missing, as part of this DROOLS-5539, it should contain everything required from tracking the work done to the tool I used to perform the migration [https://github.com/kiegroup/kie-dmn-versionconverter] which required several iteration to correctly deal with *_some_* edge-cases, which crippled down to *_many_* of the files subject of migration. > Review dmn examples version in codebase > --------------------------------------- > > Key: DROOLS-5539 > URL: https://issues.redhat.com/browse/DROOLS-5539 > Project: Drools > Issue Type: Story > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > Labels: core-team > > *Motivation*: avoid a User might find *_easily_* an outdated version (DMN v1.1) in the examples from our codebase. > *Goal*: review dmn examples version in codebase to make sure there are no "default" v1.1 model to be found, that are properly isolated in specific packages and/or specific test infrastructure. > *Impacts*: kie-dmn codebase in drools.git and downstream repos to be assessed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2020