January 2021 - jboss-jira - Jboss List Archives

[Red Hat JIRA] (WFLY-14219) Utilize JBoss Modules version 1.9 in module descriptors

by Boris Unckel (Jira)

[ https://issues.redhat.com/browse/WFLY-14219?page=com.atlassian.jira.plugi... ] Boris Unckel commented on WFLY-14219: ------------------------------------- [~smarlow] Please check https://github.com/wildfly/wildfly/pull/13904 for the javax.xml.namespace.QName from [Module "javax.ws.rs.api fix > Utilize JBoss Modules version 1.9 in module descriptors > ------------------------------------------------------- > > Key: WFLY-14219 > URL: https://issues.redhat.com/browse/WFLY-14219 > Project: WildFly > Issue Type: Task > Components: Server > Affects Versions: 22.0.0.Alpha1 > Reporter: Boris Unckel > Assignee: Boris Unckel > Priority: Major > Fix For: 23.0.0.Beta1 > > Attachments: 2020-12-13_wildfly-22.0.0.Beta1-SNAPSHOT_modules_15_16_17.txt, 2020-12-16_wfjdep2_22.0.0.Beta1-SNAPSHOT.7z, 2020-12-16_wfjdep_22.0.0.Beta1-SNAPSHOT.7z > > > There are still modules which use 1.5, 1.6 or 1.7 and do not need that. The idea is to run jdeps on each artifact of a modul, add the relevant java.* and jdk.* modules to the dependencies of the module and upgrade to version 1.8. In a first change only none-jdk modules and none which depend on system dependency. > List in 2020-12-13_wildfly-22.0.0.Beta1-SNAPSHOT_modules_15_16_17.txt > Changes in a first set of modules in WildFly-Core [WFCORE-5229|https://issues.redhat.com/browse/WFCORE-5229] integration tests were successful. -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 8 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14219) Utilize JBoss Modules version 1.9 in module descriptors

by Boris Unckel (Jira)

[ https://issues.redhat.com/browse/WFLY-14219?page=com.atlassian.jira.plugi... ] Boris Unckel updated WFLY-14219: -------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/13827, https://github.com/wildfly/wildfly/pull/13904 (was: https://github.com/wildfly/wildfly/pull/13827) > Utilize JBoss Modules version 1.9 in module descriptors > ------------------------------------------------------- > > Key: WFLY-14219 > URL: https://issues.redhat.com/browse/WFLY-14219 > Project: WildFly > Issue Type: Task > Components: Server > Affects Versions: 22.0.0.Alpha1 > Reporter: Boris Unckel > Assignee: Boris Unckel > Priority: Major > Fix For: 23.0.0.Beta1 > > Attachments: 2020-12-13_wildfly-22.0.0.Beta1-SNAPSHOT_modules_15_16_17.txt, 2020-12-16_wfjdep2_22.0.0.Beta1-SNAPSHOT.7z, 2020-12-16_wfjdep_22.0.0.Beta1-SNAPSHOT.7z > > > There are still modules which use 1.5, 1.6 or 1.7 and do not need that. The idea is to run jdeps on each artifact of a modul, add the relevant java.* and jdk.* modules to the dependencies of the module and upgrade to version 1.8. In a first change only none-jdk modules and none which depend on system dependency. > List in 2020-12-13_wildfly-22.0.0.Beta1-SNAPSHOT_modules_15_16_17.txt > Changes in a first set of modules in WildFly-Core [WFCORE-5229|https://issues.redhat.com/browse/WFCORE-5229] integration tests were successful. -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 8 months

1
0
0 / 0

[Red Hat JIRA] (WFCORE-5248) [GSS](7.3.z) TCCL should be set to logging custom-handler module

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFCORE-5248?page=com.atlassian.jira.plug... ] James Perkins moved JBEAP-20876 to WFCORE-5248: ----------------------------------------------- Component/s: Logging (was: Logging) Fix Version/s: (was: 7.3.6.GA) Key: WFCORE-5248 (was: JBEAP-20876) Affects Version/s: (was: 7.3.4.GA) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Project: WildFly Core (was: JBoss Enterprise Application Platform) > [GSS](7.3.z) TCCL should be set to logging custom-handler module > ---------------------------------------------------------------- > > Key: WFCORE-5248 > URL: https://issues.redhat.com/browse/WFCORE-5248 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Major > Attachments: reproducer-overlay.zip > > > When trying to specify the EvaluatorClass where the class exists in the module custom.evaluator , it fails with a ClassNotFound because the TCL is org.jboss.as.standalone instead of custom.evaluator module: > {code} > Loader.getTCL return: ModuleClassLoader for Module "org.jboss.as.standalone" from local module loader @6adede5 (finder: local module finder @2d928643 (roots: /tmp/jboss-eap-7.3/modules,/tmp/jboss-eap-7.3/modules/system/layers/base)) > log4j:ERROR Could not instantiate class [org.apache.log4j.asm.INFOLevelEvaluator]. > java.lang.ClassNotFoundException: org.apache.log4j.asm.INFOLevelEvaluator from [Module "org.jboss.log4j.logmanager" version 1.2.0.Final-redhat-00001 from local module loader @6adede5 (finder: local module finder @2d928643 (roots: /tmp/jboss-eap-7.3/modules,/tmp/jboss-eap-7.3/modules/system/layers/base))] > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:255) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:264) > at org.apache.log4j.helpers.Loader.loadClass(Loader.java:197) > at org.apache.log4j.helpers.OptionConverter.instantiateByClassName(OptionConverter.java:326) > at org.apache.log4j.net.SMTPAppender.setEvaluatorClass(SMTPAppender.java:549) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:217) > at org.jboss.logmanager.config.AbstractPropertyConfiguration$1.applyPostCreate(AbstractPropertyConfiguration.java:197) > at org.jboss.logmanager.config.LogContextConfigurationImpl.doApplyPostCreate(LogContextConfigurationImpl.java:313) > at org.jboss.logmanager.config.LogContextConfigurationImpl.doPrepare(LogContextConfigurationImpl.java:345) > at org.jboss.logmanager.config.LogContextConfigurationImpl.prepare(LogContextConfigurationImpl.java:289) > at org.jboss.logmanager.config.LogContextConfigurationImpl.commit(LogContextConfigurationImpl.java:298) > at org.jboss.logmanager.PropertyConfigurator.configure(PropertyConfigurator.java:546) > at org.jboss.logmanager.PropertyConfigurator.configure(PropertyConfigurator.java:97) > at org.jboss.logmanager.LogManager.readConfiguration(LogManager.java:170) > at org.jboss.logmanager.LogManager.readConfiguration(LogManager.java:132) > at java.util.logging.LogManager$3.run(LogManager.java:399) > at java.util.logging.LogManager$3.run(LogManager.java:396) > at java.security.AccessController.doPrivileged(Native Method) > at java.util.logging.LogManager.readPrimordialConfiguration(LogManager.java:396) > at java.util.logging.LogManager.access$800(LogManager.java:145) > at java.util.logging.LogManager$2.run(LogManager.java:345) > at java.security.AccessController.doPrivileged(Native Method) > at java.util.logging.LogManager.ensureLogManagerInitialized(LogManager.java:338) > at java.util.logging.LogManager.getLogManager(LogManager.java:378) > at org.jboss.modules.Main.main(Main.java:457) > {code} > {code} > <custom-handler name="email" class="org.apache.log4j.net.SMTPAppender" module="custom.evaluator"> > <level name="INFO"/> > <filter-spec value="match("WFLYSRV0025")"/> > <formatter> > <named-formatter name="PATTERN"/> > </formatter> > <properties> > <property name="EvaluatorClass" value="org.apache.log4j.asm.INFOLevelEvaluator"/> > ... > </properties> > </custom-handler> > {code} -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 8 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-5961) @watch annotation containing "!*" does not work as expected in executable model.

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-5961?page=com.atlassian.jira.plug... ] Mario Fusco moved RHDM-1586 to DROOLS-5961: ------------------------------------------- Component/s: core engine executable model (was: BRE) Docs QE Status: NEW Key: DROOLS-5961 (was: RHDM-1586) QE Status: NEW Affects Version/s: (was: 7.9.0.GA) Workflow: GIT Pull Request workflow (was: CDW with docs v1) Environment: (was: This issue occurs on RHDM 7.9.0.) Project: Drools (was: Red Hat Decision Manager) > @watch annotation containing "!*" does not work as expected in executable model. > -------------------------------------------------------------------------------- > > Key: DROOLS-5961 > URL: https://issues.redhat.com/browse/DROOLS-5961 > Project: Drools > Issue Type: Bug > Components: core engine, executable model > Reporter: Mario Fusco > Assignee: Mario Fusco > Priority: Major > Labels: support > Attachments: reproducer_model_compiler_9b.zip > > > Executing a rule like (\*1) in executable rule model, the rule is evaluated repeatedly. In this rule, re-evaluation occurs in executable model though {{@watch(!\*)}} annotation is specified to the pattern like (\*1-1). {{@watch}} annotation containing {{!\*}} as below does not work as expected, as well as {{@watch(!\*)}}. > - {{@watch(!\*, point2)}} > - {{@watch(!\*, point1)}} > - {{@watch(point1, !\*)}} > On the other hand, {{@watch}} not containing {{!\*}}, for example, {{@watch(!point1, point2)}} or {{@watch(!point1, point3)}}, works as expected. > (\*1) > {noformat} > package com.example.reproducer > dialect "mvel" > rule "rule9b3" > when > $fact : Fact( $point1 : point1, $point2 : point2 ) @watch(!*) // ..... (*1-1) > then > System.out.println("***** Action of \"rule9b3\" -- $fact = " + $fact + ", $point1 = " + $point1 + ", $point2 = " + $point2); > $point1 = $point1.add($point2); > modify($fact) { > point1 = $point1, > point3 = $point1 > } > end > {noformat} -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 8 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14219) Utilize JBoss Modules version 1.9 in module descriptors

