[JBoss JIRA] (DROOLS-3944) DMN Editor: Data type usability study
by Elizabeth Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3944?page=com.atlassian.jira.plugi... ]
Elizabeth Clayton updated DROOLS-3944:
--------------------------------------
Sprint: 2019 Week 23-25
> DMN Editor: Data type usability study
> -------------------------------------
>
> Key: DROOLS-3944
> URL: https://issues.jboss.org/browse/DROOLS-3944
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Environment: Version 7.4
> Reporter: Elizabeth Clayton
> Assignee: Sarahjane Clark
> Priority: Major
> Labels: UX, UXTeam, Usability, drools-tools
>
> Lightweight usability study to test the ease of use in viewing, creating, editing and deleting data types, particularly structured data types.
> GOALS: Access the Data Type editor in terms of productivity and usability.
> * Ease of use when creating a complex type (concern: minimizing the mouse usage.)
> * Ease of use when saving a basic data type (e.g. age: number)
> * Discoverability of actions in the kebab menu, especially, insert nested, delete.
> * Ease of use/accuracy: Type-ahead of the data type selector.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
3 months, 3 weeks
[JBoss JIRA] (WFLY-12461) Can't use smallrye-health without weld extension
by Florian Sailer (Jira)
Florian Sailer created WFLY-12461:
-------------------------------------
Summary: Can't use smallrye-health without weld extension
Key: WFLY-12461
URL: https://issues.jboss.org/browse/WFLY-12461
Project: WildFly
Issue Type: Bug
Components: MP Health
Affects Versions: 17.0.1.Final
Reporter: Florian Sailer
Assignee: Jeff Mesnil
Since this commit in the smallrye implementation it was possible to use smallrye without CDI.
https://github.com/smallrye/smallrye-health/commit/a6a7812877d74d2c3f5b29...
I'm trying to migrate from Wildfly 15.0.1-Final to 17.0.1-Final, where the smallrye-health extension unfortunately needs weld to startup. It's not possbible for me to activate weld on my sever, because there are some problems using the org.apache.cxf.jaxrs framework with weld.
I am getting the following exception while starting:
14:16:04,960 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/subsystem=microprofile-health-smallrye' are not available:
org.wildfly.weld; There are no known registration points which can provide this capability.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
1 year, 10 months
[JBoss JIRA] (WFLY-13726) PersistenceUnitServiceHandler.deployPersistenceUnitPhaseTwo
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-13726:
---------------------------------------
Summary: PersistenceUnitServiceHandler.deployPersistenceUnitPhaseTwo
Key: WFLY-13726
URL: https://issues.redhat.com/browse/WFLY-13726
Project: WildFly
Issue Type: Bug
Components: JPA / Hibernate
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 21.0.0.Beta1
PersistenceUnitServiceHandler.deployPersistenceUnitPhaseTwo is attempting to access BeanValidationAttachments.VALIDATOR_FACTORY without first confirming the capability is present. The deployPersistenceUnit method has a proper check.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (WFCORE-5078) remoting layer defines no dependencies
by Darran Lofthouse (Jira)
Darran Lofthouse created WFCORE-5078:
----------------------------------------
Summary: remoting layer defines no dependencies
Key: WFCORE-5078
URL: https://issues.redhat.com/browse/WFCORE-5078
Project: WildFly Core
Issue Type: Bug
Components: Build System, Remoting
Affects Versions: 13.0.0.Beta2
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 13.0.0.Beta3
The remoting layer depends upon legacy security realms but this dependency is not defined.
The layer named "remoting" should be updated to reference an elytron sasl-authentication-factory and the layer should depend upon the elytron layer.
There should be a second layer "legacy-remoting" which references the ApplicationRealm security realm and also this layer should have a dependency on the layer "application-security-realm".
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (WFCORE-5077) When using Galleon to provision Wildfly with core-server+managment layers, the availability of the Admin console is wrongly advertised to the user
by Brian Stansberry (Jira)
Brian Stansberry created WFCORE-5077:
----------------------------------------
Summary: When using Galleon to provision Wildfly with core-server+managment layers, the availability of the Admin console is wrongly advertised to the user
Key: WFCORE-5077
URL: https://issues.redhat.com/browse/WFCORE-5077
Project: WildFly Core
Issue Type: Bug
Components: Management
Affects Versions: 12.0.2.Final, 13.0.0.Beta2
Reporter: Fabio Burzigotti
Assignee: Brian Stansberry
When using Galleon to provision a Wildfly instance which would include just the {{core-server}} and {{managment}} layers, the LOG will trace the following lines:
{code}
...
15:38:17,219 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 20.0.1.Final (WildFly Core 12.0.3.Final) started in 1625ms - Started 86 of 89 services (27 services are lazy, passive or on-demand)
15:38:17,221 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
15:38:17,221 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
{code}
This is a wrong message for the end user because the managment interface will be available at the reported URL but the Admin console won't, returning a HTTP 404 status code.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (WFCORE-5076) remoting http-connector silently accepts invalid security-realm
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFCORE-5076?page=com.atlassian.jira.plug... ]
Darran Lofthouse moved WFLY-13724 to WFCORE-5076:
-------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-5076 (was: WFLY-13724)
Component/s: Remoting
(was: Remoting)
Fix Version/s: 13.0.0.Beta3
(was: 21.0.0.Beta1)
> remoting http-connector silently accepts invalid security-realm
> ---------------------------------------------------------------
>
> Key: WFCORE-5076
> URL: https://issues.redhat.com/browse/WFCORE-5076
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 13.0.0.Beta3
>
>
> If the remoting subsystem is changed to the following:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:remoting:4.0">
> <http-connector name="http-remoting-connector" connector-ref="default" security-realm="OtherRealm"/>
> </subsystem>
> {code}
> The server starts without error, however attempting to establish a connection fails.
> {code}
> ./jboss-cli.sh -c --controller=remote+http://localhost:8080
> Failed to connect to the controller: The controller is not available at localhost:8080: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+http://localhost:8080. The connection failed: WFLYPRT0053: Could not connect to remote+http://localhost:8080. The connection failed: Invalid response code 200
> {code}
> Although the CLI can not do anything over port 8080 it should be able to initiate a remoting connection i.e.
> {code}
> ./jboss-cli.sh -c --controller=remote+http://localhost:8080
> Failed to connect to the controller: The controller is not available at localhost:8080: org.jboss.remoting3.ServiceOpenException: Unknown service name management: Unknown service name management
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (WFLY-13724) remoting http-connector silently accepts invalid security-realm
by Darran Lofthouse (Jira)
Darran Lofthouse created WFLY-13724:
---------------------------------------
Summary: remoting http-connector silently accepts invalid security-realm
Key: WFLY-13724
URL: https://issues.redhat.com/browse/WFLY-13724
Project: WildFly
Issue Type: Bug
Components: Remoting
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 21.0.0.Beta1
If the remoting subsystem is changed to the following:
{code:xml}
<subsystem xmlns="urn:jboss:domain:remoting:4.0">
<http-connector name="http-remoting-connector" connector-ref="default" security-realm="OtherRealm"/>
</subsystem>
{code}
The server starts without error, however attempting to establish a connection fails.
{code}
./jboss-cli.sh -c --controller=remote+http://localhost:8080
Failed to connect to the controller: The controller is not available at localhost:8080: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+http://localhost:8080. The connection failed: WFLYPRT0053: Could not connect to remote+http://localhost:8080. The connection failed: Invalid response code 200
{code}
Although the CLI can not do anything over port 8080 it should be able to initiate a remoting connection i.e.
{code}
./jboss-cli.sh -c --controller=remote+http://localhost:8080
Failed to connect to the controller: The controller is not available at localhost:8080: org.jboss.remoting3.ServiceOpenException: Unknown service name management: Unknown service name management
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months