June 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1614) Requesting CLI Equivalent of Remote Echo / set -x in non-interactive mode (from within scripts)

by Jean-Francois Denise (JIRA)

Jean-Francois Denise created WFCORE-1614: -------------------------------------------- Summary: Requesting CLI Equivalent of Remote Echo / set -x in non-interactive mode (from within scripts) Key: WFCORE-1614 URL: https://issues.jboss.org/browse/WFCORE-1614 Project: WildFly Core Issue Type: Feature Request Components: CLI Reporter: Jean-Francois Denise Assignee: Jean-Francois Denise We are proposing here to add a Cli option (command line option and an XML element) to make the CLI to echo the command and its options in non interactive mode. This will help to match a given command and its output. For example, the "ls -l" command output would be: [standalone@localhost:9990 /] ls -l ATTRIBUTE VALUE TYPE launch-type STANDALONE STRING management-major-version 5 INT management-micro-version 0 INT management-minor-version 0 INT ... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1606) Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1606?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-1606: ------------------------------------------ [~iweiss] I don't believe so. Adding a security-realm should not require a reload, and AIUI here the issue is with modifying an existing security-realm. > Server reload is needed for modified security-realm even if {allow-resource-service-restart=true} is used > --------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1606 > URL: https://issues.jboss.org/browse/WFCORE-1606 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.10.Final > Reporter: Ondrej Lukas > Assignee: Brian Stansberry > > When security-realm, which is set as http-interface security-realm in management-interfaces, is modified and operation used {allow-resource-service-restart=true} header then server is NOT in reload-required state but modified security realm does not work correctly until server is manually reloaded. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1556) Poor handling of 'required', 'nillable' and 'alternatives' in AttributeDefinition

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1556?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-1556: ---------------------------------------- Assignee: Brian Stansberry > Poor handling of 'required', 'nillable' and 'alternatives' in AttributeDefinition > --------------------------------------------------------------------------------- > > Key: WFCORE-1556 > URL: https://issues.jboss.org/browse/WFCORE-1556 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > The handling of the notions of 'require'd and 'nillable' don't comply with the specs in https://docs.jboss.org/author/display/WFLY10/Description+of+the+Managemen..., particularly the "Description of an Attribute" part, where the 'required' and 'alternatives' fields are well described, with their relationship spelled out, while 'nillable' doesn't appear at all. Then in "Description of an Operation Parameter or Return Value" nillable is specified, although I think those descriptions could be tightened up in general. > The read-resource-description output for an attribute doesn't show "required" at all. > After a fair bit of thinking, I've finally recalled why the two separate notions of "required" and "nillable" exist in the first place. > The "required" and "alternatives" pieces go together. Is something required? And then if it is required, an alternative satisfies. So you can have two attributes/params, both required, but they are alternatives so one is defined and the other is not. And this is an ok thing. > And then 'nillable' comes in to help clients understand in a simple way whether they need to account for the possibility an undefined value. Basically: > nillable = !required || alternatives != null > Right now, nillable is implemented as > nillable = !required > There are a number of problems I see with AttributeDefinition: > 1) We don't output the 'required' metadata unless it's an operation param being described. This is contrary to spec. However we we shouldn't fix this unless we can have meaningful values for 'required', ones where the value can be true but the attribute/param can still have an undefined value, due to an alternative being present. If we can't fix that, there's no point outputting required as it's just redundant with what we output for 'nillable'. > 2) We do output the 'nillable' metadata, even for attribute descriptions, where it isn't in the spec. But in this case I think we change the spec, as dropping nillable would be an incompatible change. > 3) We don't properly validate the "required but has alternatives case." This can't be validated solely with ParameterValidator impls as those only see a single attribute value and don't have contextual information about other attributes/params. To get around this limitation, devs are saying that attributes with alternatives "allowNull" which is equivalent to saying they are not required. But they are required! So I think a fix for this will require AttributeDefinition itself to validate the overall resource model or operation object, and skip calling the ParameterValidator if the attribute/param is undefined and an alternative is defined. > 4) AttributeDefinition and AbstractAttributeDefinitionBuilder unfortunately have a getter/setter/constructor param for property "allowNull" instead of a property named "required". This is unfortunate because "allowNull" intuitively maps to "nillable", but "required" is a much more useful thing to set. The value of "nillable" can be derived from a "required" setting and an "alternatives" setting, but the value of required cannot be so derived. > I think a fix for this would probably start from 4), deprecating setAllowNull, adding get/setRequired and changing the meaning of the AD(Builder) constructor param to "required". The effect of this would be that all current code setting "allowNull" would now be setting a new "required" field. This should be a non-breaking change as in current code that's the effect anyway. > Next would be to fix 3), by changing how AD validates. > Next would be to change the metadata we output, such that "required" is always present and the "nillable" value is !required || alternatives != null. And change the spec accordingly. > Last, in a separate task, would be to find attributes that were configuring "allowNull = true" solely to allow validation to pass when alternatives are present, and fix them to say "required=false". -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6755) mod_cluster uses the same password for accessing sslKeyStore and sslTrustStore

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6755?page=com.atlassian.jira.plugin.... ] Radoslav Husar commented on WFLY-6755: -------------------------------------- Wow, 2012, blast from the past! > mod_cluster uses the same password for accessing sslKeyStore and sslTrustStore > ------------------------------------------------------------------------------ > > Key: WFLY-6755 > URL: https://issues.jboss.org/browse/WFLY-6755 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: JBoss AS7 7.1.1.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 11.0.0.Alpha1 > > > Problem reported by Duncan Doyle. > The passwords shouldn't be forced to be the same, in AS5 they could have been different. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-581) Ensure that OTPSaslServer informs the callback handler that it needs exclusive access to the backing identity