by Boris Unckel (Jira)

[ https://issues.redhat.com/browse/WFLY-14219?page=com.atlassian.jira.plugi... ] Boris Unckel edited comment on WFLY-14219 at 1/21/21 10:30 AM: --------------------------------------------------------------- [~smarlow] Please give me 45min for a call, after that I'll prepare a fix. The message is very clear"javax.xml.namespace.QName from [Module "javax.ws.rs.api". I just need a few min. was (Author: xf01213): [~smarlow] Please give me 45min for a call, after that I'll prepare a fix. The message is very "javax.xml.namespace.QName from [Module "javax.ws.rs.api". I just need a few min. > Utilize JBoss Modules version 1.9 in module descriptors > ------------------------------------------------------- > > Key: WFLY-14219 > URL: https://issues.redhat.com/browse/WFLY-14219 > Project: WildFly > Issue Type: Task > Components: Server > Affects Versions: 22.0.0.Alpha1 > Reporter: Boris Unckel > Assignee: Boris Unckel > Priority: Major > Fix For: 23.0.0.Beta1 > > Attachments: 2020-12-13_wildfly-22.0.0.Beta1-SNAPSHOT_modules_15_16_17.txt, 2020-12-16_wfjdep2_22.0.0.Beta1-SNAPSHOT.7z, 2020-12-16_wfjdep_22.0.0.Beta1-SNAPSHOT.7z > > > There are still modules which use 1.5, 1.6 or 1.7 and do not need that. The idea is to run jdeps on each artifact of a modul, add the relevant java.* and jdk.* modules to the dependencies of the module and upgrade to version 1.8. In a first change only none-jdk modules and none which depend on system dependency. > List in 2020-12-13_wildfly-22.0.0.Beta1-SNAPSHOT_modules_15_16_17.txt > Changes in a first set of modules in WildFly-Core [WFCORE-5229|https://issues.redhat.com/browse/WFCORE-5229] integration tests were successful. -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 8 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14219) Utilize JBoss Modules version 1.9 in module descriptors

by Boris Unckel (Jira)

[ https://issues.redhat.com/browse/WFLY-14219?page=com.atlassian.jira.plugi... ] Boris Unckel commented on WFLY-14219: ------------------------------------- [~smarlow] Please give me 45min for a call, after that I'll prepare a fix. The message is very "javax.xml.namespace.QName from [Module "javax.ws.rs.api". I just need a few min. > Utilize JBoss Modules version 1.9 in module descriptors > ------------------------------------------------------- > > Key: WFLY-14219 > URL: https://issues.redhat.com/browse/WFLY-14219 > Project: WildFly > Issue Type: Task > Components: Server > Affects Versions: 22.0.0.Alpha1 > Reporter: Boris Unckel > Assignee: Boris Unckel > Priority: Major > Fix For: 23.0.0.Beta1 > > Attachments: 2020-12-13_wildfly-22.0.0.Beta1-SNAPSHOT_modules_15_16_17.txt, 2020-12-16_wfjdep2_22.0.0.Beta1-SNAPSHOT.7z, 2020-12-16_wfjdep_22.0.0.Beta1-SNAPSHOT.7z > > > There are still modules which use 1.5, 1.6 or 1.7 and do not need that. The idea is to run jdeps on each artifact of a modul, add the relevant java.* and jdk.* modules to the dependencies of the module and upgrade to version 1.8. In a first change only none-jdk modules and none which depend on system dependency. > List in 2020-12-13_wildfly-22.0.0.Beta1-SNAPSHOT_modules_15_16_17.txt > Changes in a first set of modules in WildFly-Core [WFCORE-5229|https://issues.redhat.com/browse/WFCORE-5229] integration tests were successful. -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 8 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-12970) SmallRye Metrics - MetricsRegistryImpl - removal of entry from map which is currently iterated

by Jason Lee (Jira)

[ https://issues.redhat.com/browse/WFLY-12970?page=com.atlassian.jira.plugi... ] Jason Lee commented on WFLY-12970: ---------------------------------- The fix has been merged upstream. We can integrate that once the SR makes a new release. > SmallRye Metrics - MetricsRegistryImpl - removal of entry from map which is currently iterated > ---------------------------------------------------------------------------------------------- > > Key: WFLY-12970 > URL: https://issues.redhat.com/browse/WFLY-12970 > Project: WildFly > Issue Type: Bug > Components: MP Metrics > Reporter: Rostislav Svoboda > Assignee: Jason Lee > Priority: Major > > SmallRye Metrics - MetricsRegistryImpl - removal of entry from map which is currently iterated > https://github.com/smallrye/smallrye-metrics/blob/master/implementation/s... > Method {{removeMatching}} is iterating over {{metricMap}}. If there is a match {{remove}} method is called. This method removes entry from {{metricMap}} and from {{metadataMap}}. > I don't like the fact that the entry is removed from the map by external method while the map is currently iterated by the {{removeMatching}} method. > I think https://docs.oracle.com/javase/8/docs/api/java/util/Iterator.html#remove-- should be called in {{removeMatching}} for {{metricMap}} entry + invocation of metadataMap.remove(entry.getKey()) + log mesasge; -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 8 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14249) Ensure java.time/sql ProtoStream marshallers generate valid protobuf messages

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-14249?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-14249: -------------------------------- Summary: Ensure java.time/sql ProtoStream marshallers generate valid protobuf messages (was: Ensure java.time ProtoStream marshallers generate valid protobuf messages) > Ensure java.time/sql ProtoStream marshallers generate valid protobuf messages > ----------------------------------------------------------------------------- > > Key: WFLY-14249 > URL: https://issues.redhat.com/browse/WFLY-14249 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 22.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > Protobuf messages generated by the Externalizers from the org.wildfly.clustering.marshalling.spi module are not necessarily valid protobuf messages. > Additionally, many java.time classes can be marshalled more efficiently using native protostream marshallers, which can optimize for loose precision and positive/future values. -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 8 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14249) Ensure java.time ProtoStream marshallers generate valid protobuf messages

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-14249?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-14249: -------------------------------- Summary: Ensure java.time ProtoStream marshallers generate valid protobuf messages (was: Optimize java.time marshalling using native protostream marshallers) > Ensure java.time ProtoStream marshallers generate valid protobuf messages > ------------------------------------------------------------------------- > > Key: WFLY-14249 > URL: https://issues.redhat.com/browse/WFLY-14249 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 22.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > Many java.time classes can be marshalled more efficiently using native protostream marshallers, which can optimize for loose precision and positive/future values. -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 8 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14249) Ensure java.time ProtoStream marshallers generate valid protobuf messages

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-14249?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-14249: -------------------------------- Description: Protobuf messages generated by the Externalizers from the org.wildfly.clustering.marshalling.spi module are not necessarily valid protobuf messages. Additionally, many java.time classes can be marshalled more efficiently using native protostream marshallers, which can optimize for loose precision and positive/future values. was:Many java.time classes can be marshalled more efficiently using native protostream marshallers, which can optimize for loose precision and positive/future values. > Ensure java.time ProtoStream marshallers generate valid protobuf messages > ------------------------------------------------------------------------- > > Key: WFLY-14249 > URL: https://issues.redhat.com/browse/WFLY-14249 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 22.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > Protobuf messages generated by the Externalizers from the org.wildfly.clustering.marshalling.spi module are not necessarily valid protobuf messages. > Additionally, many java.time classes can be marshalled more efficiently using native protostream marshallers, which can optimize for loose precision and positive/future values. -- This message was sent by Atlassian Jira (v8.13.1#813001)

3 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2021