July 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-5065) Add a hook for deployment transformation

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFCORE-5065?page=com.atlassian.jira.plug... ] Brian Stansberry updated WFCORE-5065: ------------------------------------- Labels: EE9 (was: ) > Add a hook for deployment transformation > ---------------------------------------- > > Key: WFCORE-5065 > URL: https://issues.redhat.com/browse/WFCORE-5065 > Project: WildFly Core > Issue Type: Enhancement > Components: Deployment Scanner, Server > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > Labels: EE9 > Fix For: 13.0.0.Beta3 > > > Add an interface that the deployment scanner and DeploymentAddHandler can invoke to transform deployments from EE 8 to EE 9. Add an optional module dependency for the respective modules to provide an impl. > Having this in core ASAP will dists based on WF Core that want to provide an impl to do some without requiring core to provide this itself. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13546) Upgrade smallrye-open-api to 2.0.5

by Paul Ferraro (Jira)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13546) Upgrade smallrye-open-api to 2.0.5

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13546?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-13546: -------------------------------- Description: Fixes: [https://github.com/smallrye/smallrye-open-api/issues/349] [https://github.com/smallrye/smallrye-open-api/issues/353] [https://github.com/smallrye/smallrye-open-api/issues/359] Release notes: [https://github.com/smallrye/smallrye-open-api/releases/tag/2.0.0] [https://github.com/smallrye/smallrye-open-api/releases/tag/2.0.1|https://...] [https://github.com/smallrye/smallrye-open-api/releases/tag/2.0.2|https://...] [https://github.com/smallrye/smallrye-open-api/releases/tag/2.0.3|https://...] [https://github.com/smallrye/smallrye-open-api/releases/tag/2.0.4|https://...] [https://github.com/smallrye/smallrye-open-api/releases/tag/2.0.5|https://...] was: Fixes: [https://github.com/smallrye/smallrye-open-api/issues/349] [https://github.com/smallrye/smallrye-open-api/issues/353] [https://github.com/smallrye/smallrye-open-api/issues/359] > Upgrade smallrye-open-api to 2.0.5 > ---------------------------------- > > Key: WFLY-13546 > URL: https://issues.redhat.com/browse/WFLY-13546 > Project: WildFly > Issue Type: Component Upgrade > Components: MP OpenAPI > Affects Versions: 20.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > Fixes: > [https://github.com/smallrye/smallrye-open-api/issues/349] > [https://github.com/smallrye/smallrye-open-api/issues/353] > [https://github.com/smallrye/smallrye-open-api/issues/359] > > Release notes: > [https://github.com/smallrye/smallrye-open-api/releases/tag/2.0.0] > [https://github.com/smallrye/smallrye-open-api/releases/tag/2.0.1|https://...] > [https://github.com/smallrye/smallrye-open-api/releases/tag/2.0.2|https://...] > [https://github.com/smallrye/smallrye-open-api/releases/tag/2.0.3|https://...] > [https://github.com/smallrye/smallrye-open-api/releases/tag/2.0.4|https://...] > [https://github.com/smallrye/smallrye-open-api/releases/tag/2.0.5|https://...] -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13546) Upgrade smallrye-open-api to 2.0.5

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13546?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-13546: -------------------------------- Summary: Upgrade smallrye-open-api to 2.0.5 (was: Upgrade smallrye-open-api to 2.0.3) > Upgrade smallrye-open-api to 2.0.5 > ---------------------------------- > > Key: WFLY-13546 > URL: https://issues.redhat.com/browse/WFLY-13546 > Project: WildFly > Issue Type: Component Upgrade > Components: MP OpenAPI > Affects Versions: 20.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > Fixes: > [https://github.com/smallrye/smallrye-open-api/issues/349] > [https://github.com/smallrye/smallrye-open-api/issues/353] > [https://github.com/smallrye/smallrye-open-api/issues/359] -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

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

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFCORE-5053?page=com.atlassian.jira.plug... ] James Perkins commented on WFCORE-5053: --------------------------------------- [~rakesh.shah1977] Currently there is no way to get a patch for it. For WildFly there is only community support so any patching would need to be done on your own :) Also since this was considered a feature as it changed behavior it will not be in JBoss EAP until 7.4. > 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)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-13703) Increase the test coverage of LayersTestCase for the all layers case

by Yeray Borges Santana (Jira)

Yeray Borges Santana created WFLY-13703: ------------------------------------------- Summary: Increase the test coverage of LayersTestCase for the all layers case Key: WFLY-13703 URL: https://issues.redhat.com/browse/WFLY-13703 Project: WildFly Issue Type: Task Components: Build System, Test Suite Reporter: Yeray Borges Santana Assignee: Yeray Borges Santana The LayersTestCase verifies the following: * Verifies the provisioned modules are the expected ones. * Verifies the provisioned server starts successfully. Currently, we have a server provision under test that doesn't add all the layers, the idea of this task is to supply one server provisioning including all the available layers. The WildFly Galleon Layers have an inheritance structure where some layers already include others, instead of check what is already included, the idea on this task is to include all, even if they are already included by another one, Galleon will take care of merging them. In the future, when a new layer is added, we have to add to this all-in-one provision. The idea is to have one all-in-one provision for jpa and all-in-one provision for jpa-distribute. The similar task could be done if we detect additional mutually excludable layers. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[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)

4 years, 1 month

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)

4 years, 1 month

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)

4 years, 1 month

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)

4 years, 1 month

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 July 2020