[JBoss JIRA] (DROOLS-2889) Research accessibility considerations for Data Type list drag-n-drop.
by Liz Clayton (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2889?page=com.atlassian.jira.plugi... ]
Liz Clayton commented on DROOLS-2889:
-------------------------------------
[~karreiro] [~manstis] Please let me know what you think about the research in terms of using DnD for the reordering feature. If we decide to go this route, as [~srambach] suggested it will take some thinking through in terms of user experience, which will require more design sprints to work out the UX. Thanks
> Research accessibility considerations for Data Type list drag-n-drop.
> ----------------------------------------------------------------------
>
> Key: DROOLS-2889
> URL: https://issues.jboss.org/browse/DROOLS-2889
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Sarah Rambacher
> Labels: UX, UXTeam, drools-tools
> Attachments: Screen Shot 2018-08-13 at 1.42.16 PM.png
>
>
> Use Case: As a DMN user I will want to be able to reorder the list of Custom data types so that I can arrange data types in a logical order.
> Notes:
> * The Data Type dialog leverage the following PR list pattern:
> https://www.patternfly.org/pattern-library/content-views/tree-list-view
> * The list will need to be re-orderable, there is an open design jira to determine the interaction options for that feature.
> * Design is currently being iterated upon, but last iteration wireframes are posted at: https://redhat.invisionapp.com/share/B7NEEUSV539
> Verification conditions:
> * Research results summarized in the jira or a linked google doc., etc.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2889) Research accessibility considerations for Data Type list drag-n-drop.
by Sarah Rambacher (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2889?page=com.atlassian.jira.plugi... ]
Sarah Rambacher commented on DROOLS-2889:
-----------------------------------------
Here's a doc collecting some of the best examples and articles about drag and drop accessibility. There aren't a ton of resources, but there is one example of a reorder-able nested list that I think we could take from.
https://docs.google.com/document/d/1a8kxI9FAvoDlR_B9zbMGQ6wG52bzcfGW5fbSC...
[~tirelli] Regarding the scenario of copying an item to another list - it might be worth thinking about what other options there are to accomplish this while avoiding excessive complexity - even for sighted mouse users. There are a lot of little details to work out - does the user want to copy the field? move it? is it valid for that list? etc.
> Research accessibility considerations for Data Type list drag-n-drop.
> ----------------------------------------------------------------------
>
> Key: DROOLS-2889
> URL: https://issues.jboss.org/browse/DROOLS-2889
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Sarah Rambacher
> Labels: UX, UXTeam, drools-tools
> Attachments: Screen Shot 2018-08-13 at 1.42.16 PM.png
>
>
> Use Case: As a DMN user I will want to be able to reorder the list of Custom data types so that I can arrange data types in a logical order.
> Notes:
> * The Data Type dialog leverage the following PR list pattern:
> https://www.patternfly.org/pattern-library/content-views/tree-list-view
> * The list will need to be re-orderable, there is an open design jira to determine the interaction options for that feature.
> * Design is currently being iterated upon, but last iteration wireframes are posted at: https://redhat.invisionapp.com/share/B7NEEUSV539
> Verification conditions:
> * Research results summarized in the jira or a linked google doc., etc.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (SWSQE-380) Bookinfo Deploy Failing
by Guilherme Baufaker Rêgo (JIRA)
[ https://issues.jboss.org/browse/SWSQE-380?page=com.atlassian.jira.plugin.... ]
Guilherme Baufaker Rêgo resolved SWSQE-380.
-------------------------------------------
Resolution: Done
> Bookinfo Deploy Failing
> -----------------------
>
> Key: SWSQE-380
> URL: https://issues.jboss.org/browse/SWSQE-380
> Project: Kiali QE
> Issue Type: Bug
> Reporter: Matt Mahoney
> Assignee: Guilherme Baufaker Rêgo
>
> [istio] $ ansible-playbook bookinfo.yml -e istio_version=1.0.0 -e traffic_generator=true -e ingress_route=false -e rate=1 -v
> Using /etc/ansible/ansible.cfg as config file
> [WARNING]: provided hosts list is empty, only localhost is available. Note
> that the implicit localhost does not match 'all'
> ERROR! Syntax Error while loading YAML.
> mapping values are not allowed in this context
> The error appears to have been in '/home/jenkins/workspace/install-bookinfo/checkout-directory/scripts/istio/bookinfo.yml': line 13, column 15,
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (SWSQE-380) Bookinfo Deploy Failing
by Guilherme Baufaker Rêgo (JIRA)
[ https://issues.jboss.org/browse/SWSQE-380?page=com.atlassian.jira.plugin.... ]
Guilherme Baufaker Rêgo commented on SWSQE-380:
-----------------------------------------------
It seems to be a problem on the connection.
Closing this one in favor of the problem on istio upstream
> Bookinfo Deploy Failing
> -----------------------
>
> Key: SWSQE-380
> URL: https://issues.jboss.org/browse/SWSQE-380
> Project: Kiali QE
> Issue Type: Bug
> Reporter: Matt Mahoney
> Assignee: Guilherme Baufaker Rêgo
>
> [istio] $ ansible-playbook bookinfo.yml -e istio_version=1.0.0 -e traffic_generator=true -e ingress_route=false -e rate=1 -v
> Using /etc/ansible/ansible.cfg as config file
> [WARNING]: provided hosts list is empty, only localhost is available. Note
> that the implicit localhost does not match 'all'
> ERROR! Syntax Error while loading YAML.
> mapping values are not allowed in this context
> The error appears to have been in '/home/jenkins/workspace/install-bookinfo/checkout-directory/scripts/istio/bookinfo.yml': line 13, column 15,
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10881) Sync version properties names on BOMs+Quickstarts with WildFly
by Eduardo Martins (JIRA)
Eduardo Martins created WFLY-10881:
--------------------------------------
Summary: Sync version properties names on BOMs+Quickstarts with WildFly
Key: WFLY-10881
URL: https://issues.jboss.org/browse/WFLY-10881
Project: WildFly
Issue Type: Enhancement
Components: Quickstarts
Affects Versions: 13.0.0.Final
Reporter: Eduardo Martins
Assignee: Eduardo Martins
BOMs and Quickstarts projects should use the same WildFly properties names for defining dependency versions, allowing easier sync of values.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10879) Deployment is not failing as expected and according to the specification if a @Singleton @Startup @PostConstruct initialization failed
by Wolf-Dieter Fink (JIRA)
[ https://issues.jboss.org/browse/WFLY-10879?page=com.atlassian.jira.plugin... ]
Wolf-Dieter Fink updated WFLY-10879:
------------------------------------
Attachment: server.log
> Deployment is not failing as expected and according to the specification if a @Singleton @Startup @PostConstruct initialization failed
> --------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10879
> URL: https://issues.jboss.org/browse/WFLY-10879
> Project: WildFly
> Issue Type: Bug
> Reporter: Wolf-Dieter Fink
> Assignee: Jason Greene
> Attachments: server.log
>
>
> According to the spec (see below excerpt of ejb3.2 specification) the application should not avaialble if a Singleton initialization has failed.
> The current behaviour with two ejb.jar's in one ear, or other combinations is
> that the failure is logged, the deployment seems removed (there is a APP.ear.failed marker file) but another EJB of a second jar inside the ear is accesible, also web applications war deployemts are started.
> from the Spec 3.2
> 4.8.1 Singleton Session Bean Initialization
> By default, the container is responsible for deciding when to initialize a singleton session bean instance.
> However, the Bean Provider can optionally configure the singleton session bean for eager initialization.
> If the Startup annotation appears on the singleton session bean class or if the singleton session bean
> has been designated via the deployment descriptor as requiring eager initialization, the container must
> initialize the singleton session bean instance during the application startup sequence.
> ***** The container must initialize all such startup-time singleton session beans before any external client requests (that is,
> client requests originating outside of the application) are delivered to any enterprise bean components in
> the application. ******
> 4.8.4 Singleton SB error handling
> Errors occurring during singleton session bean initialization are considered fatal and must result in the
> discarding of the singleton session bean instance. ...
> If a singleton session bean fails to initialize, attempted invocations on the singleton session bean result in the
> javax.ejb.NoSuchEJBException exception as defined by Section 3.4.3 and Section 3.4.4 .
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10880) Deployment is not failing as expected and according to the specification if a @Singleton @Startup @PostConstruct initialization failed
by Wolf-Dieter Fink (JIRA)
Wolf-Dieter Fink created WFLY-10880:
---------------------------------------
Summary: Deployment is not failing as expected and according to the specification if a @Singleton @Startup @PostConstruct initialization failed
Key: WFLY-10880
URL: https://issues.jboss.org/browse/WFLY-10880
Project: WildFly
Issue Type: Bug
Reporter: Wolf-Dieter Fink
Assignee: Jason Greene
According to the spec (see below excerpt of ejb3.2 specification) the application should not avaialble if a Singleton initialization has failed.
The current behaviour with two ejb.jar's in one ear, or other combinations is
that the failure is logged, the deployment seems removed (there is a APP.ear.failed marker file) but another EJB of a second jar inside the ear is accesible, also web applications war deployemts are started.
from the Spec 3.2
4.8.1 Singleton Session Bean Initialization
By default, the container is responsible for deciding when to initialize a singleton session bean instance.
However, the Bean Provider can optionally configure the singleton session bean for eager initialization.
If the Startup annotation appears on the singleton session bean class or if the singleton session bean
has been designated via the deployment descriptor as requiring eager initialization, the container must
initialize the singleton session bean instance during the application startup sequence.
***** The container must initialize all such startup-time singleton session beans before any external client requests (that is,
client requests originating outside of the application) are delivered to any enterprise bean components in
the application. ******
4.8.4 Singleton SB error handling
Errors occurring during singleton session bean initialization are considered fatal and must result in the
discarding of the singleton session bean instance. ...
If a singleton session bean fails to initialize, attempted invocations on the singleton session bean result in the
javax.ejb.NoSuchEJBException exception as defined by Section 3.4.3 and Section 3.4.4 .
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10879) Deployment is not failing as expected and according to the specification if a @Singleton @Startup @PostConstruct initialization failed
by Wolf-Dieter Fink (JIRA)
Wolf-Dieter Fink created WFLY-10879:
---------------------------------------
Summary: Deployment is not failing as expected and according to the specification if a @Singleton @Startup @PostConstruct initialization failed
Key: WFLY-10879
URL: https://issues.jboss.org/browse/WFLY-10879
Project: WildFly
Issue Type: Bug
Reporter: Wolf-Dieter Fink
Assignee: Jason Greene
According to the spec (see below excerpt of ejb3.2 specification) the application should not avaialble if a Singleton initialization has failed.
The current behaviour with two ejb.jar's in one ear, or other combinations is
that the failure is logged, the deployment seems removed (there is a APP.ear.failed marker file) but another EJB of a second jar inside the ear is accesible, also web applications war deployemts are started.
from the Spec 3.2
4.8.1 Singleton Session Bean Initialization
By default, the container is responsible for deciding when to initialize a singleton session bean instance.
However, the Bean Provider can optionally configure the singleton session bean for eager initialization.
If the Startup annotation appears on the singleton session bean class or if the singleton session bean
has been designated via the deployment descriptor as requiring eager initialization, the container must
initialize the singleton session bean instance during the application startup sequence.
***** The container must initialize all such startup-time singleton session beans before any external client requests (that is,
client requests originating outside of the application) are delivered to any enterprise bean components in
the application. ******
4.8.4 Singleton SB error handling
Errors occurring during singleton session bean initialization are considered fatal and must result in the
discarding of the singleton session bean instance. ...
If a singleton session bean fails to initialize, attempted invocations on the singleton session bean result in the
javax.ejb.NoSuchEJBException exception as defined by Section 3.4.3 and Section 3.4.4 .
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (ELY-1639) FIPS PKCS11 Client side: only SunJSSE KeyManagers may be used
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1639?page=com.atlassian.jira.plugin.s... ]
Jan Kalina edited comment on ELY-1639 at 8/17/18 9:57 AM:
----------------------------------------------------------
[~mchoma] yes, this is correct - the alias choosing is possible only using elytron specific KeyManager, which is not allowed in FIPS.
On server side we use FilteringKeyStore, which I suppose will not work with FIPS as well.
was (Author: honza889):
[~mchoma] yes, this is correct - the alias choosing is possible only using elytron specific KeyManager (which is not allowed in FIPS)
> FIPS PKCS11 Client side: only SunJSSE KeyManagers may be used
> -------------------------------------------------------------
>
> Key: ELY-1639
> URL: https://issues.jboss.org/browse/ELY-1639
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Blocker
> Attachments: cli-wildfly-config.xml
>
>
> Fix of ELY-1622 introduced regression. It is not possible to do 1 way ssl (no key-store-ssl-certificate in wildfly-config.xml) with exception
> {code}
> 14:13:56,143 ERROR [org.jboss.as.cli.impl.CliLauncher] Error processing CLI: org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:330)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:291)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:45)
> at org.jboss.modules.Module.run(Module.java:352)
> at org.jboss.modules.Module.run(Module.java:320)
> at org.jboss.modules.Main.main(Main.java:593)
> Caused by: org.jboss.as.cli.CommandLineException: Failed to resolve host 'localhost'
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1256)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1203)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1198)
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:328)
> ... 5 more
> Caused by: java.io.IOException: Failed to obtain SSLContext
> at org.jboss.as.cli.impl.CLIModelControllerClient.<init>(CLIModelControllerClient.java:156)
> at org.jboss.as.cli.impl.ModelControllerClientFactory$2.getClient(ModelControllerClientFactory.java:85)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1222)
> ... 8 more
> Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE KeyManagers may be used
> at sun.security.ssl.SSLContextImpl.chooseKeyManager(SSLContextImpl.java:149)
> at sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:66)
> at javax.net.ssl.SSLContext.init(SSLContext.java:282)
> at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:372)
> at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:53)
> at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.getSSLContext(AuthenticationContextConfigurationClient.java:221)
> at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.getSSLContext(AuthenticationContextConfigurationClient.java:208)
> at org.jboss.as.cli.impl.CLIModelControllerClient.<init>(CLIModelControllerClient.java:153)
> ... 10 more
> {code}
> It is because after fix Fix of ELY-1622 custom keymanager is used. But it is forbidden by jdk FIPS PKCS11.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (ELY-1639) FIPS PKCS11 Client side: only SunJSSE KeyManagers may be used
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1639?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse commented on ELY-1639:
---------------------------------------
We can probably try wrapping the KeyStore with our filtering KeyStore implementation - I don't think that same restrictions are placed on the store.
> FIPS PKCS11 Client side: only SunJSSE KeyManagers may be used
> -------------------------------------------------------------
>
> Key: ELY-1639
> URL: https://issues.jboss.org/browse/ELY-1639
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Blocker
> Attachments: cli-wildfly-config.xml
>
>
> Fix of ELY-1622 introduced regression. It is not possible to do 1 way ssl (no key-store-ssl-certificate in wildfly-config.xml) with exception
> {code}
> 14:13:56,143 ERROR [org.jboss.as.cli.impl.CliLauncher] Error processing CLI: org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:330)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:291)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:45)
> at org.jboss.modules.Module.run(Module.java:352)
> at org.jboss.modules.Module.run(Module.java:320)
> at org.jboss.modules.Main.main(Main.java:593)
> Caused by: org.jboss.as.cli.CommandLineException: Failed to resolve host 'localhost'
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1256)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1203)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1198)
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:328)
> ... 5 more
> Caused by: java.io.IOException: Failed to obtain SSLContext
> at org.jboss.as.cli.impl.CLIModelControllerClient.<init>(CLIModelControllerClient.java:156)
> at org.jboss.as.cli.impl.ModelControllerClientFactory$2.getClient(ModelControllerClientFactory.java:85)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1222)
> ... 8 more
> Caused by: java.security.KeyManagementException: FIPS mode: only SunJSSE KeyManagers may be used
> at sun.security.ssl.SSLContextImpl.chooseKeyManager(SSLContextImpl.java:149)
> at sun.security.ssl.SSLContextImpl.engineInit(SSLContextImpl.java:66)
> at javax.net.ssl.SSLContext.init(SSLContext.java:282)
> at org.wildfly.security.ssl.SSLContextBuilder.lambda$build$0(SSLContextBuilder.java:372)
> at org.wildfly.security.OneTimeSecurityFactory.create(OneTimeSecurityFactory.java:53)
> at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.getSSLContext(AuthenticationContextConfigurationClient.java:221)
> at org.wildfly.security.auth.client.AuthenticationContextConfigurationClient.getSSLContext(AuthenticationContextConfigurationClient.java:208)
> at org.jboss.as.cli.impl.CLIModelControllerClient.<init>(CLIModelControllerClient.java:153)
> ... 10 more
> {code}
> It is because after fix Fix of ELY-1622 custom keymanager is used. But it is forbidden by jdk FIPS PKCS11.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months