August 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBRULES-3445) DSL expander expands lines in /* */comment block

by Mario Fusco (JIRA)

Mario Fusco created JBRULES-3445: ------------------------------------ Summary: DSL expander expands lines in /* */comment block Key: JBRULES-3445 URL: https://issues.jboss.org/browse/JBRULES-3445 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Mario Fusco Assignee: Mario Fusco When you comment some code in dslr file, the expander still tries to expand it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

1 month, 3 weeks

3
10
0 / 0

[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

3
2
0 / 0

[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

2
1
0 / 0

[JBoss JIRA] (JBMETA-420) Add the EE 9 xsds

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/JBMETA-420?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on JBMETA-420: ----------------------------------------- https://github.com/bstansberry/metadata/commits/JBMETA-420 has the WIP on that. Once the specs are approved we can update with the final versions (which I'm guessing will not change.) > 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 > Priority: Major > > 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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[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: ------------------------------- Fix Version/s: 14.0.0.Beta1 (was: 13.0.0.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 for WildFly Core 13.0.0.Final (i.e., WildFly 21 Final). -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13817) CachedConnectionManager: don't push another meta object on stack if transaction has not changed

by Tomasz Adamski (Jira)

Tomasz Adamski created WFLY-13817: ------------------------------------- Summary: CachedConnectionManager: don't push another meta object on stack if transaction has not changed Key: WFLY-13817 URL: https://issues.redhat.com/browse/WFLY-13817 Project: WildFly Issue Type: Feature Request Components: JCA Reporter: Tomasz Adamski Assignee: Tomasz Adamski -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2020