March 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1483) Support default expiration for events

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1483?page=com.atlassian.jira.plugi... ] Mario Fusco commented on DROOLS-1483: ------------------------------------- Documented by https://github.com/kiegroup/kie-docs/commit/89fddc9d16a3a0f2183a05200b6cd... > Support default expiration for events > ------------------------------------- > > Key: DROOLS-1483 > URL: https://issues.jboss.org/browse/DROOLS-1483 > Project: Drools > Issue Type: Feature Request > Environment: Drools >= 6.5 in STREAM mode > Reporter: Jochen Welle > Assignee: Mario Fusco > Fix For: 7.0.0.Beta8 > > > We would like to be able to specify a "default" expiration offset for events. The default expiration offset should be used if the inferred expiration offset is infinite. > Benefits would be: > * Expiration is guaranteed: either after the specified offset or after the inferred offset. > * Rule authors are not required to include a temporal constraint in all rules. > * Event classes can be designed if the rules are not yet known. > The current behavior of @Expires (fixed expiration offset) could be the default and an optional attribute could be added to enable the new behavior. > {code:java} > @Role(Type.EVENT) > @Expires(value = "10m") // fixed expiration offset or > @Expires(value = "10m", type="fixed") // fixed expiration offset > public class MyEvent { > ... > {code} > New behavior: > {code:java} > @Role(Type.EVENT) > @Expires(value = "10m", type="default") // new feature > public class MyEvent { > ... > {code} > The goal is to have automatic event lifetime/memory management at all times. At the moment either a fixed expiration offset has to be set, which is only possible after analysing all rules and determining the expiration offset manually. Or every rule must include some temporal constraint, which is sometimes a tough burden on the rule author. > This feature is related to: > * [link DROOLS-1227|https://issues.jboss.org/browse/DROOLS-1227] I think the new behavior would touch the same code as the fix implemented there by [~mfusco] > * [link DROOLS-586|https://issues.jboss.org/browse/DROOLS-586] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8437) [GSS](7.0.z) Support socket-binding attribute "client-mapping" in messaging subsystem

by Jörg Bäsner (JIRA)

