[JBoss JIRA] (WFLY-10937) Starting WFLY scripts with JDK 11 blows up with ModuleNotFoundException java.se
by Suganya Rajeswaran (Jira)
[ https://issues.jboss.org/browse/WFLY-10937?page=com.atlassian.jira.plugin... ]
Suganya Rajeswaran commented on WFLY-10937:
-------------------------------------------
[~baranowb] How to add the same for windows in appclient.bat??
> Starting WFLY scripts with JDK 11 blows up with ModuleNotFoundException java.se
> -------------------------------------------------------------------------------
>
> Key: WFLY-10937
> URL: https://issues.jboss.org/browse/WFLY-10937
> Project: WildFly
> Issue Type: Bug
> Components: Scripts
> Reporter: Marek Kopecký
> Assignee: Richard Opalka
> Priority: Blocker
> Labels: Java11, blocker-WF14, jdk11
> Fix For: 15.0.0.Beta1, 15.0.0.Final
>
>
> Starting WFLY scripts with JDK 11 blows up with ModuleNotFoundException java.se
> *Affected scripts*
> * appclient
> * jdr
> * wsconsume
> * wsprovide
> *Example of logs*
> {noformat}
> [mkopecky@dhcp-10-40-4-197 bin]$ ./jdr.sh
> org.jboss.modules.ModuleNotFoundException: java.se
> at org.jboss.modules.Module.addPaths(Module.java:1266)
> at org.jboss.modules.Module.link(Module.java:1622)
> at org.jboss.modules.Module.relinkIfNecessary(Module.java:1650)
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:296)
> at org.jboss.modules.Main.main(Main.java:437)
> [mkopecky@dhcp-10-40-4-197 bin]$
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (DROOLS-3548) Thread used by loadbalancer remains when connection to kie-server fails a
by Hiroko Miura (Jira)
[ https://issues.jboss.org/browse/DROOLS-3548?page=com.atlassian.jira.plugi... ]
Hiroko Miura updated DROOLS-3548:
---------------------------------
Summary: Thread used by loadbalancer remains when connection to kie-server fails a (was: Thread remains used by loadbalancer when connection to kie-server failed)
> Thread used by loadbalancer remains when connection to kie-server fails a
> -------------------------------------------------------------------------
>
> Key: DROOLS-3548
> URL: https://issues.jboss.org/browse/DROOLS-3548
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 7.11.0.Final, 7.14.0.Final
> Environment: - Red Hat Decision Manager
> - 7
> - Red Hat Process Automation Manager
> - 7
> Reporter: Hiroko Miura
> Assignee: Maciej Swiderski
> Priority: Major
> Labels: support
> Attachments: rules-client.zip
>
>
> When KieServicesClient fails to connect to KieServer, LoadBalancer is invoked to check availability of server like the following.
> ~~~
> [2019/01/24 18:19:38.411] [pool-1-thread-1] [DEBUG] (LoadBalancer.java:149) - Starting to scan if any of the failed endpoints is back online
> org.kie.server.common.rest.NoEndpointFoundException: No available endpoints found
> at org.kie.server.client.balancer.impl.AbstractBalancerStrategy.checkEmpty(AbstractBalancerStrategy.java:27)
> at org.kie.server.client.balancer.impl.RoundRobinBalancerStrategy.next(RoundRobinBalancerStrategy.java:37)
> at org.kie.server.client.balancer.LoadBalancer.getUrl(LoadBalancer.java:52)
> at org.kie.server.client.impl.AbstractKieServicesClientImpl.invoke(AbstractKieServicesClientImpl.java:809)
> at org.kie.server.client.impl.AbstractKieServicesClientImpl.makeHttpGetRequestAndCreateServiceResponse(AbstractKieServicesClientImpl.java:177)
> at org.kie.server.client.impl.KieServicesClientImpl.getServerInfo(KieServicesClientImpl.java:159)
> at org.kie.server.client.impl.KieServicesClientImpl.getCapabilitiesFromServer(KieServicesClientImpl.java:132)
> at org.kie.server.client.impl.KieServicesClientImpl.init(KieServicesClientImpl.java:87)
> at org.kie.server.client.impl.KieServicesClientImpl.<init>(KieServicesClientImpl.java:74)
> at org.kie.server.client.KieServicesFactory.newKieServicesClient(KieServicesFactory.java:101)
> at com.sample.rules.test.KieServerRestClientTest.connectionFailureTest(KieServerRestClientTest.java:55)
> ~~~
> But after that, the thread used by LoadBalancer remains until termination of client application as LoadBalancer.close() is not called.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-8462) Improve feedback after invalid request for creating a datasource
by Harald Pehl (Jira)
[ https://issues.jboss.org/browse/WFLY-8462?page=com.atlassian.jira.plugin.... ]
Harald Pehl commented on WFLY-8462:
-----------------------------------
I agree. In general, it's hard to come up with specific, user-friendly error messages. For very common use cases like data sources and deployments, I could try to be more specific when it comes to an error. That would require that I can rely on certain information in the error response e.g. error codes, specific information I can extract, ...
> Improve feedback after invalid request for creating a datasource
> ----------------------------------------------------------------
>
> Key: WFLY-8462
> URL: https://issues.jboss.org/browse/WFLY-8462
> Project: WildFly
> Issue Type: Enhancement
> Components: JCA, Web Console
> Affects Versions: 10.1.0.Final
> Reporter: Karl-Philipp Richter
> Assignee: Harald Pehl
> Priority: Major
>
> After creating a Non-XA datasource in the web frontend and pressing finish on the last dialog page, I get the message "Unknown error" and the data entered into the form is lost. Clicking on "Unknown error" a dialog is displayed with the content
> ```
> Unexpected HTTP response: 500
> Request
> {
> "name" => "jdbc/linuxtracker2",
> "jta" => true,
> "enabled" => true,
> "user-name" => "APP",
> "password" => "APP",
> "jndi-name" => "java:/jdbc/linuxtracker2",
> "use-ccm" => true,
> "pool-name" => "jdbc/linuxtracker2_Pool",
> "connection-url" => "jdbc:derby://localhost:1527/derby-pool",
> "driver-class" => "org.apache.derby.jdbc.ClientDriver",
> "driver-name" => "jdbc/linuxtracker2",
> "operation" => "add",
> "address" => [
> ("subsystem" => "datasources"),
> ("data-source" => "jdbc/linuxtracker2")
> ]
> }
> Response
> Internal Server Error
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.jdbc-driver.jdbc/linuxtracker2"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => [
> "org.wildfly.data-source.jdbc/linuxtracker2 is missing [jboss.jdbc-driver.jdbc/linuxtracker2]",
> "jboss.driver-demander.java:/jdbc/linuxtracker2 is missing [jboss.jdbc-driver.jdbc/linuxtracker2]"
> ]
> },
> "rolled-back" => true
> }
> ```
> which is extremely unhelpful given the fact that an error message listing and explaining the cause for the failure could be displayed (e.g. "the datasource xy couldn't be created because the name doesn't match the requirement yz").
> It's hard to guess that clicking on the "Unknown error" popup opens a dialog.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11645) A way to prevent automatic changes of affinity when invoking clustered beans
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-11645?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz edited comment on WFLY-11645 at 1/25/19 4:01 AM:
---------------------------------------------------------------------
What is a clustered bean?
On the one hand, this is a bean deployed on a node in a cluster. In the case of SFSBs, if this bean has passivationEnabled=true, arrangements are made for making that beans state available across the cluster to support fail-over (selecting a different target for the invocation when a previous one failed). So, SFSBs are special in this respect.
On the other hand, from the point of view of the EJB client, a clustered bean is a proxy which has affinity to a cluster. This can apply to proxies for SFSB as well as SLSBs. To tie the proxy to the cluster, you need only (in theory) assign the strong affinity or the weak affinity of the proxy as type ClusterAffinity, but in practice, we usually tie the proxy to a cluster using the strong affinity. What this does is place a restriction on the targets chosen for the invocation; in this case, the target must point to some node within the cluster named in the affinity.
For a clustered SFSB proxy, where the strong affinity is used to specify affinity to the cluster, if you wanted to send a invocations to a particular node in the cluster, you can do it by setting the weak affinity of the proxy to a NodeAffinity for the node within the cluster. For a clustered SLSB proxy, you should be able to do the same. Whether or not you still can is another matter; i'm looking at writing a test to verify that these "edge case" affinity combinations work properly.
It is true that on invocations for SFSB and SLSBs, strong affinity was being forced to the "cluster affinity", which would result in the behavior that you observed, but this was incorrect and a fix is in place to change it (https://issues.jboss.org/browse/WFLY-11489). However, the bean will still be tied to the cluster as before, even after the fix.
One of the reasons why the affinity to the cluster is retained after invocation is that if you remove affinity to the cluster (as in your example), from the EJB client point of view, this bean is no longer a clustered bean and fail-over will not happen.
was (Author: rachmato):
What is a clustered bean? On the one hand, this is a bean deployed on a node in a cluster. In the case of SFSBs, if this bean has passivationEnabled=true, arrangements are made for making that beans state available across the cluster to support fail-over (selecting a different target for the invocation when a previous one failed). So, SFSBs are special in this respect. On the other hand, from the point of view of the EJB client, a clustered bean is a proxy which has affinity to a cluster. This can apply to proxies for SFSB as well as SLSBs. To tie the proxy to the cluster, you need only (in theory) assign the strong affinity or the weak affinity of the proxy as type ClusterAffinity, but in practice, we usually tie the proxy to a cluster using the strong affinity. What this does is place a restriction on the targets chosen for the invocation; in this case, the target must point to some node within the cluster named in the affinity.
For a clustered SFSB proxy, where the strong affinity is used to specify affinity to the cluster, if you wanted to send a invocations to a particular node in the cluster, you can do it by setting the weak affinity of the proxy to a NodeAffinity for the node within the cluster. For a clustered SLSB proxy, you should be able to do the same. Whether or not you still can is another matter; i'm looking at writing a test to verify that these "egde case" affinity combinations work properly.
It is true that on invocations for SFSB and SLSBs, strong affinity was being forced to the "cluster affinity", which would result in the behavior that you observed, but this was incorrect and a fix is in place to change it (https://issues.jboss.org/browse/WFLY-11489)
> A way to prevent automatic changes of affinity when invoking clustered beans
> ----------------------------------------------------------------------------
>
> Key: WFLY-11645
> URL: https://issues.jboss.org/browse/WFLY-11645
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering, EJB
> Reporter: Jan Martiska
> Priority: Major
>
> When invoking a clustered bean, a user might want to set an affinity so that the invocations go to a particular node. This is done via EJB client APIs:
> {noformat}
> EJBClient.setStrongAffinity(beanProxy, new NodeAffinity("node1"));
> {noformat}
> however, if the bean is clustered, after each invocation, the affinity is automatically reset to a ClusterAffinity. So the user would have to apply this again before each invocation. There should be a way to tell EJB client to not do this.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11647) Do not use hardcoded groupid for wildfly-client-properties in web services tests integration subsystem
by Yeray Borges (Jira)
Yeray Borges created WFLY-11647:
-----------------------------------
Summary: Do not use hardcoded groupid for wildfly-client-properties in web services tests integration subsystem
Key: WFLY-11647
URL: https://issues.jboss.org/browse/WFLY-11647
Project: WildFly
Issue Type: Task
Components: Build System
Reporter: Yeray Borges
Assignee: Yeray Borges
The use of maven property ${project.groupId} makes easier the transition between community and product branches.
In web services tests integration subsystem, there is a hard coded dependency org.wildfly:wildfly-client-properties which should be ${project.groupId}:wildfly-client-properties
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11646) Upgrade third party libraries
by Zabee Ulla (Jira)
[ https://issues.jboss.org/browse/WFLY-11646?page=com.atlassian.jira.plugin... ]
Zabee Ulla updated WFLY-11646:
------------------------------
Description:
As per the bug that was reported here - https://hibernate.atlassian.net/browse/HHH-10028, Hibernate stays in-step with Wildfly and EAP dependency versions to ensure compatibility.
This task is a request to upgrade antlr to its latest version available against WildFly so that Hibernate also can pick the latest to be in synch with WildFly.
Hibernate (hibernate-core to be more specific) latest version is still using antlr version 2.7.7 released on Jan 13, 2007. The latest available, built and maintained version is antlr-4-Runtime 4.7.2. Another reason for going with latest of antlr is to avoid any security vulnerabilities that the library is exposed to.
was:
As per the bug that was reported here - https://hibernate.atlassian.net/browse/HHH-10028
Hibernate stays in-step with Wildfly and EAP dependency versions to ensure compatibility.
This task is a request to upgrade antlr to its latest version available against WildFly so that Hibernate also can pick the latest to be in synch with WildFly.
Hibernate (hibernate-core to be more specific) latest version is still using antlr version 2.7.7 released on Jan 13, 2007. The latest available, built and maintained version is antlr-4-Runtime 4.7.2. Another reason for going with latest of antlr is to avoid any security vulnerabilities that the library is exposed to.
> Upgrade third party libraries
> -----------------------------
>
> Key: WFLY-11646
> URL: https://issues.jboss.org/browse/WFLY-11646
> Project: WildFly
> Issue Type: Component Upgrade
> Components: JPA / Hibernate
> Reporter: Zabee Ulla
> Assignee: Scott Marlow
> Priority: Minor
>
> As per the bug that was reported here - https://hibernate.atlassian.net/browse/HHH-10028, Hibernate stays in-step with Wildfly and EAP dependency versions to ensure compatibility.
> This task is a request to upgrade antlr to its latest version available against WildFly so that Hibernate also can pick the latest to be in synch with WildFly.
> Hibernate (hibernate-core to be more specific) latest version is still using antlr version 2.7.7 released on Jan 13, 2007. The latest available, built and maintained version is antlr-4-Runtime 4.7.2. Another reason for going with latest of antlr is to avoid any security vulnerabilities that the library is exposed to.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11646) Upgrade a third party library
by Zabee Ulla (Jira)
[ https://issues.jboss.org/browse/WFLY-11646?page=com.atlassian.jira.plugin... ]
Zabee Ulla updated WFLY-11646:
------------------------------
Summary: Upgrade a third party library (was: Upgrade third party libraries)
> Upgrade a third party library
> -----------------------------
>
> Key: WFLY-11646
> URL: https://issues.jboss.org/browse/WFLY-11646
> Project: WildFly
> Issue Type: Component Upgrade
> Components: JPA / Hibernate
> Reporter: Zabee Ulla
> Assignee: Scott Marlow
> Priority: Minor
>
> As per the bug that was reported here - https://hibernate.atlassian.net/browse/HHH-10028, Hibernate stays in-step with Wildfly and EAP dependency versions to ensure compatibility.
> This task is a request to upgrade antlr to its latest version available against WildFly so that Hibernate also can pick the latest to be in synch with WildFly.
> Hibernate (hibernate-core to be more specific) latest version is still using antlr version 2.7.7 released on Jan 13, 2007. The latest available, built and maintained version is antlr-4-Runtime 4.7.2. Another reason for going with latest of antlr is to avoid any security vulnerabilities that the library is exposed to.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11645) A way to prevent automatic changes of affinity when invoking clustered beans
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-11645?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz commented on WFLY-11645:
--------------------------------------------
What is a clustered bean? On the one hand, this is a bean deployed on a node in a cluster. In the case of SFSBs, if this bean has passivationEnabled=true, arrangements are made for making that beans state available across the cluster to support fail-over (selecting a different target for the invocation when a previous one failed). So, SFSBs are special in this respect. On the other hand, from the point of view of the EJB client, a clustered bean is a proxy which has affinity to a cluster. This can apply to proxies for SFSB as well as SLSBs. To tie the proxy to the cluster, you need only (in theory) assign the strong affinity or the weak affinity of the proxy as type ClusterAffinity, but in practice, we usually tie the proxy to a cluster using the strong affinity. What this does is place a restriction on the targets chosen for the invocation; in this case, the target must point to some node within the cluster named in the affinity.
For a clustered SFSB proxy, where the strong affinity is used to specify affinity to the cluster, if you wanted to send a invocations to a particular node in the cluster, you can do it by setting the weak affinity of the proxy to a NodeAffinity for the node within the cluster. For a clustered SLSB proxy, you should be able to do the same. Whether or not you still can is another matter; i'm looking at writing a test to verify that these "egde case" affinity combinations work properly.
It is true that on invocations for SFSB and SLSBs, strong affinity was being forced to the "cluster affinity", which would result in the behavior that you observed, but this was incorrect and a fix is in place to change it (https://issues.jboss.org/browse/WFLY-11489)
> A way to prevent automatic changes of affinity when invoking clustered beans
> ----------------------------------------------------------------------------
>
> Key: WFLY-11645
> URL: https://issues.jboss.org/browse/WFLY-11645
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering, EJB
> Reporter: Jan Martiska
> Priority: Major
>
> When invoking a clustered bean, a user might want to set an affinity so that the invocations go to a particular node. This is done via EJB client APIs:
> {noformat}
> EJBClient.setStrongAffinity(beanProxy, new NodeAffinity("node1"));
> {noformat}
> however, if the bean is clustered, after each invocation, the affinity is automatically reset to a ClusterAffinity. So the user would have to apply this again before each invocation. There should be a way to tell EJB client to not do this.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (WFLY-11646) Upgrade third party libraries
by Zabee Ulla (Jira)
Zabee Ulla created WFLY-11646:
---------------------------------
Summary: Upgrade third party libraries
Key: WFLY-11646
URL: https://issues.jboss.org/browse/WFLY-11646
Project: WildFly
Issue Type: Component Upgrade
Components: JPA / Hibernate
Reporter: Zabee Ulla
Assignee: Scott Marlow
As per the bug that was reported here - https://hibernate.atlassian.net/browse/HHH-10028
Hibernate stays in-step with Wildfly and EAP dependency versions to ensure compatibility.
This task is a request to upgrade antlr to its latest version available against WildFly so that Hibernate also can pick the latest to be in synch with WildFly.
Hibernate (hibernate-core to be more specific) latest version is still using antlr version 2.7.7 released on Jan 13, 2007. The latest available, built and maintained version is antlr-4-Runtime 4.7.2. Another reason for going with latest of antlr is to avoid any security vulnerabilities that the library is exposed to.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months
[JBoss JIRA] (DROOLS-3492) Create UX proposal to show/edit Test Scenario (Preview) global setting
by Daniele Zonca (Jira)
[ https://issues.jboss.org/browse/DROOLS-3492?page=com.atlassian.jira.plugi... ]
Daniele Zonca commented on DROOLS-3492:
---------------------------------------
[~zhutaojiajia]
Fine for me :)
> Create UX proposal to show/edit Test Scenario (Preview) global setting
> ----------------------------------------------------------------------
>
> Key: DROOLS-3492
> URL: https://issues.jboss.org/browse/DROOLS-3492
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Daniele Zonca
> Assignee: tao zhu
> Priority: Major
> Labels: ScenarioSimulation, UXD, UXTeam
> Attachments: 11unnamed.png, TestScenario_Cheatsheet.png, TestScenario_TestEditor.png, TestScenario_TestReport.png, TestScenario_whole.png, test-report-icon.png, 屏幕快照 2019-01-22 下午4.44.04.png, 屏幕快照 2019-01-23 下午4.08.30.png, 屏幕快照 2019-01-23 下午4.08.30.png
>
>
> As user I want to be able to see/edit editor global settings.
> For instance DMN file linked to the scenario or the Session name of a Rule scenario
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 5 months