July 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (LOGTOOL-128) The generated skeleton files should end up in the generate source directory not the output directory

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-128?page=com.atlassian.jira.plugi... ] James Perkins commented on LOGTOOL-128: --------------------------------------- One thing to note is for tools like Zanata, which is mostly what this tool was created for, there can only be one directory that is used for an upload directory. For projects like WildFly that use a combination of both generated files as well as Java resource bundles. The idea of this was having the ability to not have to filter out these translations files as they will not be needed at runtime. > The generated skeleton files should end up in the generate source directory not the output directory > ---------------------------------------------------------------------------------------------------- > > Key: LOGTOOL-128 > URL: https://issues.jboss.org/browse/LOGTOOL-128 > Project: Log Tool > Issue Type: Bug > Reporter: James Perkins > > The generated skeleton files end up in the {{StandardLocation.CLASS_OUTPUT}} which is where compiled classes go. Since it's generated and not needed in the final archive it should be in the {{StandardLocation.SOURCE_OUTPUT}}. > One thing to note is this could be considered a breaking change. It has gone into this directory since the first release. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-128) The generated skeleton files should end up in the generate source directory not the output directory

by James Perkins (JIRA)

James Perkins created LOGTOOL-128: ------------------------------------- Summary: The generated skeleton files should end up in the generate source directory not the output directory Key: LOGTOOL-128 URL: https://issues.jboss.org/browse/LOGTOOL-128 Project: Log Tool Issue Type: Bug Reporter: James Perkins The generated skeleton files end up in the {{StandardLocation.CLASS_OUTPUT}} which is where compiled classes go. Since it's generated and not needed in the final archive it should be in the {{StandardLocation.SOURCE_OUTPUT}}. One thing to note is this could be considered a breaking change. It has gone into this directory since the first release. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2996) Re-Use Named Log-Formatter In Logging Profile

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2996?page=com.atlassian.jira.plugi... ] James Perkins closed WFCORE-2996. --------------------------------- Resolution: Done This can't be done until the [jboss-logmanager|https://issues.jboss.org/browse/LOGMGR] can allow some kind of shared log context. Which may not happen. > Re-Use Named Log-Formatter In Logging Profile > --------------------------------------------- > > Key: WFCORE-2996 > URL: https://issues.jboss.org/browse/WFCORE-2996 > Project: WildFly Core > Issue Type: Enhancement > Components: Logging > Reporter: Markus May > Assignee: James Perkins > Priority: Critical > > Right now, if I try to re-use the globally defined Named-Formatter "PATTERN" in my own logging profile, I do get an error-message stating that the Formatter "PATTERN" is not found. > To be able to re-use the same Formatter in all logging-profiles, it would be good, to be able to use these globally defined Formatters. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3039) Capability requirement can be lost if two attributes on same resource reference the same capability

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3039?page=com.atlassian.jira.plugi... ] Brian Stansberry reassigned WFCORE-3039: ---------------------------------------- Assignee: (was: Brian Stansberry) > Capability requirement can be lost if two attributes on same resource reference the same capability > --------------------------------------------------------------------------------------------------- > > Key: WFCORE-3039 > URL: https://issues.jboss.org/browse/WFCORE-3039 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Darran Lofthouse > > With the following three commands the server becomes unable to boot due to a missing dependency: - > {noformat} > /subsystem=elytron:write-attribute(name=initial-providers, value=combined-providers) > /subsystem=elytron:undefine-attribute(name=final-providers) > /subsystem=elytron/aggregate-providers=combined-providers:remove > {noformat} > If however I execute :reload after the first two commands, the final command will fail correctly. > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/aggregate-providers=combined-providers:remove > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0367: Cannot remove capability 'org.wildfly.security.providers.combined-providers' as it is required by other capabilities: > capability 'org.wildfly.security.elytron' requires it for attribute 'initial-providers' at address '/subsystem=elytron'", > "rolled-back" => true > } > {noformat} > I am only listing the 'Domain Management' component as I believe the security example is just the reproducer. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3039) Capability requirement can be lost if two attributes on same resource reference the same capability

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3039?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3039: ------------------------------------- Workaround Description: Simply reorder the reproducer steps so the operation dropping the ref to 'combined-providers' comes before the one that adds it to the other attribute: {code} /subsystem=elytron:undefine-attribute(name=final-providers) /subsystem=elytron:write-attribute(name=initial-providers, value=combined-providers) /subsystem=elytron/aggregate-providers=combined-providers:remove {code} Workaround: Workaround Exists > Capability requirement can be lost if two attributes on same resource reference the same capability > --------------------------------------------------------------------------------------------------- > > Key: WFCORE-3039 > URL: https://issues.jboss.org/browse/WFCORE-3039 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Brian Stansberry > Priority: Critical > > With the following three commands the server becomes unable to boot due to a missing dependency: - > {noformat} > /subsystem=elytron:write-attribute(name=initial-providers, value=combined-providers) > /subsystem=elytron:undefine-attribute(name=final-providers) > /subsystem=elytron/aggregate-providers=combined-providers:remove > {noformat} > If however I execute :reload after the first two commands, the final command will fail correctly. > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/aggregate-providers=combined-providers:remove > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0367: Cannot remove capability 'org.wildfly.security.providers.combined-providers' as it is required by other capabilities: > capability 'org.wildfly.security.elytron' requires it for attribute 'initial-providers' at address '/subsystem=elytron'", > "rolled-back" => true > } > {noformat} > I am only listing the 'Domain Management' component as I believe the security example is just the reproducer. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3039) Capability requirement can be lost if two attributes on same resource reference the same capability

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3039?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3039: ------------------------------------- Priority: Major (was: Critical) > Capability requirement can be lost if two attributes on same resource reference the same capability > --------------------------------------------------------------------------------------------------- > > Key: WFCORE-3039 > URL: https://issues.jboss.org/browse/WFCORE-3039 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Brian Stansberry > > With the following three commands the server becomes unable to boot due to a missing dependency: - > {noformat} > /subsystem=elytron:write-attribute(name=initial-providers, value=combined-providers) > /subsystem=elytron:undefine-attribute(name=final-providers) > /subsystem=elytron/aggregate-providers=combined-providers:remove > {noformat} > If however I execute :reload after the first two commands, the final command will fail correctly. > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/aggregate-providers=combined-providers:remove > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0367: Cannot remove capability 'org.wildfly.security.providers.combined-providers' as it is required by other capabilities: > capability 'org.wildfly.security.elytron' requires it for attribute 'initial-providers' at address '/subsystem=elytron'", > "rolled-back" => true > } > {noformat} > I am only listing the 'Domain Management' component as I believe the security example is just the reproducer. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3039) Capability requirement can be lost if two attributes on same resource reference the same capability

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3039?page=com.atlassian.jira.plugi... ] Brian Stansberry edited comment on WFCORE-3039 at 7/19/17 6:09 PM: ------------------------------------------------------------------- This problem isn't about reload; the reload just fixes the problem. The problem is that both initial-providers and final-providers are attributes on the same resource referencing the same "combined-providers" capability. The reproducer executes the "undefine-attribute" last, and that has the effect of removing the requirement, even though the initial-providers value means the requirement is still needed. There was some logic early on related to including attribute names as part of the requirement registration point data, but it has atrophied due to lack of any apparent good use case so I don't know if it can be cleanly resurrected to help handle this. Simply switching the order of the undefine-attribute and write-attribute calls prevents the problem. was (Author: brian.stansberry): This problem isn't about reload; the reload just fixes the problem. The problem is that both initial-providers and final-providers are attributes on the same resource referencing the same "combined-providers" capability. The reproducer executes the "undefine-attribute" last, and that has the effect of removing the requirement, even though the initial-providers value means the requirement is still needed. There was some logic early on related to including attribute names as part of the requirement registration point data, but it has atrophied due to lack of any apparent good use case so I don't know if it can be cleanly resurrected to help handle this. Simply switching the order of the undefine-attribute and write-attribute calls should prevent the problem. > Capability requirement can be lost if two attributes on same resource reference the same capability > --------------------------------------------------------------------------------------------------- > > Key: WFCORE-3039 > URL: https://issues.jboss.org/browse/WFCORE-3039 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Brian Stansberry > Priority: Critical > > With the following three commands the server becomes unable to boot due to a missing dependency: - > {noformat} > /subsystem=elytron:write-attribute(name=initial-providers, value=combined-providers) > /subsystem=elytron:undefine-attribute(name=final-providers) > /subsystem=elytron/aggregate-providers=combined-providers:remove > {noformat} > If however I execute :reload after the first two commands, the final command will fail correctly. > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/aggregate-providers=combined-providers:remove > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0367: Cannot remove capability 'org.wildfly.security.providers.combined-providers' as it is required by other capabilities: > capability 'org.wildfly.security.elytron' requires it for attribute 'initial-providers' at address '/subsystem=elytron'", > "rolled-back" => true > } > {noformat} > I am only listing the 'Domain Management' component as I believe the security example is just the reproducer. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3039) Capability requirement can be lost if two attributes on same resource reference the same capability

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3039?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFCORE-3039: ------------------------------------------ This problem isn't about reload; the reload just fixes the problem. The problem is that both initial-providers and final-providers are attributes on the same resource referencing the same "combined-providers" capability. The reproducer executes the "undefine-attribute" last, and that has the effect of removing the requirement, even though the initial-providers value means the requirement is still needed. There was some logic early on related to including attribute names as part of the requirement registration point data, but it has atrophied due to lack of any apparent good use case so I don't know if it can be cleanly resurrected to help handle this. Simply switching the order of the undefine-attribute and write-attribute calls should prevent the problem. > Capability requirement can be lost if two attributes on same resource reference the same capability > --------------------------------------------------------------------------------------------------- > > Key: WFCORE-3039 > URL: https://issues.jboss.org/browse/WFCORE-3039 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Brian Stansberry > Priority: Critical > > With the following three commands the server becomes unable to boot due to a missing dependency: - > {noformat} > /subsystem=elytron:write-attribute(name=initial-providers, value=combined-providers) > /subsystem=elytron:undefine-attribute(name=final-providers) > /subsystem=elytron/aggregate-providers=combined-providers:remove > {noformat} > If however I execute :reload after the first two commands, the final command will fail correctly. > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/aggregate-providers=combined-providers:remove > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0367: Cannot remove capability 'org.wildfly.security.providers.combined-providers' as it is required by other capabilities: > capability 'org.wildfly.security.elytron' requires it for attribute 'initial-providers' at address '/subsystem=elytron'", > "rolled-back" => true > } > {noformat} > I am only listing the 'Domain Management' component as I believe the security example is just the reproducer. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3039) Capability requirement can be lost if two attributes on same resource reference the same capability

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3039?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3039: ------------------------------------- Summary: Capability requirement can be lost if two attributes on same resource reference the same capability (was: Capability dependency not taken into account if reload required.) > Capability requirement can be lost if two attributes on same resource reference the same capability > --------------------------------------------------------------------------------------------------- > > Key: WFCORE-3039 > URL: https://issues.jboss.org/browse/WFCORE-3039 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Brian Stansberry > Priority: Critical > > With the following three commands the server becomes unable to boot due to a missing dependency: - > {noformat} > /subsystem=elytron:write-attribute(name=initial-providers, value=combined-providers) > /subsystem=elytron:undefine-attribute(name=final-providers) > /subsystem=elytron/aggregate-providers=combined-providers:remove > {noformat} > If however I execute :reload after the first two commands, the final command will fail correctly. > {noformat} > [standalone@localhost:9990 /] /subsystem=elytron/aggregate-providers=combined-providers:remove > { > "outcome" => "failed", > "failure-description" => "WFLYCTL0367: Cannot remove capability 'org.wildfly.security.providers.combined-providers' as it is required by other capabilities: > capability 'org.wildfly.security.elytron' requires it for attribute 'initial-providers' at address '/subsystem=elytron'", > "rolled-back" => true > } > {noformat} > I am only listing the 'Domain Management' component as I believe the security example is just the reproducer. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1667) FEEL expression fails: 1 + if true then 1 else 2

by Edson Tirelli (JIRA)

Edson Tirelli created DROOLS-1667: ------------------------------------- Summary: FEEL expression fails: 1 + if true then 1 else 2 Key: DROOLS-1667 URL: https://issues.jboss.org/browse/DROOLS-1667 Project: Drools Issue Type: Bug Components: dmn engine Affects Versions: 7.1.0.Final Reporter: Edson Tirelli Assignee: Edson Tirelli Fix For: 7.2.0.Final The following FEEL expression fails to parse: 1 + if true then 1 else 2 Similar expressions might present the same problem. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 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 July 2017