April 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-4360) Support encrypted expression resolution using a CredentialStore

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-4360?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-4360: -------------------------------- Fix Version/s: 9.0.0.Beta3 (was: 9.0.0.Beta2) > Support encrypted expression resolution using a CredentialStore > --------------------------------------------------------------- > > Key: WFCORE-4360 > URL: https://issues.jboss.org/browse/WFCORE-4360 > Project: WildFly Core > Issue Type: Feature Request > Components: Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 9.0.0.Beta3 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-4361) Enhanced mapping of X509Certificate to the underlying identity

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-4361?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-4361: -------------------------------- Fix Version/s: 9.0.0.Beta3 (was: 9.0.0.Beta2) > Enhanced mapping of X509Certificate to the underlying identity > -------------------------------------------------------------- > > Key: WFCORE-4361 > URL: https://issues.jboss.org/browse/WFCORE-4361 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Darran Lofthouse > Priority: Major > Fix For: 9.0.0.Beta3 > > > Presently we support decoding the distinguished name however there are requests to use alternative such as the subject alternative name. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-4392) Migrate CapabilityServiceTarget to new MSC API

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-4392?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-4392: -------------------------------- Fix Version/s: 9.0.0.Beta3 (was: 9.0.0.Beta2) > Migrate CapabilityServiceTarget to new MSC API > ---------------------------------------------- > > Key: WFCORE-4392 > URL: https://issues.jboss.org/browse/WFCORE-4392 > Project: WildFly Core > Issue Type: Enhancement > Components: Server > Reporter: Richard Opalka > Assignee: Richard Opalka > Priority: Major > Fix For: 9.0.0.Beta3 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-4395) The single mapper validation added via WFCORE-2364 happens at Runtime, this should be a Model time check.

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-4395?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-4395: -------------------------------- Fix Version/s: 9.0.0.Beta3 (was: 9.0.0.Beta2) > The single mapper validation added via WFCORE-2364 happens at Runtime, this should be a Model time check. > --------------------------------------------------------------------------------------------------------- > > Key: WFCORE-4395 > URL: https://issues.jboss.org/browse/WFCORE-4395 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Darran Lofthouse > Priority: Major > Fix For: 9.0.0.Beta3 > > > If possible the mappers should be flagged as being mutually exclusive, however failing that the validation should happen during Stage.MODEL. > Presently this leads to an unsatisifed dependency: - > {noformat} > 14:21:59,055 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "elytron"), > ("security-domain" => "demon-domain") > ]) - failure description: { > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.security-realm.demo-realm"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => ["org.wildfly.security.security-domain.demon-domain.initial is missing [org.wildfly.security.security-realm.demo-realm]"] > } > {noformat} > Despite this error the underlying cause is not logged at any level. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (LOGMGR-246) Wildfly 16 incorrect working log zip rotator

by James Perkins (Jira)

