November 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1949) [DMN Editor]: Context Editor: Row heights should be based on content

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1949?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-1949: -------------------------------- QE Status: ON_QA (was: NEW) > [DMN Editor]: Context Editor: Row heights should be based on content > -------------------------------------------------------------------- > > Key: DROOLS-1949 > URL: https://issues.jboss.org/browse/DROOLS-1949 > Project: Drools > Issue Type: Feature Request > Components: DMN Editor > Reporter: Michael Anstis > Assignee: Michael Anstis > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-2130) [DMN Editor] Boxed Expressions: Relations Expression editor

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2130?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-2130: -------------------------------- QE Status: ON_QA (was: NEW) > [DMN Editor] Boxed Expressions: Relations Expression editor > ----------------------------------------------------------- > > Key: DROOLS-2130 > URL: https://issues.jboss.org/browse/DROOLS-2130 > Project: Drools > Issue Type: Feature Request > Components: DMN Editor > Reporter: Michael Anstis > Assignee: Michael Anstis > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ELY-1444) Jdbc-realm with simple digest mapper

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/ELY-1444?page=com.atlassian.jira.plugin.s... ] Martin Choma updated ELY-1444: ------------------------------ Forum Reference: https://developer.jboss.org/message/978503?et=watches.email.thread#978503 > Jdbc-realm with simple digest mapper > ------------------------------------ > > Key: ELY-1444 > URL: https://issues.jboss.org/browse/ELY-1444 > Project: WildFly Elytron > Issue Type: Bug > Components: Passwords > Affects Versions: 1.2.0.Beta9 > Reporter: Martin Choma > Fix For: 1.2.0.Beta11 > > > This is inspired by ELY-1435, but in this case trying simple digest hash. > In db is stored this sha-256 password hash: 5E884898DA28047151D0E56F8DC6292773603D0D6AABBDD62A11EF721D1542D8 > I get these values by http://passwordsgenerator.net/sha256-hash-generator/ > {noformat} > 17:30:50,211 DEBUG [org.wildfly.security] (default task-3) Using UsernamePasswordAuthenticationMechanism for username authentication. Realm: [Some Realm], Username: [correctUser]. > 17:30:50,211 TRACE [org.wildfly.security] (default task-3) Handling RealmCallback: selected = [Some Realm] > 17:30:50,212 TRACE [org.wildfly.security] (default task-3) Handling NameCallback: authenticationName = correctUser > 17:30:50,212 TRACE [org.wildfly.security] (default task-3) Principal assigning: [correctUser], pre-realm rewritten: [correctUser], realm name: [jdbc-realm], post-realm rewritten: [correctUser], realm rewritten: [correctUser] > 17:30:50,215 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT PASSWORD FROM USERS WHERE NAME = ? with value correctUser > 17:30:50,301 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT roles.name FROM users, roles, users_roles WHERE users.name=? AND users.id = users_roles.userid AND roles.id = users_roles.roleid with value correctUser > 17:30:50,306 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT PASSWORD FROM USERS WHERE NAME = ? with value correctUser > 17:30:50,324 DEBUG [org.wildfly.security] (default task-3) User correctUser authentication failed. > 17:30:50,324 TRACE [org.wildfly.security] (default task-3) Handling AuthenticationCompleteCallback: fail > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ELY-1444) Jdbc-realm with simple digest mapper

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1444?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1444: ---------------------------------- Fix Version/s: 1.2.0.Beta11 > Jdbc-realm with simple digest mapper > ------------------------------------ > > Key: ELY-1444 > URL: https://issues.jboss.org/browse/ELY-1444 > Project: WildFly Elytron > Issue Type: Bug > Components: Passwords > Affects Versions: 1.2.0.Beta9 > Reporter: Martin Choma > Fix For: 1.2.0.Beta11 > > > This is inspired by ELY-1435, but in this case trying simple digest hash. > In db is stored this sha-256 password hash: 5E884898DA28047151D0E56F8DC6292773603D0D6AABBDD62A11EF721D1542D8 > I get these values by http://passwordsgenerator.net/sha256-hash-generator/ > {noformat} > 17:30:50,211 DEBUG [org.wildfly.security] (default task-3) Using UsernamePasswordAuthenticationMechanism for username authentication. Realm: [Some Realm], Username: [correctUser]. > 17:30:50,211 TRACE [org.wildfly.security] (default task-3) Handling RealmCallback: selected = [Some Realm] > 17:30:50,212 TRACE [org.wildfly.security] (default task-3) Handling NameCallback: authenticationName = correctUser > 17:30:50,212 TRACE [org.wildfly.security] (default task-3) Principal assigning: [correctUser], pre-realm rewritten: [correctUser], realm name: [jdbc-realm], post-realm rewritten: [correctUser], realm rewritten: [correctUser] > 17:30:50,215 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT PASSWORD FROM USERS WHERE NAME = ? with value correctUser > 17:30:50,301 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT roles.name FROM users, roles, users_roles WHERE users.name=? AND users.id = users_roles.userid AND roles.id = users_roles.roleid with value correctUser > 17:30:50,306 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT PASSWORD FROM USERS WHERE NAME = ? with value correctUser > 17:30:50,324 DEBUG [org.wildfly.security] (default task-3) User correctUser authentication failed. > 17:30:50,324 TRACE [org.wildfly.security] (default task-3) Handling AuthenticationCompleteCallback: fail > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFLY-9587) Investigate and introduce capabilities for the transactional subsytems transations/xts/rts

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/WFLY-9587?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka updated WFLY-9587: ---------------------------------- Summary: Investigate and introduce capabilities for the transactional subsytems transations/xts/rts (was: Investigate and add capability for the transactional subsytems transations/xts/rts) > Investigate and introduce capabilities for the transactional subsytems transations/xts/rts > ------------------------------------------------------------------------------------------ > > Key: WFLY-9587 > URL: https://issues.jboss.org/browse/WFLY-9587 > Project: WildFly > Issue Type: Feature Request > Components: Transactions, XTS > Affects Versions: 11.0.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > The notion of capability is not introduced to the transactional system. The WFLY integration expecting subsystem providing it. The transaction subsystems should support so. > https://docs.jboss.org/author/display/WFLY/Working+with+WildFly+Capabilities -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFLY-9587) Investigate and add capability for the transactional subsytems transations/xts/rts

