October 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-3054) Highlight in expression builder previous selection in Scenario right panel

by Sarah Rambacher (Jira)

[ https://issues.jboss.org/browse/DROOLS-3054?page=com.atlassian.jira.plugi... ] Sarah Rambacher commented on DROOLS-3054: ----------------------------------------- [~danielezonca] [~gabriolo] [~uxdlc] I have put some new HTML/CSS in a new PR that adjusts the view of the tree and adds a "selected" state to a list item. https://github.com/srambach/BxMS-frontend/pull/78 Rawgit (column is made wider just for easier debugging) https://rawgit.com/srambach/BxMS-frontend/8a589eba908d3d75bef21727ad3a27d... In looking at the running version, I believe that there is also a missing tag on an embedded list within one of the list items. This would be analogous to line 349 in my file drools-test-editor.html - the <div> for the embedded list. {{<div id="pf-list-simple-expansion-2" class="list-group list-view-pf tree-list-view-pf-view kie-tree-list-view-pf-view--compact">}} Hopefully this helps. I'll continue to look at the other issues you mention in DROOLS-3154. > Highlight in expression builder previous selection in Scenario right panel > -------------------------------------------------------------------------- > > Key: DROOLS-3054 > URL: https://issues.jboss.org/browse/DROOLS-3054 > Project: Drools > Issue Type: Task > Components: Scenario Simulation and Testing > Reporter: Daniele Zonca > Assignee: Gabriele Cardosi > Priority: Minor > Labels: UX, UX-CSS, UXTeam > Attachments: Screen Shot 2018-09-28 at 3.45.25 PM.png, Screen Shot 2018-10-15 at 1.38.30 PM.png, Screenshot from 2018-10-12 15-53-50.png, tree-issues.png > > > When the user edits the type of a column, the expression builder into the right panel should highlight the existing mapped type. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11213) On release of batch it still contained JDBC statements logged

by Cody Lerum (Jira)

Cody Lerum created WFLY-11213: --------------------------------- Summary: On release of batch it still contained JDBC statements logged Key: WFLY-11213 URL: https://issues.jboss.org/browse/WFLY-11213 Project: WildFly Issue Type: Bug Components: JPA / Hibernate Affects Versions: 14.0.1.Final Environment: Java 8_181 Wildfly 14.0.1.Final Reporter: Cody Lerum Assignee: Scott Marlow After updating from Wildfly 11 (Hibernate 5.1.10) to Wildfly 14.0.1 (Hibernate 5.3.6) I've started seeing the following log messages I’m starting to see the log message {code:java} 2018-10-17 20:12:47,571 INFO [org.hibernate.engine.jdbc.batch.internal.AbstractBatchImpl] (default task-54) HHH000010: On release of batch it still contained JDBC statements 2018-10-17 20:12:47,572 ERROR [org.hibernate.engine.jdbc.batch.internal.AbstractBatchImpl] (default task-54) HHH000352: Unable to release batch statement... {code} I’ve debugged where that is getting logged and all I can find is a single statement at the time. insert into EventLog (entityId, entityType, ipAddress, message, time, user, id) values (?, ?, ?, ?, ?, ?, ?) The only insert that is being created is actually being persisted to the database so this may be a spurious message. >From my early debugging this appears to happen when 1 entity is persisted which does not need an immediate inset (due to having a generated pk) and then in another method of the same transaction an entity is persisted that does need an immediate insert because of a auto increment pk. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4150) Support automatically adding / updating credentials in the CredentialStore

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-4150?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-4150: -------------------------------- Fix Version/s: 7.0.0.Alpha5 (was: 7.0.0.Beta1) > Support automatically adding / updating credentials in the CredentialStore > -------------------------------------------------------------------------- > > Key: WFCORE-4150 > URL: https://issues.jboss.org/browse/WFCORE-4150 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 7.0.0.Alpha5 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4144) Add support for registering a single JVM / Server wide default SSLContext

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-4144?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-4144: -------------------------------- Fix Version/s: 7.0.0.Alpha5 (was: 7.0.0.Beta1) > Add support for registering a single JVM / Server wide default SSLContext > ------------------------------------------------------------------------- > > Key: WFCORE-4144 > URL: https://issues.jboss.org/browse/WFCORE-4144 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 7.0.0.Alpha5 > > > By registering a global SSLContext libraries used within the application server can make use of a managed SSLContext instead of relying on one automatically being created through the standard system properties. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4144) Add support for registering a single JVM / Server wide default SSLContext

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-4144?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-4144: -------------------------------- Fix Version/s: 7.0.0.Beta1 (was: 7.0.0.Alpha4) > Add support for registering a single JVM / Server wide default SSLContext > ------------------------------------------------------------------------- > > Key: WFCORE-4144 > URL: https://issues.jboss.org/browse/WFCORE-4144 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 7.0.0.Beta1 > > > By registering a global SSLContext libraries used within the application server can make use of a managed SSLContext instead of relying on one automatically being created through the standard system properties. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4150) Support automatically adding / updating credentials in the CredentialStore

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-4150?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-4150: -------------------------------- Fix Version/s: 7.0.0.Beta1 (was: 7.0.0.Alpha4) > Support automatically adding / updating credentials in the CredentialStore > -------------------------------------------------------------------------- > > Key: WFCORE-4150 > URL: https://issues.jboss.org/browse/WFCORE-4150 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 7.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3095) Grid with multiple data/domain object instances

by Gabriele Cardosi (Jira)

[ https://issues.jboss.org/browse/DROOLS-3095?page=com.atlassian.jira.plugi... ] Gabriele Cardosi edited comment on DROOLS-3095 at 10/18/18 10:13 AM: --------------------------------------------------------------------- Modification after https://github.com/kiegroup/drools-wb/pull/963#pullrequestreview-165590336 1 User may map a property *even before* its instance; in that case, the instance header is automatically set to the property' containing data object. 2 Right/left clicking on a "property" header should insert a column with the "same" instance header, immediately at its right/left (verify that all the properties of the same instance are always grouped together) 3 Right/left clicking on a "instance" header should insert a column to the right/left of the "instance" group (verify that all the properties of the same instance are always grouped together) was (Author: gabriolo): Modification after https://github.com/kiegroup/drools-wb/pull/963#pullrequestreview-165590336 1 User may map a property *even before* its instance; in that case, the instance header is automatically set to the property' containing data object. > Grid with multiple data/domain object instances > ----------------------------------------------- > > Key: DROOLS-3095 > URL: https://issues.jboss.org/browse/DROOLS-3095 > Project: Drools > Issue Type: Task > Components: Scenario Simulation and Testing > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > > As user I want to use multiple instances of my DO in a test scenario. > *Implementation specs:* > Implement "Instance" concept on the GIVEN/EXPECTED columns. > Given/Expected columns should have three headers: > # the top one is the group (GIVEN/EXPECTED), > # the second one is the actual instance of a given type (ex Person1, Person2, Dispute) > # the third one is the specific property of the instance. > Below every instance header there could be one ore more property header - each of them belonging to that instance. > The workflow to define template creation is going to change because of the new header level: now user must define the type/name of the instance *before* mapping the final properties. > When clicking on a GIVEN "Instance" header, user should see only first-level data objects in the right panel. > When clicking on a Property header, user should see only first-level properties of the Instance it belongs to. > When clicking on an EXPECT "Instance" header, user should see only first-level data objects in the right panel *AND* the GIVEN instances. > Changing Instance type is not allowed (dose not makes sense): only "DELETE" is possible at "Instance" level. Deleting an Instance header(column) recursively delete all the properties. > These issue is related to https://issues.jboss.org/browse/DROOLS-2788 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3095) Grid with multiple data/domain object instances

by Gabriele Cardosi (Jira)

[ https://issues.jboss.org/browse/DROOLS-3095?page=com.atlassian.jira.plugi... ] Gabriele Cardosi commented on DROOLS-3095: ------------------------------------------ Modification after https://github.com/kiegroup/drools-wb/pull/963#pullrequestreview-165590336 1 User may map a property *even before* its instance; in that case, the instance header is automatically set to the property' containing data object. > Grid with multiple data/domain object instances > ----------------------------------------------- > > Key: DROOLS-3095 > URL: https://issues.jboss.org/browse/DROOLS-3095 > Project: Drools > Issue Type: Task > Components: Scenario Simulation and Testing > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > > As user I want to use multiple instances of my DO in a test scenario. > *Implementation specs:* > Implement "Instance" concept on the GIVEN/EXPECTED columns. > Given/Expected columns should have three headers: > # the top one is the group (GIVEN/EXPECTED), > # the second one is the actual instance of a given type (ex Person1, Person2, Dispute) > # the third one is the specific property of the instance. > Below every instance header there could be one ore more property header - each of them belonging to that instance. > The workflow to define template creation is going to change because of the new header level: now user must define the type/name of the instance *before* mapping the final properties. > When clicking on a GIVEN "Instance" header, user should see only first-level data objects in the right panel. > When clicking on a Property header, user should see only first-level properties of the Instance it belongs to. > When clicking on an EXPECT "Instance" header, user should see only first-level data objects in the right panel *AND* the GIVEN instances. > Changing Instance type is not allowed (dose not makes sense): only "DELETE" is possible at "Instance" level. Deleting an Instance header(column) recursively delete all the properties. > These issue is related to https://issues.jboss.org/browse/DROOLS-2788 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3095) Grid with multiple data/domain object instances

by Gabriele Cardosi (Jira)

[ https://issues.jboss.org/browse/DROOLS-3095?page=com.atlassian.jira.plugi... ] Gabriele Cardosi updated DROOLS-3095: ------------------------------------- Description: As user I want to use multiple instances of my DO in a test scenario. *Implementation specs:* Implement "Instance" concept on the GIVEN/EXPECTED columns. Given/Expected columns should have three headers: # the top one is the group (GIVEN/EXPECTED), # the second one is the actual instance of a given type (ex Person1, Person2, Dispute) # the third one is the specific property of the instance. Below every instance header there could be one ore more property header - each of them belonging to that instance. The workflow to define template creation is going to change because of the new header level: now user must define the type/name of the instance *before* mapping the final properties. When clicking on a GIVEN "Instance" header, user should see only first-level data objects in the right panel. When clicking on a Property header, user should see only first-level properties of the Instance it belongs to. When clicking on an EXPECT "Instance" header, user should see only first-level data objects in the right panel *AND* the GIVEN instances. Changing Instance type is not allowed (dose not makes sense): only "DELETE" is possible at "Instance" level. Deleting an Instance header(column) recursively delete all the properties. These issue is related to https://issues.jboss.org/browse/DROOLS-2788 was: As user I want to use multiple instances of my DO in a test scenario. *Implementation specs:* Implement "Instance" concept on the GIVEN/EXPECTED columns. Given/Expected columns should have three headers: # the top one is the group (GIVEN/EXPECTED), # the second one is the actual instance of a given type (ex Person1, Person2, Dispute) # the third one is the specific property of the instance. Below every instance header there could be one ore more property header - each of them belonging to that instance. The workflow to define template creation is going to change because of the new header level: now user must define the type/name of the instance *before* mapping the final properties. When clicking on a GIVEN "Instance" header, user should see only first-level data objects in the right panel. When clicking on a Property header, user should see only first-level properties of the Instance it belongs to. When When clicking on an EXPECT "Instance" header, user should see only first-level data objects in the right panel *AND* the GIVEN instances. Changing Instance type is not allowed (dose not makes sense): only "DELETE" is possible at "Instance" level. Deleting an Instance header(column) recursively delete all the properties. These issue is related to https://issues.jboss.org/browse/DROOLS-2788 > Grid with multiple data/domain object instances > ----------------------------------------------- > > Key: DROOLS-3095 > URL: https://issues.jboss.org/browse/DROOLS-3095 > Project: Drools > Issue Type: Task > Components: Scenario Simulation and Testing > Reporter: Gabriele Cardosi > Assignee: Gabriele Cardosi > Priority: Major > > As user I want to use multiple instances of my DO in a test scenario. > *Implementation specs:* > Implement "Instance" concept on the GIVEN/EXPECTED columns. > Given/Expected columns should have three headers: > # the top one is the group (GIVEN/EXPECTED), > # the second one is the actual instance of a given type (ex Person1, Person2, Dispute) > # the third one is the specific property of the instance. > Below every instance header there could be one ore more property header - each of them belonging to that instance. > The workflow to define template creation is going to change because of the new header level: now user must define the type/name of the instance *before* mapping the final properties. > When clicking on a GIVEN "Instance" header, user should see only first-level data objects in the right panel. > When clicking on a Property header, user should see only first-level properties of the Instance it belongs to. > When clicking on an EXPECT "Instance" header, user should see only first-level data objects in the right panel *AND* the GIVEN instances. > Changing Instance type is not allowed (dose not makes sense): only "DELETE" is possible at "Instance" level. Deleting an Instance header(column) recursively delete all the properties. > These issue is related to https://issues.jboss.org/browse/DROOLS-2788 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11198) Session draining on stopped worker won't complete if further requests are made on balancer

by Jan Kašík (Jira)

[ https://issues.jboss.org/browse/WFLY-11198?page=com.atlassian.jira.plugin... ] Jan Kašík commented on WFLY-11198: ---------------------------------- In my scenario, there are 3 workers (cluster nodes). Before sending those 10 requests I am also sending session request and verifying that session on stopped worker is still active. > Session draining on stopped worker won't complete if further requests are made on balancer > ------------------------------------------------------------------------------------------ > > Key: WFLY-11198 > URL: https://issues.jboss.org/browse/WFLY-11198 > Project: WildFly > Issue Type: Bug > Components: mod_cluster > Affects Versions: 15.0.0.Alpha1 > Reporter: Jan Kašík > Assignee: Radoslav Husar > Priority: Major > > When disabling worker with {{/subsystem=modcluster/proxy=default:stop(waittime=0)}}, the contexts are switched to {{disabled}} state. If there no further requests (on the same context which session currently times out) are made on a balancer, session correctly times out, contexts switch to {{stopped}} state and everything is OK. > However, when I run same stop operation, wait until contexts are switched into {{disabled}} state and in time in which sessions time out I make more requests on balancer, contexts will never switch to {{stopped}} state and session draining never completes. This happens intermittently (~60% of cases with 10 requests made after {{disabled}} state is in place). -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2018