August 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFWIP-90) [Artemis 2.x upgrade] Undelivered messages in remote jca topology after restart

by Miroslav Novak (JIRA)

[ https://issues.jboss.org/browse/WFWIP-90?page=com.atlassian.jira.plugin.s... ] Miroslav Novak commented on WFWIP-90: ------------------------------------- [~clebert.suconic] Maybe you can try to run it from messaging lab. There latencies to database are small. > [Artemis 2.x upgrade] Undelivered messages in remote jca topology after restart > ------------------------------------------------------------------------------- > > Key: WFWIP-90 > URL: https://issues.jboss.org/browse/WFWIP-90 > Project: WildFly WIP > Issue Type: Bug > Components: Artemis > Reporter: Miroslav Novak > Assignee: Martyn Taylor > Priority: Blocker > > There are undelivered messages in scenario with where servers in remote JCA topology are restarted. There are undelivered message after test. > Test scenario: > * Start 2 server in Artemis cluster > * Start 2 servers with MDB connected to Artemis cluster > ** MDB resends messages from InQueue to OutQueue from/to remote cluster > * Send messages to InQueue > * Restart all server (one by one) > * Consumes messages from OutQueue > Results: > After the test there are missing messages in OutQueue. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1644) Review per-request object allocation for HTTP authentication

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-1644: ------------------------------------- Summary: Review per-request object allocation for HTTP authentication Key: ELY-1644 URL: https://issues.jboss.org/browse/ELY-1644 Project: WildFly Elytron Issue Type: Task Components: HTTP Reporter: Darran Lofthouse Assignee: Darran Lofthouse -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1645) Review per-request object allocation for HTTP authentication

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-1645: ------------------------------------- Summary: Review per-request object allocation for HTTP authentication Key: ELY-1645 URL: https://issues.jboss.org/browse/ELY-1645 Project: WildFly Elytron Issue Type: Task Components: HTTP Reporter: Darran Lofthouse Assignee: Darran Lofthouse -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELYWEB-11) Review per-request object allocation for HTTP authentication

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELYWEB-11?page=com.atlassian.jira.plugin.... ] Darran Lofthouse moved ELY-1645 to ELYWEB-11: --------------------------------------------- Project: Elytron Web (was: WildFly Elytron) Key: ELYWEB-11 (was: ELY-1645) Component/s: Undertow Undertow Servlet (was: HTTP) > Review per-request object allocation for HTTP authentication > ------------------------------------------------------------ > > Key: ELYWEB-11 > URL: https://issues.jboss.org/browse/ELYWEB-11 > Project: Elytron Web > Issue Type: Task > Components: Undertow, Undertow Servlet > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4042) "filter-spec" attribute of socket-handler contains non existent "filter" alternative

by Claudio Miranda (JIRA)