by Ondra Chaloupka (JIRA)

Ondra Chaloupka created WFLY-9587: ------------------------------------- Summary: Investigate and add capability for the transactional subsytems transations/xts/rts Key: WFLY-9587 URL: https://issues.jboss.org/browse/WFLY-9587 Project: WildFly Issue Type: Feature Request Components: Transactions, XTS Affects Versions: 11.0.0.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka The notion of capability is not introduced to the transactional system. The WFLY integration expecting subsystem providing it. The transaction subsystems should support so. https://docs.jboss.org/author/display/WFLY/Working+with+WildFly+Capabilities -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFLY-9586) Persistent EJB timers should resume only once if missed multiple times

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created WFLY-9586: -------------------------------------- Summary: Persistent EJB timers should resume only once if missed multiple times Key: WFLY-9586 URL: https://issues.jboss.org/browse/WFLY-9586 Project: WildFly Issue Type: Enhancement Components: EJB Reporter: Wolf-Dieter Fink Timers which are persistent need to resume if the timeout is missed, i.e. if the server was down. The EJB specification say by §13.2: "In the event of a container crash or container shutdown, the timeout callback method for a persistent timer that has not been cancelled will be invoked on a new JVM when the container is restarted or on another JVM instance across which the container is distributed. This rule applies to both programmatically or automatically created persistent timers." The understanding is not clear and can be - resume ALL missed timeouts - resume but fire the timer only once As Wildfly prevent from having the same timeout running concurrent a server start will have the effect that multiple timeouts are fired (assume you have a timer scheduled for every second and the server is down for minutes) but only the first (or a couple) will efectively executed all other will 'only' burden the server and log warn/error messages. The effect for the server start is a slower startup, long list of log messages and no real benefit! If the spec is really unclear here a configuration flag should be added to control that behaviour (like done for ejb invocation in-vm calls - byReference/byValue) The current behaviour should be the default but a boolean attribute should allow to fire the timer only once and set the next timeout according to the schedule (recurring or calendar) in the future. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFLY-9585) Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name

by Shing Lam (JIRA)

