[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, 10 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, 10 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, 10 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, 10 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, 10 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, 10 months
[JBoss JIRA] (WFWIP-334) Bootable JAR - Cloud - Support for dns.DNS_PING
by Martin Choma (Jira)
[ https://issues.redhat.com/browse/WFWIP-334?page=com.atlassian.jira.plugin... ]
Martin Choma edited comment on WFWIP-334 at 8/27/20 2:50 AM:
-------------------------------------------------------------
There is lot of environment properties in s2i which are related to configuring clustering (~10) . [1]
{code}
OPENSHIFT_KUBE_PING_*
OPENSHIFT_DNS_PING_*
JGROUPS_*
{code}
If I understand correctly what you are suggesting here is add support for one of them {{JGROUPS_PING_PROTOCOL}}. But that leaves us with 10 other properties where customer need to leverage custom CLI anyway. My point is if it so helpful for user - I assume it is just changing one value in model?
My feeling from yesterdays meeting was design purpose is to keep <cloud> logic as small as possible.
[1] https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap...
was (Author: mchoma):
There is lot of environment properties in s2i which are related to configuring clustering (~10) . [1]
If I understand correctly what you are suggesting here is add support for one of them {{JGROUPS_PING_PROTOCOL}}. But that leaves us with 10 other properties where customer need to leverage custom CLI anyway. My point is if it so helpful for user - I assume it is just changing one value in model?
{code}
OPENSHIFT_KUBE_PING_*
OPENSHIFT_DNS_PING_*
JGROUPS_*
{code}
My feeling from yesterdays meeting was design purpose is to keep <cloud> logic as small as possible.
[1] https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap...
> Bootable JAR - Cloud - Support for dns.DNS_PING
> -----------------------------------------------
>
> Key: WFWIP-334
> URL: https://issues.redhat.com/browse/WFWIP-334
> Project: WildFly WIP
> Issue Type: Feature Request
> Reporter: Jean Francois Denise
> Assignee: Jean Francois Denise
> Priority: Major
>
> Currently kubernetes.KUBE_PING is the protocol in use when cloud is enabled.
> KUBE_PING, although requiring an Openshift permission, is the simpler configuration wise (just need KUBERNETES namespace and your are done).
> DNS_PING doesn't require the extra permission but requires a new service (to expose the port 8888 in the pod) to be created.
> I propose that we keep KUBE_PING as the default protocol and extend the cloud element with a <ping-protocol>kubernetes.KUBE_PING|dns.DNS_PING</ping-protocol> element.
> The env variable used to set the service name is the same as EAP/XP S2I builder image: OPENSHIFT_DNS_PING_SERVICE_NAME
> web-clustering example will be evolved with a profile to support DNS_PING (and also to contain a yaml example file of the ping service).
> [~luck3y], [~mchoma], [~brian.stansberry] [~fburzigo] that is the proposal to also cover DNS_PING.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months