[JBoss JIRA] (DROOLS-3954) Document UX solutions for communicating errors in graphs & grids.
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3954?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton commented on DROOLS-3954:
-------------------------------------------
[~zhutaojiajia] I was wondering if you could humor me in documenting the final Test related design solutions to this document, in the format that I have outlined:
https://docs.google.com/document/d/1fX9K_fDjEO4_wDLK9EDDb0OtEFir7S6nFH9cn...
Reason being: It's a little difficult to tell from jiras, and even InVision docs what the final design recommendation was. I only ask because I would like to reuse the design in as much as possible in DMN, Stunner, etc. For now, I'm going to reassign this jira to you, to add whatever you can, then feel free to reassign it back to me. :) Thanks for your help!
> Document UX solutions for communicating errors in graphs & grids.
> ------------------------------------------------------------------
>
> Key: DROOLS-3954
> URL: https://issues.jboss.org/browse/DROOLS-3954
> Project: Drools
> Issue Type: Story
> Components: DMN Editor, Scenario Simulation and Testing
> Reporter: Elizabeth Clayton
> Assignee: Elizabeth Clayton
> Priority: Optional
> Labels: ScenarioSimulation, Stunner, UX, UXTeam, drools-tools
>
> Scenario, DMN, and Process modeler share design solutions for displaying errors in graphs (models) and grids (scenario test, dmn boxed expressions.) To assure consistency while also documenting unique solutions per context.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 10 months
[JBoss JIRA] (DROOLS-3954) Document UX solutions for communicating errors in graphs & grids.
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3954?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton reassigned DROOLS-3954:
-----------------------------------------
Assignee: Tao Zhu (was: Elizabeth Clayton)
> Document UX solutions for communicating errors in graphs & grids.
> ------------------------------------------------------------------
>
> Key: DROOLS-3954
> URL: https://issues.jboss.org/browse/DROOLS-3954
> Project: Drools
> Issue Type: Story
> Components: DMN Editor, Scenario Simulation and Testing
> Reporter: Elizabeth Clayton
> Assignee: Tao Zhu
> Priority: Optional
> Labels: ScenarioSimulation, Stunner, UX, UXTeam, drools-tools
>
> Scenario, DMN, and Process modeler share design solutions for displaying errors in graphs (models) and grids (scenario test, dmn boxed expressions.) To assure consistency while also documenting unique solutions per context.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 10 months
[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.Beta5
(was: 9.0.0.Beta4)
> 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.Beta5
>
>
> 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)
5 years, 10 months
[JBoss JIRA] (WFLY-9529) Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry
by Scott Van Wart (Jira)
[ https://issues.jboss.org/browse/WFLY-9529?page=com.atlassian.jira.plugin.... ]
Scott Van Wart commented on WFLY-9529:
--------------------------------------
[~emmartins] Is there any further update on this? We have an ActiveMQ connection leak that I suspect is related to this. It seems every few weeks one of our Wildfly installations starts up and needs to be restarted again to gamble on some race condition. There seems to be a variety of symptoms that crop up, such as Wildfly allowing tasks to be submitted to an MES at startup, only for that task to fail because the MES isn't ready (our workaround for that is to use a scheduled MES and retry until it succeeds). I've wrapped some of our messaging logic in an EJB but it looks like instead of getting NameNotFoundException: TransactionSynchronizationRegistry it's culminating in an ActiveMQ connection leak.
Honestly, we've moved the vast majority of our messaging to Hazelcast and have a few more cases to cover. Whether or not this will get properly addressed is going to determine if we put the final nails in the coffin.
> Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9529
> URL: https://issues.jboss.org/browse/WFLY-9529
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, JMS, Naming
> Affects Versions: 14.0.1.Final, 10.1.0.Final, 11.0.0.Final, 12.0.0.Final, 13.0.0.Final
> Environment: Running on Windows 10, Java 64-bit 1.8.0_131
> Reporter: Scott Van Wart
> Assignee: Eduardo Martins
> Priority: Major
> Labels: ActiveMQ, jms, transaction
> Attachments: injected-jms.zip, injected-jms2.zip, wildfly-11-injected-jms.txt
>
>
> If I try to use an @Injected JMSContext while executing within a background task (ManagedExecutorService) or thread (ManagedThreadFactory), I get the attached stacktrace. I've experienced this a number of times with Wildfly 10.1.0, including messages sent in Infinispan's expiry task thread.
> My original workaround was to submit an additional task on a separate thread to send the message, then wait for it to complete. That seemed unreliable (sometimes it would still produce NameNotFoundException). I've resorted to creating my own JMSContext by using @Resource( lookup="java:/ConnectionFactory" ) and sending messages that way. Both workarounds prevent the message sending logic from participating in any ongoing transactions.
> I'm also attaching a sample EAR project. It can be built with Maven. It creates a background task that waits 3 seconds and then tries to send a JMS message in a new transaction using an injected JMS context. I use the standalone-full.xml profile to run it.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 10 months
[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.Beta5
(was: 9.0.0.Beta4)
> 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.Beta5
>
>
> 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)
5 years, 10 months