[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 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}
// remote (SSL is explicit in URL)
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 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
[JBoss JIRA] (DROOLS-5631) Rule evaluation optimization
by Toshiya Kobayashi (Jira)
Toshiya Kobayashi created DROOLS-5631:
-----------------------------------------
Summary: 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
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.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[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 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}
// remote (SSL is explicit in URL)
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}
// remote (SSL is explicit in URL)
final RemoteConnectionProviderFactory remoteConnectionProviderFactory = new RemoteConnectionProviderFactory();
endpoint.addConnectionProvider("remote", remoteConnectionProviderFactory, OptionMap.create(Options.SSL_ENABLED, Boolean.TRUE, Options.SSL_STARTTLS, Boolean.TRUE));
endpoint.addConnectionProvider("remote+tls", remoteConnectionProviderFactory, OptionMap.create(Options.SECURE, Boolean.TRUE));
// old (SSL is config-based)
endpoint.addConnectionProvider("remoting", remoteConnectionProviderFactory, OptionMap.create(Options.SSL_ENABLED, Boolean.TRUE, Options.SSL_STARTTLS, Boolean.TRUE));
// http - SSL is handled by the HTTP layer
final HttpUpgradeConnectionProviderFactory httpUpgradeConnectionProviderFactory = new HttpUpgradeConnectionProviderFactory();
endpoint.addConnectionProvider("remote+http", httpUpgradeConnectionProviderFactory, OptionMap.create(Options.SSL_ENABLED, Boolean.FALSE, Options.SSL_STARTTLS, Boolean.TRUE));
endpoint.addConnectionProvider("remote+https", httpUpgradeConnectionProviderFactory, OptionMap.create(Options.SECURE, Boolean.TRUE));
// old
endpoint.addConnectionProvider("http-remoting", httpUpgradeConnectionProviderFactory, OptionMap.create(Options.SSL_ENABLED, Boolean.FALSE, Options.SSL_STARTTLS, Boolean.TRUE));
endpoint.addConnectionProvider("https-remoting", httpUpgradeConnectionProviderFactory, 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 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}
> // remote (SSL is explicit in URL)
>
> 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
[JBoss JIRA] (WFLY-13828) remote+tls is not supported by EJBClient and remote-outbound-connection
by Matthias Großmann (Jira)
Matthias Großmann created WFLY-13828:
----------------------------------------
Summary: 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
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}
// remote (SSL is explicit in URL)
final RemoteConnectionProviderFactory remoteConnectionProviderFactory = new RemoteConnectionProviderFactory();
endpoint.addConnectionProvider("remote", remoteConnectionProviderFactory, OptionMap.create(Options.SSL_ENABLED, Boolean.TRUE, Options.SSL_STARTTLS, Boolean.TRUE));
endpoint.addConnectionProvider("remote+tls", remoteConnectionProviderFactory, OptionMap.create(Options.SECURE, Boolean.TRUE));
// old (SSL is config-based)
endpoint.addConnectionProvider("remoting", remoteConnectionProviderFactory, OptionMap.create(Options.SSL_ENABLED, Boolean.TRUE, Options.SSL_STARTTLS, Boolean.TRUE));
// http - SSL is handled by the HTTP layer
final HttpUpgradeConnectionProviderFactory httpUpgradeConnectionProviderFactory = new HttpUpgradeConnectionProviderFactory();
endpoint.addConnectionProvider("remote+http", httpUpgradeConnectionProviderFactory, OptionMap.create(Options.SSL_ENABLED, Boolean.FALSE, Options.SSL_STARTTLS, Boolean.TRUE));
endpoint.addConnectionProvider("remote+https", httpUpgradeConnectionProviderFactory, OptionMap.create(Options.SECURE, Boolean.TRUE));
// old
endpoint.addConnectionProvider("http-remoting", httpUpgradeConnectionProviderFactory, OptionMap.create(Options.SSL_ENABLED, Boolean.FALSE, Options.SSL_STARTTLS, Boolean.TRUE));
endpoint.addConnectionProvider("https-remoting", httpUpgradeConnectionProviderFactory, 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
[JBoss JIRA] (DROOLS-5617) Refactor MiningModel source generation
by Gabriele Cardosi (Jira)
[ https://issues.redhat.com/browse/DROOLS-5617?page=com.atlassian.jira.plug... ]
Gabriele Cardosi updated DROOLS-5617:
-------------------------------------
Summary: Refactor MiningModel source generation (was: Refacto MiningModel source generation)
> Refactor MiningModel source generation
> --------------------------------------
>
> Key: DROOLS-5617
> URL: https://issues.redhat.com/browse/DROOLS-5617
> Project: Drools
> Issue Type: Task
> Reporter: Gabriele Cardosi
> Assignee: Gabriele Cardosi
> Priority: Blocker
> Labels: TrustyAI
>
> For code generation, currently, all sources of segment models of a MiningModel are put in the main (container) model sourcemap, and the list of "nested models" is empty.
> Scope of this refactor is to populate the list of nested models with the "HasSourcesMap" version of all the models, and populate the "main" sourcemap only with the MiningModel specific sources
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFCORE-5121) Unable to add a new server in a server-group of older EAP 7 host controller that is managed by a newer EAP 7 Domain Controller
by Bartosz Spyrko-Smietanko (Jira)
[ https://issues.redhat.com/browse/WFCORE-5121?page=com.atlassian.jira.plug... ]
Bartosz Spyrko-Smietanko moved JBEAP-20160 to WFCORE-5121:
----------------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-5121 (was: JBEAP-20160)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Server
(was: Server)
Affects Version/s: (was: 7.3.1.GA)
(was: 7.2.8.GA)
> Unable to add a new server in a server-group of older EAP 7 host controller that is managed by a newer EAP 7 Domain Controller
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-5121
> URL: https://issues.redhat.com/browse/WFCORE-5121
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Bartosz Spyrko-Smietanko
> Assignee: Bartosz Spyrko-Smietanko
> Priority: Major
> Labels: customer, support-case-open
>
> I followed EAP 7.2 documentation [1] and have successfully configured a JBoss EAP 7.2.8 Domain Controller to Administer a JBoss EAP 7.1.6 Host Controller.
> I have followed all the steps listed in there and believe the configuration is OK. Both the master DC and host slave hosts started fine.
> The remote slave host "SlaveEAP71" registered successfully into the EAP 7.2.8 DC
> Cf.>>>
> {code:java}
> ...
> [Host Controller] 20:34:54,387 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.2.8.GA (WildFly Core 6.0.27.Final-redhat-00001) (Host Controller) started in 6162ms - Started 81 of 83 services (23 services are lazy, passive or on-demand)
> ...
> [Host Controller] 20:35:12,457 INFO [org.jboss.as.domain.controller] (Host Controller Service Threads - 9) WFLYHC0019: Registered remote slave host "SlaveEAP71", JBoss JBoss EAP 7.1.6.GA (WildFly 3.0.21.Final-redhat-00001)
> ...
> {code}
>
> However, when trying to add a new server in a server-group with profile copied from the older EAP 7.1.6 host , I'm not able to have this working. The following error always comes up on CLI started on EAP 7.2.8 Domain Controller
> {code:java}
> [domain@10.44.130.73:9990 /] /host=SlaveEAP71/server-config=SlaveJvm-EAP71:add(group=ServerGroup-eap71)
> {
> "outcome" => "failed",
> "result" => {},
> "failure-description" => {"host-failure-descriptions" => {"SlaveEAP71" => "WFLYHC0201: Error synchronizing the host model with the domain controller model with failure : WFLYDC0075: Cannot synchronize the model due to missing extensions: [org.wildfly.extension.microprofile.opentracing-smallrye, org.wildfly.extension.microprofile.config-smallrye, org.wildfly.extension.ee-security]."}},
> "rolled-back" => true
> }
> [domain@10.44.130.73:9990 /]
> {code}
>
> This is a the server group defined in the Host master domain.xml :
> {code:java}
> <server-groups>
> <server-group name="ServerGroup-eap71" profile="full-ha-eap71">
> <socket-binding-group ref="full-ha-eap71-sockets"/>
> </server-group>
> </server-groups>
> {code}
>
> The profile="full-ha-eap71" is copied from the EAP 7.1.6 domain.xml and added into EAP 7.2.8 domain.xml, as well as the "full-ha-eap71-sockets" socket-binding-group.
>
> *NOTE: The same issue does also happen with EAP 7.3.1 running as master host DC and EAP 7.1.6 as host slave.*
>
> [1] [https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_ap...]
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 3 months
[JBoss JIRA] (WFLY-13793) Attribute enable-amq1-prefix doesn't work (remote artemis)
by Emmanuel Hugonnet (Jira)
[ https://issues.redhat.com/browse/WFLY-13793?page=com.atlassian.jira.plugi... ]
Emmanuel Hugonnet commented on WFLY-13793:
------------------------------------------
This comes from the fact that any queue/topic created with the embedded broker will have this prefix thus we are trying to be in Artemis 1.x mode. Some magic is also occurring with Artemis client/ra code so changing this behavior might have some impact. This needs careful testing as we don't want to create refgressions
> 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
> Components: JMS, Management
> Affects Versions: 20.0.1.Final
> Reporter: Nicolas De Amicis
> Assignee: Chao Wang
> Priority: Major
> Fix For: 21.0.0.Beta1
>
>
> 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)
4 years, 3 months