January 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELYWEB-88) Upgrade WildFly Elytron to 1.11.0.Final

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELYWEB-88?page=com.atlassian.jira.plugin... ] Farah Juma resolved ELYWEB-88. ------------------------------ Resolution: Done > Upgrade WildFly Elytron to 1.11.0.Final > --------------------------------------- > > Key: ELYWEB-88 > URL: https://issues.redhat.com/browse/ELYWEB-88 > Project: Elytron Web > Issue Type: Component Upgrade > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 1.7.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1735) Clean up the 'wildfly-elytron-auth-server' module as it currently contains both public and private API

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1735?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1735: ---------------------------- Fix Version/s: 1.12.0.CR1 (was: 1.11.0.Final) > Clean up the 'wildfly-elytron-auth-server' module as it currently contains both public and private API > ------------------------------------------------------------------------------------------------------ > > Key: ELY-1735 > URL: https://issues.redhat.com/browse/ELY-1735 > Project: WildFly Elytron > Issue Type: Task > Reporter: Farah Juma > Priority: Major > Fix For: 2.0.0.Alpha7, 1.12.0.CR1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1726) Revisit the need for `wildfly-elytron-credential` to depend on `wildfly-elytron-digest`

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1726?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1726: ---------------------------- Fix Version/s: 1.12.0.CR1 (was: 1.11.0.Final) > Revisit the need for `wildfly-elytron-credential` to depend on `wildfly-elytron-digest` > --------------------------------------------------------------------------------------- > > Key: ELY-1726 > URL: https://issues.redhat.com/browse/ELY-1726 > Project: WildFly Elytron > Issue Type: Task > Components: Credentials > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.12.0.CR1 > > > This was introduced in the following PR https://github.com/wildfly-security-incubator/wildfly-elytron/pull/54 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1724) Develop an alternative to 'org.wildfly.security.credential.source.OAuth2CredentialSource'

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1724?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1724: ---------------------------- Fix Version/s: 1.12.0.CR1 (was: 1.11.0.Final) > Develop an alternative to 'org.wildfly.security.credential.source.OAuth2CredentialSource' > ----------------------------------------------------------------------------------------- > > Key: ELY-1724 > URL: https://issues.redhat.com/browse/ELY-1724 > Project: WildFly Elytron > Issue Type: Task > Reporter: Darran Lofthouse > Assignee: Ashley Abdel-Sayed > Priority: Critical > Fix For: 1.12.0.CR1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

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

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1723?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1723: ---------------------------- Fix Version/s: 1.12.0.CR1 (was: 1.11.0.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 > Assignee: Ashley Abdel-Sayed > Priority: Blocker > Fix For: 1.12.0.CR1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1700) Intermittently failing AttributeMappingSuiteChild

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1700?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1700: ---------------------------- Fix Version/s: 1.12.0.CR1 (was: 1.11.0.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.12.0.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 (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1687) Initial WildFly Elytron Performance Enhancments

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1687?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1687: ---------------------------- Fix Version/s: 1.12.0.CR1 (was: 1.11.0.Final) > Initial WildFly Elytron Performance Enhancments > ----------------------------------------------- > > Key: ELY-1687 > URL: https://issues.redhat.com/browse/ELY-1687 > Project: WildFly Elytron > Issue Type: Task > Affects Versions: 1.7.0.CR2 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 1.12.0.CR1 > > Attachments: BASIC_Auth_Load.jmx, Flight.tgz > > > Rather than this becoming a single long running task to review the performance of WildFly Elytron I think the best strategy is to identity a test strategy, obtain some metrics of that strategy under load, perform profiling to identity a set of issues and look at options to address those issues. > After that we will perform the initial metric test again and close the issue. > A new issue will then be created either to repeat the same test or start with a new test which may be a subtle change of the first test. > The first test is to test HTTP Basic authentication backed by WildFly Elytron. > * Each client will alternatively send a request with no authorization header so triggering a HTTP 401 challenge followed by a request including the header which should successfully authenticate. > Attached is a JMeter test plan configured to use 250 client threads, each submitting requests for 5 minutes. > h2. Initial Issues > h3. WildFlyElytronProvider Locking > Total block time 8.393s via calls to java.security.Provider.getServices(); > Potentially something that could be eliminated if mechanisms were loaded in advance, or at the very least the factories were loaded in advance. > h3. Memory 2.42G of char[] > e.g. > {noformat} > void java.nio.HeapCharBuffer.<init>(int, int) 13037 > CharBuffer java.nio.CharBuffer.allocate(int) 9148 > CharBuffer java.nio.charset.CharsetDecoder.decode(ByteBuffer) 9148 > CharBuffer java.nio.charset.Charset.decode(ByteBuffer) 9148 > void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9148 > {noformat} > Is there any option to re-use these as they can be cleared instead of leaving to GC. > HeapByteBuffer and HeapCharBuffer are also quite prominent. > h3. Memory 1.78G of Callback[] > Using the CallbackHandler API the use of the array is inevitable. > * Could we extend the API to avoid the array? > * Could we re-use the array? Could consider null termination. > {noformat} > boolean org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(String, String, char[]) 9222 > void org.wildfly.security.http.impl.BasicAuthenticationMechanism.evaluateRequest(HttpServerRequest) 9222 > {noformat} > h3. Memory 1.41G of HttpAuthenticator$Builder > {noformat} > HttpAuthenticator$Builder org.wildfly.security.http.HttpAuthenticator.builder() 24699 > boolean org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate() 24699 > {noformat} > Could we switch to something that associated these with a ThreadLocal and update the API to allow re-use? > h3. Memory 1.3G of SecurityContextImpl > {noformat} > SecurityContext org.wildfly.elytron.web.undertow.server.SecurityContextImpl$Builder.build() 3247 > SecurityContext org.wildfly.elytron.web.undertow.server.ElytronContextAssociationHandler.createSecurityContext(HttpServerExchange) 1673 > {noformat} > Also instances of HttpAuthenticator > {noformat} > HttpAuthenticator org.wildfly.security.http.HttpAuthenticator$Builder.build() 14624 > {noformat} > And instances of HttpAuthenticator$AuthenticationExchange. > {noformat} > boolean org.wildfly.security.http.HttpAuthenticator.authenticate() 14423 > {noformat} > As with HttpAuthenticator$Builder is there any way to consider re-use? > h3. Memory 1.21G of java.util.ArrayList > {noformat} > boolean org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate() 8911 > {noformat} > Can check the use and see if an alternative is possible. > _If this mechanism was re-written as a recursive call it would eliminate the need for the intermediate ArrayList to hold the responders._ > _This will still be a worthwhile improvement but may need to keep in mind this ArrayList size likely includes the responders which means it includes the mechs and the additional references._ > https://issues.jboss.org/browse/ELY-1689 > h3. Memory ServerAuthenticationContext States > Each ServerAuthenticationContext State is it's own class which needs to be instantiated, a single authentication requests results in multiple states. > Should the state machine be internal to the ServerAuthenticationContext so we have only one class instance? > h3. Memory SecurityIdentity > As an immutable object we can end up with intermediate throw away instances, can we optimise create once? > {noformat} > SecurityIdentity org.wildfly.security.auth.server.SecurityIdentity.withPrivateCredentials(IdentityCredentials) 11454 > ServerAuthenticationContext$AuthorizedAuthenticationState org.wildfly.security.auth.server.ServerAuthenticationContext$NameAssignedState.doAuthorization(boolean) 11454 > {noformat} > h3. Method Profiling - org.wildfly.common.iteration.ByteArrayIterator and ByteIterator > These lead to multiple instances of different classes, and the iteration is flagging in the top 10 packages. > Could a static Base64 conversion clean up a lot of this? > h1. Done > h3. Method Profiling - new HttpString > A lot of time spend creating new HttpString (Package is no3 in the top list) > {noformat} > void io.undertow.util.HttpString.<init>(String) 4 > void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.addResponseHeader(String, String) 4 > {noformat} > Could we re-use the HttpString for common header types? > Re-use of HttpString from cache https://issues.jboss.org/browse/ELYWEB-25 > h3. Memory 885Mb of Undertow FormParserFactory$ParserDefinition[] > {noformat} > FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder(boolean) 1091 > FormParserFactory$Builder io.undertow.server.handlers.form.FormParserFactory.builder() 1091 > void org.wildfly.elytron.web.undertow.server.ElytronHttpExchange.<init>(HttpServerExchange, Map, ScopeSessionListener) 1091 > {noformat} > This test did not use forms at all, is this something that can be delayed until we know it is needed? > _It may be possible for the FormParserFactory to be a single static reference, the parser it self is created on a per-request basis as needed._ > https://issues.jboss.org/browse/ELYWEB-27 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

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

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1682?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1682: ---------------------------- Fix Version/s: 1.12.0.CR1 (was: 1.11.0.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.12.0.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 (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1440) FlexibleIdentityAssociation should runAs the known SecurityIdentity before associating itself.

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1440?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1440: ---------------------------- Fix Version/s: 1.12.0.CR1 (was: 1.11.0.Final) > FlexibleIdentityAssociation should runAs the known SecurityIdentity before associating itself. > ---------------------------------------------------------------------------------------------- > > Key: ELY-1440 > URL: https://issues.redhat.com/browse/ELY-1440 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: Darran Lofthouse > Priority: Major > Fix For: 1.12.0.CR1 > > > This API was introduced to cover the case where authentication happens late in a request, generally that is quite a rare event. > Even though the API may be popular it would likely happen once for a session and all future requests for that session the identity would be known in advance. > At the moment by not running as the existing identity we are loosing all automatic identity outflow opportunities as calls pass from the servlet container to the EJB container. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-533) Deprecate all legacy code

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-533?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-533: --------------------------- Fix Version/s: 1.12.0.CR1 (was: 1.11.0.Final) > Deprecate all legacy code > ------------------------- > > Key: ELY-533 > URL: https://issues.redhat.com/browse/ELY-533 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.12.0.CR1 > > > In a few places we have legacy behaviour within the project to assist migration from previous JBoss / WildFly releases - this code should be flagged as deprecated to encourage minimal use. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-243) Ensure reference to repository is removed from pom

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-243?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-243: --------------------------- Fix Version/s: 1.12.0.CR1 (was: 1.11.0.Final) > Ensure reference to repository is removed from pom > -------------------------------------------------- > > Key: ELY-243 > URL: https://issues.redhat.com/browse/ELY-243 > Project: WildFly Elytron > Issue Type: Task > Components: Build > Reporter: Darran Lofthouse > Priority: Major > Fix For: 1.12.0.CR1 > > > We need to ensure the reference to the JBoss repo is removed from the pom and artefacts are available from Maven Central. > Also at this point probably good to put the steps in place for Elytron to also be available from Maven Central. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1741) Clean up the 'wildfly-elytron-x500' module as it currently contains both public and private API

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1741?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1741: ---------------------------- Fix Version/s: 1.12.0.CR1 (was: 1.11.0.Final) > Clean up the 'wildfly-elytron-x500' module as it currently contains both public and private API > ----------------------------------------------------------------------------------------------- > > Key: ELY-1741 > URL: https://issues.redhat.com/browse/ELY-1741 > Project: WildFly Elytron > Issue Type: Task > Reporter: Farah Juma > Priority: Major > Fix For: 2.0.0.Alpha7, 1.12.0.CR1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

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

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1740?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1740: ---------------------------- Fix Version/s: 1.12.0.CR1 (was: 1.11.0.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: 2.0.0.Alpha7, 1.12.0.CR1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1739) Clean up the 'wildfly-elytron-jaspi' module as it currently contains both public and private API

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1739?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1739: ---------------------------- Fix Version/s: 1.12.0.CR1 (was: 1.11.0.Final) > Clean up the 'wildfly-elytron-jaspi' module as it currently contains both public and private API > ------------------------------------------------------------------------------------------------ > > Key: ELY-1739 > URL: https://issues.redhat.com/browse/ELY-1739 > Project: WildFly Elytron > Issue Type: Task > Reporter: Farah Juma > Priority: Major > Fix For: 2.0.0.Alpha7, 1.12.0.CR1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1737) Clean up the 'wildfly-elytron-credential-store' module as it currently contains both public and private API

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1737?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1737: ---------------------------- Fix Version/s: 1.12.0.CR1 (was: 1.11.0.Final) > Clean up the 'wildfly-elytron-credential-store' module as it currently contains both public and private API > ----------------------------------------------------------------------------------------------------------- > > Key: ELY-1737 > URL: https://issues.redhat.com/browse/ELY-1737 > Project: WildFly Elytron > Issue Type: Task > Reporter: Farah Juma > Priority: Major > Fix For: 2.0.0.Alpha7, 1.12.0.CR1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1749) Code review of WildFlyElytronProvider

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1749?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1749: ---------------------------- Fix Version/s: 1.12.0.CR1 (was: 1.11.0.Final) > Code review of WildFlyElytronProvider > ------------------------------------- > > Key: ELY-1749 > URL: https://issues.redhat.com/browse/ELY-1749 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.12.0.CR1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1745) The AvailableRealmsCallback should not result in a NPE if there is no mechanism configuration.

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1745?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1745: ---------------------------- Fix Version/s: 1.12.0.CR1 (was: 1.11.0.Final) > The AvailableRealmsCallback should not result in a NPE if there is no mechanism configuration. > ---------------------------------------------------------------------------------------------- > > Key: ELY-1745 > URL: https://issues.redhat.com/browse/ELY-1745 > Project: WildFly Elytron > Issue Type: Bug > Components: API / SPI > Reporter: Darran Lofthouse > Priority: Major > Fix For: 1.12.0.CR1 > > > The NPE is due to the following code: - > {noformat} > } else if (callback instanceof AvailableRealmsCallback) { > Collection<String> names = stateRef.get().getMechanismConfiguration().getMechanismRealmNames(); > if (log.isTraceEnabled()) { > log.tracef("Handling AvailableRealmsCallback: realms = [%s]", String.join(", ", names)); > } > if (! names.isEmpty()) { > ((AvailableRealmsCallback) callback).setRealmNames(names.toArray(new String[names.size()])); > } > handleOne(callbacks, idx + 1); > {noformat} > If mechanism configuration is mandatory this should report an appropriate error, if not it should fallback to specifying an empty list. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1744) Remove use of java.security.acl APIs

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1744?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1744: ---------------------------- Fix Version/s: 1.12.0.CR1 (was: 1.11.0.Final) > Remove use of java.security.acl APIs > ------------------------------------ > > Key: ELY-1744 > URL: https://issues.redhat.com/browse/ELY-1744 > Project: WildFly Elytron > Issue Type: Task > Components: Realms > Reporter: Darran Lofthouse > Priority: Critical > Fix For: 1.12.0.CR1 > > > The 'java.security.acls' packages has been deprecated and flagged for removal, this will be removed in Java 13 > https://bugs.openjdk.java.net/browse/JDK-8191138 > Within WildFly Elytron we only seem to use it in the JAAS security realm which I don't believe is used although likely is public API. I believe the use was to mirror some PicketBox behaviour. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1742) Clean up the 'wildfly-elytron-x500-cert' module as it currently contains both public and private API

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1742?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1742: ---------------------------- Fix Version/s: 1.12.0.CR1 (was: 1.11.0.Final) > Clean up the 'wildfly-elytron-x500-cert' module as it currently contains both public and private API > ---------------------------------------------------------------------------------------------------- > > Key: ELY-1742 > URL: https://issues.redhat.com/browse/ELY-1742 > Project: WildFly Elytron > Issue Type: Task > Reporter: Farah Juma > Priority: Major > Fix For: 2.0.0.Alpha7, 1.12.0.CR1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1778) Enhanced Audit Logging - Feature parity with legacy audit logging

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1778?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1778: ---------------------------- Fix Version/s: 1.12.0.CR1 (was: 1.11.0.Final) > Enhanced Audit Logging - Feature parity with legacy audit logging > ----------------------------------------------------------------- > > Key: ELY-1778 > URL: https://issues.redhat.com/browse/ELY-1778 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Audit > Reporter: Justin Cook > Priority: Major > Fix For: 1.12.0.CR1 > > > This RFE for Enhanced Audit Logging in WildFly Elytron is for feature parity with legacy audit logging via: > * Additional audit events > * An "Audit" annotation -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1765) Review authentication client dependencies on credential sources

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1765?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1765: ---------------------------- Fix Version/s: 1.12.0.CR1 (was: 1.11.0.Final) > Review authentication client dependencies on credential sources > --------------------------------------------------------------- > > Key: ELY-1765 > URL: https://issues.redhat.com/browse/ELY-1765 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Darran Lofthouse > Priority: Blocker > Fix For: 1.12.0.CR1 > > > Could these credential sources be discoverable from java.security.Provider with a more generic configuration API? This could help break any dependency from authentication client to the implementation. > _In the opposite direction I think it is Ok for the impl to depend on the client._ -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1809) Update JAPICMP on a module by module basis

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1809?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1809: ---------------------------- Fix Version/s: 1.12.0.CR1 (was: 1.11.0.Final) > Update JAPICMP on a module by module basis > ------------------------------------------ > > Key: ELY-1809 > URL: https://issues.redhat.com/browse/ELY-1809 > Project: WildFly Elytron > Issue Type: Task > Components: Build > Reporter: Darran Lofthouse > Priority: Major > Fix For: 1.12.0.CR1 > > > Each module should test it's own compatibility - however the compatible version should likely be defined in the root pom. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1842) Update the tool to support generating and exporting / importing a secret key to the credential store

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1842?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1842: ---------------------------- Fix Version/s: 1.12.0.CR1 (was: 1.11.0.Final) > Update the tool to support generating and exporting / importing a secret key to the credential store > ---------------------------------------------------------------------------------------------------- > > Key: ELY-1842 > URL: https://issues.redhat.com/browse/ELY-1842 > Project: WildFly Elytron > Issue Type: Requirement > Components: Command-Line Tool, Credential Store > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 1.12.0.CR1 > > > In general the following options should be supported: - > * `--generate-secret-key` > * `--export-secret-key` > * `--import-secret-key` -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1919) Release WildFly Elytron 1.11.0.Final

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1919?page=com.atlassian.jira.plugin.... ] Farah Juma resolved ELY-1919. ----------------------------- Resolution: Done > Release WildFly Elytron 1.11.0.Final > ------------------------------------ > > Key: ELY-1919 > URL: https://issues.redhat.com/browse/ELY-1919 > Project: WildFly Elytron > Issue Type: Release > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 1.11.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1808) Undertake further review of all duplicate packages to ensure we can make unique

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/ELY-1808?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELY-1808: ---------------------------- Fix Version/s: 1.12.0.CR1 (was: 1.11.0.Final) > Undertake further review of all duplicate packages to ensure we can make unique > ------------------------------------------------------------------------------- > > Key: ELY-1808 > URL: https://issues.redhat.com/browse/ELY-1808 > Project: WildFly Elytron > Issue Type: Task > Components: Build > Reporter: Darran Lofthouse > Priority: Blocker > Fix For: 1.12.0.CR1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELYWEB-88) Upgrade WildFly Elytron to 1.11.0.Final

by Farah Juma (Jira)

Farah Juma created ELYWEB-88: -------------------------------- Summary: Upgrade WildFly Elytron to 1.11.0.Final Key: ELYWEB-88 URL: https://issues.redhat.com/browse/ELYWEB-88 Project: Elytron Web Issue Type: Component Upgrade Reporter: Farah Juma Assignee: Farah Juma Fix For: 1.7.0.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4796) Upgrade Elytron Web to 1.7.0.Final

by Farah Juma (Jira)

Farah Juma created WFCORE-4796: ---------------------------------- Summary: Upgrade Elytron Web to 1.7.0.Final Key: WFCORE-4796 URL: https://issues.redhat.com/browse/WFCORE-4796 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Farah Juma Assignee: Farah Juma -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELYWEB-87) Release Elytron Web 1.7.0.Final

by Farah Juma (Jira)

Farah Juma created ELYWEB-87: -------------------------------- Summary: Release Elytron Web 1.7.0.Final Key: ELYWEB-87 URL: https://issues.redhat.com/browse/ELYWEB-87 Project: Elytron Web Issue Type: Release Reporter: Farah Juma Assignee: Farah Juma Fix For: 1.7.0.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-1919) Release WildFly Elytron 1.11.0.Final

by Farah Juma (Jira)

Farah Juma created ELY-1919: ------------------------------- Summary: Release WildFly Elytron 1.11.0.Final Key: ELY-1919 URL: https://issues.redhat.com/browse/ELY-1919 Project: WildFly Elytron Issue Type: Release Reporter: Farah Juma Assignee: Farah Juma Fix For: 1.11.0.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4911) Allow bound variables to be a function of 3 and 4 other variables

by Lukáš Petrovický (Jira)

Lukáš Petrovický created DROOLS-4911: ---------------------------------------- Summary: Allow bound variables to be a function of 3 and 4 other variables Key: DROOLS-4911 URL: https://issues.redhat.com/browse/DROOLS-4911 Project: Drools Issue Type: Enhancement Components: executable model Affects Versions: 7.31.0.Final Reporter: Lukáš Petrovický Assignee: Lukáš Petrovický Fix For: 7.32.0.Final For a use case in OptaPlanner's Constraint Streams (see PLANNER-1764), I need to be able to call variable binding functions with 3 or 4 arguments. This will allow me to handle cases like this: {noformat} $p1: Person() $p2: Person() $p3: Person($allMoney: $p1.money + $p2.money + $p3.money) {noformat} At the moment, Drools exec model only supports cases of up to 2 arguments. I need to bring the number up to 4. I do not plan to introduce this functionality into DRL, as my use case leverages exec model directly. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12941) , Count metrics in wildfly17 does not increase

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-12941?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFLY-12941: ----------------------------------------- [~alireza.alallah] Can you be more specific? There are many different subsystems in WildFly that provide their own metrics so knowing which are a problem will help. Also, many subsystems have a 'statistics-enabled' configuration attribute with a default value of 'false'. (It's false by default because collection metrics has a perf impact so we want users to opt into it.) If that attribute is 'false' for a subsystem it may look like some metrics don't move from 0. > ,Count metrics in wildfly17 does not increase > --------------------------------------------- > > Key: WFLY-12941 > URL: https://issues.redhat.com/browse/WFLY-12941 > Project: WildFly > Issue Type: Bug > Reporter: alireza alallah > Assignee: Brian Stansberry > Priority: Major > > Count metrics in wildfly17 does not increase -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1084) kjar maven dependencies are downloaded even if scope is set to provided or test

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-1084?page=com.atlassian.jira.plug... ] Mario Fusco resolved DROOLS-1084. --------------------------------- Resolution: Done Fixed by https://github.com/kiegroup/drools/commit/70e5b2be5db1b610db41e2cecc9b0ea... > kjar maven dependencies are downloaded even if scope is set to provided or test > ------------------------------------------------------------------------------- > > Key: DROOLS-1084 > URL: https://issues.redhat.com/browse/DROOLS-1084 > Project: Drools > Issue Type: Bug > Affects Versions: 6.3.0.Final > Reporter: Lindsay Thurmond > Assignee: Mario Fusco > Priority: Major > Attachments: debug1.png, debug2.png, debug3.png > > > The creation of a new kbase triggers the specified rules kjar to be downloaded from the remote Maven repository. This works as expected but has the side effect of also downloading the Maven dependencies for the kjar. The problem is that it is downloading ALL the Maven dependencies even if they are specified as provided or test scope. This shouldn't happen since provided dependencies are expected to already be on the classpath and we should never need test dependencies at all during runtime at all. > I did some digging into the Drools source to and found out that > {{KieRepositoryImpl#getKieModule()}} > contains logic to check the classpath for the KieModule and if it can't find it to load everything from the Maven repo which includes downloading all the dependencies (and dependencies of dependencies and so on). > Unfortunately the code for checking the classpath is not actually implemented and looks like this: > {code} > private KieModule checkClasspathForKieModule(ReleaseId releaseId) { > // TODO > // ClassLoader classLoader = Thread.currentThread().getContextClassLoader(); > // URL url = classLoader.getResource( ((ReleaseIdImpl)releaseId).getPomPropertiesPath() ); > return null; > } > {code} > After nothing is found on the classpath everything is downloaded from Maven. You can see all the stuff that is going to be downloaded (if it's not already in your Maven repo) in > {{DefaultProjectDependenciesResolver#resolve() //line 159}} > You can even see here that the dependencies have been marked as provided, but regardless they are going to be downloaded. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4794) Upgrade Elytron Web to 1.7.0.CR4

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/WFCORE-4794?page=com.atlassian.jira.plug... ] Farah Juma updated WFCORE-4794: ------------------------------- Fix Version/s: 11.0.0.Beta6 (was: 11.0.0.Beta7) > Upgrade Elytron Web to 1.7.0.CR4 > -------------------------------- > > Key: WFCORE-4794 > URL: https://issues.redhat.com/browse/WFCORE-4794 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 11.0.0.Beta6 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4793) Upgrade WildFly Elytron to 1.11.0.CR5

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/WFCORE-4793?page=com.atlassian.jira.plug... ] Farah Juma updated WFCORE-4793: ------------------------------- Fix Version/s: 11.0.0.Beta6 (was: 11.0.0.Beta7) > Upgrade WildFly Elytron to 1.11.0.CR5 > ------------------------------------- > > Key: WFCORE-4793 > URL: https://issues.redhat.com/browse/WFCORE-4793 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 11.0.0.Beta6 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3376) Modules may create loggers on a deployments log context

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-3376?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-3376: -------------------------------- Fix Version/s: 11.0.0.Beta7 (was: 11.0.0.Beta6) > Modules may create loggers on a deployments log context > ------------------------------------------------------- > > Key: WFCORE-3376 > URL: https://issues.redhat.com/browse/WFCORE-3376 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Critical > Fix For: 11.0.0.Beta7 > > > Currently WildFly uses a {{ClassLoaderLogContextSelector}} to determine the log context to use when creating loggers. If a deployment has it's own log context, via logging-profile or per-deployment logging, and a dependency on a module, that module may create loggers on the deployments log context. This is due to the fact the the call stack is walked until it finds a log context associated with a class loader. > What is needed is a way to short-circuit once a non-logging API class loader is found and determine if there is an associated log context with the callers class loader. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4482) Out of the box SSL with Wildfly Elytron

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4482?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4482: -------------------------------- Fix Version/s: 11.0.0.Beta7 (was: 11.0.0.Beta6) > Out of the box SSL with Wildfly Elytron > --------------------------------------- > > Key: WFCORE-4482 > URL: https://issues.redhat.com/browse/WFCORE-4482 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Labels: EAP-CD19 > Fix For: 11.0.0.Beta7 > > > The details of this RFE will be explored within the analysis, presently Undertow depends on a security-realm that generates a self signed cert on start up so we will require an Elytron equivalent. > There may be opportunities to tie this in in some way with the new CA integration support but that can be explored in the analysis. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-944) truststore path is ignored if provider is not JKS

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-944?page=com.atlassian.jira.plugi... ] Jeff Mesnil updated WFCORE-944: ------------------------------- Fix Version/s: 11.0.0.Beta7 (was: 11.0.0.Beta6) > truststore path is ignored if provider is not JKS > ------------------------------------------------- > > Key: WFCORE-944 > URL: https://issues.redhat.com/browse/WFCORE-944 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Arto Huusko > Priority: Major > Fix For: 11.0.0.Beta7 > > > truststore configuration ignores the path and relative-to parameters if the truststore provider is anything else than JKS. > This works as documented, but it is not correct. There can be and are truststore implementations that need to load parameters or whatever data from a file, and the current implementation prevents these truststore providers from working. > We have a custom truststore that is loaded from database, and database access parameters are read from a properties file. When trying to use this with Wildfly 9, the keystore engineLoad parameter is passed in as null, even though path and relative-to are configured. > Even standard java supports PKCS12 truststores, where the same problem would occur. > So I would suggest that > - if provider is JKS, path is mandatory > - if provider is not JKS, but path is specified, it is passed to the provider -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4485) Support for multiple security realms - Distributed Identities

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4485?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4485: -------------------------------- Fix Version/s: 11.0.0.Beta7 (was: 11.0.0.Beta6) > Support for multiple security realms - Distributed Identities > ------------------------------------------------------------- > > Key: WFCORE-4485 > URL: https://issues.redhat.com/browse/WFCORE-4485 > Project: WildFly Core > Issue Type: Feature Request > Components: Security > Reporter: Farah Juma > Priority: Major > Labels: CD17-Deferred, EAP-CD19, Previous_RFE > Fix For: 11.0.0.Beta7 > > > By stacking LoginModules it was possible using PicketBox to attempt to authenticate using one remote store and if that failed try the next store in the list. > This RFE is to consider the use case where identities could be located across multiple stores and how they are aggregated together. > Additionally this use case should consider how the authorization information could be loaded from multiple sources and merged. > This RFE is not about fail over in the event of a realm being unavailable although it may be related. > This RFE is created as a result of comparing the differences between the PicketBox JAAS architecture and the Elytron architecture so I would not recommend this proceeds without some real world use cases identified. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4670) Upgrade JBoss MSC to 1.4.12.Final

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4670?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4670: -------------------------------- Fix Version/s: 11.0.0.Beta7 (was: 11.0.0.Beta6) > Upgrade JBoss MSC to 1.4.12.Final > --------------------------------- > > Key: WFCORE-4670 > URL: https://issues.redhat.com/browse/WFCORE-4670 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Server > Reporter: Katarina Hermanova > Assignee: Richard Opalka > Priority: Major > Fix For: 11.0.0.Beta7 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4791) HttpManagementConstantHeadersTestCase causes tests failures

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4791?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4791: -------------------------------- Fix Version/s: 11.0.0.Beta7 (was: 11.0.0.Beta6) > HttpManagementConstantHeadersTestCase causes tests failures > ----------------------------------------------------------- > > Key: WFCORE-4791 > URL: https://issues.redhat.com/browse/WFCORE-4791 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Reporter: Richard Opalka > Assignee: Tomas Terem > Priority: Major > Fix For: 11.0.0.Beta7 > > Attachments: testsuite.log > > > Commit 68928b0b in WildFly-Core introduced new regression. > High probably test doesn't do proper test environment clean up > and some tests following it are thus failing. The issue isn't visible > in our CI environment so it probably depends on actual tests ordering. > I am able to reproduce this issue on my laptop always. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4793) Upgrade WildFly Elytron to 1.11.0.CR5

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4793?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4793: -------------------------------- Fix Version/s: 11.0.0.Beta7 (was: 11.0.0.Beta6) > Upgrade WildFly Elytron to 1.11.0.CR5 > ------------------------------------- > > Key: WFCORE-4793 > URL: https://issues.redhat.com/browse/WFCORE-4793 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 11.0.0.Beta6 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4484) Support SSH authentication for Git persistence

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4484?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4484: -------------------------------- Fix Version/s: 11.0.0.Beta7 (was: 11.0.0.Beta6) > Support SSH authentication for Git persistence > ---------------------------------------------- > > Key: WFCORE-4484 > URL: https://issues.redhat.com/browse/WFCORE-4484 > Project: WildFly Core > Issue Type: Feature Request > Components: Management, Security > Reporter: Farah Juma > Assignee: Ashley Abdel-Sayed > Priority: Major > Labels: EAP-CD19 > Fix For: 11.0.0.Beta7 > > > Currently Elytron only supports authentication for HTTP(s) URLS so there is no way to connect to a SSH git server to pull/push configuration history -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4794) Upgrade Elytron Web to 1.7.0.CR4