[ https://issues.jboss.org/browse/LOGMGR-246?page=com.atlassian.jira.plugin... ] James Perkins moved WFWIP-157 to LOGMGR-246: -------------------------------------------- Project: JBoss Log Manager (was: WildFly WIP) Key: LOGMGR-246 (was: WFWIP-157) Component/s: core (was: Logging) > Wildfly 16 incorrect working log zip rotator > -------------------------------------------- > > Key: LOGMGR-246 > URL: https://issues.jboss.org/browse/LOGMGR-246 > Project: JBoss Log Manager > Issue Type: Bug > Components: core > Environment: Windows, > Oracle JDK 8 > Reporter: Игорь Дмитриев > Assignee: James Perkins > Priority: Major > > My logging profile configuration is: > 1) > {code:xml} > <periodic-size-rotating-file-handler name="FILE" rotate-on-boot="false" autoflush="true"> > <level name="ALL"/> > <file relative-to="jboss.server.log.dir" path="corp.log"/> > <rotate-size value="300k"/> > <max-backup-index value="10000"/> > <suffix value=".yyyy-MM-dd.zip"/> > <append value="true"/> > </periodic-size-rotating-file-handler> > {code} > File corp.log increase it size permanently, even after new corp.log.yyyy-MM-dd.N.zip file created. Due it, each .zip archive contain same corp.log with maximum current size. > 2) > {code:xml} > <periodic-size-rotating-file-handler name="FILE2" rotate-on-boot="true" autoflush="true"> > <level name="ALL"/> > <file relative-to="jboss.server.log.dir" path="corp.log"/> > <rotate-size value="300k"/> > <max-backup-index value="10000"/> > <suffix value=".yyyy-MM-dd.zip"/> > <append value="false"/> > </periodic-size-rotating-file-handler> > {code} > All work as expected, except each time corp.log reach 300k, appear pair .zip files with same content? -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBLOGGING-97) Object value passed to JBossLogManagerProvider.putMdc(String, Object) should be returned from getMdc(final String)

by James Perkins (Jira)

[ https://issues.jboss.org/browse/JBLOGGING-97?page=com.atlassian.jira.plug... ] James Perkins updated JBLOGGING-97: ----------------------------------- Priority: Major (was: Blocker) > Object value passed to JBossLogManagerProvider.putMdc(String, Object) should be returned from getMdc(final String) > ------------------------------------------------------------------------------------------------------------------ > > Key: JBLOGGING-97 > URL: https://issues.jboss.org/browse/JBLOGGING-97 > Project: JBoss Logging > Issue Type: Bug > Components: slf4j-jboss-logmanager > Affects Versions: 3.1.3.GA > Reporter: Scott Marlow > Assignee: James Perkins > Priority: Major > > Change JBossLogManagerProvider.putMdc(final String key, final Object value) to call MDC.put(key, value) instead of MDC.put(key, String.valueOf(value)) -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-3853) Ability to override existing rules in one KIA base with rules from another KIE base

by Vaclav Carnogursky (Jira)

[ https://issues.jboss.org/browse/DROOLS-3853?page=com.atlassian.jira.plugi... ] Vaclav Carnogursky updated DROOLS-3853: --------------------------------------- Summary: Ability to override existing rules in one KIA base with rules from another KIE base (was: Ability to override existing rules with rules) > Ability to override existing rules in one KIA base with rules from another KIE base > ----------------------------------------------------------------------------------- > > Key: DROOLS-3853 > URL: https://issues.jboss.org/browse/DROOLS-3853 > Project: Drools > Issue Type: Feature Request > Components: core engine > Reporter: Vaclav Carnogursky > Assignee: Mario Fusco > Priority: Minor > > I would be nice to have ability to override a rule defined in one KIE base with a rule defined in another KIE base. In Drools 5 it was possible to misuse a bug which didn't check for identical rules named to override them by using the same rule name with an appropriate drl file load order. > This has already been brought up here but I think an actual feature > request was never created https://groups.google.com/forum/#!searchin/drools-usage/overriding%7Csort... > *Use case* > Need to build a layered set of rules where extending layers may need to > override existing rules in the lower layers. I want to avoid rule duplication > (majority of rules would have to be duplicated) so prefer the layers. > *Usage* > Annotate a rule with {{@Override}}. > *Workaround* > Beyond the obvious rule packaging change to copy all rules instead of building layers I think it would be possible to do following: > To override a conflicting rule the resulting facts must be inserted logically > and rules annotated as {{@Defeasible}}. An overriding rule must have {{@Defeats("base rule")}}. > This approach might not work for all scenarios. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-3853) Ability to override existing rules with rules

by Vaclav Carnogursky (Jira)

Vaclav Carnogursky created DROOLS-3853: ------------------------------------------ Summary: Ability to override existing rules with rules Key: DROOLS-3853 URL: https://issues.jboss.org/browse/DROOLS-3853 Project: Drools Issue Type: Feature Request Components: core engine Reporter: Vaclav Carnogursky Assignee: Mario Fusco I would be nice to have ability to override a rule defined in one KIE base with a rule defined in another KIE base. In Drools 5 it was possible to misuse a bug which didn't check for identical rules named to override them by using the same rule name with an appropriate drl file load order. This has already been brought up here but I think an actual feature request was never created https://groups.google.com/forum/#!searchin/drools-usage/overriding%7Csort... *Use case* Need to build a layered set of rules where extending layers may need to override existing rules in the lower layers. I want to avoid rule duplication (majority of rules would have to be duplicated) so prefer the layers. *Usage* Annotate a rule with {{@Override}}. *Workaround* Beyond the obvious rule packaging change to copy all rules instead of building layers I think it would be possible to do following: To override a conflicting rule the resulting facts must be inserted logically and rules annotated as {{@Defeasible}}. An overriding rule must have {{@Defeats("base rule")}}. This approach might not work for all scenarios. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-4359) CommandFormatException: Invalid syntax... when using tab completion

by Jeff Mesnil (Jira)

[ https://issues.jboss.org/browse/WFCORE-4359?page=com.atlassian.jira.plugi... ] Jeff Mesnil reassigned WFCORE-4359: ----------------------------------- Assignee: Jean Francois Denise (was: James Perkins) > CommandFormatException: Invalid syntax... when using tab completion > ------------------------------------------------------------------- > > Key: WFCORE-4359 > URL: https://issues.jboss.org/browse/WFCORE-4359 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Embedded > Reporter: Miroslav Novak > Assignee: Jean Francois Denise > Priority: Major > > There is issue when tab completion is used in following malformed command: > {code} > [standalone@embedded /] /subsystem=modcluster/proxy=modcluster:add(advertise=false,proxies=mod_cluster-pro14:56:17,909 WARN [org.jboss.as.cli.impl.ValueTypeCompleter] (CLI Terminal Connection (uninterruptable)) Invalid syntax.: org.jboss.as.cli.CommandFormatException: Invalid syntax. > at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.ValueTypeCompleter$ValueTypeCallbackHandler.enteredState(ValueTypeCompleter.java:951) > at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.parsing.StateParser$ParsingContextImpl.enterState(StateParser.java:420) > at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.ValueTypeCompleter$PropertyListState$1.handle(ValueTypeCompleter.java:1248) > at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.parsing.StateParser$ParsingContextImpl.enterState(StateParser.java:421) > at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.ValueTypeCompleter$InitialValueState$1.handle(ValueTypeCompleter.java:1184) > at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.parsing.StateParser$ParsingContextImpl.parse(StateParser.java:261) > at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.parsing.StateParser.doParse(StateParser.java:150) > at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.parsing.StateParser.parseLine(StateParser.java:124) > at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.parsing.StateParser.parseLine(StateParser.java:117) > at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.parsing.StateParser.parseLine(StateParser.java:95) > at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.parsing.StateParser.parseLine(StateParser.java:75) > at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.parsing.StateParser.parse(StateParser.java:65) > at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.ValueTypeCompleter.parse(ValueTypeCompleter.java:401) > at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.ValueTypeCompleter.complete(ValueTypeCompleter.java:381) > at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.operation.OperationRequestCompleter.completeWithValueCompleter(OperationRequestCompleter.java:413) > at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.operation.OperationRequestCompleter.completeProperties(OperationRequestCompleter.java:672) > at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:709) > at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.operation.OperationRequestCompleter.complete(OperationRequestCompleter.java:90) > at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.CommandCompleter.complete(CommandCompleter.java:99) > at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.aesh.CLICompletionHandler.completeLegacyCommands(CLICompletionHandler.java:157) > at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.aesh.CLICompletionHandler.complete(CLICompletionHandler.java:133) > at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.CLICommandCompleter.doComplete(CLICommandCompleter.java:132) > at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.CLICommandCompleter.complete(CLICommandCompleter.java:54) > at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.aesh.CLICompletionHandler.complete(CLICompletionHandler.java:69) > at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.aesh.CLICompletionHandler.complete(CLICompletionHandler.java:45) > at org.aesh//org.aesh.readline.completion.CompletionHandler.createCompletionList(CompletionHandler.java:135) > at org.aesh//org.aesh.readline.completion.CompletionHandler.complete(CompletionHandler.java:103) > at org.aesh//org.aesh.readline.action.mappings.Complete.accept(Complete.java:62) > at org.aesh//org.aesh.readline.Readline$AeshInputProcessor.parse(Readline.java:246) > at org.aesh//org.aesh.readline.Readline$AeshInputProcessor.access$100(Readline.java:174) > at org.aesh//org.aesh.readline.Readline.readInput(Readline.java:95) > at org.aesh//org.aesh.readline.Readline.access$1000(Readline.java:57) > at org.aesh//org.aesh.readline.Readline$AeshInputProcessor.lambda$start$1(Readline.java:333) > at org.aesh//org.aesh.terminal.EventDecoder.accept(EventDecoder.java:118) > at org.aesh//org.aesh.terminal.EventDecoder.accept(EventDecoder.java:31) > at org.aesh//org.aesh.io.Decoder.write(Decoder.java:133) > at org.aesh//org.aesh.readline.tty.terminal.TerminalConnection.openBlocking(TerminalConnection.java:216) > at org.aesh//org.aesh.readline.tty.terminal.TerminalConnection.openBlocking(TerminalConnection.java:203) > at org.jboss.as.cli@7.0.1.Final-redhat-00001//org.jboss.as.cli.impl.ReadlineConsole$CLITerminalConnection.lambda$null$1(ReadlineConsole.java:178) > at java.base/java.lang.Thread.run(Thread.java:834) > > > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0155: 'listener' may not be null", > "rolled-back" => true > } > {code} > where attribute {{proxies}} should take a list. Exception should not be thrown. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-4399) ResourceEntry implementations to not implement equals/hashCode

by Paul Ferraro (Jira)

[ https://issues.jboss.org/browse/WFCORE-4399?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFCORE-4399: --------------------------------- Description: The default implementation of Resource.getChildren(String) returns a LinkedHashSet containing child entries. However, it seems none of the implementations of Resource.ResourceEntry implement equals() and hashCode(). This causes headaches for anyone creating a custom resource that wishes to augment the set returned by the default implementation of this method. (was: The default implementation of Resource.getChildren(String) returns a LinkedHashSet containing child entries. However, it seems none of the implementations of Resource.ResourceEntry implement equals() and hashCode(). This causes headaches for anyone creating a custom resource that wishes to augment the default implementation of this method.) > ResourceEntry implementations to not implement equals/hashCode > -------------------------------------------------------------- > > Key: WFCORE-4399 > URL: https://issues.jboss.org/browse/WFCORE-4399 > Project: WildFly Core > Issue Type: Bug > Components: Management > Affects Versions: 9.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > The default implementation of Resource.getChildren(String) returns a LinkedHashSet containing child entries. However, it seems none of the implementations of Resource.ResourceEntry implement equals() and hashCode(). This causes headaches for anyone creating a custom resource that wishes to augment the set returned by the default implementation of this method. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2019