Shing Lam created WFLY-9585: ------------------------------- Summary: Wildfly 10 ignores jboss-ejb3.xml resource-ref lookup-name Key: WFLY-9585 URL: https://issues.jboss.org/browse/WFLY-9585 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 10.1.0.Final Environment: Wilfly-10.1.0.Final with jdk-1.8.0_31 under Red Hat Enterprise Linux Server release 5.11 (Tikanga) Reporter: Shing Lam We have a ear that use a datasource that is injected. The application runs normally in Jboss EAP 6.4, with the correct datasource being used. But when deployed to Wildfly-10.1.0_Final, instead of the datasource specified in the jboss-ejb3.xml, the default datasource is alway injected. We have in the ejb-jar.xml {code:xml} <enterprise-beans> <session> <ejb-name>BackgroundRecoverySessionEJB</ejb-name> <resource-ref> <res-ref-name>jdbc/RMDataSource</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> </resource-ref> <persistence-context-ref> <persistence-context-ref-name>persistence/RMEntityManager</persistence-context-ref-name> </persistence-context-ref> </session> {code} and in jboss-ejb3.xml {code:xml} <jboss:enterprise-beans> <jboss:ejb> <ejb-name>BackgroundRecoverySessionEJB</ejb-name> <resource-ref> <res-ref-name>jdbc/RMDataSource</res-ref-name> <res-type>javax.sql.DataSource</res-type> <lookup-name>java:jboss/jdbc/RMDataSource</lookup-name> </resource-ref> </jboss:ejb> {code} the datasource java:jboss/jdbc/RMDataSource got injected into the EJB under JBoss EAP 6.4. But in WildFly 10.1, the default datasource java:jboss/datasources/ExampleDS was injected, causing "org.h2.jdbc.JdbcSQLException: Table "XXX" not found;" If we set the default datasource to java:jboss/jdbc/RMDataSource, java:jboss/jdbc/RMDataSource jot injected into the EJB. Seems like the jboss-ejb3.xml has no effect on WildFly 10.1, the default datasource is always used. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-3439) Reevaluate MultiphaseOverallContext.transformServerOperation

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3439?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3439: ------------------------------------- Description: DomainRolloutStepHandler when it's pushing ops out to the servers calls MultiphaseOverallContext.transformServerOperation, which in turn transforms the operation. But the operation in question has been supplied by the slave HC. It should not need transformation. Perhaps the result would need transformation, but I don't see how the op provided by the slave would provide reliable input for working out that transformation. One thing to be careful about when looking at this is the possibility that the operation is a composite and a step in it has not been provided by the slave HC, but rather is the original request input. As part of this, check if the "push-to-servers" workaround discussed in https://github.com/wildfly/wildfly/pull/10676 has been merged, and if it has try and remove that. was: DomainRolloutStepHandler when it's pushing ops out to the servers calls MultiphaseOverallContext.transformServerOperation, which in turn transforms the operation. But the operation in question has been supplied by the slave HC. It should not need transformation. Perhaps the result would need transformation, but I don't see how the op provided by the slave would provide reliable input for working out that transformation. One thing to be careful about when looking at this is the possibility that the operation (or a step in it if it's composite) has not been provided by the slave HC, but rather is the original request input. As part of this, check if the "push-to-servers" workaround discussed in https://github.com/wildfly/wildfly/pull/10676 has been merged, and if it has try and remove that. > Reevaluate MultiphaseOverallContext.transformServerOperation > ------------------------------------------------------------ > > Key: WFCORE-3439 > URL: https://issues.jboss.org/browse/WFCORE-3439 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > DomainRolloutStepHandler when it's pushing ops out to the servers calls MultiphaseOverallContext.transformServerOperation, which in turn transforms the operation. But the operation in question has been supplied by the slave HC. It should not need transformation. > Perhaps the result would need transformation, but I don't see how the op provided by the slave would provide reliable input for working out that transformation. > One thing to be careful about when looking at this is the possibility that the operation is a composite and a step in it has not been provided by the slave HC, but rather is the original request input. > As part of this, check if the "push-to-servers" workaround discussed in https://github.com/wildfly/wildfly/pull/10676 has been merged, and if it has try and remove that. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-3439) Reevaluate MultiphaseOverallContext.transformServerOperation

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-3439: ---------------------------------------- Summary: Reevaluate MultiphaseOverallContext.transformServerOperation Key: WFCORE-3439 URL: https://issues.jboss.org/browse/WFCORE-3439 Project: WildFly Core Issue Type: Task Components: Domain Management Reporter: Brian Stansberry Assignee: Brian Stansberry DomainRolloutStepHandler when it's pushing ops out to the servers calls MultiphaseOverallContext.transformServerOperation, which in turn transforms the operation. But the operation in question has been supplied by the slave HC. It should not need transformation. Perhaps the result would need transformation, but I don't see how the op provided by the slave would provide reliable input for working out that transformation. One thing to be careful about when looking at this is the possibility that the operation (or a step in it if it's composite) has not been provided by the slave HC, but rather is the original request input. As part of this, check if the "push-to-servers" workaround discussed in https://github.com/wildfly/wildfly/pull/10676 has been merged, and if it has try and remove that. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2017