January 2021 - jboss-jira - Jboss List Archives

[Red Hat JIRA] (WFLY-14263) Outdated "Remote EJB invocations via JNDI - EJB client API or remote-naming project" document

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-14263: --------------------------------------- Summary: Outdated "Remote EJB invocations via JNDI - EJB client API or remote-naming project" document Key: WFLY-14263 URL: https://issues.redhat.com/browse/WFLY-14263 Project: WildFly Issue Type: Bug Components: EJB Reporter: Brian Stansberry Assignee: Cheng Fang This doc looks wrong: https://docs.wildfly.org/21/Developer_Guide.html#Remote_EJB_invocations_v... AFAICT WildFly no longer ships org.jboss:jboss-remote-naming. There are also a number of places where that doc refers to WildFly 21 which I believe is a dynamic value that is now incorrect. It's generally better to not include specific WildFly versions in the docs, as the URL for our docs already include a version number. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-13706) Support a Galleon feature pack to install Keycloak adapters

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-13706?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFLY-13706: ------------------------------------ Git Pull Request: https://github.com/wildfly/wildfly/pull/13849 (was: https://github.com/wildfly/wildfly/pull/13835) > Support a Galleon feature pack to install Keycloak adapters > ----------------------------------------------------------- > > Key: WFLY-13706 > URL: https://issues.redhat.com/browse/WFLY-13706 > Project: WildFly > Issue Type: Feature Request > Components: Documentation, Security, Test Suite > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 22.0.0.Final > > > In conjunction with the bootable jar support currently being developed this feature request is to cover support for Keycloak client side adapter installation integrated with the Elytron security subsystem. > The main feature pack is anticipated to be delivered by the Keycloak project, however as this is specifically for use with WildFly we likely need WildFly documentation and possibly test cases so this Jira issue to to cover tasks required within WildFly. > -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-5929) Fix Java11 compilation issues in kie-jpmml-integration repo

by Karel Suta (Jira)

