March 2020 - mod_cluster-issues - Jboss List Archives

[JBoss JIRA] (MODCLUSTER-633) AdvertiseListenerImplTestCase fails intermittently

by Jean-Frederic Clere (Jira)

[ https://issues.redhat.com/browse/MODCLUSTER-633?page=com.atlassian.jira.p... ] Jean-Frederic Clere closed MODCLUSTER-633. ------------------------------------------ > AdvertiseListenerImplTestCase fails intermittently > -------------------------------------------------- > > Key: MODCLUSTER-633 > URL: https://issues.redhat.com/browse/MODCLUSTER-633 > Project: mod_cluster > Issue Type: Bug > Components: Core & Container Integration (Java) > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > Fix For: 2.0.0.Alpha1 > > > This is because org.jboss.modcluster.TestUtils#generateAdvertisePacketData generates wrong packet: after converting to java.lang.String#format(java.lang.String, java.lang.Object...) if the md5 hash begins with 0-es, its not padded. > Affected version 8ccb6f3aac71899777347e595bf48626fd948db8 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-639) proxy reset requests can allow for other MCMPs to bad proxy

by Jean-Frederic Clere (Jira)

[ https://issues.redhat.com/browse/MODCLUSTER-639?page=com.atlassian.jira.p... ] Jean-Frederic Clere closed MODCLUSTER-639. ------------------------------------------ > proxy reset requests can allow for other MCMPs to bad proxy > ----------------------------------------------------------- > > Key: MODCLUSTER-639 > URL: https://issues.redhat.com/browse/MODCLUSTER-639 > Project: mod_cluster > Issue Type: Bug > Components: Core & Container Integration (Java) > Affects Versions: 1.3.8.Final > Reporter: Aaron Ogburn > Assignee: Radoslav Husar > Priority: Critical > Fix For: 1.4.0.Final, 2.0.0.Alpha1, 1.3.9.Final > > > There's a timing issue between proxy reset requests and other MCMPs. This can allow for some severe start up delays if there is a configured proxy that is down or unresponsive. Start up is seen to be stalled as it tries to send enable-apps to the bad proxy: > {code} > "ServerService Thread Pool -- 72" #134 prio=5 os_prio=0 tid=0x00007f84581fa9f0 nid=0x6718 runnable [0x00007f83c1561000] > java.lang.Thread.State: RUNNABLE > at java.net.SocketInputStream.socketRead0(Native Method) > at java.net.SocketInputStream.socketRead(SocketInputStream.java:116) > at java.net.SocketInputStream.read(SocketInputStream.java:171) > at java.net.SocketInputStream.read(SocketInputStream.java:141) > at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284) > at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326) > at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178) > - locked <0x00000000eb0a4700> (a java.io.InputStreamReader) > at java.io.InputStreamReader.read(InputStreamReader.java:184) > at java.io.BufferedReader.fill(BufferedReader.java:161) > at java.io.BufferedReader.readLine(BufferedReader.java:324) > - locked <0x00000000eb0a4700> (a java.io.InputStreamReader) > at java.io.BufferedReader.readLine(BufferedReader.java:389) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:529) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:605) > - locked <0x00000000fcaac598> (a org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler$Proxy) > at org.jboss.modcluster.mcmp.impl.DefaultMCMPHandler.sendRequest(DefaultMCMPHandler.java:429) > at org.jboss.modcluster.ModClusterService.enable(ModClusterService.java:375) > at org.jboss.modcluster.ModClusterService.start(ModClusterService.java:361) > at org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter.onDeploymentStart(UndertowEventHandlerAdapter.java:136) > - locked <0x00000000fcaac7a8> (a org.wildfly.mod_cluster.undertow.UndertowEventHandlerAdapter) > at org.wildfly.extension.undertow.Host$1.invoke(Host.java:192) > at org.wildfly.extension.undertow.UndertowService.fireEvent(UndertowService.java:249) > - locked <0x00000000fcaa4598> (a java.util.Collections$SynchronizedList) > at org.wildfly.extension.undertow.Host.registerDeployment(Host.java:189) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:103) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82) > {code} > This can occur because a reset request places the proxy back in an OK state, which then allows the ENABLEs or any MCMP through. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-638) Mod_cluster listener doesn't start: misleading docs

by Jean-Frederic Clere (Jira)

[ https://issues.redhat.com/browse/MODCLUSTER-638?page=com.atlassian.jira.p... ] Jean-Frederic Clere closed MODCLUSTER-638. ------------------------------------------ > Mod_cluster listener doesn't start: misleading docs > --------------------------------------------------- > > Key: MODCLUSTER-638 > URL: https://issues.redhat.com/browse/MODCLUSTER-638 > Project: mod_cluster > Issue Type: Bug > Components: Documentation & Demos > Affects Versions: 1.4.0.Final, 2.0.0.Alpha1 > Environment: Tomcat 9.0.2, Windows, Oracle JDK 8 > Reporter: Michal Karm > Assignee: Radoslav Husar > Priority: Blocker > Labels: ux > Fix For: 2.0.0.Alpha1, 1.4.1.Final > > > h3. Old listener conf from docs fails to start, automagic elimination aftermath > h4. server.xml > {code} > <Listener className="org.jboss.modcluster.container.catalina.standalone.ModClusterListener" connectorPort="8009"/> > {code} > h4. Fails to start Tomcat server > {code} > INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version: Apache Tomcat/9.0.2 > INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server built: Nov 25 2017 21:08:02 UTC > INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server number: 9.0.2.0 > INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Name: Windows NT (unknown) > INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Version: 10.0 > INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Architecture: amd64 > INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Java Home: C:\Program Files\jdk1.8.0_last\jre > INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Version: 1.8.0_121-b13 > INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor: Oracle Corporation > INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE: C:\apache-tomcat-9.0.2-windows-x64\apache-tomcat-9.0.2 > INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME: C:\apache-tomcat-9.0.2-windows-x64\apache-tomcat-9.0.2 > INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.config.file=C:\apache-tomcat-9.0.2-windows-x64\apache-tomcat-9.0.2\conf\logging.properties > INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager > INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djdk.tls.ephemeralDHKeySize=2048 > INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.protocol.handler.pkgs=org.apache.catalina.webresources > INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dignore.endorsed.dirs= > INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.base=C:\apache-tomcat-9.0.2-windows-x64\apache-tomcat-9.0.2 > INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.home=C:\apache-tomcat-9.0.2-windows-x64\apache-tomcat-9.0.2 > INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.io.tmpdir=C:\apache-tomcat-9.0.2-windows-x64\apache-tomcat-9.0.2\temp > INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent Loaded APR based Apache Tomcat Native library [1.2.16] using APR version [1.6.3]. > INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true]. > INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent APR/OpenSSL configuration: useAprConnector [false], useOpenSSL [true] > INFO [main] org.apache.catalina.core.AprLifecycleListener.initializeSSL OpenSSL successfully initialized [OpenSSL 1.0.2m 2 Nov 2017] > INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["http-nio-8080"] > INFO [main] org.apache.tomcat.util.net.NioSelectorPool.getSharedSelector Using a shared selector for servlet write/read > INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["ajp-nio-8009"] > INFO [main] org.apache.tomcat.util.net.NioSelectorPool.getSharedSelector Using a shared selector for servlet write/read > INFO [main] org.jboss.modcluster.ModClusterService.init MODCLUSTER000001: Initializing mod_cluster version 2.0.0.Alpha1-SNAPSHOT > SEVERE [main] org.apache.catalina.startup.Catalina.load Catalina.start > org.apache.catalina.LifecycleException: Failed to initialize component [StandardServer[8005]] > at org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBase.java:441) > at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:139) > at org.apache.catalina.startup.Catalina.load(Catalina.java:622) > at org.apache.catalina.startup.Catalina.load(Catalina.java:645) > 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.apache.catalina.startup.Bootstrap.load(Bootstrap.java:309) > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:492) > Caused by: java.lang.RuntimeException: MODCLUSTER000valid advertise interface configured! Disabling multicast advertise mechanism. > at org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl.initializeDatagramChannel(AdvertiseListenerImpl.java:133) > at org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl.start(AdvertiseListenerImpl.java:140) > at org.jboss.modcluster.advertise.impl.AdvertiseListenerImpl.<init>(AdvertiseListenerImpl.java:102) > at org.jboss.modcluster.advertise.impl.AdvertiseListenerFactoryImpl.createListener(AdvertiseListenerFactoryImpl.java:38) > at org.jboss.modcluster.ModClusterService.init(ModClusterService.java:163) > at org.jboss.modcluster.container.tomcat.TomcatEventHandlerAdapter.init(TomcatEventHandlerAdapter.java:249) > at org.jboss.modcluster.container.tomcat.TomcatEventHandlerAdapter.lifecycleEvent(TomcatEventHandlerAdapter.java:187) > at org.jboss.modcluster.container.tomcat.ModClusterListener.lifecycleEvent(ModClusterListener.java:118) > at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123) > at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:424) > at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:137) > ... 8 more > INFO [main] org.apache.catalina.startup.Catalina.load Initialization processed in 1724 ms > SEVERE [main] org.apache.catalina.startup.Catalina.start The required Server component failed to start so Tomcat is unable to start. > org.apache.catalina.LifecycleException: An invalid Lifecycle transition was attempted ([before_stop]) for component [StandardService[Catalina]] in state [INITIALIZED] > at org.apache.catalina.util.LifecycleBase.invalidTransition(LifecycleBase.java:431) > at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:244) > at org.apache.catalina.core.StandardServer.stopInternal(StandardServer.java:791) > at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257) > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:175) > at org.apache.catalina.startup.Catalina.start(Catalina.java:671) > 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.apache.catalina.startup.Bootstrap.start(Bootstrap.java:353) > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:493) > WARNING [main] org.apache.catalina.util.LifecycleBase.destroy Calling stop() on failed component [StandardServer[80trigger clean-up did not complete. > org.apache.catalina.LifecycleException: An invalid Lifecycle transition was attempted ([before_stop]) for component [StandardService[Catalina]] in state [INITIALIZED] > at org.apache.catalina.util.LifecycleBase.invalidTransition(LifecycleBase.java:431) > at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:244) > at org.apache.catalina.core.StandardServer.stopInternal(StandardServer.java:791) > at org.apache.catalina.util.LifecycleBase.stop(LifecycleBase.java:257) > at org.apache.catalina.util.LifecycleBase.destroy(LifecycleBase.java:293) > at org.apache.catalina.startup.Catalina.start(Catalina.java:675) > 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.apache.catalina.startup.Bootstrap.start(Bootstrap.java:353) > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:493) > INFO [main] org.jboss.modcluster.ModClusterService.shutdown MODCLUSTER000002: Initiating mod_cluster shutdown > INFO [main] org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler ["http-nio-8080"] > INFO [main] org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler ["ajp-nio-8009"] > {code} > h2. Call to action > Please, fix the docs: > * [README.md|https://github.com/modcluster/mod_cluster/blame/7e7dcbfef3bd357...] > * [Documentation|https://github.com/modcluster/modcluster.io/blame/master/do...] > To save you some attributes lookup and copy pasting, you might want to take a look at this [complete list|https://github.com/Karm/jws-3-tomcat-8-mod_cluster/blob/master/serve...]. > I guess at least this should find its way into the docs, give or take: > {code} > <Listener className="org.jboss.modcluster.container.catalina.standalone.ModClusterListener" > advertise="true" > advertiseInterface="172.16.27.10" > advertiseGroupAddress="224.0.1.105" > advertisePort="23364" > connectorPort="8009" > /> > {code} plus the message in the log must be improved. A random user has no chance to understand what the listener wants - it just looks as if it disabled advertising:{code} java.lang.RuntimeException: MODCLUSTER000valid advertise interface configured! Disabling multicast advertise mechanism.{code}, while in fact the whole Tomcat goes down. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-642) Support JDK10 build 10+44

by Jean-Frederic Clere (Jira)

[ https://issues.redhat.com/browse/MODCLUSTER-642?page=com.atlassian.jira.p... ] Jean-Frederic Clere closed MODCLUSTER-642. ------------------------------------------ > Support JDK10 build 10+44 > ------------------------- > > Key: MODCLUSTER-642 > URL: https://issues.redhat.com/browse/MODCLUSTER-642 > Project: mod_cluster > Issue Type: Feature Request > Components: Core & Container Integration (Java) > Affects Versions: 1.3.8.Final, 1.4.0.Alpha1, 2.0.0.Alpha1 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > Labels: jdk10 > Fix For: 1.4.0.Final, 2.0.0.Alpha1, 1.3.9.Final > > > First JDK10 releases are out. > Go get the binaries http://jdk.java.net/10/ > {quote} > ---------- Forwarded message ---------- > From: Rory O'Donnell <rory.odonnell(a)oracle.com> > Date: Tue, Feb 13, 2018 at 11:25 AM > Subject: [wildfly-dev] JDK 10: First Release Candidate - JDK 10 b43 > To: wildfly-dev(a)lists.jboss.org > Hi Jason/Tomaz, > JDK 10 build 43 is our first JDK 10 Release Candidate [1] > JDK 10 Early Access build 43 is available at : - jdk.java.net/10/ > Notable changes since previous email. > build 43 > JDK-8194764 - javac incorrectly flags deprecated for removal imports > JDK-8196678 - avoid printing uninitialized buffer in os::print_memory_info on AIX > JDK-8195837 - (tz) Upgrade time-zone data to tzdata2018c > Bug fixes reported by Open Source Projects : > JDK-8196296 Lucene test crashes C2 compilation > Security Manager Survey > If you have written or maintain code that uses the SecurityManager or related APIs such as the AccessController, > then we would appreciate if you would complete this survey: https://www.surveymonkey.com/r/RSGMF3K > More info on the survey [2] > Regards, > Rory > [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-February/000742.html > [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-February/000649.html > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > {quote} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-643) Misleading JavaDoc for SPI Container Engine

by Jean-Frederic Clere (Jira)

[ https://issues.redhat.com/browse/MODCLUSTER-643?page=com.atlassian.jira.p... ] Jean-Frederic Clere closed MODCLUSTER-643. ------------------------------------------ > Misleading JavaDoc for SPI Container Engine > ------------------------------------------- > > Key: MODCLUSTER-643 > URL: https://issues.redhat.com/browse/MODCLUSTER-643 > Project: mod_cluster > Issue Type: Bug > Components: Core & Container Integration (Java) > Affects Versions: 1.3.8.Final, 1.4.0.Alpha1 > Reporter: Michal Herda > Assignee: Radoslav Husar > Priority: Trivial > Fix For: 2.0.0.Alpha1 > > > https://github.com/modcluster/mod_cluster/blob/7e4dadf03df78f05bbf06af698... > {code} > /** > * The connector to which this engine uses to communicate with its proxies. > * > * @return the connector used by mod_cluster > */ > Connector getProxyConnector(); > /** > * The connector to which this engine uses to communicate with its proxies. > * > * @return the connector used by mod_cluster > */ > Iterable<Connector> getConnectors(); > {code} > From what I see and understand from the code, the javadoc for getConnectors() does not reflect its actual purpose - it seems like a copypaste from getProxyConnector(). I am not competent enough to write a proper JavaDoc myself through - please support me with it. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-644) Implement mod_cluster Jetty integration

by Jean-Frederic Clere (Jira)

[ https://issues.redhat.com/browse/MODCLUSTER-644?page=com.atlassian.jira.p... ] Jean-Frederic Clere closed MODCLUSTER-644. ------------------------------------------ Resolution: Won't Do > Implement mod_cluster Jetty integration > --------------------------------------- > > Key: MODCLUSTER-644 > URL: https://issues.redhat.com/browse/MODCLUSTER-644 > Project: mod_cluster > Issue Type: Feature Request > Components: Core & Container Integration (Java) > Reporter: Michal Herda > Priority: Major > Fix For: Awaiting Volunteers > > > According to https://developer.jboss.org/thread/252385 : > {quote} > A Jetty module would simply need to implement the interfaces found in the mod_cluster-container-spi module. > {quote} > The interfaces in question are at https://github.com/modcluster/mod_cluster/tree/master/container/spi/src/m... > If I wanted to implement this myself, what would be required from my side to start working on this? What suggested reading should I do and what JBoss/Jetty concepts must I understand before trying to implement mod_cluster integration in Jetty? > This is a mirror of the GitHub issue at https://github.com/eclipse/jetty.project/issues/2261 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-645) Different handling of max-attempts parameter on Undertow and httpd implementation

by Jean-Frederic Clere (Jira)

[ https://issues.redhat.com/browse/MODCLUSTER-645?page=com.atlassian.jira.p... ] Jean-Frederic Clere closed MODCLUSTER-645. ------------------------------------------ > Different handling of max-attempts parameter on Undertow and httpd implementation > --------------------------------------------------------------------------------- > > Key: MODCLUSTER-645 > URL: https://issues.redhat.com/browse/MODCLUSTER-645 > Project: mod_cluster > Issue Type: Task > Affects Versions: 1.3.5.Final > Reporter: Jan Kasik > Assignee: Radoslav Husar > Priority: Critical > > The behavior of balancer is different on httpd in comparsion with Undertow implementation when max-attempts parameter is set. > * *Undertow*: max-attempts is total count of requests made by balancer in failover scenario. When max-attemps is set to 1 and target worker fails after first attempt made by balancer, no further attempts are made. > * *httpd*: max-attempts is count of retries made by balancer after first attempt fails. When max-attempts is set to 1 and target worker fails after first attempt made by balancer, second worker is chosen and request is sent towards it. > This doesn't seem right and I suggest to unify behavior across implementations. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-649) Support JDK11 build build 11-ea+3

by Jean-Frederic Clere (Jira)

[ https://issues.redhat.com/browse/MODCLUSTER-649?page=com.atlassian.jira.p... ] Jean-Frederic Clere closed MODCLUSTER-649. ------------------------------------------ > Support JDK11 build build 11-ea+3 > --------------------------------- > > Key: MODCLUSTER-649 > URL: https://issues.redhat.com/browse/MODCLUSTER-649 > Project: mod_cluster > Issue Type: Task > Components: Core & Container Integration (Java) > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > Fix For: 2.0.0.Alpha1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-648) Upgrade jboss-logging to 3.3.2.Final

by Jean-Frederic Clere (Jira)

[ https://issues.redhat.com/browse/MODCLUSTER-648?page=com.atlassian.jira.p... ] Jean-Frederic Clere closed MODCLUSTER-648. ------------------------------------------ > Upgrade jboss-logging to 3.3.2.Final > ------------------------------------ > > Key: MODCLUSTER-648 > URL: https://issues.redhat.com/browse/MODCLUSTER-648 > Project: mod_cluster > Issue Type: Component Upgrade > Components: Core & Container Integration (Java) > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > Fix For: 2.0.0.Alpha1 > > > Changelog https://github.com/jboss-logging/jboss-logging/tree/3.3.2.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years

1
0
0 / 0

[JBoss JIRA] (MODCLUSTER-647) Upgrade jboss-logging-processor to 2.1.0.Final

by Jean-Frederic Clere (Jira)

[ https://issues.redhat.com/browse/MODCLUSTER-647?page=com.atlassian.jira.p... ] Jean-Frederic Clere closed MODCLUSTER-647. ------------------------------------------ > Upgrade jboss-logging-processor to 2.1.0.Final > ---------------------------------------------- > > Key: MODCLUSTER-647 > URL: https://issues.redhat.com/browse/MODCLUSTER-647 > Project: mod_cluster > Issue Type: Component Upgrade > Components: Core & Container Integration (Java) > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > Fix For: 2.0.0.Alpha1 > > > Needed to support JDK11 EA > Changelog: https://github.com/jboss-logging/jboss-logging-tools/tree/2.1.0.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

mod_cluster-issues March 2020