April 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFWIP-317) [EAP7-1457] backward compatibility breaking change in EAP Operator API

by Petr Kremensky (Jira)

[ https://issues.redhat.com/browse/WFWIP-317?page=com.atlassian.jira.plugin... ] Petr Kremensky commented on WFWIP-317: -------------------------------------- Note we've already released EAP Operator release 1.0 twice: 1) https://errata.devel.redhat.com/advisory/48030 RHEA-2019:4236-04 EAP Operator release 1.0 - "jboss-eap-7-eap73-operator-container-1.0-7" image * QE gave a sign off to this https://mojo.redhat.com/docs/DOC-1212528 as EAP Operator release 1.0 * was claimed to be fully supported http://postoffice.corp.redhat.com/archives/eap-pm-list/2019-December/msg0... * but ultimately switched to TP https://issues.redhat.com/browse/EAP7-1258?focusedCommentId=13941877&page... 2) https://errata.devel.redhat.com/advisory/53172 RHEA-2020:1329-04 EAP Operator release 1.0 - "jboss-eap-7-eap73-operator-container-1.0-8" image * https://issues.redhat.com/browse/JBEAP-19105 * Release Category: Generally Available https://catalog.redhat.com/software/containers/detail/5dc0529ebed8bd164af... > [EAP7-1457] backward compatibility breaking change in EAP Operator API > ---------------------------------------------------------------------- > > Key: WFWIP-317 > URL: https://issues.redhat.com/browse/WFWIP-317 > Project: WildFly WIP > Issue Type: Quality Risk > Components: OpenShift > Reporter: Petr Kremensky > Assignee: Jeff Mesnil > Priority: Blocker > > [EAP Operator release 1.0|https://catalog.redhat.com/software/containers/detail/5dc0529ebed8bd1...] > * Release Category: Generally Available > * https://errata.devel.redhat.com/advisory/53172 > https://github.com/wildfly/wildfly-operator/pull/136 is into introduce a breaking change in API (see https://github.com/wildfly/wildfly-operator/pull/136#issuecomment-620584823). The reasoning for this is that the current version of API is "wildfly.org/v1alpha1" so can still can afford to do it (see https://github.com/wildfly/wildfly-operator/pull/136#issuecomment-620590664). > Although I personally think that https://issues.redhat.com/browse/EAP7-1457 is a good improvement, I do not (and as a QE I even cannot) like the fact that we can break the existing user deployments by breaking the API compatibility with 1.0 Final EAP Operator release (although our operator is still pretty young and I'm not sure how many deployments that would actually be). > We should have an explicit approval from PM/GSS in order to carry on - breaking the API compatibility by https://github.com/wildfly/wildfly-operator/pull/136 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13358) Tests for WFCORE-4950 - Regression: Legacy Ldap Realm securing EJB with JDK8 not working

by Ricardo Martin Camarero (Jira)

[ https://issues.redhat.com/browse/WFLY-13358?page=com.atlassian.jira.plugi... ] Ricardo Martin Camarero updated WFLY-13358: ------------------------------------------- Summary: Tests for WFCORE-4950 - Regression: Legacy Ldap Realm securing EJB with JDK8 not working (was: Regression: Legacy Ldap Realm securing EJB with JDK8 not working) > Tests for WFCORE-4950 - Regression: Legacy Ldap Realm securing EJB with JDK8 not working > ---------------------------------------------------------------------------------------- > > Key: WFLY-13358 > URL: https://issues.redhat.com/browse/WFLY-13358 > Project: WildFly > Issue Type: Bug > Components: EJB, Security > Reporter: Darran Lofthouse > Assignee: Ricardo Martin Camarero > Priority: Critical > Labels: downstream_dependency > Fix For: 19.1.0.Final, 20.0.0.Beta1 > > > This is likely to actually be a WFCORE issue but as this is fixed a test case to reproduce should be added to the testsuite if appropriate. > So far this seems a fairly generic issue an since WildFly 17 we must have run the testsuite against Java 8 100s if not 1000s of times so it is not appropriate to be reliant on an internal testsuite to detect the issue nine months or more later. > The following issue describes the issue in relation to EAP: - > https://issues.redhat.com/browse/JBEAP-19195 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4950) Regression: Legacy Ldap Realm securing EJB with JDK8 not working

by Ricardo Martin Camarero (Jira)

Ricardo Martin Camarero created WFCORE-4950: ----------------------------------------------- Summary: Regression: Legacy Ldap Realm securing EJB with JDK8 not working Key: WFCORE-4950 URL: https://issues.redhat.com/browse/WFCORE-4950 Project: WildFly Core Issue Type: Bug Components: Security Affects Versions: 12.0.0.Beta1 Reporter: Ricardo Martin Camarero Assignee: Ricardo Martin Camarero WFCORE issue related to JBEAP-19195. The root exception is the following: {noformat} javax.naming.NamingException: WFLYNAM0027: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "org.wildfly.extension.io" version 12.0.0.Beta1 from local module loader @5f2108b5 (finder: local module finder @31a5c39e (roots: /home/rmartinc/wildfly-20.0.0.Beta1-SNAPSHOT/modules,/home/rmartinc/wildfly-20.0.0.Beta1-SNAPSHOT/modules/system/layers/base)) [Root exception is java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.io" version 12.0.0.Beta1 from local module loader @5f2108b5 (finder: local module finder @31a5c39e (roots: /home/rmartinc/wildfly-20.0.0.Beta1-SNAPSHOT/modules,/home/rmartinc/wildfly-20.0.0.Beta1-SNAPSHOT/modules/system/layers/base))]] at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:120) at org.jboss.as.naming.InitialContext.init(InitialContext.java:101) at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154) at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:91) at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43) at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313) at javax.naming.InitialContext.init(InitialContext.java:244) at javax.naming.InitialContext.<init>(InitialContext.java:216) at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:101) at org.jboss.as.domain.management.connections.ldap.LdapConnectionManagerService.getConnection(LdapConnectionManagerService.java:272) at org.jboss.as.domain.management.connections.ldap.LdapConnectionManagerService.getConnection(LdapConnectionManagerService.java:184) at org.jboss.as.domain.management.connections.ldap.LdapConnectionManagerService.getConnection(LdapConnectionManagerService.java:180) at org.jboss.as.domain.management.security.LdapConnectionHandler.getConnection(LdapConnectionHandler.java:78) at org.jboss.as.domain.management.security.LdapUserSearcherFactory$LdapUserSearcherImpl.search(LdapUserSearcherFactory.java:125) at org.jboss.as.domain.management.security.LdapUserSearcherFactory$LdapUserSearcherImpl.search(LdapUserSearcherFactory.java:66) at org.jboss.as.domain.management.security.LdapCacheService$NoCacheCache.search(LdapCacheService.java:232) at org.jboss.as.domain.management.security.UserLdapCallbackHandler$SecurityRealmImpl.getRealmIdentity(UserLdapCallbackHandler.java:339) at org.jboss.as.domain.management.security.SecurityRealmService$SharedStateSecurityRealm.getRealmIdentity(SecurityRealmService.java:776) at org.wildfly.security.auth.server.ServerAuthenticationContext.assignName(ServerAuthenticationContext.java:1197) at org.wildfly.security.auth.server.ServerAuthenticationContext$UnassignedState.setPrincipal(ServerAuthenticationContext.java:1726) at org.wildfly.security.auth.server.ServerAuthenticationContext.setAuthenticationPrincipal(ServerAuthenticationContext.java:410) at org.wildfly.security.auth.server.ServerAuthenticationContext.setAuthenticationName(ServerAuthenticationContext.java:384) at org.wildfly.security.auth.server.ServerAuthenticationContext.setAuthenticationName(ServerAuthenticationContext.java:368) at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:912) at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:853) at org.wildfly.security.auth.callback.SocketAddressQueryCallbackHandler.handle(SocketAddressQueryCallbackHandler.java:57) at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.lambda$createSaslServer$0(TrustManagerSaslServerFactory.java:105) at org.wildfly.security.sasl.plain.PlainSaslServer.evaluateResponse(PlainSaslServer.java:118) at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1.evaluateResponse(AuthenticationCompleteCallbackSaslServerFactory.java:58) at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer.evaluateResponse(AuthenticationTimeoutSaslServerFactory.java:110) at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1.evaluateResponse(SecurityIdentitySaslServerFactory.java:59) at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:245) at org.xnio.sasl.SaslUtils.evaluateResponse(SaslUtils.java:217) at org.jboss.remoting3.remote.ServerConnectionOpenListener$AuthStepRunnable.run(ServerConnectionOpenListener.java:484) at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:991) at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1348) at java.lang.Thread.run(Thread.java:748) Caused by: java.lang.ClassNotFoundException: com.sun.jndi.ldap.LdapCtxFactory from [Module "org.wildfly.extension.io" version 12.0.0.Beta1 from local module loader @5f2108b5 (finder: local module finder @31a5c39e (roots: /home/rmartinc/wildfly-20.0.0.Beta1-SNAPSHOT/modules,/home/rmartinc/wildfly-20.0.0.Beta1-SNAPSHOT/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:348) at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:115) ... 40 more {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13358) Regression: Legacy Ldap Realm securing EJB with JDK8 not working

by Ricardo Martin Camarero (Jira)

[ https://issues.redhat.com/browse/WFLY-13358?page=com.atlassian.jira.plugi... ] Ricardo Martin Camarero reassigned WFLY-13358: ---------------------------------------------- Assignee: Ricardo Martin Camarero > Regression: Legacy Ldap Realm securing EJB with JDK8 not working > ---------------------------------------------------------------- > > Key: WFLY-13358 > URL: https://issues.redhat.com/browse/WFLY-13358 > Project: WildFly > Issue Type: Bug > Components: EJB, Security > Reporter: Darran Lofthouse > Assignee: Ricardo Martin Camarero > Priority: Critical > Labels: downstream_dependency > Fix For: 19.1.0.Final, 20.0.0.Beta1 > > > This is likely to actually be a WFCORE issue but as this is fixed a test case to reproduce should be added to the testsuite if appropriate. > So far this seems a fairly generic issue an since WildFly 17 we must have run the testsuite against Java 8 100s if not 1000s of times so it is not appropriate to be reliant on an internal testsuite to detect the issue nine months or more later. > The following issue describes the issue in relation to EAP: - > https://issues.redhat.com/browse/JBEAP-19195 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-317) [EAP7-1457] backward compatibility breaking change in EAP Operator API

by Petr Kremensky (Jira)

Petr Kremensky created WFWIP-317: ------------------------------------ Summary: [EAP7-1457] backward compatibility breaking change in EAP Operator API Key: WFWIP-317 URL: https://issues.redhat.com/browse/WFWIP-317 Project: WildFly WIP Issue Type: Quality Risk Components: OpenShift Reporter: Petr Kremensky Assignee: Jeff Mesnil [EAP Operator release 1.0|https://catalog.redhat.com/software/containers/detail/5dc0529ebed8bd1...] * Release Category: Generally Available * https://errata.devel.redhat.com/advisory/53172 https://github.com/wildfly/wildfly-operator/pull/136 is into introduce a breaking change in API (see https://github.com/wildfly/wildfly-operator/pull/136#issuecomment-620584823). The reasoning for this is that the current version of API is "wildfly.org/v1alpha1" so can still can afford to do it (see https://github.com/wildfly/wildfly-operator/pull/136#issuecomment-620590664). Although I personally think that https://issues.redhat.com/browse/EAP7-1457 is a good improvement, I do not (and as a QE I even cannot) like the fact that we can break the existing user deployments by breaking the API compatibility with 1.0 Final EAP Operator release (although our operator is still pretty young and I'm not sure how many deployments that would actually be). We should have an explicit approval from PM/GSS in order to carry on - breaking the API compatibility by https://github.com/wildfly/wildfly-operator/pull/136 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5097) @Startup @Singleton Beans Constructed Multiple Times

by Panagiotis Sotiropoulos (Jira)

[ https://issues.redhat.com/browse/WFLY-5097?page=com.atlassian.jira.plugin... ] Panagiotis Sotiropoulos reassigned WFLY-5097: --------------------------------------------- Assignee: Panagiotis Sotiropoulos > @Startup @Singleton Beans Constructed Multiple Times > ---------------------------------------------------- > > Key: WFLY-5097 > URL: https://issues.redhat.com/browse/WFLY-5097 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 9.0.1.Final > Environment: All > Reporter: Davide Crudo > Assignee: Panagiotis Sotiropoulos > Priority: Major > Attachments: singleton.zip > > > When using @Startup and/or @Singleton to start a Bean on server startup, everytime a method is accessed or the bean is injected with @EJB, both Constructor and @Postconstruct are executed. > This happens multiple times, each time any component uses the Singleton bean. > This seems similar to an issue reported for JBOSS AS 7.x (see forum link reference below) -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2437) Log local_addr and name in JChannel

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2437?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2437: --------------------------- Fix Version/s: 5.0.0.Alpha6 > Log local_addr and name in JChannel > ----------------------------------- > > Key: JGRP-2437 > URL: https://issues.redhat.com/browse/JGRP-2437 > Project: JGroups > Issue Type: Enhancement > Reporter: Diego Lovison > Assignee: Diego Lovison > Priority: Minor > Fix For: 5.0.0.Alpha6 > > > As a developer I would like to know what is the local_address ( the value printed in the log ) and what will be the address sent over the network ( the value that will be captured by TShark ) > When running a benchmark in the perf lab we start running tshark after the initial load. In this case, in the tshark dump we won't have the PING request. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4949) Expose the original task in RequestController.QueuedTask

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFCORE-4949?page=com.atlassian.jira.plug... ] Cheng Fang updated WFCORE-4949: ------------------------------- Description: org.wildfly.extension.requestcontroller.RequestController.QueuedTask runRequest() method wraps the original task as a new Runnable, and pass it back to the caller's {{Executor}} for execution. In some cases, the original task has more state and behavior than a pure Runnable. When the new temporary Runnable is passed back to the caller's {{Executor}}, these additional features are no longer available. So we need a way to expose/unwrap the original task to the caller so that the caller's {{Executor}} can work properly. See https://github.com/wildfly/wildfly-core/blob/master/request-controller/sr... was: org.wildfly.extension.requestcontroller.RequestController.QueuedTask runRequest() method wraps the original task as a new Runnable, and pass it back to the caller's {{Executor}} for execution. In some cases, the original task has more state and behavior than a pure Runnable. When the new temporary Runnable is passed back to the caller's {{Executor}}, these additional features are no longer available. See https://github.com/wildfly/wildfly-core/blob/master/request-controller/sr... > Expose the original task in RequestController.QueuedTask > -------------------------------------------------------- > > Key: WFCORE-4949 > URL: https://issues.redhat.com/browse/WFCORE-4949 > Project: WildFly Core > Issue Type: Enhancement > Components: Server > Affects Versions: 12.0.0.Beta1 > Reporter: Cheng Fang > Assignee: Cheng Fang > Priority: Major > > org.wildfly.extension.requestcontroller.RequestController.QueuedTask runRequest() method wraps the original task as a new Runnable, and pass it back to the caller's {{Executor}} for execution. > In some cases, the original task has more state and behavior than a pure Runnable. When the new temporary Runnable is passed back to the caller's {{Executor}}, these additional features are no longer available. So we need a way to expose/unwrap the original task to the caller so that the caller's {{Executor}} can work properly. > See https://github.com/wildfly/wildfly-core/blob/master/request-controller/sr... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4949) Expose the original task in RequestController.QueuedTask

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFCORE-4949?page=com.atlassian.jira.plug... ] Cheng Fang updated WFCORE-4949: ------------------------------- Description: org.wildfly.extension.requestcontroller.RequestController.QueuedTask runRequest() method wraps the original task as a new Runnable, and pass it back to the caller's {{Executor}} for execution. In some cases, the original task has more state and behavior than a pure Runnable. When the new temporary Runnable is passed back to the caller's {{Executor}}, these additional features are no longer available. See https://github.com/wildfly/wildfly-core/blob/master/request-controller/sr... > Expose the original task in RequestController.QueuedTask > -------------------------------------------------------- > > Key: WFCORE-4949 > URL: https://issues.redhat.com/browse/WFCORE-4949 > Project: WildFly Core > Issue Type: Enhancement > Components: Server > Affects Versions: 12.0.0.Beta1 > Reporter: Cheng Fang > Assignee: Cheng Fang > Priority: Major > > org.wildfly.extension.requestcontroller.RequestController.QueuedTask runRequest() method wraps the original task as a new Runnable, and pass it back to the caller's {{Executor}} for execution. > In some cases, the original task has more state and behavior than a pure Runnable. When the new temporary Runnable is passed back to the caller's {{Executor}}, these additional features are no longer available. > See https://github.com/wildfly/wildfly-core/blob/master/request-controller/sr... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4949) Expose the original task in RequestController.QueuedTask

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFCORE-4949?page=com.atlassian.jira.plug... ] Cheng Fang reassigned WFCORE-4949: ---------------------------------- Assignee: Cheng Fang (was: Jeff Mesnil) > Expose the original task in RequestController.QueuedTask > -------------------------------------------------------- > > Key: WFCORE-4949 > URL: https://issues.redhat.com/browse/WFCORE-4949 > Project: WildFly Core > Issue Type: Enhancement > Components: Server > Affects Versions: 12.0.0.Beta1 > Reporter: Cheng Fang > Assignee: Cheng Fang > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 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 April 2020