[ https://issues.redhat.com/browse/DROOLS-5929?page=com.atlassian.jira.plug... ] Karel Suta closed DROOLS-5929. ------------------------------ Resolution: Duplicate Issue > Fix Java11 compilation issues in kie-jpmml-integration repo > ----------------------------------------------------------- > > Key: DROOLS-5929 > URL: https://issues.redhat.com/browse/DROOLS-5929 > Project: Drools > Issue Type: Task > Components: PMML > Affects Versions: 7.48.0.Final > Reporter: Karel Suta > Assignee: Karel Suta > Priority: Minor > > Right now building of kie-jpmml-integration repository with Java11 results with compilation failure, caused by missing dependencies. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (DROOLS-5929) Fix Java11 compilation issues in kie-jpmml-integration repo

by Karel Suta (Jira)

Karel Suta created DROOLS-5929: ---------------------------------- Summary: Fix Java11 compilation issues in kie-jpmml-integration repo Key: DROOLS-5929 URL: https://issues.redhat.com/browse/DROOLS-5929 Project: Drools Issue Type: Task Components: PMML Affects Versions: 7.48.0.Final Reporter: Karel Suta Assignee: Karel Suta Right now building of kie-jpmml-integration repository with Java11 results with compilation failure, caused by missing dependencies. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (WFCORE-3467) Require existence of the AttributeDefinition in AbstractWriteAttributeHandler

by Petr Beran (Jira)

[ https://issues.redhat.com/browse/WFCORE-3467?page=com.atlassian.jira.plug... ] Petr Beran reassigned WFCORE-3467: ---------------------------------- Assignee: Petr Beran > Require existence of the AttributeDefinition in AbstractWriteAttributeHandler > ----------------------------------------------------------------------------- > > Key: WFCORE-3467 > URL: https://issues.redhat.com/browse/WFCORE-3467 > Project: WildFly Core > Issue Type: Task > Components: Management > Reporter: Brian Stansberry > Assignee: Petr Beran > Priority: Major > > AbstractWriteAttributeHandler has logic to deal with the case where it has no reference to an AttributeDefinition for the relevant attribute. This is compatibility code from the days before AttributeDefinition. But using AD has been the standard for many years now, so lets drop this and fail if there is no AD. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (WFLY-14262) Nightly test job Galleon linux Alt FP - JDK 8 is failing

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-14262: --------------------------------------- Summary: Nightly test job Galleon linux Alt FP - JDK 8 is failing Key: WFLY-14262 URL: https://issues.redhat.com/browse/WFLY-14262 Project: WildFly Issue Type: Bug Components: Build System, Test Suite Reporter: Brian Stansberry https://ci.wildfly.org/viewLog.html?buildId=236272&buildTypeId=WF_Galleon... I haven't looked closely but at a glance the MP TCK modules for the MP observability specs are failing. My guess is this job is still trying to run these against the ee-build, which will no longer work. -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ELY-1740) Clean up the 'wildfly-elytron-sasl' module as it currently contains both public and private API

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1740?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated ELY-1740: ---------------------------------- Fix Version/s: 1.14.2.CR1 (was: 1.14.1.Final) > Clean up the 'wildfly-elytron-sasl' module as it currently contains both public and private API > ----------------------------------------------------------------------------------------------- > > Key: ELY-1740 > URL: https://issues.redhat.com/browse/ELY-1740 > Project: WildFly Elytron > Issue Type: Task > Reporter: Farah Juma > Priority: Major > Fix For: 1.14.2.CR1, 2.0.0.Alpha10 > > -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ELY-1700) Intermittently failing AttributeMappingSuiteChild

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1700?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated ELY-1700: ---------------------------------- Fix Version/s: 1.14.2.CR1 (was: 1.14.1.Final) > Intermittently failing AttributeMappingSuiteChild > ------------------------------------------------- > > Key: ELY-1700 > URL: https://issues.redhat.com/browse/ELY-1700 > Project: WildFly Elytron > Issue Type: Bug > Components: Testsuite > Affects Versions: 1.7.0.CR2 > Reporter: Martin Choma > Priority: Minor > Fix For: 1.14.2.CR1 > > > With ration 1:1000 we see ELY01125: Ldap-backed realm failed to obtain context. > {noformat} > org.wildfly.security.auth.server.RealmUnavailableException: ELY01125: Ldap-backed realm failed to obtain context > at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.obtainContext(LdapSecurityRealm.java:215) > at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.access$600(LdapSecurityRealm.java:102) > at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:622) > at org.wildfly.security.auth.server.ServerAuthenticationContext.exists(ServerAuthenticationContext.java:447) > at org.wildfly.security.ldap.AbstractAttributeMappingSuiteChild.assertAttributes(AbstractAttributeMappingSuiteChild.java:85) > at org.wildfly.security.ldap.AbstractAttributeMappingSuiteChild.assertAttributes(AbstractAttributeMappingSuiteChild.java:77) > at org.wildfly.security.ldap.AttributeMappingSuiteChild.testSingleAttributeToSpecifiedName(AttributeMappingSuiteChild.java:33) > at org.wildfly.security.ldap.DirContextFactoryRule$1.evaluate(DirContextFactoryRule.java:218) > Caused by: javax.naming.NamingException: LDAP response read timed out, timeout used:5000ms. > at com.sun.jndi.ldap.Connection.readReply(Connection.java:507) > at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:365) > at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:214) > at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2791) > at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319) > at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192) > at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210) > at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153) > at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83) > 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.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154) > at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:436) > at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:355) > at org.wildfly.security.ldap.DirContextFactoryRule.lambda$create$0(DirContextFactoryRule.java:258) > at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.obtainContext(LdapSecurityRealm.java:203) > ... 7 more > {noformat} > {noformat} > 00:29:39,451 TRACE (main) [org.wildfly.security] <SecurityDomain.java:1036> Building security domain with defaultRealmName default. > 00:29:39,452 TRACE (main) [org.wildfly.security] <SecurityDomain.java:708> Role mapping: principal [anonymous] -> decoded roles [] -> realm mapped roles [] -> domain mapped roles [] > 00:29:39,452 TRACE (main) [org.wildfly.security] <ServerAuthenticationContext.java:1163> Principal assigning: [userWithAttributes], pre-realm rewritten: [userWithAttributes], realm name: [default], post-realm rewritten: [userWithAttributes], realm rewritten: [userWithAttributes] > 00:29:39,453 DEBUG (main) [org.wildfly.security] <LdapSecurityRealm.java:189> Obtaining lock for identity [userWithAttributes]... > 00:29:39,454 DEBUG (main) [org.wildfly.security] <LdapSecurityRealm.java:197> Obtained lock for identity [userWithAttributes]. > 00:29:39,454 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:427> Creating [class javax.naming.directory.InitialDirContext] with environment: > 00:29:39,454 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.security.credentials] with value [******] > 00:29:39,455 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.ldap.factory.socket] with value [org.wildfly.security.auth.realm.ldap.ThreadLocalSSLSocketFactory] > 00:29:39,455 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.security.authentication] with value [simple] > 00:29:39,456 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.provider.url] with value [ldap://localhost:11390/] > 00:29:39,456 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [com.sun.jndi.ldap.read.timeout] with value [60000] > 00:29:39,456 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [com.sun.jndi.ldap.connect.timeout] with value [5000] > 00:29:39,456 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.security.principal] with value [uid=server,dc=elytron,dc=wildfly,dc=org] > 00:29:39,457 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.referral] with value [ignore] > 00:29:39,457 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:428> Property [java.naming.factory.initial] with value [com.sun.jndi.ldap.LdapCtxFactory] > 00:29:44,528 DEBUG (main) [org.wildfly.security] <SimpleDirContextFactoryBuilder.java:438> Could not create [class javax.naming.ldap.InitialLdapContext]. Failed to connect to LDAP server.: javax.naming.NamingException: LDAP response read timed out, timeout used:5000ms. > at com.sun.jndi.ldap.Connection.readReply(Connection.java:507) > at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:365) > at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:214) > at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2791) > at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319) > at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192) > at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210) > at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153) > at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83) > 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.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154) > at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.createDirContext(SimpleDirContextFactoryBuilder.java:436) > at org.wildfly.security.auth.realm.ldap.SimpleDirContextFactoryBuilder$SimpleDirContextFactory.obtainDirContext(SimpleDirContextFactoryBuilder.java:355) > at org.wildfly.security.ldap.DirContextFactoryRule.lambda$create$0(DirContextFactoryRule.java:258) > at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.obtainContext(LdapSecurityRealm.java:203) > at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm.access$600(LdapSecurityRealm.java:102) > at org.wildfly.security.auth.realm.ldap.LdapSecurityRealm$LdapRealmIdentity.exists(LdapSecurityRealm.java:622) > at org.wildfly.security.auth.server.ServerAuthenticationContext.exists(ServerAuthenticationContext.java:447) > at org.wildfly.security.ldap.AbstractAttributeMappingSuiteChild.assertAttributes(AbstractAttributeMappingSuiteChild.java:85) > at org.wildfly.security.ldap.AbstractAttributeMappingSuiteChild.assertAttributes(AbstractAttributeMappingSuiteChild.java:77) > at org.wildfly.security.ldap.AttributeMappingSuiteChild.testSingleAttributeToSpecifiedName(AttributeMappingSuiteChild.java:33) > 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.executeTestMethod(JUnit4TestRunnerDecorator.java:162) > at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.invokeExplosively(JUnit4TestRunnerDecorator.java:71) > at mockit.integration.junit4.internal.MockFrameworkMethod.invokeExplosively(MockFrameworkMethod.java:37) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:27) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.wildfly.security.ldap.DirContextFactoryRule$1.evaluate(DirContextFactoryRule.java:218) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) > 00:29:44,529 INFO (pool-3-thread-2) [org.apache.directory.server.ldap.handlers.LdapRequestHandler] <LdapRequestHandler.java:131> ignoring the message Abandon Request : > Message Id : 1org.apache.directory.api.ldap.model.message.AbandonRequestImpl@8444b052 received from null session > {noformat} > Maybe just to try prolong SimpleDirContextFactoryBuilder#DEFAULT_CONNECT_TIMEOUT [1] > This issue occurs also with ELY-1699. It is very probable machine was slow. But it would be fine if testsuite could cope with this situation as well. > > [1] https://github.com/wildfly-security/wildfly-elytron/blob/38e1e01972414ad7... -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ELY-1682) Fallback to another SASL client mechanism when SASL client initialisation fails

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1682?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated ELY-1682: ---------------------------------- Fix Version/s: 1.14.2.CR1 (was: 1.14.1.Final) > Fallback to another SASL client mechanism when SASL client initialisation fails > ------------------------------------------------------------------------------- > > Key: ELY-1682 > URL: https://issues.redhat.com/browse/ELY-1682 > Project: WildFly Elytron > Issue Type: Bug > Components: SASL > Affects Versions: 1.7.0.CR1 > Reporter: Martin Choma > Priority: Major > Fix For: 1.14.2.CR1 > > Attachments: org.jboss.eapqe.krbldap.eap71.tests.krb.ejb.KerberosEjbGssapiTestCase-output.txt > > > {code:title=HipChat conversation} > Martin Choma: I have got this situation here; Server is authenticated with GSSAPI and PLAIN. Client has only username/password credential - no kerberos credential. > But client tries to create GssapiSaslClient as well (which make problem on IBM). Once I set .setSaslMechanismSelector(SaslMechanismSelector.fromString("PLAIN")) scenario works ok. > I wonder could Authentication Client be smart enough to not try to initialize authentication mechanisms which it has not credentials for? > Darran Lofthouse: Client side GSSAPI we tend not to have configured credentials as the mech obtains from OS level. The mech should fail and allow the next mech to be selected > Martin Choma: Ok, so I will create issue. Seems on client side this mechanism fallback does not work properly. (At least in IBM JDK case). > In this case it is initialization of mechanism which is failing, so maybe fallback does not have chance to get involved. > Darran Lofthouse: Sounds possible, if a mech can not initialise we should likely treat it as a failed mech and move on - maybe something needed in Remoting > though for that one as that is where that loop happens but start with an ELY issue > {code} -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 months

1
0
0 / 0

[Red Hat JIRA] (ELY-1723) Separate auth client parsing from the API.

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/ELY-1723?page=com.atlassian.jira.plugin.... ] Darran Lofthouse updated ELY-1723: ---------------------------------- Fix Version/s: 1.14.2.CR1 (was: 1.14.1.Final) > Separate auth client parsing from the API. > ------------------------------------------ > > Key: ELY-1723 > URL: https://issues.redhat.com/browse/ELY-1723 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Priority: Blocker > Fix For: 1.14.2.CR1 > > -- This message was sent by Atlassian Jira (v8.13.1#813001)

5 years, 3 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 January 2021