[JBoss JIRA] (DROOLS-3760) [DMN Designer] Enumeration constraint dialog doesn't scroll to latest entry
by Jozef Marko (Jira)
[ https://issues.jboss.org/browse/DROOLS-3760?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-3760:
--------------------------------
Tester: Jozef Marko (was: Yevgeniy Fomin)
> [DMN Designer] Enumeration constraint dialog doesn't scroll to latest entry
> ---------------------------------------------------------------------------
>
> Key: DROOLS-3760
> URL: https://issues.jboss.org/browse/DROOLS-3760
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.19.0.Final
> Reporter: Jozef Marko
> Assignee: Guilherme Carreiro
> Priority: Minor
> Labels: drools-tools
> Attachments: Screenshot from 2019-03-12 09-53-39.png
>
>
> This issue was spotted during review of the DROOLS-3666 task, however not sure if it is related to changes introduced there.
> If user adds enumeration constraints and they do not fit the dialog size, there appears vertical scrollbar. However the scrollbar moves to the beginning of the list every time the add button is pressed. This forces user to scroll to the latest added entry every time the add button is pressed.
> We have already this functionality of scrolling to latest in the data types list view component - list of all declared data types.
> h3. Current state
> The attached picture show the state of dialog when new constraint was just added and the entries count doesn't fit the dialog size.
> h3. Expected state
> The scrollbar in the attached dialog is scrolled down.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (JGRP-2334) TCPPing: resolving hosts with InetAddress.getAllByName() to get all addresses
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2334?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-2334.
----------------------------
Resolution: Done
> TCPPing: resolving hosts with InetAddress.getAllByName() to get all addresses
> -----------------------------------------------------------------------------
>
> Key: JGRP-2334
> URL: https://issues.jboss.org/browse/JGRP-2334
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 4.0.19
> Reporter: Falco Thiel
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.1
>
>
> We want to discuss a change in the TCPPing module.
> We plan to run wildfly instances in a container orchestration system. In the system which we want to use, the node discovery over multicast is not working.
> The other solution is to use TCPPing with initial_hosts set. But now we have to solve the following problems:
> * the initial_hosts property is not very dynamic
> * the ip addresses will/can change if a container is restarted
> * the host names are dynamically generated
> At this point it seems the node discovery can not be done with TCPPing, at least not in an easy way.
> The main problem: How to find out all running nodes for a server group?
> Now we investigate our orchestration system and find a solution to solve the problem. Our orchestration system (and we think others will have this too) has an internal DNS service.
> Over this service all containers for a dns name can be resolved with a nslookup request.
> Example:
> We have a scalable wildfly service. We name it "wildfly-server". If a container under this service is started then the container gets a host name like "wildfly-server-0" and a dynamic ip address.
> After starting one or more container we can do a nslookup with the service name:
> >nslookup wildfly-server
> Name: wildfly-server
> Address 1: 10.42.2.139 wildfly-server-1.wildfly-server
> Address 2: 10.42.1.198 wildfly-server-0.wildfly-server
> Address 3: 10.42.0.161 wildfly-server-2.wildfly-server
> The service name has multiple A-Records registered. If an instance is started or stopped then the DNS Records are updated. Now we tried to use this service name for the initial_hosts property.
> initial_hosts=wildfly-server[7600]
> Sometimes it worked and sometimes it doesn't. The reason was that only the first InetAddress entry was used in the org.jgroups.util.Util class (method parseCommaDelimitedHosts). After we changed it a bit (see [https://github.com/Sternwald-Systems/JGroups/commit/db0b899f9c67348a0cb07...] ) it worked as expected. What we do is to call InetAddress.getAllByName(host) and loop over the result array, instead of just using the first array element.
> There is only one limitation if the domain mode with more than one server group is used. Here the same port offset for all servers of one server group must be set.
> *Conclusion*
> There are different orchestration systems available on the market. The worst case will be to write a custom discovery service for jgroups for each of them.
> For instance for the kubernetes system there already exists such a service (jgroups-kubernetes).
> But if an orchestration system already has an internal DNS service to resolve a dns name to get all running containers TCPPing (with our changes) could be used out of the box.
> Additionally there is a second method in the org.jgroups.util.Util class called parseCommaDelimitedHosts2 which does nearly the same but for the TCPGossip protocol.
> We think it would make sense to change this method too, otherwise there are different behaviors. I you don't mind, we would apply the changes to this method too, before creating a pull request.
> It is also important to document this well so other people can find this information if they have the same problem.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (JGRP-2334) TCPPing: resolving hosts with InetAddress.getAllByName() to get all addresses
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2334?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2334:
--------------------------------
Regardless of whether you use DNS, or not, this proposed change makes sense. I'll apply it.
Thanks,
> TCPPing: resolving hosts with InetAddress.getAllByName() to get all addresses
> -----------------------------------------------------------------------------
>
> Key: JGRP-2334
> URL: https://issues.jboss.org/browse/JGRP-2334
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 4.0.19
> Reporter: Falco Thiel
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.1
>
>
> We want to discuss a change in the TCPPing module.
> We plan to run wildfly instances in a container orchestration system. In the system which we want to use, the node discovery over multicast is not working.
> The other solution is to use TCPPing with initial_hosts set. But now we have to solve the following problems:
> * the initial_hosts property is not very dynamic
> * the ip addresses will/can change if a container is restarted
> * the host names are dynamically generated
> At this point it seems the node discovery can not be done with TCPPing, at least not in an easy way.
> The main problem: How to find out all running nodes for a server group?
> Now we investigate our orchestration system and find a solution to solve the problem. Our orchestration system (and we think others will have this too) has an internal DNS service.
> Over this service all containers for a dns name can be resolved with a nslookup request.
> Example:
> We have a scalable wildfly service. We name it "wildfly-server". If a container under this service is started then the container gets a host name like "wildfly-server-0" and a dynamic ip address.
> After starting one or more container we can do a nslookup with the service name:
> >nslookup wildfly-server
> Name: wildfly-server
> Address 1: 10.42.2.139 wildfly-server-1.wildfly-server
> Address 2: 10.42.1.198 wildfly-server-0.wildfly-server
> Address 3: 10.42.0.161 wildfly-server-2.wildfly-server
> The service name has multiple A-Records registered. If an instance is started or stopped then the DNS Records are updated. Now we tried to use this service name for the initial_hosts property.
> initial_hosts=wildfly-server[7600]
> Sometimes it worked and sometimes it doesn't. The reason was that only the first InetAddress entry was used in the org.jgroups.util.Util class (method parseCommaDelimitedHosts). After we changed it a bit (see [https://github.com/Sternwald-Systems/JGroups/commit/db0b899f9c67348a0cb07...] ) it worked as expected. What we do is to call InetAddress.getAllByName(host) and loop over the result array, instead of just using the first array element.
> There is only one limitation if the domain mode with more than one server group is used. Here the same port offset for all servers of one server group must be set.
> *Conclusion*
> There are different orchestration systems available on the market. The worst case will be to write a custom discovery service for jgroups for each of them.
> For instance for the kubernetes system there already exists such a service (jgroups-kubernetes).
> But if an orchestration system already has an internal DNS service to resolve a dns name to get all running containers TCPPing (with our changes) could be used out of the box.
> Additionally there is a second method in the org.jgroups.util.Util class called parseCommaDelimitedHosts2 which does nearly the same but for the TCPGossip protocol.
> We think it would make sense to change this method too, otherwise there are different behaviors. I you don't mind, we would apply the changes to this method too, before creating a pull request.
> It is also important to document this well so other people can find this information if they have the same problem.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (JGRP-2334) TCPPing: resolving hosts with InetAddress.getAllByName() to get all addresses
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2334?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2334:
---------------------------
Fix Version/s: 4.1.1
> TCPPing: resolving hosts with InetAddress.getAllByName() to get all addresses
> -----------------------------------------------------------------------------
>
> Key: JGRP-2334
> URL: https://issues.jboss.org/browse/JGRP-2334
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 4.0.19
> Reporter: Falco Thiel
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.1
>
>
> We want to discuss a change in the TCPPing module.
> We plan to run wildfly instances in a container orchestration system. In the system which we want to use, the node discovery over multicast is not working.
> The other solution is to use TCPPing with initial_hosts set. But now we have to solve the following problems:
> * the initial_hosts property is not very dynamic
> * the ip addresses will/can change if a container is restarted
> * the host names are dynamically generated
> At this point it seems the node discovery can not be done with TCPPing, at least not in an easy way.
> The main problem: How to find out all running nodes for a server group?
> Now we investigate our orchestration system and find a solution to solve the problem. Our orchestration system (and we think others will have this too) has an internal DNS service.
> Over this service all containers for a dns name can be resolved with a nslookup request.
> Example:
> We have a scalable wildfly service. We name it "wildfly-server". If a container under this service is started then the container gets a host name like "wildfly-server-0" and a dynamic ip address.
> After starting one or more container we can do a nslookup with the service name:
> >nslookup wildfly-server
> Name: wildfly-server
> Address 1: 10.42.2.139 wildfly-server-1.wildfly-server
> Address 2: 10.42.1.198 wildfly-server-0.wildfly-server
> Address 3: 10.42.0.161 wildfly-server-2.wildfly-server
> The service name has multiple A-Records registered. If an instance is started or stopped then the DNS Records are updated. Now we tried to use this service name for the initial_hosts property.
> initial_hosts=wildfly-server[7600]
> Sometimes it worked and sometimes it doesn't. The reason was that only the first InetAddress entry was used in the org.jgroups.util.Util class (method parseCommaDelimitedHosts). After we changed it a bit (see [https://github.com/Sternwald-Systems/JGroups/commit/db0b899f9c67348a0cb07...] ) it worked as expected. What we do is to call InetAddress.getAllByName(host) and loop over the result array, instead of just using the first array element.
> There is only one limitation if the domain mode with more than one server group is used. Here the same port offset for all servers of one server group must be set.
> *Conclusion*
> There are different orchestration systems available on the market. The worst case will be to write a custom discovery service for jgroups for each of them.
> For instance for the kubernetes system there already exists such a service (jgroups-kubernetes).
> But if an orchestration system already has an internal DNS service to resolve a dns name to get all running containers TCPPing (with our changes) could be used out of the box.
> Additionally there is a second method in the org.jgroups.util.Util class called parseCommaDelimitedHosts2 which does nearly the same but for the TCPGossip protocol.
> We think it would make sense to change this method too, otherwise there are different behaviors. I you don't mind, we would apply the changes to this method too, before creating a pull request.
> It is also important to document this well so other people can find this information if they have the same problem.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-9703) Improve archetype "wildfly-javaee7-webapp-ear-blank-archetype" to simplify upgrade to recent WildFly versions
by Wolfgang Knauf (Jira)
[ https://issues.jboss.org/browse/WFLY-9703?page=com.atlassian.jira.plugin.... ]
Wolfgang Knauf commented on WFLY-9703:
--------------------------------------
To sum up a longer thread on the dev mailing list: the archetype is generated based on the kitchensink-ear quickstart.
This fails with the recent quickstart version, because pom.xml of kitchensink-ear references the quickstart root pom, which is not pulled to the archetype. The "readme.md" file also does not work due to some includes.
Also, there was a discussion whether it is helpful to create an archetype which contains all classes of the sample. Better just create a blank archetype.
So I started creating a new archetype "wildfly-javaee-ear-archetype" from scratch, which will be independent of the quickstart. When releasing a new WildFly version, the archetype has to be updated manually.
> Improve archetype "wildfly-javaee7-webapp-ear-blank-archetype" to simplify upgrade to recent WildFly versions
> -------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9703
> URL: https://issues.jboss.org/browse/WFLY-9703
> Project: WildFly
> Issue Type: Bug
> Components: EE
> Affects Versions: 11.0.0.Final
> Reporter: Wolfgang Knauf
> Priority: Minor
>
> When using this archetype, the "pom.xml" of the root project points to JBoss 8.2.1 / WildFly 9.0.0Alpha1
> After changing the versions to WildFly 11, several additional changes are necessary. I suggest to add at least some comments about necessary changes. It would be even better to upgrade the archetype to a more recent WildFly version ;-).
> In "pom.xml" of the root project:
> * Dependeny "jboss-javaee-7.0-with-tools" has to be changed to artifactId = "wildfly-javaee7-with-tools".
> * Dependency "jboss-javaee-7.0-with-hibernate" does not seem to exist any longer
> So, add a comment to those dependencies about error messages when switching to a new WildFly version and about the necessary changes. This comment should contain the new snippet.
> In "pom.xml" of the web project:
> * Dependeny with groupId = "org.jboss.resteasy", artifactId="jaxrs-api" was changed to groupId = "org.jboss.spec.javax.ws.rs", artifactId = "jboss-jaxrs-api_2.0_spec" ([WFLY-4128|https://issues.jboss.org/browse/WFLY-4128])
> In "pom.xml" of the ejb project:
> * Test dependency with groupid = "org.wildfly", artifactId = "wildfly-arquillian-container-managed": the groupId is "org.wildfly.arquillian" (changed beetween 8.1.0 and 11.)
> * Test dependency with groupid = "org.wildfly", artifactId = "wildfly-arquillian-container-remote": the groupId is "org.wildfly.arquillian"
> Additionally, it would be helpful if the web project contains the dependencies with groupId = "org.jboss.spec.javax.ejb" and artifactId = "jboss-ejb-api_3.2_spec" (for use of the "@EJB" annotation in e.g. servlets or JFS components) and groupId = "org.jboss.spec.javax.servlet", artifactId = "jboss-servlet-api_3.1_spec" (for being able to code servlets).
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (JGRP-2334) TCPPing: resolving hosts with InetAddress.getAllByName() to get all addresses
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2334?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2334:
--------------------------------
How about using {{dns.DNS_PING}}?
> TCPPing: resolving hosts with InetAddress.getAllByName() to get all addresses
> -----------------------------------------------------------------------------
>
> Key: JGRP-2334
> URL: https://issues.jboss.org/browse/JGRP-2334
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 4.0.19
> Reporter: Falco Thiel
> Assignee: Bela Ban
> Priority: Major
>
> We want to discuss a change in the TCPPing module.
> We plan to run wildfly instances in a container orchestration system. In the system which we want to use, the node discovery over multicast is not working.
> The other solution is to use TCPPing with initial_hosts set. But now we have to solve the following problems:
> * the initial_hosts property is not very dynamic
> * the ip addresses will/can change if a container is restarted
> * the host names are dynamically generated
> At this point it seems the node discovery can not be done with TCPPing, at least not in an easy way.
> The main problem: How to find out all running nodes for a server group?
> Now we investigate our orchestration system and find a solution to solve the problem. Our orchestration system (and we think others will have this too) has an internal DNS service.
> Over this service all containers for a dns name can be resolved with a nslookup request.
> Example:
> We have a scalable wildfly service. We name it "wildfly-server". If a container under this service is started then the container gets a host name like "wildfly-server-0" and a dynamic ip address.
> After starting one or more container we can do a nslookup with the service name:
> >nslookup wildfly-server
> Name: wildfly-server
> Address 1: 10.42.2.139 wildfly-server-1.wildfly-server
> Address 2: 10.42.1.198 wildfly-server-0.wildfly-server
> Address 3: 10.42.0.161 wildfly-server-2.wildfly-server
> The service name has multiple A-Records registered. If an instance is started or stopped then the DNS Records are updated. Now we tried to use this service name for the initial_hosts property.
> initial_hosts=wildfly-server[7600]
> Sometimes it worked and sometimes it doesn't. The reason was that only the first InetAddress entry was used in the org.jgroups.util.Util class (method parseCommaDelimitedHosts). After we changed it a bit (see [https://github.com/Sternwald-Systems/JGroups/commit/db0b899f9c67348a0cb07...] ) it worked as expected. What we do is to call InetAddress.getAllByName(host) and loop over the result array, instead of just using the first array element.
> There is only one limitation if the domain mode with more than one server group is used. Here the same port offset for all servers of one server group must be set.
> *Conclusion*
> There are different orchestration systems available on the market. The worst case will be to write a custom discovery service for jgroups for each of them.
> For instance for the kubernetes system there already exists such a service (jgroups-kubernetes).
> But if an orchestration system already has an internal DNS service to resolve a dns name to get all running containers TCPPing (with our changes) could be used out of the box.
> Additionally there is a second method in the org.jgroups.util.Util class called parseCommaDelimitedHosts2 which does nearly the same but for the TCPGossip protocol.
> We think it would make sense to change this method too, otherwise there are different behaviors. I you don't mind, we would apply the changes to this method too, before creating a pull request.
> It is also important to document this well so other people can find this information if they have the same problem.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-11793) JPA EntityManager merge infinite loop - java.lang.StackOverflowError
by Bruno Maioli Martins (Jira)
[ https://issues.jboss.org/browse/WFLY-11793?page=com.atlassian.jira.plugin... ]
Bruno Maioli Martins commented on WFLY-11793:
---------------------------------------------
Here is the link to the problem reported in Hibernate ORM Core: [https://hibernate.atlassian.net/projects/HHH/issues/HHH-13296|http://exam...]
> JPA EntityManager merge infinite loop - java.lang.StackOverflowError
> --------------------------------------------------------------------
>
> Key: WFLY-11793
> URL: https://issues.jboss.org/browse/WFLY-11793
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 15.0.1.Final
> Environment: MAC OS Mojave
> Java 11
> Wildfly 15.0.1-Final
> Data Base Postgresql
> Reporter: Bruno Maioli Martins
> Assignee: Scott Marlow
> Priority: Critical
> Attachments: jstack.txt, server+querys.log, server-1.log, teste.zip
>
>
> Dear,
> When executing the update of a record invoking getEntityManager().merge(obj) the application goes into infinite loop. This behavior only occurs when there is a OneToMany bidirectional mapping of the entity Papel -> PermissaoAtribuida.
> If the same code runs outside of the Wildfly server context its execution occurs normally.
> Apparently the call getEntityManager.().merge(obj) attempts infinite selects to sync the object with transaction context before doing the merge.
> Attach the source code of my test classes.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month
[JBoss JIRA] (WFLY-11793) JPA EntityManager merge infinite loop - java.lang.StackOverflowError
by Bruno Maioli Martins (Jira)
[ https://issues.jboss.org/browse/WFLY-11793?page=com.atlassian.jira.plugin... ]
Bruno Maioli Martins edited comment on WFLY-11793 at 3/21/19 7:09 AM:
----------------------------------------------------------------------
Here is the link to the problem reported in Hibernate ORM Core: [https://hibernate.atlassian.net/projects/HHH/issues/HHH-13296]
was (Author: brunomaioli):
Here is the link to the problem reported in Hibernate ORM Core: [https://hibernate.atlassian.net/projects/HHH/issues/HHH-13296|http://exam...]
> JPA EntityManager merge infinite loop - java.lang.StackOverflowError
> --------------------------------------------------------------------
>
> Key: WFLY-11793
> URL: https://issues.jboss.org/browse/WFLY-11793
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 15.0.1.Final
> Environment: MAC OS Mojave
> Java 11
> Wildfly 15.0.1-Final
> Data Base Postgresql
> Reporter: Bruno Maioli Martins
> Assignee: Scott Marlow
> Priority: Critical
> Attachments: jstack.txt, server+querys.log, server-1.log, teste.zip
>
>
> Dear,
> When executing the update of a record invoking getEntityManager().merge(obj) the application goes into infinite loop. This behavior only occurs when there is a OneToMany bidirectional mapping of the entity Papel -> PermissaoAtribuida.
> If the same code runs outside of the Wildfly server context its execution occurs normally.
> Apparently the call getEntityManager.().merge(obj) attempts infinite selects to sync the object with transaction context before doing the merge.
> Attach the source code of my test classes.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 1 month