[JBoss JIRA] (DROOLS-2644) [DMN Designer] Deletion of the column causes last column width increase
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2644?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2644:
--------------------------------
Description:
There are situations when the undo of column deletion causes unexpected grid total width increase. See the steps to reproduce.
h3. Manual Accpetance Test
# Steps to reproduce fixed (/)
# Steps to reproduce fixed when decision table / relation is not top level context entry (x)
# Repeat steps to reproduce, save and reopen, edit the expression (/)
was:
There are situations when the undo of column deletion causes unexpected grid total width increase. See the steps to reproduce.
h3. Manual Accpetance Test
# Steps to reproduce fixed (/)
# Steps to reproduce fixed when decision table / relation is not top level context entry
# Repeat steps to reproduce, save and reopen, edit the expression (/)
> [DMN Designer] Deletion of the column causes last column width increase
> -----------------------------------------------------------------------
>
> Key: DROOLS-2644
> URL: https://issues.jboss.org/browse/DROOLS-2644
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.8.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Minor
>
> There are situations when the undo of column deletion causes unexpected grid total width increase. See the steps to reproduce.
> h3. Manual Accpetance Test
> # Steps to reproduce fixed (/)
> # Steps to reproduce fixed when decision table / relation is not top level context entry (x)
> # Repeat steps to reproduce, save and reopen, edit the expression (/)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (JGRP-2253) FD_SOCK is not working in AWS environment
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2253?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2253:
--------------------------------
Created JGRP-2280 to fix the client_bind_port issue
> FD_SOCK is not working in AWS environment
> -----------------------------------------
>
> Key: JGRP-2253
> URL: https://issues.jboss.org/browse/JGRP-2253
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.10
> Environment: AWS - EC2
> Reporter: Sibin Karnavar
> Assignee: Bela Ban
> Fix For: 4.0.13
>
>
> We have our failure detection defined like below.
> <FD_SOCK external_port="7804" />
> <FD timeout="3000" max_tries="3" />
> <VERIFY_SUSPECT timeout="3000" />
> Please note that we have used FD instead of FD_ALL in AWS. We will be changing it to FD_ALL later after detailed testing.
> In my local, this is working perfect. As soon as I kill my node, I was able to see that view change was happening immediately with FD_SOCK.
> We were not mentioning the external_port in the FD_SOCK but later I thought it may be an issue with the port and defined it as 7804 and added the same port to the security group that allows to access this port among all the nodes. So no issue with the port.
> Can you please let us know if we need any additional configurations to make FD_SOCK works well in AWS.
> Thanks,
> Sibin
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (JGRP-2280) FD_SOCK: use port_range for client ports, too
by Bela Ban (JIRA)
Bela Ban created JGRP-2280:
------------------------------
Summary: FD_SOCK: use port_range for client ports, too
Key: JGRP-2280
URL: https://issues.jboss.org/browse/JGRP-2280
Project: JGroups
Issue Type: Bug
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 4.0.13
Currently, when defining {{client_bind_port}} in {{FD_SOCK}}, if that port is taken, an exception will be thrown. It would be better to test binding to a range of ports, using {{port_range}} for that.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (JGRP-2253) FD_SOCK is not working in AWS environment
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2253?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2253:
--------------------------------
You're right: if client_bind_port != 0, then I should use the same code to create the Socket as for creation of the ServerSocket. I'll change this.
> FD_SOCK is not working in AWS environment
> -----------------------------------------
>
> Key: JGRP-2253
> URL: https://issues.jboss.org/browse/JGRP-2253
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.0.10
> Environment: AWS - EC2
> Reporter: Sibin Karnavar
> Assignee: Bela Ban
> Fix For: 4.0.13
>
>
> We have our failure detection defined like below.
> <FD_SOCK external_port="7804" />
> <FD timeout="3000" max_tries="3" />
> <VERIFY_SUSPECT timeout="3000" />
> Please note that we have used FD instead of FD_ALL in AWS. We will be changing it to FD_ALL later after detailed testing.
> In my local, this is working perfect. As soon as I kill my node, I was able to see that view change was happening immediately with FD_SOCK.
> We were not mentioning the external_port in the FD_SOCK but later I thought it may be an issue with the port and defined it as 7804 and added the same port to the security group that allows to access this port among all the nodes. So no issue with the port.
> Can you please let us know if we need any additional configurations to make FD_SOCK works well in AWS.
> Thanks,
> Sibin
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (DROOLS-2644) [DMN Designer] Deletion of the column causes last column width increase
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2644?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2644:
--------------------------------
Description:
There are situations when the undo of column deletion causes unexpected grid total width increase. See the steps to reproduce.
h3. Manual Accpetance Test
# Steps to reproduce fixed (/)
# Steps to reproduce fixed when decision table / relation is not top level context entry
# Repeat steps to reproduce, save and reopen, edit the expression (/)
was:
There are situations when the undo of column deletion causes unexpected grid total width increase. See the steps to reproduce.
h3. Manual Accpetance Test
# Steps to reproduce fixed (/)
# Steps to reproduce fixed when decision table / relation is not top level context entry
# Repeat steps to reproduce, save and reopen, edit the expression (x)
> [DMN Designer] Deletion of the column causes last column width increase
> -----------------------------------------------------------------------
>
> Key: DROOLS-2644
> URL: https://issues.jboss.org/browse/DROOLS-2644
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.8.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Minor
>
> There are situations when the undo of column deletion causes unexpected grid total width increase. See the steps to reproduce.
> h3. Manual Accpetance Test
> # Steps to reproduce fixed (/)
> # Steps to reproduce fixed when decision table / relation is not top level context entry
> # Repeat steps to reproduce, save and reopen, edit the expression (/)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (DROOLS-2644) [DMN Designer] Deletion of the column causes last column width increase
by Jozef Marko (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2644?page=com.atlassian.jira.plugi... ]
Jozef Marko updated DROOLS-2644:
--------------------------------
Description:
There are situations when the undo of column deletion causes unexpected grid total width increase. See the steps to reproduce.
h3. Manual Accpetance Test
# Steps to reproduce fixed (/)
# Steps to reproduce fixed when decision table / relation is not top level context entry
# Repeat steps to reproduce, save and reopen, edit the expression (x)
was:
There are situations when the undo of column deletion causes unexpected grid total width increase. See the steps to reproduce.
h3. Manual Accpetance Test
# Steps to reproduce fixed
# Steps to reproduce fixed when decision table / relation is not top level context entry
# Repeat steps to reproduce, save and reopen, edit the expression (x)
> [DMN Designer] Deletion of the column causes last column width increase
> -----------------------------------------------------------------------
>
> Key: DROOLS-2644
> URL: https://issues.jboss.org/browse/DROOLS-2644
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.8.0.Final
> Reporter: Jozef Marko
> Assignee: Michael Anstis
> Priority: Minor
>
> There are situations when the undo of column deletion causes unexpected grid total width increase. See the steps to reproduce.
> h3. Manual Accpetance Test
> # Steps to reproduce fixed (/)
> # Steps to reproduce fixed when decision table / relation is not top level context entry
> # Repeat steps to reproduce, save and reopen, edit the expression (x)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10520) Add Hibernate ORM 5.3 compatibility transformer
by Gail Badner (JIRA)
[ https://issues.jboss.org/browse/WFLY-10520?page=com.atlassian.jira.plugin... ]
Gail Badner commented on WFLY-10520:
------------------------------------
[~smarlow], I've pushed my fix for HHH-12729 to https://github.com/gbadner/hibernate-core/tree/HHH-12729 .
I still need to add more information to the description for HHH-12729 and add a commit updating the migration guide before creating a PR.
I've also created a PR for your WFLY-10520_hibernatecompatabilitytransformer branch:
https://github.com/scottmarlow/wildfly/pull/18
If you build my PR using my HHH-12729 branch, you will see that all tests pass except 1, testORA5_3_1_Compatibility_getFirstResultNegative(). That test fails because setHibernateFirstResult( -1) will actually set the value to 0. In 5.1, a negative value was actually set; we can't do that in 5.3 though. IMO, this could be documented in the migration guide. In this case, Hibernate will start results from position 0, just as was done in 5.1.
> Add Hibernate ORM 5.3 compatibility transformer
> -----------------------------------------------
>
> Key: WFLY-10520
> URL: https://issues.jboss.org/browse/WFLY-10520
> Project: WildFly
> Issue Type: Task
> Components: JPA / Hibernate
> Reporter: Gail Badner
> Assignee: Scott Marlow
> Fix For: 14.0.0.CR1
>
>
> A compatibility transformer needs to be added to address Hibernate ORM 5.3 API methods that are no longer compatible with 5.1.
> From https://docs.google.com/document/d/1cAVBdeQXQfpTwH0f_GKSahh_gRd7bKI6kII-w...
> # Change call to org.hibernate.BasicQueryContract.getFlushMode() to instead call BasicQueryContract.getHibernateFlushMode().
> # Change call to org.hibernate.Session.getFlushMode, to instead call Session.getHibernateFlushMode()
> # Modify calls to org.hibernate.Query.getFirstResult() to convert returned int, to Integer result.
> # Modify calls to org.hibernate.Query.getMaxResults() to convert returned int, to Integer result, if returned int value is <= 0, null should be used, if Integer.MAX_VALUE is, the transformer should replace with null reference.
> # App References to Enum org.hibernate.FlushMode.NEVER (0) should be transformed to reference FlushMode.MANUAL (0) instead.
> # For call to org.hibernate.Query.setMaxResults(int), instead call org.hibernate.Query.setHibernateMaxResults(int) which will be added soon to ORM 5.3.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10520) Add Hibernate ORM 5.3 compatibility transformer
by Gail Badner (JIRA)
[ https://issues.jboss.org/browse/WFLY-10520?page=com.atlassian.jira.plugin... ]
Gail Badner commented on WFLY-10520:
------------------------------------
I've created the following to deal with {{org.hibernate.Query#getFirstResult}}, {{#setFirstResult}}, {{#getMaxResults}}, and {{#setMaxResults} incompatibilities:
https://hibernate.atlassian.net/browse/HHH-12729
> Add Hibernate ORM 5.3 compatibility transformer
> -----------------------------------------------
>
> Key: WFLY-10520
> URL: https://issues.jboss.org/browse/WFLY-10520
> Project: WildFly
> Issue Type: Task
> Components: JPA / Hibernate
> Reporter: Gail Badner
> Assignee: Scott Marlow
> Fix For: 14.0.0.CR1
>
>
> A compatibility transformer needs to be added to address Hibernate ORM 5.3 API methods that are no longer compatible with 5.1.
> From https://docs.google.com/document/d/1cAVBdeQXQfpTwH0f_GKSahh_gRd7bKI6kII-w...
> # Change call to org.hibernate.BasicQueryContract.getFlushMode() to instead call BasicQueryContract.getHibernateFlushMode().
> # Change call to org.hibernate.Session.getFlushMode, to instead call Session.getHibernateFlushMode()
> # Modify calls to org.hibernate.Query.getFirstResult() to convert returned int, to Integer result.
> # Modify calls to org.hibernate.Query.getMaxResults() to convert returned int, to Integer result, if returned int value is <= 0, null should be used, if Integer.MAX_VALUE is, the transformer should replace with null reference.
> # App References to Enum org.hibernate.FlushMode.NEVER (0) should be transformed to reference FlushMode.MANUAL (0) instead.
> # For call to org.hibernate.Query.setMaxResults(int), instead call org.hibernate.Query.setHibernateMaxResults(int) which will be added soon to ORM 5.3.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10520) Add Hibernate ORM 5.3 compatibility transformer
by Gail Badner (JIRA)
[ https://issues.jboss.org/browse/WFLY-10520?page=com.atlassian.jira.plugin... ]
Gail Badner commented on WFLY-10520:
------------------------------------
[~smarlow], I agree that too much logging is not helpful. I am concerned though that 5.1 applications will magically work until the compatibility transformer is removed. In some cases, there will be compiler errors. In other cases, such as usage of {{org.hibernate.Query#getFirstResult}}, {{#setFirstResult}}, {{#getMaxResults}}, and {{#setMaxResults}}, the code will compile successfully, but they may see some unexpected behavior.
> Add Hibernate ORM 5.3 compatibility transformer
> -----------------------------------------------
>
> Key: WFLY-10520
> URL: https://issues.jboss.org/browse/WFLY-10520
> Project: WildFly
> Issue Type: Task
> Components: JPA / Hibernate
> Reporter: Gail Badner
> Assignee: Scott Marlow
> Fix For: 14.0.0.CR1
>
>
> A compatibility transformer needs to be added to address Hibernate ORM 5.3 API methods that are no longer compatible with 5.1.
> From https://docs.google.com/document/d/1cAVBdeQXQfpTwH0f_GKSahh_gRd7bKI6kII-w...
> # Change call to org.hibernate.BasicQueryContract.getFlushMode() to instead call BasicQueryContract.getHibernateFlushMode().
> # Change call to org.hibernate.Session.getFlushMode, to instead call Session.getHibernateFlushMode()
> # Modify calls to org.hibernate.Query.getFirstResult() to convert returned int, to Integer result.
> # Modify calls to org.hibernate.Query.getMaxResults() to convert returned int, to Integer result, if returned int value is <= 0, null should be used, if Integer.MAX_VALUE is, the transformer should replace with null reference.
> # App References to Enum org.hibernate.FlushMode.NEVER (0) should be transformed to reference FlushMode.MANUAL (0) instead.
> # For call to org.hibernate.Query.setMaxResults(int), instead call org.hibernate.Query.setHibernateMaxResults(int) which will be added soon to ORM 5.3.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10637) NPE when reading oracle jdbc 12.2.0.1 datasource with include-runtime
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFLY-10637?page=com.atlassian.jira.plugin... ]
Lin Gao commented on WFLY-10637:
--------------------------------
I created WFLY-10640 for the datasource-class-name and xa-datasource-class-name validation issue.
> NPE when reading oracle jdbc 12.2.0.1 datasource with include-runtime
> ---------------------------------------------------------------------
>
> Key: WFLY-10637
> URL: https://issues.jboss.org/browse/WFLY-10637
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Reporter: Claudio Miranda
> Assignee: Lin Gao
>
> Download oracle jdbc driver at http://www.oracle.com/technetwork/database/features/jdbc/jdbc-ucp-122-311...
> Install the driver as a module
> {code}
> $ cat modules/system/layers/base/com/oracle/jdbc/main/module.xml
> <?xml version="1.0" encoding="UTF-8"?>
> <module name="com.oracle.jdbc" xmlns="urn:jboss:module:1.5">
> <resources>
> <resource-root path="ojdbc8.jar"/>
> </resources>
> <dependencies>
> <module name="javax.api"/>
> <module name="javax.transaction.api"/>
> </dependencies>
> </module>
> {code}
> Add the jdbc-driver resource
> {code}
> /profile=full-ha/subsystem=datasources/jdbc-driver=oracle_8_xa:add(driver-module-name=com.oracle.jdbc,driver-name=oracle_8_xa,driver-datasource-class-name=oracle.jdbc.datasource.OracleDataSource,driver-xa-datasource-class-name=oracle.jdbc.xa.client.OracleXADataSource,driver-class-name=oracle.jdbc.OracleDriver)
> {code}
> Wildfly log shows it is ok
> {code}
> [Server:server-three] 13:44:28,939 INFO [org.jboss.as.connector.subsystems.datasources] (ServerService Thread Pool -- 73) WFLYJCA0004: Deploying JDBC-compliant driver class oracle.jdbc.OracleDriver (version 12.2)
> [Server:server-three] 13:44:28,939 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-6) WFLYJCA0018: Started Driver service with driver-name = oracle_8_xa
> {code}
> Read the jdbc-driver on a runtime server
> {code}
> /host=master/server=server-three/subsystem=datasources/jdbc-driver=oracle_8_xa:read-resource(include-runtime)
> {
> "outcome" => "success",
> "result" => undefined,
> "failure-description" => undefined
> {code}
> Wildfly log shows the error
> {code}
> 2018-06-25 13:45:00,165 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 73) WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> ("subsystem" => "datasources"),
> ("jdbc-driver" => "oracle_8_xa")
> ]): java.lang.NullPointerException
> at org.jboss.as.connector.subsystems.datasources.GetDataSourceClassInfoOperationHandler.possiblePropsSetters(GetDataSourceClassInfoOperationHandler.java:182)
> at org.jboss.as.connector.subsystems.datasources.GetDataSourceClassInfoOperationHandler.findPropsFromCls(GetDataSourceClassInfoOperationHandler.java:124)
> at org.jboss.as.connector.subsystems.datasources.GetDataSourceClassInfoOperationHandler.dsClsInfoNode(GetDataSourceClassInfoOperationHandler.java:96)
> at org.jboss.as.connector.subsystems.datasources.GetDataSourceClassInfoOperationHandler$1.execute(GetDataSourceClassInfoOperationHandler.java:82)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:999)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:743)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:467)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1411)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:423)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:249)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:190)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:143)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:139)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:198)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:162)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:158)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:158)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> {code}
> It works if omit include-runtime, but there is no runtime information
> The following drivers works with include-runtime
> - postgresql-42.2.2.jre6.jar
> - ojdbc7.jar
> - mssql-jdbc-6.5.3.jre8-preview.jar
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years