September 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12575) Upgrade RESTEasy to 3.10.0.Final

by Ivo Studensky (Jira)

[ https://issues.jboss.org/browse/WFLY-12575?page=com.atlassian.jira.plugin... ] Ivo Studensky updated WFLY-12575: --------------------------------- Fix Version/s: (was: 18.0.0.Beta1) > Upgrade RESTEasy to 3.10.0.Final > -------------------------------- > > Key: WFLY-12575 > URL: https://issues.jboss.org/browse/WFLY-12575 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Ivo Studensky > Assignee: Alessio Soldano > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12575) Upgrade RESTEasy to 3.10.0.Final

by Ivo Studensky (Jira)

[ https://issues.jboss.org/browse/WFLY-12575?page=com.atlassian.jira.plugin... ] Ivo Studensky updated WFLY-12575: --------------------------------- Component/s: REST > Upgrade RESTEasy to 3.10.0.Final > -------------------------------- > > Key: WFLY-12575 > URL: https://issues.jboss.org/browse/WFLY-12575 > Project: WildFly > Issue Type: Component Upgrade > Components: REST > Reporter: Ivo Studensky > Assignee: Alessio Soldano > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12575) Upgrade RESTEasy to 3.10.0.Final

by Ivo Studensky (Jira)

Ivo Studensky created WFLY-12575: ------------------------------------ Summary: Upgrade RESTEasy to 3.10.0.Final Key: WFLY-12575 URL: https://issues.jboss.org/browse/WFLY-12575 Project: WildFly Issue Type: Component Upgrade Reporter: Ivo Studensky Assignee: Alessio Soldano Fix For: 18.0.0.Beta1 -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4674) Custom handlers, formatters and filters cause the server to crash if the log manager is on the boot class path

by Dustin Kut Moy Cheung (Jira)

[ https://issues.jboss.org/browse/WFCORE-4674?page=com.atlassian.jira.plugi... ] Dustin Kut Moy Cheung commented on WFCORE-4674: ----------------------------------------------- Thanks for creating the JIRA! Let me know how I can help with this! I'll happily be a guinea pig :) > Custom handlers, formatters and filters cause the server to crash if the log manager is on the boot class path > -------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-4674 > URL: https://issues.jboss.org/browse/WFCORE-4674 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Critical > Labels: OpenShift, jdk11 > > If the log manager is on the boot class path with Java 11, {{-Xbootclasspath/a:jboss-logmanager.jar}}, and a custom handler, formatter or filter is used the server will fail to boot as the log manager can't see the types in jboss-modules. This seems due to the fact that the log manager is on the boot class path and jboss-modules is on the system class path. > Example exception: > {code} > Failed to read or configure the org.jboss.logmanager.LogManager > java.lang.IllegalArgumentException: Failed to load module "org.jboss.logmanager" for formatter "JSON" > at org.jboss.logmanager.config.AbstractPropertyConfiguration.<init>(AbstractPropertyConfiguration.java:65) > at org.jboss.logmanager.config.FormatterConfigurationImpl.<init>(FormatterConfigurationImpl.java:30) > at org.jboss.logmanager.config.LogContextConfigurationImpl.addFormatterConfiguration(LogContextConfigurationImpl.java:172) > at org.jboss.logmanager.PropertyConfigurator.configureFormatter(PropertyConfigurator.java:631) > at org.jboss.logmanager.PropertyConfigurator.configureHandler(PropertyConfigurator.java:701) > at org.jboss.logmanager.PropertyConfigurator.configureLogger(PropertyConfigurator.java:583) > at org.jboss.logmanager.PropertyConfigurator.configure(PropertyConfigurator.java:521) > 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:523) > Caused by: java.lang.NoClassDefFoundError: org/jboss/modules/ModuleLoader > at org.jboss.logmanager.config.AbstractPropertyConfiguration$ModuleFinder.getClassLoader(AbstractPropertyConfiguration.java:556) > at org.jboss.logmanager.config.AbstractPropertyConfiguration.<init>(AbstractPropertyConfiguration.java:63) > ... 19 more > {code} -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBVFS-209) Jboss Not able to load cryptoj jar

by Tomaž Cerar (Jira)

[ https://issues.jboss.org/browse/JBVFS-209?page=com.atlassian.jira.plugin.... ] Tomaž Cerar closed JBVFS-209. ----------------------------- Resolution: Cannot Reproduce EAP 6.x does not use Undertow, and stacktrace indicates it happened on Undertow powered web server. > Jboss Not able to load cryptoj jar > ---------------------------------- > > Key: JBVFS-209 > URL: https://issues.jboss.org/browse/JBVFS-209 > Project: JBoss VFS > Issue Type: Bug > Reporter: Amulya Nidhi > Assignee: Tomaž Cerar > Priority: Minor > Attachments: hello.war > > > Jboss 6.3 Not able to load cryptoj jar -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-954) Check new sonar qube

by Filip Brychta (Jira)

Filip Brychta created SWSQE-954: ----------------------------------- Summary: Check new sonar qube Key: SWSQE-954 URL: https://issues.jboss.org/browse/SWSQE-954 Project: Kiali QE Issue Type: QE Task Reporter: Filip Brychta Hello all, The Central CI Team is excited to announce the release of SonarQube 7.8 (Community Edition) version on PSI OpenShift [1]. What is Sonarqube? SonarQube is an open-source platform for continuous inspection of code quality to perform automatic reviews with static analysis to detect bugs, code smells, and security vulnerabilities on 25+ programming languages. So far we have used SonarQube 6.7 (Community Edition) [2] and we still continue to support it. This sonar instance is deployed on two RHEV machines, one for UI, and one for DB (Postgresql). Enhancements in our new instance: - Sonar is running on two containers (sonar and Postgresql) on PSI OpenShift. - Login through Https protocol (to configure your sonar-scanner to work with https sonar server you can look here [3]). - SonarGo plugin is now supporting GoLint, GoVet, and GoMetaLinter. For more information, search here [4] The full Release Upgrade Notes are located here [5]. Almost all known plugins from the earlier version of Sonar are now installed in a more advanced version with new capabilities. Installed Plugins: - C++ (Community) - Community Branch Plugin - Git, Github Authentication and Gitlab - LDAP - Jacoco - SonarGo - SonarJava - SonarPython - SonarRuby There are many more plugins installed and this is of course only a partial list. All our Documentation and relevant links are hosted on the Central CI Confluence home page. Our Jump page is located here [6]. I encourage you to take a look and start using this new SonarQube instance! If you have any questions or concerns you can send an email directly to ci-ops-qe(a)redhat.com. Best Regards, Shay Shevach [1] https://ccit-sonarqube.cloud.paas.psi.redhat.com [2] http://sonar-server.lab.eng.rdu2.redhat.com [3] https://docs.engineering.redhat.com/display/CentralCI/Configure+Sonar-Sca... [4] https://docs.sonarqube.org/latest/analysis/external-issues [5] https://docs.sonarqube.org/latest/setup/upgrade-notes/ [6] https://docs.engineering.redhat.com/pages/viewpage.action?pageId=44543267 -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2382) Jgroup version 4.0.13.Final.jar is causing memory leaks

by Rashmi Acharya (Jira)

[ https://issues.jboss.org/browse/JGRP-2382?page=com.atlassian.jira.plugin.... ] Rashmi Acharya commented on JGRP-2382: -------------------------------------- We have changed the implementation from NAKACK to NAKACK2 and UNICAST3 in new JGroups version. MERGE protocol - <MERGE3 min_interval="3000" max_interval="5000" /> We need Both DistributionPropertyString and PropertyString in the product for load distribution and heartBeat features between nodes.. I am working with customer to upload the heap file for your analysis. > Jgroup version 4.0.13.Final.jar is causing memory leaks > ------------------------------------------------------- > > Key: JGRP-2382 > URL: https://issues.jboss.org/browse/JGRP-2382 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 4.0.13 > Environment: AIX machine 7.1 with JDK 1.8 > Reporter: Rashmi Acharya > Assignee: Bela Ban > Priority: Major > > We are observing a constant memory growth and leak with JGroup version 4.0.13 .. > One of our customer is having two node cluster environment and in one node we are observing org.Group.Messages which contain org.groups.Header and org.groups.Stack.ipAddress objects.. these are not getting cleared from memory.. > We dont see any exception related to Jgroups from logs and but it is causing a gradual emory growth and OOM. > Here is the Jgroups cluster configuration we have: > dynamic.cluster.property_string > <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd"> > <TCP bind_addr="&HOST_ADDR;" bind_port="&MULTICAST_NODE_PORT2;"/> > <TCPPING async_discovery="true" initial_hosts="&CLUSTER_INITIAL_HOSTS;" port_range="0" send_cache_on_join="true"/> > <MERGE3 min_interval="3000" max_interval="5000" /> > <FD_ALL timeout="20000" interval="15000"/> > <FD_SOCK/> > <FD timeout="5000" max_tries="48" /> > <VERIFY_SUSPECT timeout="1500"/> > <BARRIER/> > <pbcast.NAKACK2 use_mcast_xmit="false" discard_delivered_msgs="true"/> > <UNICAST3/> > <pbcast.STABLE desired_avg_gossip="20000" max_bytes="0" stability_delay="1000"/> > <pbcast.GMS print_local_addr="true" join_timeout="15000" /> > </config> > ================================= > dynamic.cluster.distribution_property_string > <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd"> > <TCP bind_port="&MULTICAST_NODE_PORT1;" /> > <TCPPING async_discovery="true" initial_hosts="&CLUSTER_INITIAL_HOSTS;" port_range="0" send_cache_on_join="true"/> > <MERGE3 min_interval="3000" max_interval="5000"/> > <FD_SOCK/> > <FD timeout="5000" max_tries="48"/> > <VERIFY_SUSPECT timeout="1500"/> > <BARRIER/> > <pbcast.NAKACK2 use_mcast_xmit="false" discard_delivered_msgs="true"/> > <UNICAST3/> > <pbcast.STABLE desired_avg_gossip="20000" max_bytes="0" stability_delay="1000" /> > <pbcast.GMS print_local_addr="true" join_timeout="5000"/> > </config> > ================================ > dynamic.cluster.lock.protocolStack > <config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:org:jgroups" xsi:schemaLocation="urn:org:jgroups http://www.jgroups.org/schema/jgroups.xsd"> > <TCP bind_addr="&HOST_ADDR;" bind_port="&MULTICAST_NODE_PORT3;"/> > <TCPPING async_discovery="true" initial_hosts="&CLUSTER_INITIAL_HOSTS;" port_range="0" send_cache_on_join="true"/> > <MERGE3 min_interval="3000" max_interval="5000"/> > <FD_ALL timeout="20000" interval="5000"/> > <FD timeout="5000" max_tries="48"/> > <VERIFY_SUSPECT timeout="1500"/> > <BARRIER/> > <pbcast.NAKACK2 use_mcast_xmit="false" discard_delivered_msgs="true"/> > <UNICAST3 /> <pbcast.STABLE desired_avg_gossip="20000" /> > <pbcast.GMS print_local_addr="true" join_timeout="5000"/> > <FRAG2 frag_size="8096"/> > <CENTRAL_LOCK2/> > </config> -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12461) Can't use smallrye-health without weld extension

by Florian Sailer (Jira)

[ https://issues.jboss.org/browse/WFLY-12461?page=com.atlassian.jira.plugin... ] Florian Sailer commented on WFLY-12461: --------------------------------------- Hey guys, any suggestions about a timeline ?! > Can't use smallrye-health without weld extension > ------------------------------------------------ > > Key: WFLY-12461 > URL: https://issues.jboss.org/browse/WFLY-12461 > Project: WildFly > Issue Type: Bug > Components: MP Health > Affects Versions: 17.0.1.Final > Reporter: Florian Sailer > Assignee: Jeff Mesnil > Priority: Major > > Since this commit in the smallrye implementation it was possible to use smallrye without CDI. > https://github.com/smallrye/smallrye-health/commit/a6a7812877d74d2c3f5b29... > I'm trying to migrate from Wildfly 15.0.1-Final to 17.0.1-Final, where the smallrye-health extension unfortunately needs weld to startup. It's not possbible for me to activate weld on my sever, because there are some problems using the org.apache.cxf.jaxrs framework with weld. > I am getting the following exception while starting: > 14:16:04,960 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/subsystem=microprofile-health-smallrye' are not available: > org.wildfly.weld; There are no known registration points which can provide this capability. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4550) openshift-ha-cep manages different or wrong versions of GAVs

by Massimiliano Dessi (Jira)

[ https://issues.jboss.org/browse/DROOLS-4550?page=com.atlassian.jira.plugi... ] Massimiliano Dessi commented on DROOLS-4550: -------------------------------------------- https://github.com/kiegroup/openshift-drools-hacep/pull/47 > openshift-ha-cep manages different or wrong versions of GAVs > ------------------------------------------------------------ > > Key: DROOLS-4550 > URL: https://issues.jboss.org/browse/DROOLS-4550 > Project: Drools > Issue Type: Bug > Reporter: Massimiliano Dessi > Assignee: Massimiliano Dessi > Priority: Critical > -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-953) ocp4-kqe2 cluster is stuck and not possible to remove

by Filip Brychta (Jira)

[ https://issues.jboss.org/browse/SWSQE-953?page=com.atlassian.jira.plugin.... ] Filip Brychta updated SWSQE-953: -------------------------------- Sprint: Kiali Sprint #28 > ocp4-kqe2 cluster is stuck and not possible to remove > ----------------------------------------------------- > > Key: SWSQE-953 > URL: https://issues.jboss.org/browse/SWSQE-953 > Project: Kiali QE > Issue Type: Bug > Reporter: Filip Brychta > Assignee: Filip Brychta > Priority: Major > Labels: infrastructure > > After mixing ocp 4.1 and 4.2 installation the ocp4-kqe2 is stuck and it's not possible to remove it even manually. -- This message was sent by Atlassian Jira (v7.13.5#713005)

6 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 September 2019