August 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2496) Incorrect schema

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2496?page=com.atlassian.jira.plugin... ] Bela Ban resolved JGRP-2496. ---------------------------- Resolution: Done > Incorrect schema > ---------------- > > Key: JGRP-2496 > URL: https://issues.redhat.com/browse/JGRP-2496 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.2.5, 5.0.1 > > > XmlSchemeGenerator generates incorrect XSD: > {code:xml} > <xs:attribute type="xs:string" version="${version}" /> needs to be changed to > <xs:attribute type="xs:string" name="version" /> > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2496) Incorrect schema

by Bela Ban (Jira)

Bela Ban created JGRP-2496: ------------------------------ Summary: Incorrect schema Key: JGRP-2496 URL: https://issues.redhat.com/browse/JGRP-2496 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Fix For: 4.2.5, 5.0.1 XmlSchemeGenerator generates incorrect XSD: {code:xml} <xs:attribute type="xs:string" version="${version}" /> needs to be changed to <xs:attribute type="xs:string" name="version" /> {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13674) WARN if deployment descriptor has ${...} but *property-replacement=false

by Yeray Borges Santana (Jira)

[ https://issues.redhat.com/browse/WFLY-13674?page=com.atlassian.jira.plugi... ] Yeray Borges Santana commented on WFLY-13674: --------------------------------------------- I think there could be two points to take care: # How to be able to log a useful message; I would expect to see in the log the descriptor name being parsed and the value of the XML element that is using a variable expression ${...} when the descriptor replacement is disabled. However, when *property-replacement=false, we are using the no-op replacer, which is initialized in the PropertyReplacers itself, that means, the property replacer has no knowledge about which file is being parsed. So, we should find out how to do it to avoid a massive modification in all the parsers. Passing this specific no-op replacer to WildFly core to handle the specific spec descriptors parsed by WildFly core should not be complex, indeed we are already passing it. # We should verify each descriptor. As far as I remember, one of the complexity with the descriptors is we are not using a standard consistent way to replace those properties. So, each descriptor could be using a different approach, I hope all of them are using the PropertyReplacers.NO_OP_REPLACER if the *property-replacement=false Is this change limited only to the spec descriptors or is it for all the descriptors handled by the server? > WARN if deployment descriptor has ${...} but *property-replacement=false > ------------------------------------------------------------------------ > > Key: WFLY-13674 > URL: https://issues.redhat.com/browse/WFLY-13674 > Project: WildFly > Issue Type: Enhancement > Components: EE > Affects Versions: 20.0.0.Final > Reporter: Brad Maxwell > Assignee: Brian Stansberry > Priority: Major > > WARN if deployment descriptor has ${...} but *property-replacement=false > By default the property replacement defaults to true for jboss deployment descriptors and false for annotations and spec deployment descriptors: > > {code:java} > "annotation-property-replacement" => false, > "jboss-descriptor-property-replacement" => true, > "spec-descriptor-property-replacement" => false, {code} > > In the persistence.xml for example, there is a freeform <properties> with properties that can change over time and default values. If *property-replacement is false , then ${...} is passed to the DUP to configure and can cause problems such as in this hibernate property which changed from default value of false to true and the user was unaware that system property substitution was not occurring because they had not enabled it. > > {code:java} > <?xml version="1.0" encoding="UTF-8"?> > <persistence version="2.1" > xmlns="http://xmlns.jcp.org/xml/ns/persistence" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/persistence http://xmlns.jcp.org/xml/ns/persistence/persistence_2_1.xsd"> > <persistence-unit name=“example” transaction-type="JTA"> > <jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source> > <properties> > <property name="hibernate.cache.use_second_level_cache" value="${hibernate_cache.enabled:false}" /> > </properties> > </persistence-unit> > </persistence> {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5084) Why does the elytron layer bring in access control?

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFCORE-5084?page=com.atlassian.jira.plug... ] Darran Lofthouse commented on WFCORE-5084: ------------------------------------------ [~brian.stansberry] +1 it looks like the management layers already bring it in, it's only purpose is to provide an RBAC mapping where local authentication is in use with the management interfaces so only has a meaning if the management interfaces are secured one way or another so I think we can just remove it from the ELytron layer. My test was web-server and reviewing the diff once elytron was added, there are no management interfaces in my set of layers so no need for the $local to SuperUser mapping. > Why does the elytron layer bring in access control? > --------------------------------------------------- > > Key: WFCORE-5084 > URL: https://issues.redhat.com/browse/WFCORE-5084 > Project: WildFly Core > Issue Type: Task > Components: Build System, Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 13.0.0.Beta4 > > > The following shows the set of changes created by adding the elytron layer to a provisioned server: > https://gist.github.com/darranl/68f4a3d60560dae9a9225ec1a0e35a9f/revisions > This includes the following: > {code:xml} > <management> > <access-control provider="simple"> > <role-mapping> > <role name="SuperUser"> > <include> > <user name="$local"/> > </include> > </role> > </role-mapping> > </access-control> > </management> > {code} > Shouldn't this section be added if any form of authenticated management is added instead? -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5486) CEP doesn't evaluate correctly when a bind variable is used as the first temporal parameter in executable model

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5486?page=com.atlassian.jira.plug... ] Toshiya Kobayashi updated DROOLS-5486: -------------------------------------- Story Points: 5 (was: 3) > CEP doesn't evaluate correctly when a bind variable is used as the first temporal parameter in executable model > --------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-5486 > URL: https://issues.redhat.com/browse/DROOLS-5486 > Project: Drools > Issue Type: Bug > Components: executable model > Affects Versions: 7.39.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > With the below test, standard-drl fires but executable-model doesn't. > {code:java} > @Test > public void testAfterOnLongFields2() throws Exception { > String str = > "import " + StockTick.class.getCanonicalName() + ";\n" + > "declare StockTick @timestamp(timeFieldAsLong) end\n" + > "rule R when\n" + > " $a : StockTick( company == \"DROO\" )\n" + > " $b : StockTick( company == \"ACME\", $a.timeFieldAsLong after[5,8] timeFieldAsLong )\n" + > "then\n" + > " System.out.println(\"fired\");\n" + > "end\n"; > KieSession ksession = getKieSession(getCepKieModuleModel(), str); > SessionPseudoClock clock = ksession.getSessionClock(); > > ReteDumper.dumpRete(ksession); > ksession.insert( new StockTick( "ACME" ).setTimeField( 0 ) ); > ksession.insert( new StockTick( "DROO" ).setTimeField( 6 ) ); > assertEquals( 1, ksession.fireAllRules() ); > } > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1200) Automate RequestAuth https://github.com/kiali/kiali/pull/3083

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1200?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan commented on SWSQE-1200: --------------------------------------- https://github.com/Kiali-QE/kiali-qe-python/pull/315 > Automate RequestAuth https://github.com/kiali/kiali/pull/3083 > ------------------------------------------------------------- > > Key: SWSQE-1200 > URL: https://issues.redhat.com/browse/SWSQE-1200 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1200) Automate RequestAuth https://github.com/kiali/kiali/pull/3083

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1200?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan reassigned SWSQE-1200: ------------------------------------- Assignee: Hayk Hovsepyan > Automate RequestAuth https://github.com/kiali/kiali/pull/3083 > ------------------------------------------------------------- > > Key: SWSQE-1200 > URL: https://issues.redhat.com/browse/SWSQE-1200 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1198) Automate AuthPolicy https://github.com/kiali/kiali/pull/3063

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1198?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan updated SWSQE-1198: ---------------------------------- Sprint: Kiali Sprint #43 > Automate AuthPolicy https://github.com/kiali/kiali/pull/3063 > ------------------------------------------------------------ > > Key: SWSQE-1198 > URL: https://issues.redhat.com/browse/SWSQE-1198 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Priority: Major > Labels: automation > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1200) Automate RequestAuth https://github.com/kiali/kiali/pull/3083

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1200?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan updated SWSQE-1200: ---------------------------------- Sprint: Kiali Sprint #43 > Automate RequestAuth https://github.com/kiali/kiali/pull/3083 > ------------------------------------------------------------- > > Key: SWSQE-1200 > URL: https://issues.redhat.com/browse/SWSQE-1200 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Priority: Major > Labels: automation > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1200) Automate RequestAuth https://github.com/kiali/kiali/pull/3083

by Hayk Hovsepyan (Jira)

Hayk Hovsepyan created SWSQE-1200: ------------------------------------- Summary: Automate RequestAuth https://github.com/kiali/kiali/pull/3083 Key: SWSQE-1200 URL: https://issues.redhat.com/browse/SWSQE-1200 Project: Kiali QE Issue Type: QE Task Reporter: Hayk Hovsepyan -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2020