February 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-3674) UX proposal for error reporting after test run

by Amanda Han (Jira)

[ https://issues.jboss.org/browse/DROOLS-3674?page=com.atlassian.jira.plugi... ] Amanda Han updated DROOLS-3674: ------------------------------- Attachment: Error reporting after test run-different kinds.png > UX proposal for error reporting after test run > ---------------------------------------------- > > Key: DROOLS-3674 > URL: https://issues.jboss.org/browse/DROOLS-3674 > Project: Drools > Issue Type: Task > Components: Scenario Simulation and Testing > Reporter: Daniele Zonca > Assignee: tao zhu > Priority: Major > Labels: ScenarioSimulation, UXTeam > Attachments: Error reporting after test run-different kinds.png, Error reporting after test run-popup.png, Error reporting after test run.png > > > As user after a test run, I want see not only the cell that are not correct (red background) but also the reason. > For instance have the possibility to see the actual value that is different from the expected or the error message. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11774) Rename microprofile layer to be observability

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-11774?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-11774: ------------------------------------ Issue Type: Task (was: Feature Request) > Rename microprofile layer to be observability > --------------------------------------------- > > Key: WFLY-11774 > URL: https://issues.jboss.org/browse/WFLY-11774 > Project: WildFly > Issue Type: Task > Components: Build System > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > Priority: Major > Fix For: 16.0.0.CR1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2951) Unable to debug drools file with eclipse

by raghu thota (Jira)

[ https://issues.jboss.org/browse/DROOLS-2951?page=com.atlassian.jira.plugi... ] raghu thota commented on DROOLS-2951: ------------------------------------- I am curious to know if there are any updates on this task. Thank you ! > Unable to debug drools file with eclipse > ---------------------------------------- > > Key: DROOLS-2951 > URL: https://issues.jboss.org/browse/DROOLS-2951 > Project: Drools > Issue Type: Bug > Reporter: raghu thota > Assignee: Mario Fusco > Priority: Major > Labels: Drools, debugging > > I am trying to debug a .drl file using Eclipse mars (version Mars.2 Release (4.5.2)) and drools version 5.5.0.FINAL. I have added drools runtime. After running the Junit test as "Debug as Drools Junit test" , I got the following error. > An internal error occurred during: "Launching DroolsDummyTest.testHelloWorldRule (1)". > org.drools.eclipse.launching.DroolsVMDebugger.renderProcessLabel([Ljava/lang/String;)Ljava/lang/String; > This is the problem with incompatibility of drools and eclipse. I am able to debug other drools (version 5.5.0.FINAL) applications using Eclipse Helios. But, My current project is written in Java 7 which is not supported by Helios. > I am referring the link : http://docs.jboss.org/drools/release/5.5.0.Final/drools-expert-docs/html/... -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11750) Allow cluster to use DNS addresses instead of IP addresses

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFLY-11750?page=com.atlassian.jira.plugin... ] Paul Ferraro commented on WFLY-11750: ------------------------------------- [~tomekadamski] Thanks for elaborating - I think I understand the issue now. {quote}But if I understand correctly HA features and correct transaction recovery are independent. {quote} Correct. {quote}As a result, the client has a record in its permanent object store and tries to finish the transaction. As the record contains the IP address of the failed node the client will wait till the server is up again to finish the transaction.{quote} The address would have been obtained from the service URL of the ejb client connection. {quote}That node will have the new cluster identity. My understanding is that it has no effect on transaction recovery which will work fine.{quote} Correct. {quote}But the key thing here IMO is, the way remoting gets node information.{quote} Agreed. The server supplies this information via client mappings, the destination address for which is stored and supplied as a string. Thus the server *should* already be capable of seeding the client with a hostname instead of an IP address. However, I suspect that the address used by the transaction client is taken from the remote connection itself - which likely use the resolved destination address (as the established connection will have already resolved the host name), rather than preferring the host name over the address, if it exists. {quote}Another thing: does clustering takes care of replicating Narayana object store? If this is the case then the problem would be different.{quote} Clustering does not currently perform any state replication on behalf of the the Narayana object store. > Allow cluster to use DNS addresses instead of IP addresses > ---------------------------------------------------------- > > Key: WFLY-11750 > URL: https://issues.jboss.org/browse/WFLY-11750 > Project: WildFly > Issue Type: Feature Request > Components: Clustering > Affects Versions: 16.0.0.Beta1 > Reporter: Tomasz Adamski > Assignee: Paul Ferraro > Priority: Major > > We would need a configuration that would allow for the cluster to use DNS addresses instead of IP addresses. The reason is that OpenShift guarantees the node identity under DNS address and not under IP address. > Sample scenario that may currently fail when application are deployed in OpenShift: > A (application) > B (clustered application) > 1. A calls transactional invocation on B > 2. as a result of discovery process A obtains a cluster topology from B and uses one of obtained IP addresses for the connection > 3. as the invocation is transactional the object-store records are written in A's persistent object store; those records are based on the data obtained from the cluster => subordinate node is identified by the IP address from point two > 4. B node fails > 5. OpenShift restarts node B on another IP address > 6. A attempts recovery and persistently fails > OTOH OpenShift guarantees node identity under DNS address. As a result, at point 5 node is guaranteed to restart on established DNS address so if the cluster used this address instead of physical addresses the scenario above will finish with A being able to recover the transaction. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4347) Update Maven Plugins to 2.0.0.Final

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-4347?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-4347: -------------------------------- Issue Type: Component Upgrade (was: Enhancement) > Update Maven Plugins to 2.0.0.Final > ----------------------------------- > > Key: WFCORE-4347 > URL: https://issues.jboss.org/browse/WFCORE-4347 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Build System > Reporter: Eduardo Martins > Assignee: Eduardo Martins > Priority: Major > Fix For: 8.0.0.CR1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4341) Upgrade Undertow to 2.0.19.Final

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-4341?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-4341: -------------------------------- Issue Type: Component Upgrade (was: Bug) > Upgrade Undertow to 2.0.19.Final > -------------------------------- > > Key: WFCORE-4341 > URL: https://issues.jboss.org/browse/WFCORE-4341 > Project: WildFly Core > Issue Type: Component Upgrade > Reporter: Flavia Rainone > Assignee: Flavia Rainone > Priority: Major > Fix For: 8.0.0.CR1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-629) Enabled automatic encryption of passwords stored in configuration

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-629?page=com.atlassian.jira.plugin... ] Jeff Mesnil updated WFCORE-629: ------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 8.0.0.CR1) > Enabled automatic encryption of passwords stored in configuration > ----------------------------------------------------------------- > > Key: WFCORE-629 > URL: https://issues.jboss.org/browse/WFCORE-629 > Project: WildFly Core > Issue Type: Feature Request > Components: Management, Security > Environment: Wildfly 9 > Reporter: Jason Shepherd > Assignee: Darran Lofthouse > Priority: Major > Fix For: 9.0.0.Beta1 > > > Currently encrypting passwords such as Datasource passwords can only be done 'after the fact'. You have to create the datasource first, then retrospectively store the password in the vault and dereference it in the configuration. > It would be great if could turn on automatic storage of passwords in the vault so that when you create a Datasource password, or add a resource adapter which specifies a remote resource password, those passwords were automatically added to the vault, and deferenced in the configuration file. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2496) Functionality in WildFly to encrypt database passwords

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-2496?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-2496: -------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 8.0.0.CR1) > Functionality in WildFly to encrypt database passwords > ------------------------------------------------------ > > Key: WFCORE-2496 > URL: https://issues.jboss.org/browse/WFCORE-2496 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Carlton Zachary > Assignee: Darran Lofthouse > Priority: Major > Fix For: 9.0.0.Beta1 > > > Is it possible to add functionality to WildFly to encrypt a data source password when the data source is being created? Currently WildFly/EAP stores the password as plain text in the domain.xml/standalone.xml. > Thanks -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3542) Elytron JDBC realm password mapping is not consistent with underlying implementation

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-3542?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-3542: -------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 8.0.0.CR1) > Elytron JDBC realm password mapping is not consistent with underlying implementation > ------------------------------------------------------------------------------------ > > Key: WFCORE-3542 > URL: https://issues.jboss.org/browse/WFCORE-3542 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: David Lloyd > Assignee: Darran Lofthouse > Priority: Major > Fix For: 9.0.0.Beta1 > > > There is no way to configure the JDBC realm to use modular crypt in WildFly, even though the underlying realm does support it. > The problem is that the *{{salt-index}} and {{itereration-count-index}} attributes should be optional*, and if they not given, a value of {{-1}} should be passed to the mapper. By omitting both of these values, the database column values will then be recognized as modular-crypt strings. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3832) Support hex encoding in jdbc-realm for elytron

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-3832?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-3832: -------------------------------- Fix Version/s: 9.0.0.Beta1 (was: 8.0.0.CR1) > Support hex encoding in jdbc-realm for elytron > ---------------------------------------------- > > Key: WFCORE-3832 > URL: https://issues.jboss.org/browse/WFCORE-3832 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Affects Versions: 5.0.0.Alpha7 > Reporter: Jan Kalina > Assignee: Darran Lofthouse > Priority: Major > Labels: elytron > Fix For: 9.0.0.Beta1 > > > Old database login-module can be configured passing the attribute {{hashEncoding}}, for example: > {code:xml} > <login-module code="Database" flag="required"> > <module-option name="dsJndiName" value="java:jboss/datasources/ExampleDS"/> > <module-option name="principalsQuery" value="SELECT password FROM User WHERE username = ?"/> > <module-option name="rolesQuery" value="SELECT role, 'Roles' FROM User WHERE username = ?"/> > <module-option name="hashAlgorithm" value="SHA-1"/> > <module-option name="hashEncoding" value="hex"/> > <module-option name="hashCharset" value="UTF-8"/> > </login-module> > {code} > Currently jdbc-realm in elytron only uses base64 encoding if hash is stored in a text column. This way the migration is more complicated cos the password hash is not valid changing from old security system to elytron. > Think also about the charset attribute. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 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 February 2019