[ https://issues.jboss.org/browse/WFCORE-4042?page=com.atlassian.jira.plugi... ] Claudio Miranda updated WFCORE-4042: ------------------------------------ Description: The socket-handler resource, contains an attribute "filter-spec" and the "alternatives" contains a non existent "filter" attribute {code} "filter-spec" => { "type" => STRING, "description" => "A filter expression value to define a filter. Example for a filter that does not match a pattern: not(match(\"JBAS.*\"))", "expressions-allowed" => true, "required" => false, "nillable" => true, "alternatives" => ["filter"], "min-length" => 1L, "max-length" => 2147483647L, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "no-services" }, {code} In HAL we use the metadata to validate user input and in this case, we undefine the alternative attribute the user didn't set, "filter", resulting in an error because the attribute doesn't exist. I did a workaround, but would be interesting to fix the alternatives metadata. was: The socket-handler resource, contains an attribute "filter-spec" and the "alternatives" contains a non existent "filter" attribute {code} "filter-spec" => { "type" => STRING, "description" => "A filter expression value to define a filter. Example for a filter that does not match a pattern: not(match(\"JBAS.*\"))", "expressions-allowed" => true, "required" => false, "nillable" => true, "alternatives" => ["filter"], "min-length" => 1L, "max-length" => 2147483647L, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "no-services" }, {code} I see there is the same problem for periodic-rotating-file-handler, but I didn't check other handlers. In HAL we use the metadata to validate user input and in this case, we undefine the alternative attribute the user didn't set, "filter", resulting in an error because the attribute doesn't exist. I did a workaround, but would be interesting to fix the alternatives metadata. > "filter-spec" attribute of socket-handler contains non existent "filter" alternative > ------------------------------------------------------------------------------------ > > Key: WFCORE-4042 > URL: https://issues.jboss.org/browse/WFCORE-4042 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: Claudio Miranda > Assignee: James Perkins > > The socket-handler resource, contains an attribute "filter-spec" and the "alternatives" contains a non existent "filter" attribute > {code} > "filter-spec" => { > "type" => STRING, > "description" => "A filter expression value to define a filter. Example for a filter that does not match a pattern: not(match(\"JBAS.*\"))", > "expressions-allowed" => true, > "required" => false, > "nillable" => true, > "alternatives" => ["filter"], > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "no-services" > }, > {code} > In HAL we use the metadata to validate user input and in this case, we undefine the alternative attribute the user didn't set, "filter", resulting in an error because the attribute doesn't exist. I did a workaround, but would be interesting to fix the alternatives metadata. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4041) ManagementRealm does now show plain-text attribute in default read-resource output

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-4041?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-4041: ------------------------------------- Component/s: Management [~jmesnil] FYI. This isn't really anything specific to the elytron subsystem. It's a general problem with how ReadAttributeHandler is dealing with attributes that use ObjectTypeAttributeDefinition. This is not at all a simple fix. It likely requires a rethink of how RAH extracts values from the model, and perhaps an addition to the AttributeDefinition API to allow RAH to delegate that to the AD. BTW, the request in the description is not expected to show the 'plain-text' attribute as the config doesn't explicitly define it. To see undefined attribute that have defaults, the request would need to be: {code} /subsystem=elytron/properties-realm=ManagementRealm:read-resource(include-defaults=true) {code} That doesn't work either though, which is the bug. :) This illustrates that things work fine if the 'plain-text' is defined: {code} [standalone@embedded /] /subsystem=elytron/properties-realm=ManagementRealm:write-attribute(name=users-properties.plain-text,value=false) { "outcome" => "success", "response-headers" => { "operation-requires-reload" => true, "process-state" => "reload-required" } } [standalone@embedded /] /subsystem=elytron/properties-realm=ManagementRealm:read-resource() { "outcome" => "success", "result" => { "groups-attribute" => "groups", "groups-properties" => { "path" => "mgmt-groups.properties", "relative-to" => "jboss.server.config.dir" }, "users-properties" => { "path" => "mgmt-users.properties", "relative-to" => "jboss.server.config.dir", "digest-realm-name" => "ManagementRealm", "plain-text" => false } }, "response-headers" => {"process-state" => "reload-required"} } {code} > ManagementRealm does now show plain-text attribute in default read-resource output > ---------------------------------------------------------------------------------- > > Key: WFCORE-4041 > URL: https://issues.jboss.org/browse/WFCORE-4041 > Project: WildFly Core > Issue Type: Bug > Components: Management, Security > Reporter: Justin Cook > Assignee: Justin Cook > > Currently running /subsystem=elytron/properties-realm=ManagementRealm:read-resource() results in the output: > {code} > { > "outcome" => "success", > "result" => { > "groups-attribute" => "groups", > "groups-properties" => { > "path" => "mgmt-groups.properties", > "relative-to" => "jboss.server.config.dir" > }, > "users-properties" => { > "path" => "mgmt-users.properties", > "relative-to" => "jboss.server.config.dir", > "digest-realm-name" => "ManagementRealm" > } > } > } > {code} > which is missing the plain-text attribute -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2795) [DMN Designer] Data-types: Grid: DecisionTable

by Michael Anstis (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2795?page=com.atlassian.jira.plugi... ] Michael Anstis updated DROOLS-2795: ----------------------------------- Description: *_Decision Table_* - (x) Grid header _could_ show Output Data Type - (/) Editing Output Data Type is possible via Properties panel - (x) Hide Output Data Type in header when there are multiple {{OutputClause}} columns - (/) {{InputClause}} columns header should show Input Data Type - (/) {{InputClause}} columns should support changing the Input Data Type - (x) {{OutputClause}} columns header should show Output Data Type - (x) {{OutputClause}} columns should support changing the Output Data Type was: *_Decision Table_* - (x) Grid header _could_ show Output Data Type - (/) Editing Output Data Type is possible via Properties panel - (x) Hide Output Data Type in header when there are multiple {{OutputClause}} columns - (x) {{InputClause}} columns header should show Input Data Type - (x) {{InputClause}} columns should support changing the Input Data Type - (x) {{OutputClause}} columns header should show Output Data Type - (x) {{OutputClause}} columns should support changing the Output Data Type > [DMN Designer] Data-types: Grid: DecisionTable > ---------------------------------------------- > > Key: DROOLS-2795 > URL: https://issues.jboss.org/browse/DROOLS-2795 > Project: Drools > Issue Type: Feature Request > Components: DMN Editor > Reporter: Michael Anstis > Assignee: Michael Anstis > > *_Decision Table_* > - (x) Grid header _could_ show Output Data Type > - (/) Editing Output Data Type is possible via Properties panel > - (x) Hide Output Data Type in header when there are multiple {{OutputClause}} columns > - (/) {{InputClause}} columns header should show Input Data Type > - (/) {{InputClause}} columns should support changing the Input Data Type > - (x) {{OutputClause}} columns header should show Output Data Type > - (x) {{OutputClause}} columns should support changing the Output Data Type -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4042) "filter-spec" attribute of socket-handler contains non existent "filter" alternative

