[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
[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
[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
[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
[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
[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
[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