Jörg Bäsner created WFLY-8437: --------------------------------- Summary: [GSS](7.0.z) Support socket-binding attribute "client-mapping" in messaging subsystem Key: WFLY-8437 URL: https://issues.jboss.org/browse/WFLY-8437 Project: WildFly Issue Type: Bug Components: JMS Affects Versions: 10.1.0.Final Reporter: Jörg Bäsner Assignee: Jeff Mesnil The messaging subsystem doesn't take into account the "client-mapping" attribute of the <socket-binding> when creating a <http-connector>. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2283) Make 'required' attributes clearer when using tab completion within CLI

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2283?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-2283: ------------------------------------------ Please get input from the UX team on this. (See the JBEAP component list to find the name of the current lead for "User Experience".) > Make 'required' attributes clearer when using tab completion within CLI > ----------------------------------------------------------------------- > > Key: WFCORE-2283 > URL: https://issues.jboss.org/browse/WFCORE-2283 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Darran Lofthouse > Assignee: Jean-Francois Denise > > The following is some example output pressing tab to reveal the parameters of 'add': - > {{[standalone@localhost:9990 /] ./subsystem=elytron/key-store=localhost:add( > ! alias-filter credential-reference path provider-name providers relative-to required type }} > From this is it not clear which are actually required. > Suggestions to make it clearer: - > * Show required / optional in different colours. > * Add something to the required attributes e.g. '*' > * Add something to the optional requirements e.g. {optional_arg} > Maybe this can go one step further and take into account arguments already added by the user, especially where attributes require another attribute or are an alternative. > Once an attribute is identified as being an alternative to another attribute maybe it should be omitted altogether from the list or maybe also have something adding to it !attr_name. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2283) Make 'required' attributes clearer when using tab completion within CLI

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2283?page=com.atlassian.jira.plugi... ] Jean-Francois Denise commented on WFCORE-2283: ---------------------------------------------- I have done some experimentation to better expose mandatory arguments (should also apply to complex object properties). An efficient way would be to only expose required attributes first then, once all required attributes have been provided, propose optional ones. This has the benefit to: 1) Better drive users to fill an operation by reducing the amount of exposed arguments to the right set. 2) Reduce the risk to forget required arguments. 3) Comply with existing CLI user experience. High level commands have already this kind of logic. "Required" options are exposed first, then optional options are exposed incrementally. 4) In case there is only one required argument, it will be automatically inlined. Then optionals are proposed. As an example, today: list-add(<TAB> filter handlers name With such approach: list-add(<TAB> list-add(name= list-add(name=xxx,<TAB> filter handlers > Make 'required' attributes clearer when using tab completion within CLI > ----------------------------------------------------------------------- > > Key: WFCORE-2283 > URL: https://issues.jboss.org/browse/WFCORE-2283 > Project: WildFly Core > Issue Type: Feature Request > Components: CLI > Reporter: Darran Lofthouse > Assignee: Jean-Francois Denise > > The following is some example output pressing tab to reveal the parameters of 'add': - > {{[standalone@localhost:9990 /] ./subsystem=elytron/key-store=localhost:add( > ! alias-filter credential-reference path provider-name providers relative-to required type }} > From this is it not clear which are actually required. > Suggestions to make it clearer: - > * Show required / optional in different colours. > * Add something to the required attributes e.g. '*' > * Add something to the optional requirements e.g. {optional_arg} > Maybe this can go one step further and take into account arguments already added by the user, especially where attributes require another attribute or are an alternative. > Once an attribute is identified as being an alternative to another attribute maybe it should be omitted altogether from the list or maybe also have something adding to it !attr_name. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8428) :read-resource(include-runtime) fails for /subsystem=undertow/application-security-domain=*

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-8428?page=com.atlassian.jira.plugin.... ] Tomaz Cerar commented on WFLY-8428: ----------------------------------- This is already fixed in my "capabilites" branch. > :read-resource(include-runtime) fails for /subsystem=undertow/application-security-domain=* > ------------------------------------------------------------------------------------------- > > Key: WFLY-8428 > URL: https://issues.jboss.org/browse/WFLY-8428 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Harald Pehl > Assignee: Tomaz Cerar > > The {{:read-resource(include-runtime=true)}} operation is used by the console as part of the generic model browser. However it fails for {{/subsystem=undertow/application-security-domain=foo}}: > {code} > [standalone@localhost:9990 /] /subsystem=undertow/application-security-domain=foo:read-resource(include-runtime=true) > { > "outcome" => "failed", > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2565) Incorrect permission class-name should throw exception at runtime

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2565?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet commented on WFCORE-2565: ------------------------------------------- After discussing with [~dlofthouse] this should log a warning instead of throwing an error. > Incorrect permission class-name should throw exception at runtime > ----------------------------------------------------------------- > > Key: WFCORE-2565 > URL: https://issues.jboss.org/browse/WFCORE-2565 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta9 > Reporter: Ondrej Lukas > Assignee: ehsavoie Hugonnet > > In case when some permission mapper (tried with constant-permission-mapper and simple-permission-mapper) includes permission with non-existent class-name then it seems that no exception is thrown during runtime. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8436) [GSS](7.0.z) Support socket-binding attribute "client-mapping" in messaging subsystem

by Jörg Bäsner (JIRA)

Jörg Bäsner created WFLY-8436: --------------------------------- Summary: [GSS](7.0.z) Support socket-binding attribute "client-mapping" in messaging subsystem Key: WFLY-8436 URL: https://issues.jboss.org/browse/WFLY-8436 Project: WildFly Issue Type: Bug Components: JMS Affects Versions: 10.1.0.Final Reporter: Jörg Bäsner Assignee: Jeff Mesnil The messaging subsystem doesn't take into account the "client-mapping" attribute of the <socket-binding> when creating a <http-connector>. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8428) :read-resource(include-runtime) fails for /subsystem=undertow/application-security-domain=*

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-8428?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-8428: --------------------------------- Assignee: Tomaz Cerar (was: Stuart Douglas) > :read-resource(include-runtime) fails for /subsystem=undertow/application-security-domain=* > ------------------------------------------------------------------------------------------- > > Key: WFLY-8428 > URL: https://issues.jboss.org/browse/WFLY-8428 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Reporter: Harald Pehl > Assignee: Tomaz Cerar > > The {{:read-resource(include-runtime=true)}} operation is used by the console as part of the generic model browser. However it fails for {{/subsystem=undertow/application-security-domain=foo}}: > {code} > [standalone@localhost:9990 /] /subsystem=undertow/application-security-domain=foo:read-resource(include-runtime=true) > { > "outcome" => "failed", > "rolled-back" => true > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-74) 2nd baselines

by viet nguyen (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-74?page=com.atlassian.jira.plu... ] viet nguyen commented on HAWKULARQE-74: --------------------------------------- I hit a hard limit at 239 pods on the node !239pods.png|thumbnail! {code} [root@b20 ~]# free -g total used free shared buff/cache available Mem: 62 16 32 3 13 41 Swap: 0 0 0 {code} > 2nd baselines > ------------- > > Key: HAWKULARQE-74 > URL: https://issues.jboss.org/browse/HAWKULARQE-74 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > Attachments: 239pods.png > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-7412) A security-domain can only load login-modules from a single JBoss module

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-7412?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-7412: ----------------------------------------------- Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1280512|https://bugzilla.redhat.com/show_bug.cgi?id=1280512] from VERIFIED to CLOSED > A security-domain can only load login-modules from a single JBoss module > -------------------------------------------------------------------------- > > Key: WFLY-7412 > URL: https://issues.jboss.org/browse/WFLY-7412 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Derek Horton > Assignee: Stefan Guilhen > Fix For: 11.0.0.Alpha1 > > > A security-domain can only load login-modules from a single JBoss module. Even though the security-domain configuration will allow each login module defined within a single security-domain to have a "module" attribute, the only module that is used to load the login-modules is the last "module" attribute that the parsing system locates. > For example, with the following configuration, it looks like "org.jboss.example.CustomLoginModule" should be loaded from the "org.jboss.example" jboss-module and "org.jboss.example.CustomBaseCertLoginModule" should be loaded from the "org.jboss.another.example" jboss-module: > <security-domain name="jmx-console" cache-type="default"> > <authentication> > <login-module code="org.jboss.example.CustomLoginModule" module="org.jboss.example" flag="required"> > <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/> > <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/> > </login-module> > <login-module code="org.jboss.example.CustomBaseCertLoginModule" module="org.jboss.another.example" flag="required"> > <module-option name="usersProperties" value="${jboss.server.config.dir}/users.properties"/> > <module-option name="rolesProperties" value="${jboss.server.config.dir}/roles.properties"/> > </login-module> > </authentication> > </security-domain> > Unfortunately, it does not work like this. Only the "org.jboss.another.example" jboss-module is used to load the custom login modules. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 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 March 2017