by Farah Juma (JIRA)

Farah Juma created ELY-581: ------------------------------ Summary: Ensure that OTPSaslServer informs the callback handler that it needs exclusive access to the backing identity Key: ELY-581 URL: https://issues.jboss.org/browse/ELY-581 Project: WildFly Elytron Issue Type: Feature Request Components: SASL Reporter: Farah Juma Assignee: Farah Juma Exclusive access is needed since the stored password is updated after a guess has been verified. The OTP multiple simultaneous authentication sessions test should also be unignored. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-311) Odd rules execution for expired events

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-311?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-311. -------------------------------- Fix Version/s: 7.0.0.Beta1 Resolution: Done Fixed by https://github.com/droolsjbpm/drools/commit/454dfeb1d > Odd rules execution for expired events > -------------------------------------- > > Key: DROOLS-311 > URL: https://issues.jboss.org/browse/DROOLS-311 > Project: Drools > Issue Type: Bug > Affects Versions: 5.5.0.Final, 6.0.0.CR5 > Environment: Windows Vista 64, JRE6 (x86) > Reporter: Karol Sobczak > Assignee: Mario Fusco > Priority: Critical > Fix For: 7.0.0.Beta1 > > Attachments: expiredrules.zip > > > I have declared two types: > declare Motion > @role( event ) > @expires( 5s ) > @timestamp( eventTime ) > eventTime : long > end > declare Recording > end > and following rules: > rule "StartRecording" > when > Motion() > not Recording() > then > insert(new Recording()) > end > the problem is that when I put a lot of "Motions", sleep (so "Motions" become expired) and then do fireAllRules(), I got "StartRecording" executed multiple times (and not only once), event though "Recording" is inserted every time. > Another issue would be when instead of "StartRecording" rule I would have "StopRecording" rule: > rule "StopRecording" > when > $m : Motion() > $r : Recording() > then > System.err.println("Recording: " + $r); > retract($r); > end > then when there is a "Recording" fact inserted and multiple expired "Motions", the rule would be executed multiple times (when "Motions" expire) and $r would be null after the first "StopRecording" rule execution. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6755) mod_cluster uses the same password for accessing sslKeyStore and sslTrustStore

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6755?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-6755: --------------------------------- Assignee: Radoslav Husar (was: Tomaz Cerar) > mod_cluster uses the same password for accessing sslKeyStore and sslTrustStore > ------------------------------------------------------------------------------ > > Key: WFLY-6755 > URL: https://issues.jboss.org/browse/WFLY-6755 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: JBoss AS7 7.1.1.Final > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 11.0.0.Alpha1 > > > Problem reported by Duncan Doyle. > The passwords shouldn't be forced to be the same, in AS5 they could have been different. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1613) Merge Parsers and Completers

by Jean-Francois Denise (JIRA)

Jean-Francois Denise created WFCORE-1613: -------------------------------------------- Summary: Merge Parsers and Completers Key: WFCORE-1613 URL: https://issues.jboss.org/browse/WFCORE-1613 Project: WildFly Core Issue Type: Feature Request Components: CLI Reporter: Jean-Francois Denise Assignee: Alexey Loubyansky Today we have multiple parsers and completers for the same kind of syntax. It implies that any evolution done at the syntax level, needs to be duplicated in multiple places. We would have a big maintainability gain if they were merged them all together. That would also be a big effort. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6755) mod_cluster uses the same password for accessing sslKeyStore and sslTrustStore

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6755?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-6755: ------------------------------ Comment: was deleted (was: merged in upstream) > mod_cluster uses the same password for accessing sslKeyStore and sslTrustStore > ------------------------------------------------------------------------------ > > Key: WFLY-6755 > URL: https://issues.jboss.org/browse/WFLY-6755 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: JBoss AS7 7.1.1.Final > Reporter: Radoslav Husar > Assignee: Tomaz Cerar > Fix For: 11.0.0.Alpha1 > > > Problem reported by Duncan Doyle. > The passwords shouldn't be forced to be the same, in AS5 they could have been different. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6755) mod_cluster uses the same password for accessing sslKeyStore and sslTrustStore

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-6755?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-6755: ------------------------------ Affects Version/s: JBoss AS7 7.1.1.Final > mod_cluster uses the same password for accessing sslKeyStore and sslTrustStore > ------------------------------------------------------------------------------ > > Key: WFLY-6755 > URL: https://issues.jboss.org/browse/WFLY-6755 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: JBoss AS7 7.1.1.Final > Reporter: Radoslav Husar > Assignee: Tomaz Cerar > Fix For: 11.0.0.Alpha1 > > > Problem reported by Duncan Doyle. > The passwords shouldn't be forced to be the same, in AS5 they could have been different. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

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 June 2016