by Claudio Miranda (JIRA)

Claudio Miranda created WFCORE-4042: --------------------------------------- Summary: "filter-spec" attribute of socket-handler contains non existent "filter" alternative Key: WFCORE-4042 URL: https://issues.jboss.org/browse/WFCORE-4042 Project: WildFly Core Issue Type: Bug Components: Logging Reporter: Claudio Miranda Assignee: James Perkins The socket-handler resource, contains an attribute "filter-spec" and the "alternatives" contains a non existent "filter" attribute {code} "filter-spec" => { "type" => STRING, "description" => "A filter expression value to define a filter. Example for a filter that does not match a pattern: not(match(\"JBAS.*\"))", "expressions-allowed" => true, "required" => false, "nillable" => true, "alternatives" => ["filter"], "min-length" => 1L, "max-length" => 2147483647L, "access-type" => "read-write", "storage" => "configuration", "restart-required" => "no-services" }, {code} I see there is the same problem for periodic-rotating-file-handler, but I didn't check other handlers. In HAL we use the metadata to validate user input and in this case, we undefine the alternative attribute the user didn't set, "filter", resulting in an error because the attribute doesn't exist. I did a workaround, but would be interesting to fix the alternatives metadata. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4041) ManagementRealm does now show plain-text attribute in default read-resource output

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-4041?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-4041: ------------------------------------- Description: Currently running /subsystem=elytron/properties-realm=ManagementRealm:read-resource() results in the output: {code} { "outcome" => "success", "result" => { "groups-attribute" => "groups", "groups-properties" => { "path" => "mgmt-groups.properties", "relative-to" => "jboss.server.config.dir" }, "users-properties" => { "path" => "mgmt-users.properties", "relative-to" => "jboss.server.config.dir", "digest-realm-name" => "ManagementRealm" } } } {code} which is missing the plain-text attribute was: Currently running /subsystem=elytron/properties-realm=ManagementRealm:read-resource() results in the output: { "outcome" => "success", "result" => { "groups-attribute" => "groups", "groups-properties" => { "path" => "mgmt-groups.properties", "relative-to" => "jboss.server.config.dir" }, "users-properties" => { "path" => "mgmt-users.properties", "relative-to" => "jboss.server.config.dir", "digest-realm-name" => "ManagementRealm" } } } which is missing the plain-text attribute > ManagementRealm does now show plain-text attribute in default read-resource output > ---------------------------------------------------------------------------------- > > Key: WFCORE-4041 > URL: https://issues.jboss.org/browse/WFCORE-4041 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Justin Cook > Assignee: Justin Cook > > Currently running /subsystem=elytron/properties-realm=ManagementRealm:read-resource() results in the output: > {code} > { > "outcome" => "success", > "result" => { > "groups-attribute" => "groups", > "groups-properties" => { > "path" => "mgmt-groups.properties", > "relative-to" => "jboss.server.config.dir" > }, > "users-properties" => { > "path" => "mgmt-users.properties", > "relative-to" => "jboss.server.config.dir", > "digest-realm-name" => "ManagementRealm" > } > } > } > {code} > which is missing the plain-text attribute -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10847) Multiple service modules in single EAR use same tracer instance

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-10847?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFLY-10847: ----------------------------------------- EARs are used all sorts of ways and I don't think you can assume a particular pattern dominates and others are edge cases. The wikipedia description of them[1] is useful: {quote} a file format used by Java EE for packaging one or more modules into a single archive so that the deployment of the various modules onto an application server happens simultaneously and coherently {quote} As part of "coherently" I'd included the shared classloading rules that EE specifies for EARs. Anyone who wants to take advantage of that simultaneous and coherent deployment model might use an ear. One thought I have though is that for a loooonnnng time now EE supports packaging EJBs in wars, no longer requiring an EAR. And of course using CDI managed beans in a webapp doesn't require an EAR. So some of the original ancient use case for an ear is no longer applicable, increasing the probability that someone using an EAR today is doing so because they are deploying multiple wars. That doesn't answer whether those folks conceive of those multiple wars as a single service. I figure some do some don't. [~bmaxwell] Any thoughts on this? [1] https://en.wikipedia.org/wiki/EAR_(file_format) > Multiple service modules in single EAR use same tracer instance > --------------------------------------------------------------- > > Key: WFLY-10847 > URL: https://issues.jboss.org/browse/WFLY-10847 > Project: WildFly > Issue Type: Bug > Components: MP OpenTracing > Reporter: Michal Jurc > Assignee: Juraci Paixão Kröhling > Priority: Blocker > Fix For: 14.0.0.CR1 > > > When deploying an EAR with two stand-alone JAX-RS services in stand-alone WAR modules, both of the services use the same {{Tracer}} instance. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 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 August 2018