July 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-5053) Prometheus JMX exporter jar, stops starting the wildfly server.

by Rakesh Kumar Shah (Jira)

[ https://issues.redhat.com/browse/WFCORE-5053?page=com.atlassian.jira.plug... ] Rakesh Kumar Shah commented on WFCORE-5053: ------------------------------------------- Hi James, We verified the jar which you have mentioned, it is working fine. Quick question, is there any way to get patched version with this change? In case, if it is required to be a paid patch support, let us know. Thank you -Rakesh > Prometheus JMX exporter jar, stops starting the wildfly server. > ---------------------------------------------------------------- > > Key: WFCORE-5053 > URL: https://issues.redhat.com/browse/WFCORE-5053 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: Rakesh Kumar Shah > Assignee: James Perkins > Priority: Major > Fix For: 13.0.0.Beta1 > > > Trying to integrate the Prometheus JMX exporter with wildfly. After spending lot of time and work around it, wildfly is not starting. It throws following exception. > {code} > java.lang.ClassNotFoundException: org.jboss.logmanager.LogManager > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583) > at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) > at java.logging/java.util.logging.LogManager$1.run(LogManager.java:239) > at java.logging/java.util.logging.LogManager$1.run(LogManager.java:223) > at java.base/java.security.AccessController.doPrivileged(Native Method) > at java.logging/java.util.logging.LogManager.<clinit>(LogManager.java:223) > at java.logging/java.util.logging.Logger.demandLogger(Logger.java:648) > at java.logging/java.util.logging.Logger.getLogger(Logger.java:717) > at java.logging/java.util.logging.Logger.getLogger(Logger.java:701) > at io.prometheus.jmx.shaded.io.prometheus.jmx.JmxCollector.<clinit>(JmxCollector.java:39) > at io.prometheus.jmx.shaded.io.prometheus.jmx.JavaAgent.premain(JavaAgent.java:29) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:513) > at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:525) > WARNING: Failed to load the specified log manager class org.jboss.logmanager.LogManager > Exception in thread "main" java.lang.NoClassDefFoundError: org/jboss/logmanager/Level > at java.base/java.lang.Class.forName0(Native Method) > at java.base/java.lang.Class.forName(Class.java:398) > at org.jboss.modules.Module.run(Module.java:340) > at org.jboss.modules.Module.run(Module.java:320) > at org.jboss.modules.Main.main(Main.java:617) > Caused by: java.lang.ClassNotFoundException: org.jboss.logmanager.Level > at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:583) > at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521) > at org.jboss.modules.JDKSpecific.getSystemClass(JDKSpecific.java:183) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:395) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11959) AbstractSimpleApplicationClientTestCase pollutes the build/target/ installation

by Martin Stefanko (Jira)

[ https://issues.redhat.com/browse/WFLY-11959?page=com.atlassian.jira.plugi... ] Martin Stefanko reassigned WFLY-11959: -------------------------------------- Assignee: (was: Lukas Burda) > AbstractSimpleApplicationClientTestCase pollutes the build/target/ installation > ------------------------------------------------------------------------------- > > Key: WFLY-11959 > URL: https://issues.redhat.com/browse/WFLY-11959 > Project: WildFly > Issue Type: Bug > Components: Application Client, Test Suite > Reporter: Brian Stansberry > Priority: Minor > > AbstractSimpleApplicationClientTestCase uses AppClientWrapper which ends up writing a log file in the WildFly installation in build/target. That's not ideal as that's not a test installation and its content shouldn't be polluted. > It's not critical as by the time the testsuite has run the build module has already created a zip of its installation, and that zip is what would get deployed if a release was being done. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13697) JBoss CLI can't find java:app/AppName

by Michal Petrov (Jira)

[ https://issues.redhat.com/browse/WFLY-13697?page=com.atlassian.jira.plugi... ] Michal Petrov commented on WFLY-13697: -------------------------------------- The proper naming context is set up via [JavaNamespaceSetup|https://github.com/wildfly/wildfly/blob/master/ee... is tied to a deployment, so when the action comes from CLI or HAL the context is not set. I don't think this can be solved with CLI, the contexts are managed by Naming/EE and those are not a part of core. I'm guessing the context can be set when connection is established by CLI but I don't know if that's the way to go. > JBoss CLI can't find java:app/AppName > ------------------------------------- > > Key: WFLY-13697 > URL: https://issues.redhat.com/browse/WFLY-13697 > Project: WildFly > Issue Type: Bug > Components: CLI > Affects Versions: JBoss AS7 7.2.0.Final > Reporter: José Fernando Tepedino Martins > Assignee: Michal Petrov > Priority: Minor > Labels: CLI, JNDI > > With a JEE aplication in a WAR package, when starting a functionality, as a Batch Job, via CLI, CDI injection and JNDI lookup fail to find resources 'java:app/AppName' and 'java:module/ModuleName'. > For example, a job listener or other job artifact with the following code > {code:java} > @Resource(lookup="java:app/AppName") > private String applicationName;{code} > or > {code:java} > private String applicationName; > @PostConstruct > protected void initialize() throws NamingException { > applicationName = InitialContext.doLookup("java:app/AppName"); > }{code} > when the batch job is started from JBoss CLI, the following error will be logged: > {code:java} > javax.naming.NameNotFoundException: java:app/AppName > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5064) Incorrect use of KeyManagerFactory.getDefaultAlgorithm instead of TrustManagerFactory

by Ricardo Martin Camarero (Jira)

Ricardo Martin Camarero created WFCORE-5064: ----------------------------------------------- Summary: Incorrect use of KeyManagerFactory.getDefaultAlgorithm instead of TrustManagerFactory Key: WFCORE-5064 URL: https://issues.redhat.com/browse/WFCORE-5064 Project: WildFly Core Issue Type: Bug Components: Security Affects Versions: 13.0.0.Beta2 Reporter: Ricardo Martin Camarero Assignee: Ricardo Martin Camarero When configuring https using the old security-realm the trust-manager factory is selected using [the line|https://github.com/wildfly/wildfly-core/blob/12.0.3.Final/domain-man...]: {code:java} trustManagerFactory = TrustManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm()); {code} Which is incorrect and should use the TrustManagerFactory. Therefore by default in openjdk we are using the {{SunX509}} factory instead of the default {{PKIX}} implementation. The default values for both factories are defined in the {{java.security}} file from the jdk: {code:java} # # Determines the default key and trust manager factory algorithms for # the javax.net.ssl package. # ssl.KeyManagerFactory.algorithm=SunX509 ssl.TrustManagerFactory.algorithm=PKIX {code} Using a exotic configuration can lead to an error if the KeyManagerFactory is configured to an algorithm that is not valid for the TrustManagerFactory (NewSunX509 for example). -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5394) Coverage Report Improvements (CVS File)

by Yeser Amer (Jira)

[ https://issues.redhat.com/browse/DROOLS-5394?page=com.atlassian.jira.plug... ] Yeser Amer reopened DROOLS-5394: -------------------------------- > Coverage Report Improvements (CVS File) > --------------------------------------- > > Key: DROOLS-5394 > URL: https://issues.redhat.com/browse/DROOLS-5394 > Project: Drools > Issue Type: Enhancement > Reporter: Yeser Amer > Assignee: Yeser Amer > Priority: Major > Labels: ScenarioSimulation, drools-tools > > Proposed solution tohttps://issues.redhat.com/browse/RHPAM-2616, is to put the same data shown on Coverage Report inside the generated CSV Report file. > This means to add following data: > Overall Stats (Available rules, executed rules, coverage percentage); > Rules counters -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5528) Drools buisness central ldap authentication

by prabhat kumar (Jira)

[ https://issues.redhat.com/browse/DROOLS-5528?page=com.atlassian.jira.plug... ] prabhat kumar commented on DROOLS-5528: --------------------------------------- Hi Toshiya, Appreciate your reply, I have already done the steps that you have suggested multiple time but still no luck, I'm unable to understand whether this is a bug or something else we are missing. Because I tried all the approaches that was mentioned in the documentation for ldap configuration but stuck at the above mentioned point. Thanks Prabhat Kumar > Drools buisness central ldap authentication > ------------------------------------------- > > Key: DROOLS-5528 > URL: https://issues.redhat.com/browse/DROOLS-5528 > Project: Drools > Issue Type: Feature Request > Reporter: prabhat kumar > Assignee: Mario Fusco > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13697) JBoss CLI can't find java:app/AppName

by Michal Petrov (Jira)

[ https://issues.redhat.com/browse/WFLY-13697?page=com.atlassian.jira.plugi... ] Michal Petrov reassigned WFLY-13697: ------------------------------------ Assignee: Michal Petrov (was: Jean Francois Denise) > JBoss CLI can't find java:app/AppName > ------------------------------------- > > Key: WFLY-13697 > URL: https://issues.redhat.com/browse/WFLY-13697 > Project: WildFly > Issue Type: Bug > Components: CLI > Affects Versions: JBoss AS7 7.2.0.Final > Reporter: José Fernando Tepedino Martins > Assignee: Michal Petrov > Priority: Minor > Labels: CLI, JNDI > > With a JEE aplication in a WAR package, when starting a functionality, as a Batch Job, via CLI, CDI injection and JNDI lookup fail to find resources 'java:app/AppName' and 'java:module/ModuleName'. > For example, a job listener or other job artifact with the following code > {code:java} > @Resource(lookup="java:app/AppName") > private String applicationName;{code} > or > {code:java} > private String applicationName; > @PostConstruct > protected void initialize() throws NamingException { > applicationName = InitialContext.doLookup("java:app/AppName"); > }{code} > when the batch job is started from JBoss CLI, the following error will be logged: > {code:java} > javax.naming.NameNotFoundException: java:app/AppName > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5530) DMN strongly typed codegen Eclipse MP OpenAPI enum for String

by Kris Verlaenen (Jira)

[ https://issues.redhat.com/browse/DROOLS-5530?page=com.atlassian.jira.plug... ] Kris Verlaenen updated DROOLS-5530: ----------------------------------- Sprint: 2020 Week 28-30 (from Jul 6), 2020 Week 31-33 (from Jul 27) (was: 2020 Week 28-30 (from Jul 6)) > DMN strongly typed codegen Eclipse MP OpenAPI enum for String > ------------------------------------------------------------- > > Key: DROOLS-5530 > URL: https://issues.redhat.com/browse/DROOLS-5530 > Project: Drools > Issue Type: Feature Request > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > Priority: Major > Attachments: image-2020-07-24-13-59-42-492.png > > > When Strongly typed facility codegenerate any Java class based on the ItemDefinition from DMN, will annotate String type with the list of `allowedValues` as a Eclipse MP OpenAPI enum, when this information is available. > This way, any facility which inspect the MP OpenAPI annotation, can rely on this information for consistency and data validation. > Example: > !image-2020-07-24-13-59-42-492.png|thumbnail! -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5521) OutOfBound Exception for last DecisionTable cell

by Kris Verlaenen (Jira)

[ https://issues.redhat.com/browse/DROOLS-5521?page=com.atlassian.jira.plug... ] Kris Verlaenen updated DROOLS-5521: ----------------------------------- Sprint: 2020 Week 28-30 (from Jul 6), 2020 Week 31-33 (from Jul 27) (was: 2020 Week 28-30 (from Jul 6)) > OutOfBound Exception for last DecisionTable cell > ------------------------------------------------ > > Key: DROOLS-5521 > URL: https://issues.redhat.com/browse/DROOLS-5521 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.41.0.Final > Reporter: Jozef Marko > Assignee: Jozef Marko > Priority: Major > Labels: drools-tools, regression > Attachments: edit-last-cell-of-row-and-press-tab.webm > > > This issue is caused by DROOLS-5442. > It can be spotted when user start to edit last cell of DMN Decision table row and finish the edit mode by pressing TAB key. It causes an attempt to select next cell of the row and an exception is thrown. See the attached video. > h3. Acceptance criteria > Check pressing TAB when edit mode of last cell is active for: > - Guided Decision Table > - Test Scenario > - DMN Decision Table > - DMN Relation > - DMN Context > - DMN Function > - DMN Literal Expression > - DMN List -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5509) Date field in Guided rule template is not displaying correct date

by Kris Verlaenen (Jira)

[ https://issues.redhat.com/browse/DROOLS-5509?page=com.atlassian.jira.plug... ] Kris Verlaenen updated DROOLS-5509: ----------------------------------- Sprint: 2020 Week 28-30 (from Jul 6), 2020 Week 31-33 (from Jul 27) (was: 2020 Week 28-30 (from Jul 6)) > Date field in Guided rule template is not displaying correct date > ----------------------------------------------------------------- > > Key: DROOLS-5509 > URL: https://issues.redhat.com/browse/DROOLS-5509 > Project: Drools > Issue Type: Bug > Components: Guided Template Editor > Reporter: Toni Rikkola > Assignee: Toni Rikkola > Priority: Major > Labels: drools-tools > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 9 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 2020