[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)
2 months, 1 week
[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)
10 months
[JBoss JIRA] (JBMETA-420) Add the EE 9 xsds
by Brian Stansberry (Jira)
Brian Stansberry created JBMETA-420:
---------------------------------------
Summary: Add the EE 9 xsds
Key: JBMETA-420
URL: https://issues.redhat.com/browse/JBMETA-420
Project: JBoss Metadata
Issue Type: Enhancement
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Follow up on JBMETA-419 by adding the relevant EE 9 xsd documents.
They're not final yet so I figure it's better to add them separately from the JBMETA-419 parsing enhancement, which isn't particularly reliant on the exact schema files.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 9 months
[JBoss JIRA] (WFCORE-5103) Adding non existent and not required keystore fails
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFCORE-5103?page=com.atlassian.jira.plug... ]
Farah Juma commented on WFCORE-5103:
------------------------------------
[~jdenise] This looks like it might just be a configuration issue. If you specify the {{type}} attribute, the operation will succeed:
{{/subsystem=elytron/key-store=keystore:add(path="/etc/foo/keystore.jks", credential-reference={clear-text=${keystore.password}}, type=JKS)}}
[~mmazanek] From your work on WFCORE-4058, do you remember if this behaviour is intentional? i.e., Is it expected that if the file that backs a {{key-store}} doesn't exist then the {{type}} attribute must be specified even if the file is not required to exist at the time the {{KeyStore}} service starts?
> Adding non existent and not required keystore fails
> ---------------------------------------------------
>
> Key: WFCORE-5103
> URL: https://issues.redhat.com/browse/WFCORE-5103
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Jean Francois Denise
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 13.0.0.Beta6
>
>
> We are in a case where a CLI script is executed in an embedded server. They keystore added doesn't exist locally when the script is run. The operation is:
> /subsystem=elytron/key-store=keystore:add(required=false, path="/etc/foo/keystore.jks", credential-reference=\{clear-text=${keystore.password}})
> Error:
> "failure-description" => {"WFLYCTL0080: Failed services" => {"org.wildfly.security.key-store.keystore" => "WFLYELY00004: Unable to start the service.
> [ERROR] Caused by: org.jboss.msc.service.StartException in anonymous service: WFLYELY00022: KeyStore file '/etc/wf-secrets/keystore.jks' does not exist and required."}},
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 9 months
[JBoss JIRA] (WFLY-13808) Make HTTP server available during deployment when starting up
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13808?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFLY-13808:
-----------------------------------------
Thanks, [~lojze.blatnik].
> Make HTTP server available during deployment when starting up
> -------------------------------------------------------------
>
> Key: WFLY-13808
> URL: https://issues.redhat.com/browse/WFLY-13808
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 20.0.1.Final
> Reporter: Alojzij Blatnik
> Assignee: Brian Stansberry
> Priority: Major
> Attachments: diff.patch
>
>
> HTTP server isn't available during deployment when Wildfly is starting up. That behavior is a feature, so that HTTP server is not serving until application isn't fully deployed. That behavior causes us trouble, because we have EAR with multiple services in WARs which communicate with each other during deployment phase.
> That was introduced in Wildfly 11 and is still present in 20.0.1. I think, that this wasn't intended to behave by default (see start suspended or start normal) [https://github.com/wildfly/wildfly/blob/master/docs/src/main/asciidoc/_ad... settings actually make no difference - it starts suspended in both cases (only admin-only is honored correctly).
> I was poking around the source code (see diff.patch) and made small changes in wildfly-core to make it work, but AbstractControllerService would need to be if-elsed by desired start mode.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 9 months
[JBoss JIRA] (WFCORE-5013) Remove the wildfly-openssl i386 bindings
by Farah Juma (Jira)
[ https://issues.redhat.com/browse/WFCORE-5013?page=com.atlassian.jira.plug... ]
Farah Juma updated WFCORE-5013:
-------------------------------
Description: We should remove the wildfly-openssl-linux-i386 and the wildfly-openssl-windows-i386 bindings. (was: We should remove the wildfly-openssl-linux-i386 and the wildfly-openssl-windows-i386 bindings for WildFly Core 13.0.0.Final (i.e., WildFly 21 Final).)
> Remove the wildfly-openssl i386 bindings
> ----------------------------------------
>
> Key: WFCORE-5013
> URL: https://issues.redhat.com/browse/WFCORE-5013
> Project: WildFly Core
> Issue Type: Task
> Components: Security
> Reporter: Farah Juma
> Assignee: Farah Juma
> Priority: Blocker
> Fix For: 14.0.0.Beta1
>
>
> We should remove the wildfly-openssl-linux-i386 and the wildfly-openssl-windows-i386 bindings.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 9 months