by Jeff Mesnil (Jira)

[ https://issues.redhat.com/browse/WFCORE-4794?page=com.atlassian.jira.plug... ] Jeff Mesnil updated WFCORE-4794: -------------------------------- Fix Version/s: 11.0.0.Beta7 (was: 11.0.0.Beta6) > Upgrade Elytron Web to 1.7.0.CR4 > -------------------------------- > > Key: WFCORE-4794 > URL: https://issues.redhat.com/browse/WFCORE-4794 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 11.0.0.Beta6 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12945) Migrate undertow subsystem to new MSC value API

by Richard Opalka (Jira)

[ https://issues.redhat.com/browse/WFLY-12945?page=com.atlassian.jira.plugi... ] Richard Opalka updated WFLY-12945: ---------------------------------- Fix Version/s: 19.0.0.Beta1 > Migrate undertow subsystem to new MSC value API > ----------------------------------------------- > > Key: WFLY-12945 > URL: https://issues.redhat.com/browse/WFLY-12945 > Project: WildFly > Issue Type: Enhancement > Components: Web (Undertow) > Reporter: Richard Opalka > Assignee: Richard Opalka > Priority: Major > Fix For: 19.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12945) Migrate undertow subsystem to new MSC value API

by Richard Opalka (Jira)

Richard Opalka created WFLY-12945: ------------------------------------- Summary: Migrate undertow subsystem to new MSC value API Key: WFLY-12945 URL: https://issues.redhat.com/browse/WFLY-12945 Project: WildFly Issue Type: Enhancement Components: Web (Undertow) Reporter: Richard Opalka Assignee: Richard Opalka -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4795) Make timeout of ManagedExplodedContentServitor configurable

by Jo Vandermeeren (Jira)

Jo Vandermeeren created WFCORE-4795: --------------------------------------- Summary: Make timeout of ManagedExplodedContentServitor configurable Key: WFCORE-4795 URL: https://issues.redhat.com/browse/WFCORE-4795 Project: WildFly Core Issue Type: Enhancement Components: Server Reporter: Jo Vandermeeren Assignee: Jeff Mesnil The [ManagedExplodedContentServitor |https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/org/jboss/as/server/deployment/ManagedExplodedContentServitor.java] deletes previously staged exploded managed WARs before deploying again from the repository. This class uses a latch to wait 60 seconds before failing the deployment with a StartException. On a Windows VM deleting an exploded WAR can take a long time, especially with Virus scanning enabled. It would be appreciated if this timeout was either increased or configurable. We now had to work around this issue by manually deleting the _standalone/data/managed-exploded_ directory and its contents before booting WildFly. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4909) Infinite recursion in drools after version change from v7.20 to v7.21

by Crosson David (Jira)

[ https://issues.redhat.com/browse/DROOLS-4909?page=com.atlassian.jira.plug... ] Crosson David commented on DROOLS-4909: --------------------------------------- Thank you very much, this is it, now no more looping within our reference knowledge base :) I was wondering, why this limitation has been introduced after 7.20.0.Final ? As it was working fine previously ? Performance considerations ? > Infinite recursion in drools after version change from v7.20 to v7.21 > --------------------------------------------------------------------- > > Key: DROOLS-4909 > URL: https://issues.redhat.com/browse/DROOLS-4909 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.21.0.Final, 7.22.0.Final, 7.23.0.Final, 7.25.0.Final, 7.31.0.Final > Environment: Both Mac and Windows > Reporter: Crosson David > Assignee: Mario Fusco > Priority: Major > Attachments: Screen Shot 2019-07-10 at 3.53.10 PM.png, Screen Shot 2019-07-10 at 5.56.32 PM.png, Screen Shot 2019-07-10 at 5.59.28 PM.png, error.png, pojo.png, static.png, static_error.png, toto.drl > > > https://issues.redhat.com/browse/DROOLS-4288 > The problem is not fully solved, I got a forever loop on my KB since 7.21.0.Final, I tried with 7.25.0.Final but without success, and the issue is still here with 7.31.0.Final. Will go back to release 7.20.0.Final > (the only fix I can apply is to add no-loop clause to my rules although it shouldn't be necessary). > I can't share the affected KB, and unfortunately I was unable to reproduce the issue loop on a smaller example > The affected rule looks like : > {{rule "reset metric to max score when no more issues are present" > //no-loop // TODO - no-loop TO BE REMOVED AS IT SHOULDN'T BE NECESSARY > when > Something($id:identity, $origin:origin) > not Issue($id == identity, $origin == origin, category!="metrics") > $scoring: Scoring(name == "performance", $id == identity, $origin == origin) > then > modify($scoring) > { setValue(100.0); } > end}} > ---- > from https://issues.redhat.com/browse/DROOLS-4288 : > When there is a version change in drools-compiler from `7.20.0.Final` to `7.21.0.Final` some rules are looping recursively. > *Code in github:* > [The working version|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7.20] > [The recursively looping version|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7.21] > [The change between working and looping version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...] > *More details* > When I fire a rule whose `then` part modifies a fact that is already checked in the `when` part: > {code:java} > rule "rule 1.1" > when > $sampleDomain: SampleDomain(instanceVariable2 == "Value of instance variable") > then > System.out.println("Rule 1.1 fired"); > modify($sampleDomain){ > setInstanceVariable1(3) > } > end > {code} > it doesn't loop recursively. > But when I call another rule which call a static function from another class: > {code:java} > rule "rule 1.2" > when > $sampleDomain: SampleDomain(CoreUtils.anotherFunction()) > then > System.out.println("Rule 1.2 fired"); > modify($sampleDomain){ > setInstanceVariable1(3) > } > end > {code} > it loops recursively. > The class with static function is > {code:java} > import com.drool_issue.domain.SampleDomain; > public class CoreUtils { > > public static boolean anotherFunction() { > System.out.println("anotherFunction() inside CoreUtils"); > return true; > } > > public static boolean anotherFunction(SampleDomain sampleDomain) { > System.out.println("anotherFunction(SampleDomain sampleDomain) inside CoreUtils"); > return true; > } > } > {code} > My domain file is: > {code:java} > public class SampleDomain { > private int instanceVariable1; > private String instanceVariable2; > private int instanceVariable3; > > > public int getInstanceVariable1() { > return instanceVariable1; > } > public void setInstanceVariable1(int instanceVariable1) { > this.instanceVariable1 = instanceVariable1; > } > public String getInstanceVariable2() { > return instanceVariable2; > } > public void setInstanceVariable2(String instanceVariable2) { > this.instanceVariable2 = instanceVariable2; > } > public int getInstanceVariable3() { > return instanceVariable3; > } > public void setInstanceVariable3(int instanceVariable3) { > this.instanceVariable3 = instanceVariable3; > } > > > } > {code} > This is only caused after version change from `7.20.0.Final` to `7.21.0.Final`. Any guess on what the problem might be? > When I further looked into the problem I saw this too. > When we add two functions into the `SampleDomain` class ie > {code:java} > public boolean anotherFunction() { > return true; > } > > public boolean anotherFunction(SampleDomain sampleDomain) { > return true; > } > {code} > and use this in the rule like: > {code:java} > rule "rule 1.4" > when > $sampleDomain: SampleDomain(anotherFunction()) > then > System.out.println("Rule 1.4 fired"); > modify($sampleDomain){ > setInstanceVariable1(3) > } > end > {code} > and > {code:java} > rule "rule 1.5" > when > $sampleDomain: SampleDomain(anotherFunction($sampleDomain)) > then > System.out.println("Rule 1.5 fired"); > modify($sampleDomain){ > setInstanceVariable3(4) > } > end > {code} > these also loops recursively. > *Code in github:* > [The recursive looping when using non static methods|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7....] > [The change between working and above version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...] > Also when any of the static method is made non static then method from the domain class is called even though the static method is specified in the rule. > *Code portions to be noted here are:* > [Rule where static method is called.|https://github.com/padippist/DroolsIssueReporting/blob/bde2804b25...] > [Another rule which also call the static method.|https://github.com/padippist/DroolsIssueReporting/blob/bde2804b25...] > [The static access modifier removed from the functions which where previously static.|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...] > *Code in github:* > [Weird behaviour when removing static modifier for the functions.|https://github.com/padippist/DroolsIssueReporting/tree/issue_v...] > [The change between working and above version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...] > *All this are caused in versions after `7.20.0.Final`, ie `7.21.0.Final`, `7.22.0.Final` and `7.23.0.Final`* -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-290) Response Content-Type is 'application/json' even when HTTP request defines 'application/json-patch+json' "Accept" header

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFWIP-290?page=com.atlassian.jira.plugin... ] Paul Ferraro resolved WFWIP-290. -------------------------------- Resolution: Done Fixed. > Response Content-Type is 'application/json' even when HTTP request defines 'application/json-patch+json' "Accept" header > ------------------------------------------------------------------------------------------------------------------------ > > Key: WFWIP-290 > URL: https://issues.redhat.com/browse/WFWIP-290 > Project: WildFly WIP > Issue Type: Bug > Components: MP OpenAPI > Reporter: Fabio Burzigotti > Assignee: Paul Ferraro > Priority: Major > > When sending HTTP request header "Accept: application/json-patch+json", "Content-Type: application/json" response is returned. > This behavior seems to be less strict compared to what is defined by the spec, as it states "application/json" is specifically needed in order to get the same value back from server. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4785) PathAddress leaked on reload

by Jean Francois Denise (Jira)

[ https://issues.redhat.com/browse/WFCORE-4785?page=com.atlassian.jira.plug... ] Jean Francois Denise updated WFCORE-4785: ----------------------------------------- Description: Boot server, connect CLI and reload. On a complex standalone.xml configuration, I can see 150+ PathAddress being leaked. As an example, the PathAddress [("core-service" => "management"),("management-interface" => "http-interface")] is leaked after the first reload (and only the first one, additional reloads don't create leak). Attached heapdump, server.log and configuration used (reduced standalone.xml). server.log contains traces of Instrumented PathAddress. Each created instance has an ID to track finalization. server.log contains stacktrace of PathAddress allocation. You will notice: 0) Server starts and allocates 9 PathAddress for the management-interface=http-interface. 1) GC occurs (forced from remote), 7 PathAddress are finalized. Instance 149 and 338 are not finalized. 2) Reload occurs and allocates 9 new PathAddress for the management-interface=http-interface. 3) GC occurs (forced from remote), 8 PathAddress are finalized. Instance 338 is Finalized but NOT instance 149. 4) We have 3 remaining PathAddress 149, 600 and 789 5) Reload occurs and allocates 9 new PathAddress for the management-interface=http-interface. 6) GC occurs (forced from remote), 9 PathAddress are finalized, we still have 149, new ones being 1029 and 1218. So we have a leak of 1 PathAddress instance, instance 149. was: Boot server, connect CLI and reload. As an example, the PathAddress [("core-service" => "management"),("management-interface" => "http-interface")] is leaked after the first reload (and only the first one, additional reloads don't create leak). Attached heapdump, server.log and configuration used (reduced standalone.xml). server.log contains traces of Instrumented PathAddress. Each created instance has an ID to track finalization. server.log contains stacktrace of PathAddress allocation. You will notice: 0) Server starts and allocates 9 PathAddress for the management-interface=http-interface. 1) GC occurs (forced from remote), 7 PathAddress are finalized. Instance 149 and 338 are not finalized. 2) Reload occurs and allocates 9 new PathAddress for the management-interface=http-interface. 3) GC occurs (forced from remote), 8 PathAddress are finalized. Instance 338 is Finalized but NOT instance 149. 4) We have 3 remaining PathAddress 149, 600 and 789 5) Reload occurs and allocates 9 new PathAddress for the management-interface=http-interface. 6) GC occurs (forced from remote), 9 PathAddress are finalized, we still have 149, new ones being 1029 and 1218. So we have a leak of 1 PathAddress instance, instance 149. > PathAddress leaked on reload > ---------------------------- > > Key: WFCORE-4785 > URL: https://issues.redhat.com/browse/WFCORE-4785 > Project: WildFly Core > Issue Type: Bug > Components: Management > Reporter: Jean Francois Denise > Assignee: Jeff Mesnil > Priority: Major > Attachments: after-reload.hprof, nominal.hprof, server.log, standalone-minimal2.xml > > > Boot server, connect CLI and reload. > On a complex standalone.xml configuration, I can see 150+ PathAddress being leaked. > As an example, the PathAddress [("core-service" => "management"),("management-interface" => "http-interface")] is leaked after the first reload (and only the first one, additional reloads don't create leak). > Attached heapdump, server.log and configuration used (reduced standalone.xml). > server.log contains traces of Instrumented PathAddress. Each created instance has an ID to track finalization. > server.log contains stacktrace of PathAddress allocation. > You will notice: > 0) Server starts and allocates 9 PathAddress for the management-interface=http-interface. > 1) GC occurs (forced from remote), 7 PathAddress are finalized. Instance 149 and 338 are not finalized. > 2) Reload occurs and allocates 9 new PathAddress for the management-interface=http-interface. > 3) GC occurs (forced from remote), 8 PathAddress are finalized. Instance 338 is Finalized but NOT instance 149. > 4) We have 3 remaining PathAddress 149, 600 and 789 > 5) Reload occurs and allocates 9 new PathAddress for the management-interface=http-interface. > 6) GC occurs (forced from remote), 9 PathAddress are finalized, we still have 149, new ones being 1029 and 1218. > So we have a leak of 1 PathAddress instance, instance 149. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-290) Response Content-Type is 'application/json' even when HTTP request defines 'application/json-patch+json' "Accept" header

by Fabio Burzigotti (Jira)

[ https://issues.redhat.com/browse/WFWIP-290?page=com.atlassian.jira.plugin... ] Fabio Burzigotti commented on WFWIP-290: ---------------------------------------- Tanks [~pferraro], I fixed the TS accordingly. This issue can be considered as resolved in the above mentioned version of the feature branch. > Response Content-Type is 'application/json' even when HTTP request defines 'application/json-patch+json' "Accept" header > ------------------------------------------------------------------------------------------------------------------------ > > Key: WFWIP-290 > URL: https://issues.redhat.com/browse/WFWIP-290 > Project: WildFly WIP > Issue Type: Bug > Components: MP OpenAPI > Reporter: Fabio Burzigotti > Assignee: Paul Ferraro > Priority: Major > > When sending HTTP request header "Accept: application/json-patch+json", "Content-Type: application/json" response is returned. > This behavior seems to be less strict compared to what is defined by the spec, as it states "application/json" is specifically needed in order to get the same value back from server. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12880) Upgrade Jaeger client to 0.34.1 and Apache Thrift to 0.13.0

by Ilia Vassilev (Jira)

[ https://issues.redhat.com/browse/WFLY-12880?page=com.atlassian.jira.plugi... ] Ilia Vassilev updated WFLY-12880: --------------------------------- Summary: Upgrade Jaeger client to 0.34.1 and Apache Thrift to 0.13.0 (was: Upgrade Jaeger client to 0.34.1) > Upgrade Jaeger client to 0.34.1 and Apache Thrift to 0.13.0 > ----------------------------------------------------------- > > Key: WFLY-12880 > URL: https://issues.redhat.com/browse/WFLY-12880 > Project: WildFly > Issue Type: Component Upgrade > Components: MP OpenTracing > Affects Versions: 18.0.1.Final > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Major > Labels: downstream_dependency > Fix For: 19.0.0.Beta1 > > > Upgrade Jaeger client to 1.1.0 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2431) Fix NPE when debugging Message::readHeader

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2431?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2431: --------------------------- Fix Version/s: 4.1.9 > Fix NPE when debugging Message::readHeader > ------------------------------------------ > > Key: JGRP-2431 > URL: https://issues.redhat.com/browse/JGRP-2431 > Project: JGroups > Issue Type: Bug > Reporter: Diego Lovison > Assignee: Diego Lovison > Priority: Optional > Fix For: 4.1.9 > > > When debugging the following method a NPE will throw if you try to evaluate the "hdr" expression. > {code:java} > protected static Header readHeader(DataInput in) throws IOException, ClassNotFoundException { > short magic_number=in.readShort(); > Header hdr=ClassConfigurator.create(magic_number); > hdr.readFrom(in); > return hdr; > } > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2431) Fix NPE when debugging Message::readHeader

by Diego Lovison (Jira)

[ https://issues.redhat.com/browse/JGRP-2431?page=com.atlassian.jira.plugin... ] Diego Lovison reassigned JGRP-2431: ----------------------------------- Assignee: Diego Lovison (was: Bela Ban) > Fix NPE when debugging Message::readHeader > ------------------------------------------ > > Key: JGRP-2431 > URL: https://issues.redhat.com/browse/JGRP-2431 > Project: JGroups > Issue Type: Bug > Reporter: Diego Lovison > Assignee: Diego Lovison > Priority: Optional > > When debugging the following method a NPE will throw if you try to evaluate the "hdr" expression. > {code:java} > protected static Header readHeader(DataInput in) throws IOException, ClassNotFoundException { > short magic_number=in.readShort(); > Header hdr=ClassConfigurator.create(magic_number); > hdr.readFrom(in); > return hdr; > } > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2431) Fix NPE when debugging Message::readHeader

by Diego Lovison (Jira)

Diego Lovison created JGRP-2431: ----------------------------------- Summary: Fix NPE when debugging Message::readHeader Key: JGRP-2431 URL: https://issues.redhat.com/browse/JGRP-2431 Project: JGroups Issue Type: Bug Reporter: Diego Lovison Assignee: Bela Ban When debugging the following method a NPE will throw if you try to evaluate the "hdr" expression. {code:java} protected static Header readHeader(DataInput in) throws IOException, ClassNotFoundException { short magic_number=in.readShort(); Header hdr=ClassConfigurator.create(magic_number); hdr.readFrom(in); return hdr; } {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2410) TestNG: upgrade to 7.0.0

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2410?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2410: --------------------------- Fix Version/s: 4.2.0 (was: 4.1.9) > TestNG: upgrade to 7.0.0 > ------------------------ > > Key: JGRP-2410 > URL: https://issues.redhat.com/browse/JGRP-2410 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Optional > Fix For: 4.2.0 > > > There were some issues running the stack-dependent tests in 7.0.0, that's why I reverted to 6.14.3. Need to revisit this. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2416) Native image: test IPv6 addresses

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2416?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2416: --------------------------- Fix Version/s: 4.2.0 (was: 4.1.9) > Native image: test IPv6 addresses > --------------------------------- > > Key: JGRP-2416 > URL: https://issues.redhat.com/browse/JGRP-2416 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.2.0 > > > Currently, we're using IPv4 because of flag {{-J-Djava.net.preferIPv4Stack=true}} in the generation of the native image with GraalVM. > Remove this flag and test IPv6 addresses with UDP, TCP and TCP_NIO2. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2404) Better configuration sanity checks

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2404?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2404: --------------------------- Fix Version/s: 4.2.0 (was: 4.1.9) > Better configuration sanity checks > ---------------------------------- > > Key: JGRP-2404 > URL: https://issues.redhat.com/browse/JGRP-2404 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.2.0 > > > Investigate whether more sanity checks can be applied to a configuration, e.g. missing UNICAST3 when TCP is configured etc. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2413) Probe: get rid of 'jmx' and 'op'

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2413?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2413: --------------------------- Fix Version/s: 4.2.0 (was: 4.1.9) > Probe: get rid of 'jmx' and 'op' > -------------------------------- > > Key: JGRP-2413 > URL: https://issues.redhat.com/browse/JGRP-2413 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Optional > Fix For: 4.2.0 > > > Instead of {{probe.sh jmx=NAKACK2.level}} -> {{probe.sh NAKACK2.level}} and > {{probe.sh op=UNICAST3.dumpRoutingTable}} -> {{UNICAST3.dumpRoutingTable}} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2430) GossipRouter: more efficient routing

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2430?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2430: --------------------------- Fix Version/s: 4.2.0 (was: 4.1.9) > GossipRouter: more efficient routing > ------------------------------------ > > Key: JGRP-2430 > URL: https://issues.redhat.com/browse/JGRP-2430 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.2.0 > > > GossipRouter supports both NIO (ByteBuffer) and TCP (stream-based) connections. In both cases, however, the entire message is read and then routed to the destination address. > It would be better to only read the cluster name and target address, and then use efficient stream-to-stream (or channel-to-channel) _transfer mechanisms_, which avoids temporary copies of data and the full reading of messages. > Investigate whether this is possible. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2420) Look at submariner for xsite traffic

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2420?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2420: --------------------------- Fix Version/s: 4.2.0 (was: 4.1.9) > Look at submariner for xsite traffic > ------------------------------------ > > Key: JGRP-2420 > URL: https://issues.redhat.com/browse/JGRP-2420 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Optional > Fix For: 4.2.0 > > > See whether submariner can help with xsite (especially if we can avoid the LB issues). > [1] submariner.io -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2421) Don't log an IllegalArgumentException when receiving an invalid delta view

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2421?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2421: --------------------------- Fix Version/s: 4.2.0 (was: 4.1.9) > Don't log an IllegalArgumentException when receiving an invalid delta view > -------------------------------------------------------------------------- > > Key: JGRP-2421 > URL: https://issues.redhat.com/browse/JGRP-2421 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 4.1.6 > Reporter: Dan Berindei > Assignee: Bela Ban > Priority: Minor > Fix For: 4.2.0 > > > When the cluster is unstable but not because of the network (e.g. excessive load and long GC pauses), a suspected node can keep receiving view updates long after it was excluded from the view. > The first view triggers a warning about not being a member, but because later delta-views cannot be reconstructed, their warnings look much worse, even though they're about the same thing. > {noformat} > 11:31:05,281 WARN [org.jgroups.protocols.pbcast.GMS] (jgroups-79,edg-perf03-47882) edg-perf03-47882: not member of view [edg-perf01-21541|6]; discarding it > 11:31:16,267 WARN [org.jgroups.protocols.pbcast.GMS] (jgroups-80,edg-perf03-47882) edg-perf03-47882: failed to create view from delta-view; dropping view: java.lang.IllegalStateException: the view-id of the delta view ([edg-perf01-21541|6]) doesn't match the current view-id ([edg-perf01-21541|5]); discarding delta view [edg-perf01-21541|7], ref-view=[edg-perf01-21541|6], left=[edg-perf06-47720] > {noformat} > Maybe GMS could keep track of when it receives a view in which it is not a member and stop processing delta views from that node? -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2401) Version number for configuration

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2401?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2401: --------------------------- Fix Version/s: 4.2.0 (was: 4.1.9) > Version number for configuration > -------------------------------- > > Key: JGRP-2401 > URL: https://issues.redhat.com/browse/JGRP-2401 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.2.0 > > > Add a version to the config, which corresponds with the JGroups version. > At startup, if the JGroups version and the confi version don't match, issue a warning. Possibly don't start if the major version differs. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2403) Dump information in panic scenarios

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2403?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2403: --------------------------- Fix Version/s: 4.2.0 (was: 4.1.9) > Dump information in panic scenarios > ----------------------------------- > > Key: JGRP-2403 > URL: https://issues.redhat.com/browse/JGRP-2403 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.2.0 > > > When there is a panic situation (e.g. thread pool exhausted), dump information to a file at FATAL level. > Also dump the most important information to another log (file) periodically (e.g. every 15 minutes). This log should be enabled by default, e.g. in Infinispan. > These files can be sent to support via an SOS report. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2412) GMS: reduce likelyhood of merges on concurrent new member startup

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2412?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2412: --------------------------- Fix Version/s: 4.2.0 (was: 4.1.9) > GMS: reduce likelyhood of merges on concurrent new member startup > ----------------------------------------------------------------- > > Key: JGRP-2412 > URL: https://issues.redhat.com/browse/JGRP-2412 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.2.0 > > > When multiple new members are started concurrently, and no coord is present yet, different clients get different discovery results, and this may lead to merging. > If we have no coord, we could run the discovery protocol multiple time, *with the current members list being cached*, and then might end up with a more similar list of new members. > This could be governed by an additional attribute in {{Discovery}} ({{num_discovery_runs}}?) -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2402) SOS report

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2402?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2402: --------------------------- Fix Version/s: 4.2.0 (was: 4.1.9) > SOS report > ---------- > > Key: JGRP-2402 > URL: https://issues.redhat.com/browse/JGRP-2402 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.2.0 > > > Add the ability to dump the most important attributes to a file / log (configurable), e.g.: > * Max threads > * Number of rejected messages > * Size of retransmission tables (NAKACK2, UNICAST3) > This can be used to diagnose issues by telling the customer to invoke this command and attach the resulting file to a ticket -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2406) MERGE3 not working with TCP using ForkJoinPool

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2406?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2406: --------------------------- Fix Version/s: 4.2.0 (was: 4.1.9) > MERGE3 not working with TCP using ForkJoinPool > ---------------------------------------------- > > Key: JGRP-2406 > URL: https://issues.redhat.com/browse/JGRP-2406 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.1.8 > Reporter: Olivier Peyrusse > Assignee: Bela Ban > Priority: Minor > Fix For: 4.2.0 > > Attachments: logs.tgz, project.zip, timeline.txt > > > With JDK11, using the TCP protocol with the ForkJoinPool is causing constant failures of MERGE3. > I consistently observed the following, from the point of view of a member M > - M asks for other coordinator views. It contacts A and B > - A and B send their views > - M waits and timeouts for receiving views and abort the merge > - immediately after aborting the merge, M process messages containing the views of A and B. > In [^timeline.txt], you will see the extracts for logs from the various members at play. > After many experiments, the one parameter causing this issue is in the TCP protocol. > {code:xml} > <TCP > ... > thread_pool.use_fork_join_pool="true" /> > {code} > Setting {{thread_pool.use_fork_join_pool}} to true repeatedly produces the problem, while using {{thread_pool.use_fork_join_pool}} with false works fine. > Project details: > - as tested within Kubernetes, this project uses KUBE_PING as its discovery protocol > - to understand the reason for the failed merges, I created the protocol MERGE4, that is MERGE3 with additional logs. > - [^logs.tgz] contains all logs from the various members involved in the test. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2374) TCP/TCP_NIO2: add TLS

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2374?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2374: --------------------------- Fix Version/s: 4.2.0 (was: 4.1.9) > TCP/TCP_NIO2: add TLS > --------------------- > > Key: JGRP-2374 > URL: https://issues.redhat.com/browse/JGRP-2374 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.2.0 > > > Add TLS to the TCP and TCP_NIO2 transports. Look into wildfly-openssl [1] for the impl. > [1] https://github.com/wildfly-security/wildfly-openssl -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12880) Upgrade Jaeger client to 0.34.1

by Ilia Vassilev (Jira)

[ https://issues.redhat.com/browse/WFLY-12880?page=com.atlassian.jira.plugi... ] Ilia Vassilev updated WFLY-12880: --------------------------------- Labels: downstream_dependency (was: ) > Upgrade Jaeger client to 0.34.1 > ------------------------------- > > Key: WFLY-12880 > URL: https://issues.redhat.com/browse/WFLY-12880 > Project: WildFly > Issue Type: Component Upgrade > Components: MP OpenTracing > Affects Versions: 18.0.1.Final > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Major > Labels: downstream_dependency > Fix For: 19.0.0.Beta1 > > > Upgrade Jaeger client to 1.1.0 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4882) [Guided DecisionTable] Incorrect getters and setters for fields that starts with one lowercase letter

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4882?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4882: -------------------------------- Affects Version/s: 7.31.0.Final > [Guided DecisionTable] Incorrect getters and setters for fields that starts with one lowercase letter > ----------------------------------------------------------------------------------------------------- > > Key: DROOLS-4882 > URL: https://issues.redhat.com/browse/DROOLS-4882 > Project: Drools > Issue Type: Bug > Components: Guided Decision Table Editor, Guided Decision Tree Editor, Guided Rule Editor, Guided Score Card Editor, Guided Template Editor > Affects Versions: 7.31.0.Final > Reporter: Jozef Marko > Assignee: Toni Rikkola > Priority: Major > Labels: reported-by-qe > > If the guided decision table uses fact field that has form 'xXxxx' then the generated getters and setters are incorrect. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12944) (7.3.z) Upgrade Jaeger client to 0.34.1

by Ilia Vassilev (Jira)

Ilia Vassilev created WFLY-12944: ------------------------------------ Summary: (7.3.z) Upgrade Jaeger client to 0.34.1 Key: WFLY-12944 URL: https://issues.redhat.com/browse/WFLY-12944 Project: WildFly Issue Type: Component Upgrade Components: MP OpenTracing Affects Versions: 18.0.1.Final Reporter: Ilia Vassilev Assignee: Emmanuel Hugonnet Fix For: 19.0.0.Beta1 Upgrade Jaeger client to 1.1.0 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12944) (7.3.z) Upgrade Jaeger client to 0.34.1

by Ilia Vassilev (Jira)

[ https://issues.redhat.com/browse/WFLY-12944?page=com.atlassian.jira.plugi... ] Ilia Vassilev reassigned WFLY-12944: ------------------------------------ Assignee: Ilia Vassilev (was: Emmanuel Hugonnet) > (7.3.z) Upgrade Jaeger client to 0.34.1 > --------------------------------------- > > Key: WFLY-12944 > URL: https://issues.redhat.com/browse/WFLY-12944 > Project: WildFly > Issue Type: Component Upgrade > Components: MP OpenTracing > Reporter: Ilia Vassilev > Assignee: Ilia Vassilev > Priority: Major > Fix For: 7.3.1.GA > > > Upgrade Jaeger client to 1.1.0 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2430) GossipRouter: more efficient routing

by Bela Ban (Jira)

Bela Ban created JGRP-2430: ------------------------------ Summary: GossipRouter: more efficient routing Key: JGRP-2430 URL: https://issues.redhat.com/browse/JGRP-2430 Project: JGroups Issue Type: Enhancement Reporter: Bela Ban Assignee: Bela Ban Fix For: 4.1.9 GossipRouter supports both NIO (ByteBuffer) and TCP (stream-based) connections. In both cases, however, the entire message is read and then routed to the destination address. It would be better to only read the cluster name and target address, and then use efficient stream-to-stream (or channel-to-channel) _transfer mechanisms_, which avoids temporary copies of data and the full reading of messages. Investigate whether this is possible. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4909) Infinite recursion in drools after version change from v7.20 to v7.21

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-4909?page=com.atlassian.jira.plug... ] Mario Fusco resolved DROOLS-4909. --------------------------------- Resolution: Explained Drools calculates the property reactivity of a pattern from the constraints used in that pattern. In case it is not able to figure out which property a constraint is impacting it takes the safest possible choice disabling the property reactivity for the whole pattern. To do this it analyzes the left part of a constraint (this is a known limitation) so in this sense {code} $card == card {code} and {code} card == $card {code} are not equivalent. In the first case Drools looks for a property named '$card' in the Metric object and since it cannot find any it disables the property reactivity for that pattern. Replace the first with the second in your drl and it will work as expected. > Infinite recursion in drools after version change from v7.20 to v7.21 > --------------------------------------------------------------------- > > Key: DROOLS-4909 > URL: https://issues.redhat.com/browse/DROOLS-4909 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.21.0.Final, 7.22.0.Final, 7.23.0.Final, 7.25.0.Final, 7.31.0.Final > Environment: Both Mac and Windows > Reporter: Crosson David > Assignee: Mario Fusco > Priority: Major > Attachments: Screen Shot 2019-07-10 at 3.53.10 PM.png, Screen Shot 2019-07-10 at 5.56.32 PM.png, Screen Shot 2019-07-10 at 5.59.28 PM.png, error.png, pojo.png, static.png, static_error.png, toto.drl > > > https://issues.redhat.com/browse/DROOLS-4288 > The problem is not fully solved, I got a forever loop on my KB since 7.21.0.Final, I tried with 7.25.0.Final but without success, and the issue is still here with 7.31.0.Final. Will go back to release 7.20.0.Final > (the only fix I can apply is to add no-loop clause to my rules although it shouldn't be necessary). > I can't share the affected KB, and unfortunately I was unable to reproduce the issue loop on a smaller example > The affected rule looks like : > {{rule "reset metric to max score when no more issues are present" > //no-loop // TODO - no-loop TO BE REMOVED AS IT SHOULDN'T BE NECESSARY > when > Something($id:identity, $origin:origin) > not Issue($id == identity, $origin == origin, category!="metrics") > $scoring: Scoring(name == "performance", $id == identity, $origin == origin) > then > modify($scoring) > { setValue(100.0); } > end}} > ---- > from https://issues.redhat.com/browse/DROOLS-4288 : > When there is a version change in drools-compiler from `7.20.0.Final` to `7.21.0.Final` some rules are looping recursively. > *Code in github:* > [The working version|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7.20] > [The recursively looping version|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7.21] > [The change between working and looping version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...] > *More details* > When I fire a rule whose `then` part modifies a fact that is already checked in the `when` part: > {code:java} > rule "rule 1.1" > when > $sampleDomain: SampleDomain(instanceVariable2 == "Value of instance variable") > then > System.out.println("Rule 1.1 fired"); > modify($sampleDomain){ > setInstanceVariable1(3) > } > end > {code} > it doesn't loop recursively. > But when I call another rule which call a static function from another class: > {code:java} > rule "rule 1.2" > when > $sampleDomain: SampleDomain(CoreUtils.anotherFunction()) > then > System.out.println("Rule 1.2 fired"); > modify($sampleDomain){ > setInstanceVariable1(3) > } > end > {code} > it loops recursively. > The class with static function is > {code:java} > import com.drool_issue.domain.SampleDomain; > public class CoreUtils { > > public static boolean anotherFunction() { > System.out.println("anotherFunction() inside CoreUtils"); > return true; > } > > public static boolean anotherFunction(SampleDomain sampleDomain) { > System.out.println("anotherFunction(SampleDomain sampleDomain) inside CoreUtils"); > return true; > } > } > {code} > My domain file is: > {code:java} > public class SampleDomain { > private int instanceVariable1; > private String instanceVariable2; > private int instanceVariable3; > > > public int getInstanceVariable1() { > return instanceVariable1; > } > public void setInstanceVariable1(int instanceVariable1) { > this.instanceVariable1 = instanceVariable1; > } > public String getInstanceVariable2() { > return instanceVariable2; > } > public void setInstanceVariable2(String instanceVariable2) { > this.instanceVariable2 = instanceVariable2; > } > public int getInstanceVariable3() { > return instanceVariable3; > } > public void setInstanceVariable3(int instanceVariable3) { > this.instanceVariable3 = instanceVariable3; > } > > > } > {code} > This is only caused after version change from `7.20.0.Final` to `7.21.0.Final`. Any guess on what the problem might be? > When I further looked into the problem I saw this too. > When we add two functions into the `SampleDomain` class ie > {code:java} > public boolean anotherFunction() { > return true; > } > > public boolean anotherFunction(SampleDomain sampleDomain) { > return true; > } > {code} > and use this in the rule like: > {code:java} > rule "rule 1.4" > when > $sampleDomain: SampleDomain(anotherFunction()) > then > System.out.println("Rule 1.4 fired"); > modify($sampleDomain){ > setInstanceVariable1(3) > } > end > {code} > and > {code:java} > rule "rule 1.5" > when > $sampleDomain: SampleDomain(anotherFunction($sampleDomain)) > then > System.out.println("Rule 1.5 fired"); > modify($sampleDomain){ > setInstanceVariable3(4) > } > end > {code} > these also loops recursively. > *Code in github:* > [The recursive looping when using non static methods|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7....] > [The change between working and above version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...] > Also when any of the static method is made non static then method from the domain class is called even though the static method is specified in the rule. > *Code portions to be noted here are:* > [Rule where static method is called.|https://github.com/padippist/DroolsIssueReporting/blob/bde2804b25...] > [Another rule which also call the static method.|https://github.com/padippist/DroolsIssueReporting/blob/bde2804b25...] > [The static access modifier removed from the functions which where previously static.|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...] > *Code in github:* > [Weird behaviour when removing static modifier for the functions.|https://github.com/padippist/DroolsIssueReporting/tree/issue_v...] > [The change between working and above version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...] > *All this are caused in versions after `7.20.0.Final`, ie `7.21.0.Final`, `7.22.0.Final` and `7.23.0.Final`* -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12937) Expired distributed web sessions/SFSBs not properly removed following rehash

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-12937?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-12937: -------------------------------- Priority: Blocker (was: Critical) > Expired distributed web sessions/SFSBs not properly removed following rehash > ---------------------------------------------------------------------------- > > Key: WFLY-12937 > URL: https://issues.redhat.com/browse/WFLY-12937 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 18.0.1.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Blocker > > On topology change, changes to primary session ownership determine when a given member should schedule expiration of a given session, or cancel a scheduled expiration of a previously owned session. Primary ownership is determined by 2 components: the key partitioner and a consistent hash. The key partitioner determines which the segment to which a given key is assigned. A consistent hash determines which member is the primary owner of a given segment. > The logic for determining primary ownership changes currently uses the wrong key partitioner. Currently, we use the partitioner from the cache configuration. However, when grouping is enabled (which is the case for web sessions and SFSBs), this parititioner is wrapped by a GroupPartitioner at runtime. That is the one we need. > This results in expired web sessions/SFSBs remaining in memory, potentially indefinitely. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4698) Adding "expression" type handling for Collection type propereties

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4698?page=com.atlassian.jira.plug... ] Jozef Marko commented on DROOLS-4698: ------------------------------------- h3. Manual review comment 4 Mixing creating and defining collection seems causing troubles. Imagine you are in state [1], and then click duplicate first row, you will get [2] [1] !Screenshot from 2020-01-08 14-36-33.png|thumbnail! [2] !Screenshot from 2020-01-08 14-36-52.png|thumbnail! > Adding "expression" type handling for Collection type propereties > ----------------------------------------------------------------- > > Key: DROOLS-4698 > URL: https://issues.redhat.com/browse/DROOLS-4698 > Project: Drools > Issue Type: Feature Request > Components: Scenario Simulation and Testing > Reporter: Yeser Amer > Assignee: Yeser Amer > Priority: Major > Labels: UX, UXTeam, drools-tools > Attachments: Screenshot from 2020-01-08 14-14-05.png, Screenshot from 2020-01-08 14-20-30.png, Screenshot from 2020-01-08 14-36-33.png, Screenshot from 2020-01-08 14-36-52.png, test urgent.scesim, urgent.dmn > > > Support is about both drools/java collections and dmn collections. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4698) Adding "expression" type handling for Collection type propereties

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4698?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4698: -------------------------------- Attachment: Screenshot from 2020-01-08 14-36-52.png Screenshot from 2020-01-08 14-36-33.png > Adding "expression" type handling for Collection type propereties > ----------------------------------------------------------------- > > Key: DROOLS-4698 > URL: https://issues.redhat.com/browse/DROOLS-4698 > Project: Drools > Issue Type: Feature Request > Components: Scenario Simulation and Testing > Reporter: Yeser Amer > Assignee: Yeser Amer > Priority: Major > Labels: UX, UXTeam, drools-tools > Attachments: Screenshot from 2020-01-08 14-14-05.png, Screenshot from 2020-01-08 14-20-30.png, Screenshot from 2020-01-08 14-36-33.png, Screenshot from 2020-01-08 14-36-52.png, test urgent.scesim, urgent.dmn > > > Support is about both drools/java collections and dmn collections. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12943) Upgrade HAL to 3.2.5.Final

by Harald Pehl (Jira)

[ https://issues.redhat.com/browse/WFLY-12943?page=com.atlassian.jira.plugi... ] Harald Pehl updated WFLY-12943: ------------------------------- Description: Diff: https://github.com/hal/console/compare/3.2.4.Final...3.2.5.Final (was: Diff: https://github.com/hal/console/compare/3.2.1.Final...3.2.4.Final) > Upgrade HAL to 3.2.5.Final > -------------------------- > > Key: WFLY-12943 > URL: https://issues.redhat.com/browse/WFLY-12943 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Priority: Major > Fix For: 19.0.0.Beta1 > > > Diff: https://github.com/hal/console/compare/3.2.4.Final...3.2.5.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12943) Upgrade HAL to 3.2.5.Final

by Harald Pehl (Jira)

[ https://issues.redhat.com/browse/WFLY-12943?page=com.atlassian.jira.plugi... ] Harald Pehl updated WFLY-12943: ------------------------------- Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/12829) > Upgrade HAL to 3.2.5.Final > -------------------------- > > Key: WFLY-12943 > URL: https://issues.redhat.com/browse/WFLY-12943 > Project: WildFly > Issue Type: Component Upgrade > Components: Web Console > Reporter: Harald Pehl > Assignee: Harald Pehl > Priority: Major > Fix For: 19.0.0.Beta1 > > > Diff: https://github.com/hal/console/compare/3.2.1.Final...3.2.4.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4698) Adding "expression" type handling for Collection type propereties

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4698?page=com.atlassian.jira.plug... ] Jozef Marko commented on DROOLS-4698: ------------------------------------- h3. Manual review comment 3 Please have a look on [^test urgent.scesim] . From my understanding/expectation all should pass, but just the second one does. Could you please advice what is wrong with 1. and 3.? > Adding "expression" type handling for Collection type propereties > ----------------------------------------------------------------- > > Key: DROOLS-4698 > URL: https://issues.redhat.com/browse/DROOLS-4698 > Project: Drools > Issue Type: Feature Request > Components: Scenario Simulation and Testing > Reporter: Yeser Amer > Assignee: Yeser Amer > Priority: Major > Labels: UX, UXTeam, drools-tools > Attachments: Screenshot from 2020-01-08 14-14-05.png, Screenshot from 2020-01-08 14-20-30.png, test urgent.scesim, urgent.dmn > > > Support is about both drools/java collections and dmn collections. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12943) Upgrade HAL to 3.2.5.Final

by Harald Pehl (Jira)

Harald Pehl created WFLY-12943: ---------------------------------- Summary: Upgrade HAL to 3.2.5.Final Key: WFLY-12943 URL: https://issues.redhat.com/browse/WFLY-12943 Project: WildFly Issue Type: Component Upgrade Components: Web Console Reporter: Harald Pehl Assignee: Harald Pehl Fix For: 19.0.0.Beta1 Diff: https://github.com/hal/console/compare/3.2.1.Final...3.2.4.Final -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4698) Adding "expression" type handling for Collection type propereties

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4698?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4698: -------------------------------- Attachment: test urgent.scesim > Adding "expression" type handling for Collection type propereties > ----------------------------------------------------------------- > > Key: DROOLS-4698 > URL: https://issues.redhat.com/browse/DROOLS-4698 > Project: Drools > Issue Type: Feature Request > Components: Scenario Simulation and Testing > Reporter: Yeser Amer > Assignee: Yeser Amer > Priority: Major > Labels: UX, UXTeam, drools-tools > Attachments: Screenshot from 2020-01-08 14-14-05.png, Screenshot from 2020-01-08 14-20-30.png, test urgent.scesim, urgent.dmn > > > Support is about both drools/java collections and dmn collections. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12942) Upgrade WildFly Core 11.0.0.Beta6

by Jeff Mesnil (Jira)

Jeff Mesnil created WFLY-12942: ---------------------------------- Summary: Upgrade WildFly Core 11.0.0.Beta6 Key: WFLY-12942 URL: https://issues.redhat.com/browse/WFLY-12942 Project: WildFly Issue Type: Component Upgrade Components: Management Reporter: Jeff Mesnil Assignee: Jeff Mesnil Fix For: 19.0.0.Beta1 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4698) Adding "expression" type handling for Collection type propereties

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4698?page=com.atlassian.jira.plug... ] Jozef Marko commented on DROOLS-4698: ------------------------------------- h3. Manual review comment 2 Scrollbars in the popup do not work rolling wheel on mouse. User can just click on it and drag manually. !Screenshot from 2020-01-08 14-20-30.png|thumbnail! > Adding "expression" type handling for Collection type propereties > ----------------------------------------------------------------- > > Key: DROOLS-4698 > URL: https://issues.redhat.com/browse/DROOLS-4698 > Project: Drools > Issue Type: Feature Request > Components: Scenario Simulation and Testing > Reporter: Yeser Amer > Assignee: Yeser Amer > Priority: Major > Labels: UX, UXTeam, drools-tools > Attachments: Screenshot from 2020-01-08 14-14-05.png, Screenshot from 2020-01-08 14-20-30.png, urgent.dmn > > > Support is about both drools/java collections and dmn collections. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4698) Adding "expression" type handling for Collection type propereties

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4698?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4698: -------------------------------- Attachment: Screenshot from 2020-01-08 14-20-30.png > Adding "expression" type handling for Collection type propereties > ----------------------------------------------------------------- > > Key: DROOLS-4698 > URL: https://issues.redhat.com/browse/DROOLS-4698 > Project: Drools > Issue Type: Feature Request > Components: Scenario Simulation and Testing > Reporter: Yeser Amer > Assignee: Yeser Amer > Priority: Major > Labels: UX, UXTeam, drools-tools > Attachments: Screenshot from 2020-01-08 14-14-05.png, Screenshot from 2020-01-08 14-20-30.png, urgent.dmn > > > Support is about both drools/java collections and dmn collections. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2408) RELAY2: forward message to site master

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2408?page=com.atlassian.jira.plugin... ] Bela Ban closed JGRP-2408. -------------------------- Resolution: Won't Fix This only happens when we have a {{LoadBalancer}} service in front of the bridge cluster (site masters). I don't recommend that anyway, instead a GossipRouter/TUNNEL combo should be used. Also, this approch would create too much traffic. Therefore, this issue is moot. > RELAY2: forward message to site master > -------------------------------------- > > Key: JGRP-2408 > URL: https://issues.redhat.com/browse/JGRP-2408 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Major > Fix For: 4.1.9 > > > If we get a message targetted for a site master, and we're not the site master, forward it to the actual site master. > This scenario occurs when we have a load balancer (e.g. ELB), and a request is sent to it. Which IP address it picks is non-deterministic, and therefore even non site masters can get the message. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4611) It is impossible to use infinity values

by Daniele Zonca (Jira)

[ https://issues.redhat.com/browse/DROOLS-4611?page=com.atlassian.jira.plug... ] Daniele Zonca updated DROOLS-4611: ---------------------------------- Story Points: 1 > It is impossible to use infinity values > --------------------------------------- > > Key: DROOLS-4611 > URL: https://issues.redhat.com/browse/DROOLS-4611 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Reporter: Anna Dupliak > Assignee: Daniele Zonca > Priority: Major > Labels: ScenarioSimulation, drools-tools > Attachments: screenshot-1.png, screenshot-2.png > > > It is impossible to use infinity values. > *workaround > If one expect some infinity value as a result -> they could compare it with the "1/0" expression -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4611) It is impossible to use infinity values

by Daniele Zonca (Jira)

[ https://issues.redhat.com/browse/DROOLS-4611?page=com.atlassian.jira.plug... ] Daniele Zonca updated DROOLS-4611: ---------------------------------- Sprint: 2020 Week 01-03 (from Dec 30) > It is impossible to use infinity values > --------------------------------------- > > Key: DROOLS-4611 > URL: https://issues.redhat.com/browse/DROOLS-4611 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Reporter: Anna Dupliak > Assignee: Daniele Zonca > Priority: Major > Labels: ScenarioSimulation, drools-tools > Attachments: screenshot-1.png, screenshot-2.png > > > It is impossible to use infinity values. > *workaround > If one expect some infinity value as a result -> they could compare it with the "1/0" expression -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4698) Adding "expression" type handling for Collection type propereties

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4698?page=com.atlassian.jira.plug... ] Jozef Marko commented on DROOLS-4698: ------------------------------------- h3. Manual review comment 1 - If I am trying to create a test scenario for [^urgent.dmn] I am getting !Screenshot from 2020-01-08 14-14-05.png|thumbnail! even when I am creating tests scenario for the first time. > Adding "expression" type handling for Collection type propereties > ----------------------------------------------------------------- > > Key: DROOLS-4698 > URL: https://issues.redhat.com/browse/DROOLS-4698 > Project: Drools > Issue Type: Feature Request > Components: Scenario Simulation and Testing > Reporter: Yeser Amer > Assignee: Yeser Amer > Priority: Major > Labels: UX, UXTeam, drools-tools > Attachments: Screenshot from 2020-01-08 14-14-05.png, urgent.dmn > > > Support is about both drools/java collections and dmn collections. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4698) Adding "expression" type handling for Collection type propereties

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4698?page=com.atlassian.jira.plug... ] Jozef Marko edited comment on DROOLS-4698 at 1/8/20 8:18 AM: ------------------------------------------------------------- h3. Manual review comment 1 If I am trying to create a test scenario for [^urgent.dmn] I am getting !Screenshot from 2020-01-08 14-14-05.png|thumbnail! even when I am creating tests scenario for the first time. was (Author: jomarko): h3. Manual review comment 1 - If I am trying to create a test scenario for [^urgent.dmn] I am getting !Screenshot from 2020-01-08 14-14-05.png|thumbnail! even when I am creating tests scenario for the first time. > Adding "expression" type handling for Collection type propereties > ----------------------------------------------------------------- > > Key: DROOLS-4698 > URL: https://issues.redhat.com/browse/DROOLS-4698 > Project: Drools > Issue Type: Feature Request > Components: Scenario Simulation and Testing > Reporter: Yeser Amer > Assignee: Yeser Amer > Priority: Major > Labels: UX, UXTeam, drools-tools > Attachments: Screenshot from 2020-01-08 14-14-05.png, urgent.dmn > > > Support is about both drools/java collections and dmn collections. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4698) Adding "expression" type handling for Collection type propereties

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4698?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4698: -------------------------------- Attachment: urgent.dmn > Adding "expression" type handling for Collection type propereties > ----------------------------------------------------------------- > > Key: DROOLS-4698 > URL: https://issues.redhat.com/browse/DROOLS-4698 > Project: Drools > Issue Type: Feature Request > Components: Scenario Simulation and Testing > Reporter: Yeser Amer > Assignee: Yeser Amer > Priority: Major > Labels: UX, UXTeam, drools-tools > Attachments: Screenshot from 2020-01-08 14-14-05.png, urgent.dmn > > > Support is about both drools/java collections and dmn collections. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4698) Adding "expression" type handling for Collection type propereties

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4698?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4698: -------------------------------- Attachment: Screenshot from 2020-01-08 14-14-05.png > Adding "expression" type handling for Collection type propereties > ----------------------------------------------------------------- > > Key: DROOLS-4698 > URL: https://issues.redhat.com/browse/DROOLS-4698 > Project: Drools > Issue Type: Feature Request > Components: Scenario Simulation and Testing > Reporter: Yeser Amer > Assignee: Yeser Amer > Priority: Major > Labels: UX, UXTeam, drools-tools > Attachments: Screenshot from 2020-01-08 14-14-05.png > > > Support is about both drools/java collections and dmn collections. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-290) Response Content-Type is 'application/json' even when HTTP request defines 'application/json-patch+json' "Accept" header

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFWIP-290?page=com.atlassian.jira.plugin... ] Paul Ferraro commented on WFWIP-290: ------------------------------------ {quote} when sending "Accept: application/*", then HTTP 200 is returned with "application/yaml" Content-Type. Is this behavior wanted?{quote} Yes. > Response Content-Type is 'application/json' even when HTTP request defines 'application/json-patch+json' "Accept" header > ------------------------------------------------------------------------------------------------------------------------ > > Key: WFWIP-290 > URL: https://issues.redhat.com/browse/WFWIP-290 > Project: WildFly WIP > Issue Type: Bug > Components: MP OpenAPI > Reporter: Fabio Burzigotti > Assignee: Paul Ferraro > Priority: Major > > When sending HTTP request header "Accept: application/json-patch+json", "Content-Type: application/json" response is returned. > This behavior seems to be less strict compared to what is defined by the spec, as it states "application/json" is specifically needed in order to get the same value back from server. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12486) Memory leak in OpenTracing when deployment is redeployed multiple times

by Miroslav Novak (Jira)

[ https://issues.redhat.com/browse/WFLY-12486?page=com.atlassian.jira.plugi... ] Miroslav Novak commented on WFLY-12486: --------------------------------------- [~ehugonnet] thanks, I've tried WF build from https://github.com/wildfly/wildfly/pull/12878 and do not see any memory/thread leak. > Memory leak in OpenTracing when deployment is redeployed multiple times > ----------------------------------------------------------------------- > > Key: WFLY-12486 > URL: https://issues.redhat.com/browse/WFLY-12486 > Project: WildFly > Issue Type: Bug > Components: MP OpenTracing > Affects Versions: 17.0.0.Final, 17.0.1.Final, 18.0.1.Final > Reporter: Jan Stourac > Assignee: Emmanuel Hugonnet > Priority: Blocker > Fix For: 19.0.0.Beta1 > > Attachments: memory-leak-bad.png, memory-leak-good.png, wildfly-thread-leak.png > > > There seems to be a memory leak when a deployment is redeployed multiple times (100 times in our test). This is very similar to what has been described in WFLY-10991. Also first commit this started to happen is [this one|https://github.com/wildfly/wildfly/commit/74170b5f49dd83f6b9ebd489f85...] - JaegerTracing and Apache Thrift dependencies update. Thus I selected MP OpenTracing component for this issue. > Test and deployment is same as is described in WFLY-10991. > Size of the extra heap in use is about 27MB plus when compared to the initial size before multiple redeploy operations. > I've tried to check manually via [visualVM|https://visualvm.github.io/] tool. Screenshot with suspicious jaegertracing instances are attached - there are much more jaegertracing class instances with new version of Jager Tracing and Apache Thrift dependencies, which is suspicious. > Interesting thing is that when microprofile-opentracing-smallrye subsystem is removed via: > {code} > /subsystem=microprofile-opentracing-smallrye:remove() > {code} > the memory leak is still present. This is kind of confusing to me. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4909) Infinite recursion in drools after version change from v7.20 to v7.21

by Crosson David (Jira)

[ https://issues.redhat.com/browse/DROOLS-4909?page=com.atlassian.jira.plug... ] Crosson David edited comment on DROOLS-4909 at 1/8/20 7:13 AM: --------------------------------------------------------------- I was able to reproduce the issue, by reaching the same level of complexity as for our original KB : [^toto.drl] the kmodule.xml config : <kbase name="HelloKB" packages="dummy" eventProcessingMode="stream" equalsBehavior="equality"> <ksession name="HelloKS" default="true"/> </kbase> was (Author: dacr): I was able to reproduce the issue, by reaching the same level of complexity as for our original KB : [^toto.drl] > Infinite recursion in drools after version change from v7.20 to v7.21 > --------------------------------------------------------------------- > > Key: DROOLS-4909 > URL: https://issues.redhat.com/browse/DROOLS-4909 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.21.0.Final, 7.22.0.Final, 7.23.0.Final, 7.25.0.Final, 7.31.0.Final > Environment: Both Mac and Windows > Reporter: Crosson David > Assignee: Mario Fusco > Priority: Major > Attachments: Screen Shot 2019-07-10 at 3.53.10 PM.png, Screen Shot 2019-07-10 at 5.56.32 PM.png, Screen Shot 2019-07-10 at 5.59.28 PM.png, error.png, pojo.png, static.png, static_error.png, toto.drl > > > https://issues.redhat.com/browse/DROOLS-4288 > The problem is not fully solved, I got a forever loop on my KB since 7.21.0.Final, I tried with 7.25.0.Final but without success, and the issue is still here with 7.31.0.Final. Will go back to release 7.20.0.Final > (the only fix I can apply is to add no-loop clause to my rules although it shouldn't be necessary). > I can't share the affected KB, and unfortunately I was unable to reproduce the issue loop on a smaller example > The affected rule looks like : > {{rule "reset metric to max score when no more issues are present" > //no-loop // TODO - no-loop TO BE REMOVED AS IT SHOULDN'T BE NECESSARY > when > Something($id:identity, $origin:origin) > not Issue($id == identity, $origin == origin, category!="metrics") > $scoring: Scoring(name == "performance", $id == identity, $origin == origin) > then > modify($scoring) > { setValue(100.0); } > end}} > ---- > from https://issues.redhat.com/browse/DROOLS-4288 : > When there is a version change in drools-compiler from `7.20.0.Final` to `7.21.0.Final` some rules are looping recursively. > *Code in github:* > [The working version|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7.20] > [The recursively looping version|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7.21] > [The change between working and looping version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...] > *More details* > When I fire a rule whose `then` part modifies a fact that is already checked in the `when` part: > {code:java} > rule "rule 1.1" > when > $sampleDomain: SampleDomain(instanceVariable2 == "Value of instance variable") > then > System.out.println("Rule 1.1 fired"); > modify($sampleDomain){ > setInstanceVariable1(3) > } > end > {code} > it doesn't loop recursively. > But when I call another rule which call a static function from another class: > {code:java} > rule "rule 1.2" > when > $sampleDomain: SampleDomain(CoreUtils.anotherFunction()) > then > System.out.println("Rule 1.2 fired"); > modify($sampleDomain){ > setInstanceVariable1(3) > } > end > {code} > it loops recursively. > The class with static function is > {code:java} > import com.drool_issue.domain.SampleDomain; > public class CoreUtils { > > public static boolean anotherFunction() { > System.out.println("anotherFunction() inside CoreUtils"); > return true; > } > > public static boolean anotherFunction(SampleDomain sampleDomain) { > System.out.println("anotherFunction(SampleDomain sampleDomain) inside CoreUtils"); > return true; > } > } > {code} > My domain file is: > {code:java} > public class SampleDomain { > private int instanceVariable1; > private String instanceVariable2; > private int instanceVariable3; > > > public int getInstanceVariable1() { > return instanceVariable1; > } > public void setInstanceVariable1(int instanceVariable1) { > this.instanceVariable1 = instanceVariable1; > } > public String getInstanceVariable2() { > return instanceVariable2; > } > public void setInstanceVariable2(String instanceVariable2) { > this.instanceVariable2 = instanceVariable2; > } > public int getInstanceVariable3() { > return instanceVariable3; > } > public void setInstanceVariable3(int instanceVariable3) { > this.instanceVariable3 = instanceVariable3; > } > > > } > {code} > This is only caused after version change from `7.20.0.Final` to `7.21.0.Final`. Any guess on what the problem might be? > When I further looked into the problem I saw this too. > When we add two functions into the `SampleDomain` class ie > {code:java} > public boolean anotherFunction() { > return true; > } > > public boolean anotherFunction(SampleDomain sampleDomain) { > return true; > } > {code} > and use this in the rule like: > {code:java} > rule "rule 1.4" > when > $sampleDomain: SampleDomain(anotherFunction()) > then > System.out.println("Rule 1.4 fired"); > modify($sampleDomain){ > setInstanceVariable1(3) > } > end > {code} > and > {code:java} > rule "rule 1.5" > when > $sampleDomain: SampleDomain(anotherFunction($sampleDomain)) > then > System.out.println("Rule 1.5 fired"); > modify($sampleDomain){ > setInstanceVariable3(4) > } > end > {code} > these also loops recursively. > *Code in github:* > [The recursive looping when using non static methods|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7....] > [The change between working and above version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...] > Also when any of the static method is made non static then method from the domain class is called even though the static method is specified in the rule. > *Code portions to be noted here are:* > [Rule where static method is called.|https://github.com/padippist/DroolsIssueReporting/blob/bde2804b25...] > [Another rule which also call the static method.|https://github.com/padippist/DroolsIssueReporting/blob/bde2804b25...] > [The static access modifier removed from the functions which where previously static.|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...] > *Code in github:* > [Weird behaviour when removing static modifier for the functions.|https://github.com/padippist/DroolsIssueReporting/tree/issue_v...] > [The change between working and above version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...] > *All this are caused in versions after `7.20.0.Final`, ie `7.21.0.Final`, `7.22.0.Final` and `7.23.0.Final`* -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4910) [DMN Designer] Data Types - Redesign placeholder screen

by Guilherme Gomes (Jira)

Guilherme Gomes created DROOLS-4910: --------------------------------------- Summary: [DMN Designer] Data Types - Redesign placeholder screen Key: DROOLS-4910 URL: https://issues.redhat.com/browse/DROOLS-4910 Project: Drools Issue Type: Task Components: DMN Editor Reporter: Guilherme Gomes Assignee: Guilherme Gomes Attachments: prototype.png Redesign placeholder screen: !prototype.png|thumbnail|width=600! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4910) [DMN Designer] Data Types - Redesign placeholder screen

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-4910?page=com.atlassian.jira.plug... ] Guilherme Gomes updated DROOLS-4910: ------------------------------------ Description: Redesign placeholder screen: !prototype.png|width=800! was: Redesign placeholder screen: !prototype.png|width=600! > [DMN Designer] Data Types - Redesign placeholder screen > ------------------------------------------------------- > > Key: DROOLS-4910 > URL: https://issues.redhat.com/browse/DROOLS-4910 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Guilherme Gomes > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > Attachments: prototype.png > > > Redesign placeholder screen: > !prototype.png|width=800! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4910) [DMN Designer] Data Types - Redesign placeholder screen

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-4910?page=com.atlassian.jira.plug... ] Guilherme Gomes updated DROOLS-4910: ------------------------------------ Description: Redesign placeholder screen: !prototype.png|width=600! was: Redesign placeholder screen: !prototype.png|thumbnail|width=300! > [DMN Designer] Data Types - Redesign placeholder screen > ------------------------------------------------------- > > Key: DROOLS-4910 > URL: https://issues.redhat.com/browse/DROOLS-4910 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Guilherme Gomes > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > Attachments: prototype.png > > > Redesign placeholder screen: > !prototype.png|width=600! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4910) [DMN Designer] Data Types - Redesign placeholder screen

by Guilherme Gomes (Jira)

[ https://issues.redhat.com/browse/DROOLS-4910?page=com.atlassian.jira.plug... ] Guilherme Gomes updated DROOLS-4910: ------------------------------------ Description: Redesign placeholder screen: !prototype.png|thumbnail|width=300! was: Redesign placeholder screen: !prototype.png|thumbnail|width=600! > [DMN Designer] Data Types - Redesign placeholder screen > ------------------------------------------------------- > > Key: DROOLS-4910 > URL: https://issues.redhat.com/browse/DROOLS-4910 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Guilherme Gomes > Assignee: Guilherme Gomes > Priority: Major > Labels: drools-tools > Attachments: prototype.png > > > Redesign placeholder screen: > !prototype.png|thumbnail|width=300! -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4909) Infinite recursion in drools after version change from v7.20 to v7.21

by Crosson David (Jira)

[ https://issues.redhat.com/browse/DROOLS-4909?page=com.atlassian.jira.plug... ] Crosson David commented on DROOLS-4909: --------------------------------------- I was able to reproduce the issue, by reaching the same level of complexity as for our original KB : [^toto.drl] > Infinite recursion in drools after version change from v7.20 to v7.21 > --------------------------------------------------------------------- > > Key: DROOLS-4909 > URL: https://issues.redhat.com/browse/DROOLS-4909 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.21.0.Final, 7.22.0.Final, 7.23.0.Final, 7.25.0.Final, 7.31.0.Final > Environment: Both Mac and Windows > Reporter: Crosson David > Assignee: Mario Fusco > Priority: Major > Attachments: Screen Shot 2019-07-10 at 3.53.10 PM.png, Screen Shot 2019-07-10 at 5.56.32 PM.png, Screen Shot 2019-07-10 at 5.59.28 PM.png, error.png, pojo.png, static.png, static_error.png, toto.drl > > > https://issues.redhat.com/browse/DROOLS-4288 > The problem is not fully solved, I got a forever loop on my KB since 7.21.0.Final, I tried with 7.25.0.Final but without success, and the issue is still here with 7.31.0.Final. Will go back to release 7.20.0.Final > (the only fix I can apply is to add no-loop clause to my rules although it shouldn't be necessary). > I can't share the affected KB, and unfortunately I was unable to reproduce the issue loop on a smaller example > The affected rule looks like : > {{rule "reset metric to max score when no more issues are present" > //no-loop // TODO - no-loop TO BE REMOVED AS IT SHOULDN'T BE NECESSARY > when > Something($id:identity, $origin:origin) > not Issue($id == identity, $origin == origin, category!="metrics") > $scoring: Scoring(name == "performance", $id == identity, $origin == origin) > then > modify($scoring) > { setValue(100.0); } > end}} > ---- > from https://issues.redhat.com/browse/DROOLS-4288 : > When there is a version change in drools-compiler from `7.20.0.Final` to `7.21.0.Final` some rules are looping recursively. > *Code in github:* > [The working version|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7.20] > [The recursively looping version|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7.21] > [The change between working and looping version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...] > *More details* > When I fire a rule whose `then` part modifies a fact that is already checked in the `when` part: > {code:java} > rule "rule 1.1" > when > $sampleDomain: SampleDomain(instanceVariable2 == "Value of instance variable") > then > System.out.println("Rule 1.1 fired"); > modify($sampleDomain){ > setInstanceVariable1(3) > } > end > {code} > it doesn't loop recursively. > But when I call another rule which call a static function from another class: > {code:java} > rule "rule 1.2" > when > $sampleDomain: SampleDomain(CoreUtils.anotherFunction()) > then > System.out.println("Rule 1.2 fired"); > modify($sampleDomain){ > setInstanceVariable1(3) > } > end > {code} > it loops recursively. > The class with static function is > {code:java} > import com.drool_issue.domain.SampleDomain; > public class CoreUtils { > > public static boolean anotherFunction() { > System.out.println("anotherFunction() inside CoreUtils"); > return true; > } > > public static boolean anotherFunction(SampleDomain sampleDomain) { > System.out.println("anotherFunction(SampleDomain sampleDomain) inside CoreUtils"); > return true; > } > } > {code} > My domain file is: > {code:java} > public class SampleDomain { > private int instanceVariable1; > private String instanceVariable2; > private int instanceVariable3; > > > public int getInstanceVariable1() { > return instanceVariable1; > } > public void setInstanceVariable1(int instanceVariable1) { > this.instanceVariable1 = instanceVariable1; > } > public String getInstanceVariable2() { > return instanceVariable2; > } > public void setInstanceVariable2(String instanceVariable2) { > this.instanceVariable2 = instanceVariable2; > } > public int getInstanceVariable3() { > return instanceVariable3; > } > public void setInstanceVariable3(int instanceVariable3) { > this.instanceVariable3 = instanceVariable3; > } > > > } > {code} > This is only caused after version change from `7.20.0.Final` to `7.21.0.Final`. Any guess on what the problem might be? > When I further looked into the problem I saw this too. > When we add two functions into the `SampleDomain` class ie > {code:java} > public boolean anotherFunction() { > return true; > } > > public boolean anotherFunction(SampleDomain sampleDomain) { > return true; > } > {code} > and use this in the rule like: > {code:java} > rule "rule 1.4" > when > $sampleDomain: SampleDomain(anotherFunction()) > then > System.out.println("Rule 1.4 fired"); > modify($sampleDomain){ > setInstanceVariable1(3) > } > end > {code} > and > {code:java} > rule "rule 1.5" > when > $sampleDomain: SampleDomain(anotherFunction($sampleDomain)) > then > System.out.println("Rule 1.5 fired"); > modify($sampleDomain){ > setInstanceVariable3(4) > } > end > {code} > these also loops recursively. > *Code in github:* > [The recursive looping when using non static methods|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7....] > [The change between working and above version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...] > Also when any of the static method is made non static then method from the domain class is called even though the static method is specified in the rule. > *Code portions to be noted here are:* > [Rule where static method is called.|https://github.com/padippist/DroolsIssueReporting/blob/bde2804b25...] > [Another rule which also call the static method.|https://github.com/padippist/DroolsIssueReporting/blob/bde2804b25...] > [The static access modifier removed from the functions which where previously static.|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...] > *Code in github:* > [Weird behaviour when removing static modifier for the functions.|https://github.com/padippist/DroolsIssueReporting/tree/issue_v...] > [The change between working and above version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...] > *All this are caused in versions after `7.20.0.Final`, ie `7.21.0.Final`, `7.22.0.Final` and `7.23.0.Final`* -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4909) Infinite recursion in drools after version change from v7.20 to v7.21

by Crosson David (Jira)

[ https://issues.redhat.com/browse/DROOLS-4909?page=com.atlassian.jira.plug... ] Crosson David updated DROOLS-4909: ---------------------------------- Attachment: toto.drl > Infinite recursion in drools after version change from v7.20 to v7.21 > --------------------------------------------------------------------- > > Key: DROOLS-4909 > URL: https://issues.redhat.com/browse/DROOLS-4909 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.21.0.Final, 7.22.0.Final, 7.23.0.Final, 7.25.0.Final, 7.31.0.Final > Environment: Both Mac and Windows > Reporter: Crosson David > Assignee: Mario Fusco > Priority: Major > Attachments: Screen Shot 2019-07-10 at 3.53.10 PM.png, Screen Shot 2019-07-10 at 5.56.32 PM.png, Screen Shot 2019-07-10 at 5.59.28 PM.png, error.png, pojo.png, static.png, static_error.png, toto.drl > > > https://issues.redhat.com/browse/DROOLS-4288 > The problem is not fully solved, I got a forever loop on my KB since 7.21.0.Final, I tried with 7.25.0.Final but without success, and the issue is still here with 7.31.0.Final. Will go back to release 7.20.0.Final > (the only fix I can apply is to add no-loop clause to my rules although it shouldn't be necessary). > I can't share the affected KB, and unfortunately I was unable to reproduce the issue loop on a smaller example > The affected rule looks like : > {{rule "reset metric to max score when no more issues are present" > //no-loop // TODO - no-loop TO BE REMOVED AS IT SHOULDN'T BE NECESSARY > when > Something($id:identity, $origin:origin) > not Issue($id == identity, $origin == origin, category!="metrics") > $scoring: Scoring(name == "performance", $id == identity, $origin == origin) > then > modify($scoring) > { setValue(100.0); } > end}} > ---- > from https://issues.redhat.com/browse/DROOLS-4288 : > When there is a version change in drools-compiler from `7.20.0.Final` to `7.21.0.Final` some rules are looping recursively. > *Code in github:* > [The working version|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7.20] > [The recursively looping version|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7.21] > [The change between working and looping version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...] > *More details* > When I fire a rule whose `then` part modifies a fact that is already checked in the `when` part: > {code:java} > rule "rule 1.1" > when > $sampleDomain: SampleDomain(instanceVariable2 == "Value of instance variable") > then > System.out.println("Rule 1.1 fired"); > modify($sampleDomain){ > setInstanceVariable1(3) > } > end > {code} > it doesn't loop recursively. > But when I call another rule which call a static function from another class: > {code:java} > rule "rule 1.2" > when > $sampleDomain: SampleDomain(CoreUtils.anotherFunction()) > then > System.out.println("Rule 1.2 fired"); > modify($sampleDomain){ > setInstanceVariable1(3) > } > end > {code} > it loops recursively. > The class with static function is > {code:java} > import com.drool_issue.domain.SampleDomain; > public class CoreUtils { > > public static boolean anotherFunction() { > System.out.println("anotherFunction() inside CoreUtils"); > return true; > } > > public static boolean anotherFunction(SampleDomain sampleDomain) { > System.out.println("anotherFunction(SampleDomain sampleDomain) inside CoreUtils"); > return true; > } > } > {code} > My domain file is: > {code:java} > public class SampleDomain { > private int instanceVariable1; > private String instanceVariable2; > private int instanceVariable3; > > > public int getInstanceVariable1() { > return instanceVariable1; > } > public void setInstanceVariable1(int instanceVariable1) { > this.instanceVariable1 = instanceVariable1; > } > public String getInstanceVariable2() { > return instanceVariable2; > } > public void setInstanceVariable2(String instanceVariable2) { > this.instanceVariable2 = instanceVariable2; > } > public int getInstanceVariable3() { > return instanceVariable3; > } > public void setInstanceVariable3(int instanceVariable3) { > this.instanceVariable3 = instanceVariable3; > } > > > } > {code} > This is only caused after version change from `7.20.0.Final` to `7.21.0.Final`. Any guess on what the problem might be? > When I further looked into the problem I saw this too. > When we add two functions into the `SampleDomain` class ie > {code:java} > public boolean anotherFunction() { > return true; > } > > public boolean anotherFunction(SampleDomain sampleDomain) { > return true; > } > {code} > and use this in the rule like: > {code:java} > rule "rule 1.4" > when > $sampleDomain: SampleDomain(anotherFunction()) > then > System.out.println("Rule 1.4 fired"); > modify($sampleDomain){ > setInstanceVariable1(3) > } > end > {code} > and > {code:java} > rule "rule 1.5" > when > $sampleDomain: SampleDomain(anotherFunction($sampleDomain)) > then > System.out.println("Rule 1.5 fired"); > modify($sampleDomain){ > setInstanceVariable3(4) > } > end > {code} > these also loops recursively. > *Code in github:* > [The recursive looping when using non static methods|https://github.com/padippist/DroolsIssueReporting/tree/issue_v_7....] > [The change between working and above version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...] > Also when any of the static method is made non static then method from the domain class is called even though the static method is specified in the rule. > *Code portions to be noted here are:* > [Rule where static method is called.|https://github.com/padippist/DroolsIssueReporting/blob/bde2804b25...] > [Another rule which also call the static method.|https://github.com/padippist/DroolsIssueReporting/blob/bde2804b25...] > [The static access modifier removed from the functions which where previously static.|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...] > *Code in github:* > [Weird behaviour when removing static modifier for the functions.|https://github.com/padippist/DroolsIssueReporting/tree/issue_v...] > [The change between working and above version|https://github.com/padippist/DroolsIssueReporting/compare/issue_v...] > *All this are caused in versions after `7.20.0.Final`, ie `7.21.0.Final`, `7.22.0.Final` and `7.23.0.Final`* -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 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 2020