January 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12949) Upgrade WildFly-Http-Client from 1.0.18.final to 1.1.0.Final

by Richard Opalka (Jira)

[ https://issues.redhat.com/browse/WFLY-12949?page=com.atlassian.jira.plugi... ] Richard Opalka updated WFLY-12949: ---------------------------------- Summary: Upgrade WildFly-Http-Client from 1.0.18.final to 1.1.0.Final (was: Upgrade WildFly-Http-Client from 1.0.18.final to 1.0.19.Final) > Upgrade WildFly-Http-Client from 1.0.18.final to 1.1.0.Final > ------------------------------------------------------------ > > Key: WFLY-12949 > URL: https://issues.redhat.com/browse/WFLY-12949 > Project: WildFly > Issue Type: Component Upgrade > Components: EJB > Reporter: Richard Opalka > Assignee: Richard Opalka > Priority: Major > Fix For: 19.0.0.Beta1 > > > This component upgrade incorporates: > > New features: > * [WEJBHTTP-34] EJB over HTTP discovery support > > Bug fixes: > * [WEJBHTTP-31] Notify waiters when WildflyClientInputStream read listener reads 0 regardless of whether pooled.getBuffer().hasRemaining() returns true or false > * [WEJBHTTP-32] Remove duplicate notifyAll invocation from WildflyClientInputStream read listener > * [WEJBHTTP-35] Discovery result is not completed if no HTTP connections are configured -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12972) MP Fault Tolerance - Fault Tolerance is missing logging code when activated

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-12972?page=com.atlassian.jira.plugi... ] Radoslav Husar commented on WFLY-12972: --------------------------------------- I can see if we can get this done in the new impl. > MP Fault Tolerance - Fault Tolerance is missing logging code when activated > --------------------------------------------------------------------------- > > Key: WFLY-12972 > URL: https://issues.redhat.com/browse/WFLY-12972 > Project: WildFly > Issue Type: Bug > Components: MP Fault Tolerance > Reporter: Miroslav Novak > Assignee: Radoslav Husar > Priority: Minor > > If MP FT is activated by deployment then INFO log is missing logging code: > {code} > 10:18:31,626 INFO [io.smallrye.faulttolerance.HystrixExtension] (MSC service thread 1-1) MicroProfile: Fault Tolerance activated > {code} > Logging code should be added. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12925) MP FT retry.callsSucceededRetried.total metric has wrong value

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-12925?page=com.atlassian.jira.plugi... ] Radoslav Husar commented on WFLY-12925: --------------------------------------- Needs 2.1.5 or newer upgrade. > MP FT retry.callsSucceededRetried.total metric has wrong value > -------------------------------------------------------------- > > Key: WFLY-12925 > URL: https://issues.redhat.com/browse/WFLY-12925 > Project: WildFly > Issue Type: Bug > Components: MP Fault Tolerance > Affects Versions: 19.0.0.Beta1 > Reporter: Ivan Straka > Assignee: Radoslav Husar > Priority: Major > > When method annotated with @Fallback and @Retry fails, MP FT retry.callsSucceededRetried.total metric even though the method fails everytime and falls into a fallback method. > The issue is only in the metric. The method is retried as expected and fallback method is invoked only once as expected. > *Reproducer:* > https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... > *CDI Bean:* > {code:java} > @Fallback(fallbackMethod = "isReadyFallback") > @Retry(maxRetries = MAX_RETRIES) > public boolean isReady() throws IOException { > service.simulateOpeningResources(); > return ready.get(); > } > public boolean isReadyFallback() { > return readyInMainenance.get(); > } > @Counted(name = "simulation-count", absolute = true, displayName = "Simulation Count", description = "Number of simulateOpeningResources invocations", reusable = true) > public void simulateOpeningResources() throws IOException { > if (inMaintanance.get()) { > throw new IOException("In maintanance"); > } > } > {code} > https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... > *Smallrye issue* > https://github.com/smallrye/smallrye-fault-tolerance/issues/159 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12924) MP FT fallback metric is incremented wrongly

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-12924?page=com.atlassian.jira.plugi... ] Radoslav Husar commented on WFLY-12924: --------------------------------------- Needs 2.1.5 or newer upgrade. > MP FT fallback metric is incremented wrongly > -------------------------------------------- > > Key: WFLY-12924 > URL: https://issues.redhat.com/browse/WFLY-12924 > Project: WildFly > Issue Type: Bug > Components: MP Fault Tolerance > Affects Versions: 19.0.0.Beta1 > Reporter: Ivan Straka > Assignee: Radoslav Husar > Priority: Major > > When method annotated with @Fallback and @Retry fails, MP FT fallback counter metric (fallback.calls.total) is incremented by 2. Meaning if the method fails N times (due to @Retry) fallback is invoked and the metric is 2. > The issue is only in the metric. Fallback method is invoked only once as expected. > *Reproducer:* > https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... > *CDI Bean:* > {code:java} > @Fallback(fallbackMethod = "isReadyFallback") > @Retry(maxRetries = MAX_RETRIES) > public boolean isReady() throws IOException { > service.simulateOpeningResources(); > return ready.get(); > } > public boolean isReadyFallback() { > return readyInMainenance.get(); > } > @Counted(name = "simulation-count", absolute = true, displayName = "Simulation Count", description = "Number of simulateOpeningResources invocations", reusable = true) > public void simulateOpeningResources() throws IOException { > if (inMaintanance.get()) { > throw new IOException("In maintanance"); > } > } > {code} > https://github.com/istraka/eap-microprofile-test-suite/blob/mp-ft-metrics... > *Smallrye issue* > https://github.com/smallrye/smallrye-fault-tolerance/issues/158 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-158) Artemis 2.7.0 logs password for STOMP protocol in clear text in debug logs

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFWIP-158?page=com.atlassian.jira.plugin... ] Brian Stansberry reassigned WFWIP-158: -------------------------------------- Assignee: Emmanuel Hugonnet (was: Justin Bertram) [~ehugonnet] Please link this to the EAP7 for a still WIP feature being developed on a topic branch, or move it to another issue tracker like JBEAP that tracks work on the main code branches. > Artemis 2.7.0 logs password for STOMP protocol in clear text in debug logs > -------------------------------------------------------------------------- > > Key: WFWIP-158 > URL: https://issues.redhat.com/browse/WFWIP-158 > Project: WildFly WIP > Issue Type: Bug > Components: Artemis > Reporter: Miroslav Novak > Assignee: Emmanuel Hugonnet > Priority: Major > > If TRACE log is enabled for {{org.apache.activemq.artemis}} then StompProtoco is logging password in clear text: > {code} > 13:48:06,488 DEBUG [org.apache.commons.beanutils.BeanUtils] (ServerService Thread Pool -- 86) BeanUtils.populate(org.apache.activemq.artemis.core.protocol.stomp.StompProtocolManager@2aa25516, {needClientAuth=tru > e, trustStorePassword=hornetqexample, keyStorePassword=hornetqexample, port=6445, sslEnabled=true, host=127.0.0.1, trustStorePath=/home/hudson/hudson_workspace/workspace/eap-7.x-messaging-weekly-common-ssl/eap-t > estsuite/jboss-hornetq-testsuite/tests-eap7/src/test/resources/org/jboss/qa/hornetq/test/transportprotocols/hornetq.example.truststore, keyStorePath=/home/hudson/hudson_workspace/workspace/eap-7.x-messaging-week > ly-common-ssl/eap-testsuite/jboss-hornetq-testsuite/tests-eap7/src/test/resources/org/jboss/qa/hornetq/test/transportprotocols/hornetq.example.keystore}) > ... > 13:48:06,488 TRACE [org.apache.commons.beanutils.BeanUtils] (ServerService Thread Pool -- 86) setProperty(org.apache.activemq.artemis.core.protocol.stomp.StompProtocolManager@2aa25516, trustStorePassword, horn > etqexample) > ... > 13:48:06,489 TRACE [org.apache.commons.beanutils.BeanUtils] (ServerService Thread Pool -- 86) setProperty(org.apache.activemq.artemis.core.protocol.stomp.StompProtocolManager@2aa25516, keyStorePassword, hornet > qexample) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-134) Bad WARN messages: AMQ222211: Storage is back to stable now...

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFWIP-134?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFWIP-134: ---------------------------------------- [~ehugonnet] Please link this to the EAP7 for a still WIP feature being developed on a topic branch, or move it to another issue tracker like JBEAP that tracks work on the main code branches. Or resolve if out of date. > Bad WARN messages: AMQ222211: Storage is back to stable now... > -------------------------------------------------------------- > > Key: WFWIP-134 > URL: https://issues.redhat.com/browse/WFWIP-134 > Project: WildFly WIP > Issue Type: Bug > Components: Artemis > Reporter: Miroslav Novak > Assignee: Francesco Nigro > Priority: Major > > There are unwanted WARN messages: > {code} > 13:47:48,158 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 15.0.0.Alpha1-SNAPSHOT (WildFly Core 7.0.0.Alpha4) started in 8017ms - Started 495 of 723 services (489 services are lazy, passive or on-demand) > 13:47:50,235 WARN [org.apache.activemq.artemis.core.server] (Thread-0 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@371ff371)) AMQ222183: Blocking message production on address 'jms.queue.InQueue'; size is currently: 10,635,300 bytes; max-size-bytes on address: 10,485,760, global-max-size is 10,635,300 > 13:47:52,642 WARN [org.apache.activemq.artemis.core.server] (Thread-4 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@371ff371)) AMQ222211: Storage is back to stable now, under max-disk-usage. > 13:47:57,642 WARN [org.apache.activemq.artemis.core.server] (Thread-15 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@371ff371)) AMQ222211: Storage is back to stable now, under max-disk-usage. > ... > {code} > when server has configured {{global-max-memory-size}} and address-full-policy to BLOCK. Once {{global-max-memory-size}} then starts to log above warnings which with max-disk-usage. Which is not correct as no disk limitation was reached. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-273) Templates at eap-cd-dev branch still referring to image version 17

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFWIP-273?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFWIP-273: ---------------------------------------- [~luck3y] This should not be in WFWIP. It's not about work on a WIP feature in a topic branch. Perhaps it was a topic branch when originally filed but now it should be in CLOUD. > Templates at eap-cd-dev branch still referring to image version 17 > ------------------------------------------------------------------ > > Key: WFWIP-273 > URL: https://issues.redhat.com/browse/WFWIP-273 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Jan Blizňák > Assignee: Ken Wills > Priority: Critical > > https://github.com/jboss-container-images/jboss-eap-7-openshift-image/tre... > These templates still use image version 17 instead of 18. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-259) Delete s2i-producers and s2i-universe project files during image build

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFWIP-259?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFWIP-259: ---------------------------------------- [~jdenise] Please resolve this if done or move to CLOUD if not done. The WIP feature it was reported against is merged. > Delete s2i-producers and s2i-universe project files during image build > ---------------------------------------------------------------------- > > Key: WFWIP-259 > URL: https://issues.redhat.com/browse/WFWIP-259 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Jan Blizňák > Assignee: Jean Francois Denise > Priority: Minor > > These files seem to be not needed after image is built: > {code:java} > /opt/jboss/container/wildfly/s2i/galleon/provisioning/jboss-s2i-producers/ > /opt/jboss/container/wildfly/s2i/galleon/provisioning/jboss-s2i-universe/ > {code} > The artifacts themselves are already installed at galleon-m2-repository so these files ^ can be probably deleted during image build. > {code:java} > /opt/jboss/container/wildfly/s2i/galleon/galleon-m2-repository/org/jboss/universe/producer/s2i-producers/1.0.0.Final/ > /opt/jboss/container/wildfly/s2i/galleon/galleon-m2-repository/org/jboss/universe/s2i-universe/1.0.0.Final/ > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-256) Duration of server configuration is not printed

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFWIP-256?page=com.atlassian.jira.plugin... ] Brian Stansberry resolved WFWIP-256. ------------------------------------ Resolution: Migrated to another ITS [~yersan] I'm resolving this as the WIP feature it was reported against is now merged. I resolve it as "Migrated to another ITS" with the other Issue Tracking System being the CLOUD JIRA project where you've got an issue open. > Duration of server configuration is not printed > ----------------------------------------------- > > Key: WFWIP-256 > URL: https://issues.redhat.com/browse/WFWIP-256 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Jan Blizňák > Assignee: Yeray Borges > Priority: Minor > > {code:java} > INFO Configuring the server using embedded server > INFO Duration: > INFO Running jboss-eap-7-tech-preview/eap-cd-openshift-rhel8 image, version 18.0 > {code} > The cause is the wrong usage of log_info function in {{/opt/eap/bin/launch/openshift-common.sh}} > {code:java} > log_info "Duration: " $((end-start)) " milliseconds" > {code} > which is actually calling it with 3 arguments while the function prints only the first one. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-276) Boot time of application built via S2I is much longer than in before-Galleon times

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFWIP-276?page=com.atlassian.jira.plugin... ] Brian Stansberry resolved WFWIP-276. ------------------------------------ Resolution: Migrated to another ITS [~jdenise] I'm closing this one out as the WIP feature it was reported against is closed. I'm treating it as "Migrated to another ITS", the other Issue Tracking System being the EAP7 JIRA project. > Boot time of application built via S2I is much longer than in before-Galleon times > ---------------------------------------------------------------------------------- > > Key: WFWIP-276 > URL: https://issues.redhat.com/browse/WFWIP-276 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Jan Blizňák > Assignee: Jean Francois Denise > Priority: Critical > Attachments: test-app.zip > > > As a consequence of Galleon RFEs EAP7-891 and mainly EAP7-1216 there is big difference in pod with EAP application start up time which requires S2I configuration. > This is an overview of quick comparison of average boot times of the application pods of the attached test app (we are not interested in build/deploy pod times etc): > ||17.0-6||pod time||EAP boot||config time > |#1 | 8283|6128|2155 > |#2 | 9446|7548|1898 > |#3 | 8767|6871| 1896 > |#4 | 8568|6272| 2296 > |#5 | 8000 |6362|1638 > ||average ||8613ms||6636ms||1977ms > ||18.0-7||pod time||EAP boot||config time > |#1 |13769|5716|8053 > |#2 |13362|5952|7410 > |#3 |14261|6093|8168 > |#4 |14322|6135|8187 > |#5 |13921|6326|7595 > ||average||13927ms||6044ms||7883ms > pod time = time from the pod start until EAP is fully booted (log contains {{started in ..}}) > EAP boot = time of boot EAP itself == {{started in ..}} > config time = the difference of previou timess = anything before EAP boot begins > Again we are talking here about the time needed for prepared application image to full start. We can clearly see the EAP boot times are comparable between 17 and 18 images but the configs times are almost 4 times longer with CD18 images. > This is very unfortunate as in my point of view the pod boot time is the most critical time for our users - they would typically prepare the app images only once in a time but their application can scale up and down many times during its uptime. > The cause of this that when S2I is needed with image 18.0+ the part of the configuration that was previously done during S2I build just once is now processed on *each* pod start. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12733) EJB Timers: Forcing refresh timers in a database-data-store in a clustered environment

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-12733?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFLY-12733: ----------------------------------------- [~cfang] Sorry, your question from November got buried. We should avoid making accessing the management layer from application code a requirement for a feature. An application user is not an administrative user and would not be trusted. To work around that the application would likely try to do things such that the application code is privileged, and by doing that they would be opening up a security hole. > EJB Timers: Forcing refresh timers in a database-data-store in a clustered environment > -------------------------------------------------------------------------------------- > > Key: WFLY-12733 > URL: https://issues.redhat.com/browse/WFLY-12733 > Project: WildFly > Issue Type: Feature Request > Components: EJB > Reporter: Rhuan Rocha > Assignee: Cheng Fang > Priority: Major > > The EJB Timer has a way to persist timers in a database using datasources. It is described [here|https://docs.jboss.org/author/display/WFLY10/EJB3+Clustered+Database...]. The database-data-store has an attribute called refresh-interval that define a time in milliseconds to refresh the timers reading the timers from database. Look this sample of configuration. > > {code:java} > <data-stores> > <file-data-store name="default-file-store" path="timer-service-data" relative-to="jboss.server.data.dir"/> > <database-data-store name="clustered-store" datasource-jndi-name="java:/jdbc/MyDataSource" partition="timer" refresh-interval="60000" allow-execution="true"/> > </data-stores> > {code} > The RFE is to Wildfly provide a way to force the refresh programmatically. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12978) Current implementation of MP-JWT doesn't require claims which should be required

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-12978?page=com.atlassian.jira.plugi... ] Darran Lofthouse moved WFWIP-293 to WFLY-12978: ----------------------------------------------- Project: WildFly (was: WildFly WIP) Key: WFLY-12978 (was: WFWIP-293) Component/s: MP JWT (was: MP JWT) > Current implementation of MP-JWT doesn't require claims which should be required > -------------------------------------------------------------------------------- > > Key: WFLY-12978 > URL: https://issues.redhat.com/browse/WFLY-12978 > Project: WildFly > Issue Type: Bug > Components: MP JWT > Reporter: Jan Kasik > Assignee: Darran Lofthouse > Priority: Major > > Chapter 4.1 of MP-JWT 1.1 recommends minimal set of JWT claims which should be required. > Current implementation doesn't check for following claims and returns 200/OK if they are missing: > * {{upn}} > * {{jti}} > * {{groups}} > * {{iat}} > * {{sub}} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12979) JWT signed by 1024 bit long key is rejected

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-12979?page=com.atlassian.jira.plugi... ] Darran Lofthouse moved WFWIP-288 to WFLY-12979: ----------------------------------------------- Project: WildFly (was: WildFly WIP) Key: WFLY-12979 (was: WFWIP-288) Component/s: MP JWT (was: MP JWT) > JWT signed by 1024 bit long key is rejected > ------------------------------------------- > > Key: WFLY-12979 > URL: https://issues.redhat.com/browse/WFLY-12979 > Project: WildFly > Issue Type: Bug > Components: MP JWT > Reporter: Jan Kasik > Assignee: Darran Lofthouse > Priority: Major > > According to MP-JWT 1.1 specification, 1024 and 2048 bit key sizes must be supported. Though when there is JWT signed by 1024 bit long key presented to the server, it is rejected and client receives "Unauthorized" (code 401) message. > See chapter 9.2. Supported Public Key Formats: > {quote} > Support for RSA Public Keys of 1024 or 2048 bits in length is required. Other key sizes are allowed, but should be considered vendor-specific. > {quote} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12980) Full reload is needed after microprofile-jwt-smallrye subsystem removal

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-12980?page=com.atlassian.jira.plugi... ] Darran Lofthouse moved WFWIP-298 to WFLY-12980: ----------------------------------------------- Project: WildFly (was: WildFly WIP) Key: WFLY-12980 (was: WFWIP-298) Component/s: MP JWT (was: MP JWT) > Full reload is needed after microprofile-jwt-smallrye subsystem removal > ----------------------------------------------------------------------- > > Key: WFLY-12980 > URL: https://issues.redhat.com/browse/WFLY-12980 > Project: WildFly > Issue Type: Bug > Components: MP JWT > Reporter: Jan Kasik > Assignee: Darran Lofthouse > Priority: Major > > When user is removing MP subsystem, full reload is required. This is partly a benefit because it provides a fast fail solution for deployments which requires classes from this subsystem. On the other hand, reload might not be feasible for user under in their current conditions. This is why it has to be reduced as much as possible. > Is there other way to provide fast fail without requiring full reload? -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-297) Base64 encoded JWKS from a file fails to resolve

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFWIP-297?page=com.atlassian.jira.plugin... ] Darran Lofthouse updated WFWIP-297: ----------------------------------- Priority: Critical (was: Blocker) > Base64 encoded JWKS from a file fails to resolve > ------------------------------------------------ > > Key: WFWIP-297 > URL: https://issues.redhat.com/browse/WFWIP-297 > Project: WildFly WIP > Issue Type: Bug > Components: MP JWT > Reporter: Jan Kasik > Assignee: Darran Lofthouse > Priority: Critical > > JWKS supplied through {{mp.jwt.verify.publickey.location}} fails to resolve when encoded to Base64 string. Seems like the SmallRye is trying to parse the file content as a PEM key. See excerpt from log. > This breaks specification compatibility because according to MP-JWT 1.1 which specifies in section 9.2.3: > {quote} > The JWKS may be supplied in plain JSON or Base64 URL encoded JSON format. > {quote} > {code} > 12:04:02,323 DEBUG [io.smallrye.jwt.config.JWTAuthContextInfoProvider] (default task-1) init, mpJwtPublicKey=NONE, mpJwtIssuer=issuer, mpJwtLocation=META-INF/keys.jwks > ... > 12:04:02,326 DEBUG [io.smallrye.jwt.auth.principal.KeyLocationResolver] (default task-1) Trying to create a key from the encoded PEM key... > 12:04:02,326 DEBUG [io.smallrye.jwt.auth.principal.KeyLocationResolver] (default task-1) Failed to create a key from the encoded PEM key: java.security.spec.InvalidKeySpecException: java.security.InvalidKeyException: invalid key format > at sun.security.rsa.RSAKeyFactory.engineGeneratePublic(RSAKeyFactory.java:205) > ... > Caused by: org.jose4j.jwt.consumer.InvalidJwtException: JWT processing failed. Additional details: [[17] Unable to process JOSE object (cause: org.jose4j.lang.UnresolvableKeyException: Failed to resolve a key from: META-INF/keys.jwks): JsonWebSignature{"kid":"blue-key","typ":"JWT","alg":"RS256"}->eyJraWQiOiJibHVlLWtleSIsInR5cCI6IkpXVCIsImFsZyI6IlJTMjU2In0=.eyJqdGkiOiJmMjc2YjVhYS0zMGZiLTQ4MWEtYjk0MS0xNDJhNjBmMGZiNjMiLCJzdWIiOiJGQUtFX1VTRVIiLCJncm91cHMiOlsiZ3JvdXAyIiwiZ3JvdXAxIl0sImF1ZCI6Im1pY3JvcHJvZmlsZS1qd3QtdGVzdHN1aXRlIiwiaXNzIjoiaXNzdWVyIiwiaWF0IjoxNTc4NjU0MjQxLCJleHAiOjE1Nzg2NTc4NDEsInVwbiI6IkZBS0VfVVNFUiIsInByZWZlcnJlZF91c2VybmFtZSI6IkZBS0VfVVNFUiJ9.AEe5kEr0s2p4CDbqwHPRwLziktwABX0OmM2aCEgdUF71eXlCu72ZhwNYDac3NyXMNhWp7k_xxX0I20EIbwBQsiJFmQZgqXZuK44Kc3jnMWDHT8kdPU03G3rIZBA2aiYsVy2gZ67gG_VnFx453fqHOxBIXtDsy1mzdrHwHLgY5iOklAodlv0Oe-H2Qik8oEj_k2R0a9b9E9pu7RHkono1d8TIuufwuJOIv7QSSo9w5vC74mYvd_RhZKvLACLx4ry9KVWamtDp_hMpclAqeUCjvcL-2VMI1VaDE3ZE7XonNMbCjwjxLzTtRLwVZAoYiD3eXSYkFTLGUT4BtfE8P5B3Uvb6pjf50e_EgYePAwvY-PFBFPB54BWcO433B3Pk411XYHUZweQfMHumateCwPJXZXcCoWjGj8ujHH3Leje_9gswzxDxd0JI2zjJEwasTBMixC65Jz9W5lKwQVVTHULP49KIbRXFkU52gTizMZNaABSGI48naMHr0Xu42yDKSrwkJTO3zNW1kSVi-3BMU6fmUxK8BF3xy2VgDgg_Rpmx_eQCBrGE36J-swHZbAPmiMKYT96D3rZHcMHa1oj784Em_h1p3sfr27ZCd0vpO7rOmHWzk1SWnb5GkySuuedwBQL-K5VT3mytqwFOg_UXZMkxSEGbn37WRzMa2KxfXKgRA-A=] > at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:271) > at org.jose4j.jwt.consumer.JwtConsumer.process(JwtConsumer.java:433) > at io.smallrye.jwt.auth.principal.DefaultJWTTokenParser.parse(DefaultJWTTokenParser.java:88) > ... 40 more > Caused by: org.jose4j.lang.UnresolvableKeyException: Failed to resolve a key from: META-INF/keys.jwks > at io.smallrye.jwt.auth.principal.KeyLocationResolver.resolveKey(KeyLocationResolver.java:101) > at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:213) > ... 42 more > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12976) Base64 encoded JWKS from a file fails to resolve

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-12976?page=com.atlassian.jira.plugi... ] Darran Lofthouse moved WFWIP-297 to WFLY-12976: ----------------------------------------------- Project: WildFly (was: WildFly WIP) Key: WFLY-12976 (was: WFWIP-297) Component/s: MP JWT (was: MP JWT) > Base64 encoded JWKS from a file fails to resolve > ------------------------------------------------ > > Key: WFLY-12976 > URL: https://issues.redhat.com/browse/WFLY-12976 > Project: WildFly > Issue Type: Bug > Components: MP JWT > Reporter: Jan Kasik > Assignee: Darran Lofthouse > Priority: Critical > > JWKS supplied through {{mp.jwt.verify.publickey.location}} fails to resolve when encoded to Base64 string. Seems like the SmallRye is trying to parse the file content as a PEM key. See excerpt from log. > This breaks specification compatibility because according to MP-JWT 1.1 which specifies in section 9.2.3: > {quote} > The JWKS may be supplied in plain JSON or Base64 URL encoded JSON format. > {quote} > {code} > 12:04:02,323 DEBUG [io.smallrye.jwt.config.JWTAuthContextInfoProvider] (default task-1) init, mpJwtPublicKey=NONE, mpJwtIssuer=issuer, mpJwtLocation=META-INF/keys.jwks > ... > 12:04:02,326 DEBUG [io.smallrye.jwt.auth.principal.KeyLocationResolver] (default task-1) Trying to create a key from the encoded PEM key... > 12:04:02,326 DEBUG [io.smallrye.jwt.auth.principal.KeyLocationResolver] (default task-1) Failed to create a key from the encoded PEM key: java.security.spec.InvalidKeySpecException: java.security.InvalidKeyException: invalid key format > at sun.security.rsa.RSAKeyFactory.engineGeneratePublic(RSAKeyFactory.java:205) > ... > Caused by: org.jose4j.jwt.consumer.InvalidJwtException: JWT processing failed. Additional details: [[17] Unable to process JOSE object (cause: org.jose4j.lang.UnresolvableKeyException: Failed to resolve a key from: META-INF/keys.jwks): JsonWebSignature{"kid":"blue-key","typ":"JWT","alg":"RS256"}->eyJraWQiOiJibHVlLWtleSIsInR5cCI6IkpXVCIsImFsZyI6IlJTMjU2In0=.eyJqdGkiOiJmMjc2YjVhYS0zMGZiLTQ4MWEtYjk0MS0xNDJhNjBmMGZiNjMiLCJzdWIiOiJGQUtFX1VTRVIiLCJncm91cHMiOlsiZ3JvdXAyIiwiZ3JvdXAxIl0sImF1ZCI6Im1pY3JvcHJvZmlsZS1qd3QtdGVzdHN1aXRlIiwiaXNzIjoiaXNzdWVyIiwiaWF0IjoxNTc4NjU0MjQxLCJleHAiOjE1Nzg2NTc4NDEsInVwbiI6IkZBS0VfVVNFUiIsInByZWZlcnJlZF91c2VybmFtZSI6IkZBS0VfVVNFUiJ9.AEe5kEr0s2p4CDbqwHPRwLziktwABX0OmM2aCEgdUF71eXlCu72ZhwNYDac3NyXMNhWp7k_xxX0I20EIbwBQsiJFmQZgqXZuK44Kc3jnMWDHT8kdPU03G3rIZBA2aiYsVy2gZ67gG_VnFx453fqHOxBIXtDsy1mzdrHwHLgY5iOklAodlv0Oe-H2Qik8oEj_k2R0a9b9E9pu7RHkono1d8TIuufwuJOIv7QSSo9w5vC74mYvd_RhZKvLACLx4ry9KVWamtDp_hMpclAqeUCjvcL-2VMI1VaDE3ZE7XonNMbCjwjxLzTtRLwVZAoYiD3eXSYkFTLGUT4BtfE8P5B3Uvb6pjf50e_EgYePAwvY-PFBFPB54BWcO433B3Pk411XYHUZweQfMHumateCwPJXZXcCoWjGj8ujHH3Leje_9gswzxDxd0JI2zjJEwasTBMixC65Jz9W5lKwQVVTHULP49KIbRXFkU52gTizMZNaABSGI48naMHr0Xu42yDKSrwkJTO3zNW1kSVi-3BMU6fmUxK8BF3xy2VgDgg_Rpmx_eQCBrGE36J-swHZbAPmiMKYT96D3rZHcMHa1oj784Em_h1p3sfr27ZCd0vpO7rOmHWzk1SWnb5GkySuuedwBQL-K5VT3mytqwFOg_UXZMkxSEGbn37WRzMa2KxfXKgRA-A=] > at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:271) > at org.jose4j.jwt.consumer.JwtConsumer.process(JwtConsumer.java:433) > at io.smallrye.jwt.auth.principal.DefaultJWTTokenParser.parse(DefaultJWTTokenParser.java:88) > ... 40 more > Caused by: org.jose4j.lang.UnresolvableKeyException: Failed to resolve a key from: META-INF/keys.jwks > at io.smallrye.jwt.auth.principal.KeyLocationResolver.resolveKey(KeyLocationResolver.java:101) > at org.jose4j.jwt.consumer.JwtConsumer.processContext(JwtConsumer.java:213) > ... 42 more > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-280) Warnings propagated from io.smallrye.jwt.auth.* don't have assigned ID

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFWIP-280?page=com.atlassian.jira.plugin... ] Darran Lofthouse updated WFWIP-280: ----------------------------------- Priority: Major (was: Critical) > Warnings propagated from io.smallrye.jwt.auth.* don't have assigned ID > ---------------------------------------------------------------------- > > Key: WFWIP-280 > URL: https://issues.redhat.com/browse/WFWIP-280 > Project: WildFly WIP > Issue Type: Bug > Components: MP JWT > Reporter: Jan Kasik > Assignee: Darran Lofthouse > Priority: Major > > Warning which are propagated to log from io.smallrye.jwt.auth package don't have assigned logging ID. > Example: > {code} > 11:52:50,705 WARN [io.smallrye.jwt.auth.mechanism.JWTHttpAuthenticationMechanism] (default task-1) Unable to validate bearer token: Failed to verify token: io.smallrye.jwt.auth.principal.ParseException: Failed to verify token > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12977) Warnings propagated from io.smallrye.jwt.auth.* don't have assigned ID

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-12977?page=com.atlassian.jira.plugi... ] Darran Lofthouse moved WFWIP-280 to WFLY-12977: ----------------------------------------------- Project: WildFly (was: WildFly WIP) Key: WFLY-12977 (was: WFWIP-280) Component/s: MP JWT (was: MP JWT) > Warnings propagated from io.smallrye.jwt.auth.* don't have assigned ID > ---------------------------------------------------------------------- > > Key: WFLY-12977 > URL: https://issues.redhat.com/browse/WFLY-12977 > Project: WildFly > Issue Type: Bug > Components: MP JWT > Reporter: Jan Kasik > Assignee: Darran Lofthouse > Priority: Major > > Warning which are propagated to log from io.smallrye.jwt.auth package don't have assigned logging ID. > Example: > {code} > 11:52:50,705 WARN [io.smallrye.jwt.auth.mechanism.JWTHttpAuthenticationMechanism] (default task-1) Unable to validate bearer token: Failed to verify token: io.smallrye.jwt.auth.principal.ParseException: Failed to verify token > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-293) Current implementation of MP-JWT doesn't require claims which should be required

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFWIP-293?page=com.atlassian.jira.plugin... ] Darran Lofthouse updated WFWIP-293: ----------------------------------- Priority: Major (was: Critical) > Current implementation of MP-JWT doesn't require claims which should be required > -------------------------------------------------------------------------------- > > Key: WFWIP-293 > URL: https://issues.redhat.com/browse/WFWIP-293 > Project: WildFly WIP > Issue Type: Bug > Components: MP JWT > Reporter: Jan Kasik > Assignee: Darran Lofthouse > Priority: Major > > Chapter 4.1 of MP-JWT 1.1 recommends minimal set of JWT claims which should be required. > Current implementation doesn't check for following claims and returns 200/OK if they are missing: > * {{upn}} > * {{jti}} > * {{groups}} > * {{iat}} > * {{sub}} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-294) JWT is rejected if signature matching public key is not first in JWK set

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFWIP-294?page=com.atlassian.jira.plugin... ] Darran Lofthouse updated WFWIP-294: ----------------------------------- Priority: Critical (was: Blocker) > JWT is rejected if signature matching public key is not first in JWK set > ------------------------------------------------------------------------ > > Key: WFWIP-294 > URL: https://issues.redhat.com/browse/WFWIP-294 > Project: WildFly WIP > Issue Type: Bug > Components: MP JWT > Reporter: Jan Kasik > Assignee: Darran Lofthouse > Priority: Critical > Attachments: jwks.json, jwt.base64 > > > When public key on remote server is configured to be JWK set, the JWT which has correctly configured key ID to aim on matching public key from the set is rejected if matching public key is not on first position in the set array. > This behavior is reproducible in the case the JWKS is set via {{mp.jwt.verify.publickey}} property. > Attached is "flawed" key set with "blue-key" placed on first position in array when JOSE header has {{kid}} set to "orange-key" and JWT itself is signed by private key which is from "orange" key pair. > This breaks MP-JWT specification compatibility because the MP-JWT 1.1 states: > In section 9.2.3: > {quote} > If the incoming JWT uses the kid header field and there is a key in the supplied JWK set with the same kid, only that key is considered for verification of the JWT’s digital signature. > {quote} > In section 4.1: > {quote} > kid - This JOSE header parameter is a hint indicating which key was used to secure the JWT. RFC7515, Section-4.1.4 > {quote} > And the RFC7515, Section-4.1.4 states: > {quote} > When used with a JWK, the "kid" value is used to match a JWK "kid" parameter value. > {quote} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12975) JWT is rejected if signature matching public key is not first in JWK set

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-12975?page=com.atlassian.jira.plugi... ] Darran Lofthouse moved WFWIP-294 to WFLY-12975: ----------------------------------------------- Project: WildFly (was: WildFly WIP) Key: WFLY-12975 (was: WFWIP-294) Component/s: MP JWT (was: MP JWT) > JWT is rejected if signature matching public key is not first in JWK set > ------------------------------------------------------------------------ > > Key: WFLY-12975 > URL: https://issues.redhat.com/browse/WFLY-12975 > Project: WildFly > Issue Type: Bug > Components: MP JWT > Reporter: Jan Kasik > Assignee: Darran Lofthouse > Priority: Critical > Attachments: jwks.json, jwt.base64 > > > When public key on remote server is configured to be JWK set, the JWT which has correctly configured key ID to aim on matching public key from the set is rejected if matching public key is not on first position in the set array. > This behavior is reproducible in the case the JWKS is set via {{mp.jwt.verify.publickey}} property. > Attached is "flawed" key set with "blue-key" placed on first position in array when JOSE header has {{kid}} set to "orange-key" and JWT itself is signed by private key which is from "orange" key pair. > This breaks MP-JWT specification compatibility because the MP-JWT 1.1 states: > In section 9.2.3: > {quote} > If the incoming JWT uses the kid header field and there is a key in the supplied JWK set with the same kid, only that key is considered for verification of the JWT’s digital signature. > {quote} > In section 4.1: > {quote} > kid - This JOSE header parameter is a hint indicating which key was used to secure the JWT. RFC7515, Section-4.1.4 > {quote} > And the RFC7515, Section-4.1.4 states: > {quote} > When used with a JWK, the "kid" value is used to match a JWK "kid" parameter value. > {quote} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12974) Default cache configurations for local/passivating caches are overly restrictive

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-12974: ----------------------------------- Summary: Default cache configurations for local/passivating caches are overly restrictive Key: WFLY-12974 URL: https://issues.redhat.com/browse/WFLY-12974 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 18.0.1.Final Reporter: Paul Ferraro Assignee: Paul Ferraro For local caches with either a passivating, non-shared cache store; or without a cache store, the use of transactions overly restricts concurrency and limits performance. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12881) Cannot customize split detection and merge policy for Infinispan partition handling

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-12881?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-12881: ---------------------------------- Fix Version/s: 20.0.0.Beta1 > Cannot customize split detection and merge policy for Infinispan partition handling > ----------------------------------------------------------------------------------- > > Key: WFLY-12881 > URL: https://issues.redhat.com/browse/WFLY-12881 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 18.0.1.Final > Reporter: Paul Ferraro > Assignee: Radoslav Husar > Priority: Critical > Fix For: 20.0.0.Beta1 > > > Currently, partition handling of an Infinispan cache is hard coded. When enabled, both reads and writes are denied on minority partitions (of a given segment) and, more critically, upon partition merge, no reconciliation of any data conflicts occurs. > Users need to be able to configure this, at least to support the built in read/write on split policy and the built-in merge policies. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12969) Include Openshift Instructions in EAP non-CD Quickstarts READMEs

by Eduardo Martins (Jira)

[ https://issues.redhat.com/browse/WFLY-12969?page=com.atlassian.jira.plugi... ] Eduardo Martins updated WFLY-12969: ----------------------------------- Summary: Include Openshift Instructions in EAP non-CD Quickstarts READMEs (was: Include openshift instructions in baremetal Quickstarts docs) > Include Openshift Instructions in EAP non-CD Quickstarts READMEs > ---------------------------------------------------------------- > > Key: WFLY-12969 > URL: https://issues.redhat.com/browse/WFLY-12969 > Project: WildFly > Issue Type: Feature Request > Components: Quickstarts > Reporter: Eduardo Martins > Assignee: Eduardo Martins > Priority: Major > > Currently QS readmes include the openshift instructions only for CD releases. QS that run on Openshift (those included in CD releases) should contain openshift instructions for non-CD releases too, as the openshift image is released. > For example helloworld QS, which is also included in CD release: > https://raw.githubusercontent.com/wildfly/quickstart/master/helloworld/RE... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10199) Using jboss-modules loading outside WildFly 12 is broken

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFLY-10199?page=com.atlassian.jira.plugi... ] James Perkins updated WFLY-10199: --------------------------------- Fix Version/s: 13.0.0.Final > Using jboss-modules loading outside WildFly 12 is broken > -------------------------------------------------------- > > Key: WFLY-10199 > URL: https://issues.redhat.com/browse/WFLY-10199 > Project: WildFly > Issue Type: Bug > Affects Versions: 12.0.0.Final > Reporter: Martin Perina > Assignee: David Lloyd > Priority: Major > Fix For: 13.0.0.Final > > > oVirt is using jboss-modules not only for dependencies inside WildFly, but also when executing command line tools outside WildFly process. We are using following method which worked fine from JBoss 7 to WildFly11: > {code} > export JAVA_MODULEPATH="<PATH TO OUR MODULES>" > exec "${JAVA_HOME}/bin/java" \ > -jar "${JBOSS_HOME}/jboss-modules.jar" \ > -dependencies org.ovirt.engine.core.tools \ > -class org.ovirt.engine.core.cryptotool.Main \ > "$@" > {code} > where "org.ovirt.engine.core.tools" is one of our existing module and in class we have standard Java class with main() method executing logic of specific command line tool. > When I try to execute this code with WildFly 12.0.0.FINAL I receive following exception: > {code} > Exception in thread "main" java.lang.NullPointerException > at java.util.Hashtable.put(Hashtable.java:460) > at java.util.Properties.setProperty(Properties.java:166) > at java.lang.System.setProperty(System.java:796) > at org.jboss.modules.PropertyWriteAction.run(PropertyWriteAction.java:40) > at org.jboss.modules.PropertyWriteAction.run(PropertyWriteAction.java:28) > at java.security.AccessController.doPrivileged(Native Method) > at org.jboss.modules.Main.main(Main.java:390) > {code} > When I tried to replace jboss-modules.jar provided by WildFly 12.0.0.FINAL with manuall build using latest code in 1.7 branch (commit a52a323c5c3d71cf9597f06951155e4639cbb707) I receive different error: > {code} > org.jboss.modules.ModuleNotFoundException: org.ovirt.engine.core.tools > at org.jboss.modules.Module.addPaths(Module.java:1221) > at org.jboss.modules.Module.link(Module.java:1577) > at org.jboss.modules.Module.relinkIfNecessary(Module.java:1605) > at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:296) > at org.jboss.modules.Main.main(Main.java:426) > {code} > I haven't found any documentation describing such incompatible between 1.6 and 1.7, so is there any way how to have above execution compatible with both jboss-modules versions? > Thanks > Martin -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4920) Scenario simulation for DMN with collections throws en error

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4920?page=com.atlassian.jira.plug... ] Jozef Marko updated DROOLS-4920: -------------------------------- Description: If a user tries to create a test scenario for [^urgent.dmn] he will get a [1] even when he is creating test scenario for the first time. [1] !Screenshot from 2020-01-08 14-14-05.png|thumbnail! h3. Acceptance criteria https://github.com/jboss-integration/bxms-qe-tests/pull/3048 was: If a user tries to create a test scenario for [^urgent.dmn] he will get a [1] even when he is creating test scenario for the first time. [1] !Screenshot from 2020-01-08 14-14-05.png|thumbnail! > Scenario simulation for DMN with collections throws en error > ------------------------------------------------------------ > > Key: DROOLS-4920 > URL: https://issues.redhat.com/browse/DROOLS-4920 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.31.0.Final > Reporter: Jozef Marko > Assignee: Yeser Amer > Priority: Major > Labels: drools-tools > Attachments: Screenshot from 2020-01-08 14-14-05.png, urgent.dmn > > > If a user tries to create a test scenario for [^urgent.dmn] he will get a [1] even when he is creating test scenario for the first time. > [1] > !Screenshot from 2020-01-08 14-14-05.png|thumbnail! > h3. Acceptance criteria > https://github.com/jboss-integration/bxms-qe-tests/pull/3048 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4920) Scenario simulation for DMN with collections throws en error

by Jozef Marko (Jira)

[ https://issues.redhat.com/browse/DROOLS-4920?page=com.atlassian.jira.plug... ] Jozef Marko commented on DROOLS-4920: ------------------------------------- Reproducer test https://github.com/jboss-integration/bxms-qe-tests/pull/3048 > Scenario simulation for DMN with collections throws en error > ------------------------------------------------------------ > > Key: DROOLS-4920 > URL: https://issues.redhat.com/browse/DROOLS-4920 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Affects Versions: 7.31.0.Final > Reporter: Jozef Marko > Assignee: Yeser Amer > Priority: Major > Labels: drools-tools > Attachments: Screenshot from 2020-01-08 14-14-05.png, urgent.dmn > > > If a user tries to create a test scenario for [^urgent.dmn] he will get a [1] even when he is creating test scenario for the first time. > [1] > !Screenshot from 2020-01-08 14-14-05.png|thumbnail! -- 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 commented on JGRP-2430: -------------------------------- Compare the perf between sending local messages (e.g. over TCP or UDP) and sending remote messages (TUNNEL <-> GossipRouter) > 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. > Also look into routing of entire message _batches_. > 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] (WFLY-12973) add micro profile artifacts to BOMs

by Stefano Maestri (Jira)

Stefano Maestri created WFLY-12973: -------------------------------------- Summary: add micro profile artifacts to BOMs Key: WFLY-12973 URL: https://issues.redhat.com/browse/WFLY-12973 Project: WildFly Issue Type: Enhancement Components: BOM Reporter: Stefano Maestri Assignee: Stefano Maestri 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-3510) Decision table unable to generate rule for row with pattern without constraint

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-3510?page=com.atlassian.jira.plug... ] Mario Fusco resolved DROOLS-3510. --------------------------------- Resolution: Explained The behaviour of suppressing a pattern when it has no constraint cannot be changed also due to backward compatibility reason. It's easy to workaround this behaviour by adding a fake constraint always evaluating to true as I demonstrated in the attached DummyConstraints.xls file. > Decision table unable to generate rule for row with pattern without constraint > ------------------------------------------------------------------------------ > > Key: DROOLS-3510 > URL: https://issues.redhat.com/browse/DROOLS-3510 > Project: Drools > Issue Type: Bug > Components: decision tables > Affects Versions: 7.15.0.Final > Reporter: Andre Piwoni > Assignee: Mario Fusco > Priority: Minor > Attachments: DummyConstraint.xls, MissingConstraint.xls, failingDecisionTable.xlsx > > > When second condition refers to a field of a variable bound in first condition and there exists row/rule without condition constraint than decision table compiler fails to generate rules. See attachment. > Expected rules to be generated: > {code:java} > rule "Test_1" > when > $factA:FactA(hasSomething == "true") > $numberOfFactsB: Number(this > 0, this <= 1) from accumulate(FactB(x == 1) from $factA.listOfFactsB,count(1)) > then > insert(X); > end > rule "Test_2" > when > $factA:FactA(hasSomething == "true") > $numberOfFactsB: Number(this > 1, this <= 2) from accumulate(FactB(x == 1) from $factA.listOfFactsB,count(1)) > then > insert(X); > end > rule "Test_3" > when > $factA:FactA() > $numberOfFactsB: Number(this > 2, this <= 3) from accumulate(FactB(x == 1) from $factA.listOfFactsB,count(1)) > then > insert(Y); > end > {code} > Also, there does not seem an alternative way to generate following rule using decision table: > {code:java} > rule "Test" > when > $factA:FactA($factsB: listOfFactsB) > $numberOfFactsB: Number(this > 1) from accumulate(FactB(x == 1) from $factsB,count(1)) > then > insert(Y); > end > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3510) Decision table unable to generate rule for row with pattern without constraint

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-3510?page=com.atlassian.jira.plug... ] Mario Fusco updated DROOLS-3510: -------------------------------- Attachment: DummyConstraint.xls > Decision table unable to generate rule for row with pattern without constraint > ------------------------------------------------------------------------------ > > Key: DROOLS-3510 > URL: https://issues.redhat.com/browse/DROOLS-3510 > Project: Drools > Issue Type: Bug > Components: decision tables > Affects Versions: 7.15.0.Final > Reporter: Andre Piwoni > Assignee: Mario Fusco > Priority: Minor > Attachments: DummyConstraint.xls, MissingConstraint.xls, failingDecisionTable.xlsx > > > When second condition refers to a field of a variable bound in first condition and there exists row/rule without condition constraint than decision table compiler fails to generate rules. See attachment. > Expected rules to be generated: > {code:java} > rule "Test_1" > when > $factA:FactA(hasSomething == "true") > $numberOfFactsB: Number(this > 0, this <= 1) from accumulate(FactB(x == 1) from $factA.listOfFactsB,count(1)) > then > insert(X); > end > rule "Test_2" > when > $factA:FactA(hasSomething == "true") > $numberOfFactsB: Number(this > 1, this <= 2) from accumulate(FactB(x == 1) from $factA.listOfFactsB,count(1)) > then > insert(X); > end > rule "Test_3" > when > $factA:FactA() > $numberOfFactsB: Number(this > 2, this <= 3) from accumulate(FactB(x == 1) from $factA.listOfFactsB,count(1)) > then > insert(Y); > end > {code} > Also, there does not seem an alternative way to generate following rule using decision table: > {code:java} > rule "Test" > when > $factA:FactA($factsB: listOfFactsB) > $numberOfFactsB: Number(this > 1) from accumulate(FactB(x == 1) from $factsB,count(1)) > then > insert(Y); > end > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12940) Upgrade JBossWS to 5.4.0.Final

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-12940?page=com.atlassian.jira.plugi... ] Darran Lofthouse commented on WFLY-12940: ----------------------------------------- I am just marking as a Blocker as it contains the final pieces for WS / Elytron integration https://issues.redhat.com/browse/JBWS-4179 If this is not included the alternative may be the need to revert some changes to Elytron and WildFly Core. > Upgrade JBossWS to 5.4.0.Final > ------------------------------- > > Key: WFLY-12940 > URL: https://issues.redhat.com/browse/WFLY-12940 > Project: WildFly > Issue Type: Task > Components: Web Services > Affects Versions: 18.0.1.Final > Reporter: Jim Ma > Assignee: Jim Ma > Priority: Blocker > 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-12940) Upgrade JBossWS to 5.4.0.Final

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFLY-12940?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFLY-12940: ------------------------------------ Priority: Blocker (was: Major) > Upgrade JBossWS to 5.4.0.Final > ------------------------------- > > Key: WFLY-12940 > URL: https://issues.redhat.com/browse/WFLY-12940 > Project: WildFly > Issue Type: Task > Components: Web Services > Affects Versions: 18.0.1.Final > Reporter: Jim Ma > Assignee: Jim Ma > Priority: Blocker > 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] (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: --------------------------- Description: 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. Also look into routing of entire message _batches_. Investigate whether this is possible. was: 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. > 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. > Also look into routing of entire message _batches_. > 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-4936) Unsaved changes dialog appears even if it just have been saved

by Toni Rikkola (Jira)

Toni Rikkola created DROOLS-4936: ------------------------------------ Summary: Unsaved changes dialog appears even if it just have been saved Key: DROOLS-4936 URL: https://issues.redhat.com/browse/DROOLS-4936 Project: Drools Issue Type: Bug Components: Guided Rule Editor Reporter: Toni Rikkola Assignee: Toni Rikkola Open a GRE file. Add a fact pattern. Save. Close and the editor still thinks it has not been saved. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2435) ClientGmsImpl ignores newer view during join

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/JGRP-2435?page=com.atlassian.jira.plugin... ] Dan Berindei commented on JGRP-2435: ------------------------------------ I was able to reproduce the issue in {{org.jgroups.tests.ConcurrentStartupTest.testConcurrentJoinWithLOCAL_PING}}. I added {{@Test(invocationCount = 100)}} and an {{Uphandler}} that pretends to do some work on the first view: {code:java} channel.setUpHandler(new UpHandler() { boolean hasView = false; @Override public Object up(Event evt) { if (evt.getType() == Event.VIEW_CHANGE && !hasView) { hasView = true; try { Thread.sleep(ThreadLocalRandom.current().nextInt(50)); } catch (InterruptedException e) { e.printStackTrace(); } } return null; } @Override public Object up(Message msg) { return null; } }); {code} > ClientGmsImpl ignores newer view during join > -------------------------------------------- > > Key: JGRP-2435 > URL: https://issues.redhat.com/browse/JGRP-2435 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.1.9 > Reporter: Dan Berindei > Assignee: Bela Ban > Priority: Major > Fix For: 5.0, 4.2.0 > > > We have random failures in a test that starts 4 nodes in parallel ({{org.infinispan.InitialClusterSizeTest.testInitialClusterSize}}). I get at least one failure if I add {{@Test(invocationCount=100)}}, but I did not get any failure when I did the same with {{org.jgroups.tests.ConcurrentStartupTest.testConcurrentJoinWithLOCAL_PING()}}, maybe because the Infinispan test sends some additional messages and sometimes changes how messages are processed. > The problem seems to be that after receiving a {{JOIN_RSP}} and installing the first view, the GMS implementation is still {{ClientGmsImpl}} when receiving the second view, and the view is ignored. Because this second view already has all 4 members, there is no other {{VIEW}} message and the test just times out. > I added some logs in TP and GMS for debugging, and this is what I see: > {noformat} > 10:37:42,896 TRACE (ucast-receiver-2,Test-NodeC:[]) [UDP] Received oob=false internal=true message GMS: GmsHeader[JOIN_RSP], UNICAST3: DATA, seqno=1, first, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > 10:37:42,898 TRACE (mcast-receiver-3,Test-NodeC:[]) [UDP] Received oob=false internal=false message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=1], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > 10:37:42,906 TRACE (jgroups-4,Test-NodeC:[]) [UDP] Test-NodeC: received [Test-NodeB to Test-NodeC, 61 bytes, flags=INTERNAL], headers are GMS: GmsHeader[JOIN_RSP], UNICAST3: DATA, seqno=1, first, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > 10:37:42,906 TRACE (jgroups-4,Test-NodeC:[]) [GMS] Handling message GMS: GmsHeader[JOIN_RSP], UNICAST3: DATA, seqno=1, first, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > 10:37:42,907 DEBUG (ForkThread-1,InitialClusterSizeTest:[]) [GMS] Test-NodeC: installing view [Test-NodeB|1] (2) [Test-NodeB, Test-NodeC] > 10:37:42,947 TRACE (mcast-receiver-3,Test-NodeC:[]) [UDP] Received oob=false internal=false message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=2], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [UDP] Test-NodeC: received message batch of from Test-NodeB: dest=null, sender=Test-NodeB > 1: > #1: GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=1], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [GMS] Handling message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=1], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [UDP] Test-NodeC: received message batch of from Test-NodeB: dest=null, sender=Test-NodeB > 1: > #1: GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=2], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [GMS] Handling message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=2], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > ### GmsImpl.handleViewChange() {} > 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [GMS] GmsImpl ignoring view update [Test-NodeB|2] (4) [Test-NodeB, Test-NodeC, Test-NodeA, Test-NodeD] > 10:37:42,950 TRACE (jgroups-5,Test-NodeC:[]) [UDP] Test-NodeC: sending msg to Test-NodeB, src=Test-NodeC, headers are GMS: GmsHeader[VIEW_ACK], UNICAST3: DATA, seqno=3, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > ### The ack for the JOIN_RSP is only sent here > 10:37:43,034 TRACE (ForkThread-1,InitialClusterSizeTest:[]) [UDP] Test-NodeC: sending msg to Test-NodeB, src=Test-NodeC, headers are GMS: GmsHeader[VIEW_ACK], UNICAST3: DATA, seqno=4, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > 10:37:43,034 DEBUG (ForkThread-1,InitialClusterSizeTest:[]) [JGroupsTransport] Waiting for 4 nodes, current view has 2 > {noformat} > To help debugging, {{TP.passBatchUp}} should really log the headers of the messages in the batch, and {{GMS}} and the {{GmsImpl}} subclasses should log at least a DEBUG message every time they ignore a view (even when {{log_view_warnings==false}}). I also suggest removing the default implementations from {{GmsImpl}} and updating the {{ClientGmsImpl}} javadoc, because it talks about handling {{ViewChange}} instead of {{JoinResponse}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2435) ClientGmsImpl ignores newer view during join

by Dan Berindei (Jira)

[ https://issues.redhat.com/browse/JGRP-2435?page=com.atlassian.jira.plugin... ] Dan Berindei commented on JGRP-2435: ------------------------------------ Yes, it's the problem I described in the delta view thread. After looking closer at the logs I realized I have some the delta-view failure as well: {noformat} 14:52:04,511 TRACE (mcast-receiver-3,NodeC:[]) [UDP] Received oob=false internal=false message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=1], TP: [cluster=org.infinispan.remoting.transport.Test] 14:52:04,511 TRACE (ucast-receiver-2,NodeC:[]) [UDP] Received oob=false internal=true message GMS: GmsHeader[JOIN_RSP], UNICAST3: DATA, seqno=1, first, TP: [cluster=org.infinispan.remoting.transport.Test] 14:52:04,529 TRACE (jgroups-5,NodeC:[]) [UDP] NodeC: received [NodeD to NodeC, 61 bytes, flags=INTERNAL], headers are GMS: GmsHeader[JOIN_RSP], UNICAST3: DATA, seqno=1, first, TP: [cluster=org.infinispan.remoting.transport.Test] 14:52:04,529 DEBUG (ForkThread-3,Test:[]) [GMS] NodeC: installing view [NodeD|1] (2) [NodeD, NodeC] 14:52:04,532 TRACE (mcast-receiver-3,NodeC:[]) [UDP] Received oob=false internal=false message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=2], TP: [cluster=org.infinispan.remoting.transport.Test] ### 2nd view is ignored 14:52:04,532 TRACE (jgroups-4,NodeC:[]) [GMS] GmsImpl ignoring view update [NodeD|2] (3) [NodeD, NodeC, NodeA] 14:52:04,543 TRACE (mcast-receiver-3,NodeC:[]) [UDP] Received oob=false internal=false message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=3], TP: [cluster=org.infinispan.remoting.transport.Test] 14:52:04,543 TRACE (jgroups-4,NodeC:[]) [GMS] Handling message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=3], TP: [cluster=org.infinispan.remoting.transport.Test] ### 3rd view is delta view, can't be restored 14:52:04,543 WARN (jgroups-4,NodeC:[]) [GMS] NodeC: failed to create view from delta-view; dropping view: java.lang.IllegalStateException: the view-id of the delta view ([NodeD|2]) doesn't match the current view-id ([NodeD|1]); discarding delta view [NodeD|3], ref-view=[NodeD|2], joined=[NodeB] 14:52:04,543 TRACE (jgroups-4,NodeC:[]) [GMS] NodeC: sending request for full view to NodeD 14:52:04,543 TRACE (jgroups-4,NodeC:[]) [UDP] NodeC: sending msg to NodeD, src=NodeC, headers are GMS: GmsHeader[GET_CURRENT_VIEW], UNICAST3: DATA, seqno=3, TP: [cluster=org.infinispan.remoting.transport.Test] 14:52:04,544 TRACE (ucast-receiver-2,NodeC:[]) [UDP] Received oob=true internal=true message GMS: GmsHeader[VIEW], UNICAST3: DATA, seqno=2, TP: [cluster=org.infinispan.remoting.transport.Test] 14:52:04,544 TRACE (jgroups-4,NodeC:[]) [UDP] NodeC: received [NodeD to NodeC, 91 bytes, flags=OOB|INTERNAL], headers are GMS: GmsHeader[VIEW], UNICAST3: DATA, seqno=2, TP: [cluster=org.infinispan.remoting.transport.Test] 14:52:04,544 TRACE (jgroups-4,NodeC:[]) [GMS] Handling message GMS: GmsHeader[VIEW], UNICAST3: DATA, seqno=2, TP: [cluster=org.infinispan.remoting.transport.Test] ### Full 3rd view is also ignored 14:52:04,544 TRACE (jgroups-4,NodeC:[]) [GMS] GmsImpl ignoring view update [NodeD|3] (4) [NodeD, NodeC, NodeA, NodeB] 14:52:04,545 TRACE (jgroups-4,NodeC:[]) [UDP] NodeC: sending msg to NodeD, src=NodeC, headers are GMS: GmsHeader[VIEW_ACK], UNICAST3: DATA, seqno=4, TP: [cluster=org.infinispan.remoting.transport.Test] 14:52:04,557 TRACE (ForkThread-3,Test:[]) [UDP] NodeC: sending msg to NodeD, src=NodeC, headers are GMS: GmsHeader[VIEW_ACK], UNICAST3: DATA, seqno=6, TP: [cluster=org.infinispan.remoting.transport.Test] {noformat} > ClientGmsImpl ignores newer view during join > -------------------------------------------- > > Key: JGRP-2435 > URL: https://issues.redhat.com/browse/JGRP-2435 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.1.9 > Reporter: Dan Berindei > Assignee: Bela Ban > Priority: Major > Fix For: 5.0, 4.2.0 > > > We have random failures in a test that starts 4 nodes in parallel ({{org.infinispan.InitialClusterSizeTest.testInitialClusterSize}}). I get at least one failure if I add {{@Test(invocationCount=100)}}, but I did not get any failure when I did the same with {{org.jgroups.tests.ConcurrentStartupTest.testConcurrentJoinWithLOCAL_PING()}}, maybe because the Infinispan test sends some additional messages and sometimes changes how messages are processed. > The problem seems to be that after receiving a {{JOIN_RSP}} and installing the first view, the GMS implementation is still {{ClientGmsImpl}} when receiving the second view, and the view is ignored. Because this second view already has all 4 members, there is no other {{VIEW}} message and the test just times out. > I added some logs in TP and GMS for debugging, and this is what I see: > {noformat} > 10:37:42,896 TRACE (ucast-receiver-2,Test-NodeC:[]) [UDP] Received oob=false internal=true message GMS: GmsHeader[JOIN_RSP], UNICAST3: DATA, seqno=1, first, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > 10:37:42,898 TRACE (mcast-receiver-3,Test-NodeC:[]) [UDP] Received oob=false internal=false message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=1], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > 10:37:42,906 TRACE (jgroups-4,Test-NodeC:[]) [UDP] Test-NodeC: received [Test-NodeB to Test-NodeC, 61 bytes, flags=INTERNAL], headers are GMS: GmsHeader[JOIN_RSP], UNICAST3: DATA, seqno=1, first, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > 10:37:42,906 TRACE (jgroups-4,Test-NodeC:[]) [GMS] Handling message GMS: GmsHeader[JOIN_RSP], UNICAST3: DATA, seqno=1, first, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > 10:37:42,907 DEBUG (ForkThread-1,InitialClusterSizeTest:[]) [GMS] Test-NodeC: installing view [Test-NodeB|1] (2) [Test-NodeB, Test-NodeC] > 10:37:42,947 TRACE (mcast-receiver-3,Test-NodeC:[]) [UDP] Received oob=false internal=false message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=2], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [UDP] Test-NodeC: received message batch of from Test-NodeB: dest=null, sender=Test-NodeB > 1: > #1: GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=1], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [GMS] Handling message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=1], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [UDP] Test-NodeC: received message batch of from Test-NodeB: dest=null, sender=Test-NodeB > 1: > #1: GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=2], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [GMS] Handling message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=2], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > ### GmsImpl.handleViewChange() {} > 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [GMS] GmsImpl ignoring view update [Test-NodeB|2] (4) [Test-NodeB, Test-NodeC, Test-NodeA, Test-NodeD] > 10:37:42,950 TRACE (jgroups-5,Test-NodeC:[]) [UDP] Test-NodeC: sending msg to Test-NodeB, src=Test-NodeC, headers are GMS: GmsHeader[VIEW_ACK], UNICAST3: DATA, seqno=3, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > ### The ack for the JOIN_RSP is only sent here > 10:37:43,034 TRACE (ForkThread-1,InitialClusterSizeTest:[]) [UDP] Test-NodeC: sending msg to Test-NodeB, src=Test-NodeC, headers are GMS: GmsHeader[VIEW_ACK], UNICAST3: DATA, seqno=4, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > 10:37:43,034 DEBUG (ForkThread-1,InitialClusterSizeTest:[]) [JGroupsTransport] Waiting for 4 nodes, current view has 2 > {noformat} > To help debugging, {{TP.passBatchUp}} should really log the headers of the messages in the batch, and {{GMS}} and the {{GmsImpl}} subclasses should log at least a DEBUG message every time they ignore a view (even when {{log_view_warnings==false}}). I also suggest removing the default implementations from {{GmsImpl}} and updating the {{ClientGmsImpl}} javadoc, because it talks about handling {{ViewChange}} instead of {{JoinResponse}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12972) MP Fault Tolerance - Fault Tolerance is missing logging code when activated

by Miroslav Novak (Jira)

[ https://issues.redhat.com/browse/WFLY-12972?page=com.atlassian.jira.plugi... ] Miroslav Novak moved WFWIP-286 to WFLY-12972: --------------------------------------------- Project: WildFly (was: WildFly WIP) Key: WFLY-12972 (was: WFWIP-286) Component/s: MP Fault Tolerance (was: MP Fault Tolerance) > MP Fault Tolerance - Fault Tolerance is missing logging code when activated > --------------------------------------------------------------------------- > > Key: WFLY-12972 > URL: https://issues.redhat.com/browse/WFLY-12972 > Project: WildFly > Issue Type: Bug > Components: MP Fault Tolerance > Reporter: Miroslav Novak > Assignee: Radoslav Husar > Priority: Minor > > If MP FT is activated by deployment then INFO log is missing logging code: > {code} > 10:18:31,626 INFO [io.smallrye.faulttolerance.HystrixExtension] (MSC service thread 1-1) MicroProfile: Fault Tolerance activated > {code} > Logging code should be added. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2383) Remove most attributes from sample configurations

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2383?page=com.atlassian.jira.plugin... ] Bela Ban resolved JGRP-2383. ---------------------------- Resolution: Done > Remove most attributes from sample configurations > ------------------------------------------------- > > Key: JGRP-2383 > URL: https://issues.redhat.com/browse/JGRP-2383 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 5.0 > > > The sample configs have many attributes, e.g. > {code:xml} > <pbcast.NAKACK2 xmit_interval="500" > xmit_table_num_rows="100" > xmit_table_msgs_per_row="2000" > xmit_table_max_compaction_time="30000" > use_mcast_xmit="true" > discard_delivered_msgs="true" /> > {code} > This is bad: if default values are changed, people need to upgrade their configs (which they usually don't!). > In the above example, the only attribute that's really useful is {{xmit_interval}}, the others can be removed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12899) Failing JMXPropertyEditorsTestCase in 18.0.0.Final

by James Crowley (Jira)

[ https://issues.redhat.com/browse/WFLY-12899?page=com.atlassian.jira.plugi... ] James Crowley commented on WFLY-12899: -------------------------------------- [~baranowb] You are correct that Jenkins is triggering the docker to test WFLY. Manually, setting USER works but seems odd. I agree most of the time on Linux systems USER will be set, but here we are with the issue with Docker. If this is suppose check env variables expansion, could you not assert a random environment variable specifically for this test? I feel that would be cleaner then assuming the Linux system will have USER set. > Failing JMXPropertyEditorsTestCase in 18.0.0.Final > -------------------------------------------------- > > Key: WFLY-12899 > URL: https://issues.redhat.com/browse/WFLY-12899 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 18.0.0.Final > Reporter: James Crowley > Assignee: Bartosz Baranowski > Priority: Major > > When calling "./mvnw install -DallTests", it gets up to the JMXPropertyEditorsTestCase and fails with this error, "Caused by: java.lang.IllegalStateException: Failed to resolve expression: env.USER"}}}}". > Looking at the source code for the test [here|https://github.com/wildfly/wildfly/blob/1bf993be72b570a0c780a58ba05c...], it looks like USER is suppose to be defined by USER_SYS_PROP. > I am not sure what the problem is but I know it is failing somewhere in the above test. > You can see the full log in the in Adopt's test [here|https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/1436/conso...]. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2222) Remove deprecated S3_PING and GOOGLE_PING from the codebase

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2222?page=com.atlassian.jira.plugin... ] Bela Ban resolved JGRP-2222. ---------------------------- Resolution: Done > Remove deprecated S3_PING and GOOGLE_PING from the codebase > ----------------------------------------------------------- > > Key: JGRP-2222 > URL: https://issues.redhat.com/browse/JGRP-2222 > Project: JGroups > Issue Type: Task > Reporter: Radoslav Husar > Assignee: Bela Ban > Priority: Major > Fix For: 5.0 > > > As discussed on the clustering meeting it is desired to remove the code from the codebase since version 5 to reduce confusion and distribution size. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12970) SmallRye Metrics - MetricsRegistryImpl - removal of entry from map which is currently iterated

by Rostislav Svoboda (Jira)

[ https://issues.redhat.com/browse/WFLY-12970?page=com.atlassian.jira.plugi... ] Rostislav Svoboda moved WFWIP-131 to WFLY-12970: ------------------------------------------------ Project: WildFly (was: WildFly WIP) Key: WFLY-12970 (was: WFWIP-131) Component/s: MP Metrics (was: MP Metrics) > SmallRye Metrics - MetricsRegistryImpl - removal of entry from map which is currently iterated > ---------------------------------------------------------------------------------------------- > > Key: WFLY-12970 > URL: https://issues.redhat.com/browse/WFLY-12970 > Project: WildFly > Issue Type: Bug > Components: MP Metrics > Reporter: Rostislav Svoboda > Assignee: Jeff Mesnil > Priority: Major > > SmallRye Metrics - MetricsRegistryImpl - removal of entry from map which is currently iterated > https://github.com/smallrye/smallrye-metrics/blob/master/implementation/s... > Method {{removeMatching}} is iterating over {{metricMap}}. If there is a match {{remove}} method is called. This method removes entry from {{metricMap}} and from {{metadataMap}}. > I don't like the fact that the entry is removed from the map by external method while the map is currently iterated by the {{removeMatching}} method. > I think https://docs.oracle.com/javase/8/docs/api/java/util/Iterator.html#remove-- should be called in {{removeMatching}} for {{metricMap}} entry + invocation of metadataMap.remove(entry.getKey()) + log mesasge; -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12971) SmallRye Metrics - JmxWorker - findKeyForValueToBeReplaced could use some polish

by Rostislav Svoboda (Jira)

[ https://issues.redhat.com/browse/WFLY-12971?page=com.atlassian.jira.plugi... ] Rostislav Svoboda moved WFWIP-130 to WFLY-12971: ------------------------------------------------ Project: WildFly (was: WildFly WIP) Key: WFLY-12971 (was: WFWIP-130) Component/s: MP Metrics (was: MP Metrics) > SmallRye Metrics - JmxWorker - findKeyForValueToBeReplaced could use some polish > -------------------------------------------------------------------------------- > > Key: WFLY-12971 > URL: https://issues.redhat.com/browse/WFLY-12971 > Project: WildFly > Issue Type: Bug > Components: MP Metrics > Reporter: Rostislav Svoboda > Assignee: Jeff Mesnil > Priority: Major > > SmallRye Metrics - JmxWorker - findKeyForValueToBeReplaced could use some polish > https://github.com/smallrye/smallrye-metrics/blob/master/implementation/s... > - iterate entrySet instead of keySet > - can it happen that there are more entries with value '*' ? > - shouldn't the for cycle end when the (first?) match is found ? -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12206) Dependencies - micro version bump

by Rostislav Svoboda (Jira)

[ https://issues.redhat.com/browse/WFLY-12206?page=com.atlassian.jira.plugi... ] Rostislav Svoboda closed WFLY-12206. ------------------------------------ Resolution: Won't Do PR was closed, follow-up PRs were triggered by this > Dependencies - micro version bump > --------------------------------- > > Key: WFLY-12206 > URL: https://issues.redhat.com/browse/WFLY-12206 > Project: WildFly > Issue Type: Task > Reporter: Rostislav Svoboda > Assignee: Rostislav Svoboda > Priority: Major > > Dependencies - micro version bump > Several components have newer versions available -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4701) SecurityCommandsTestCase and SyslogAuditLogTestCase cleanup

by Rostislav Svoboda (Jira)

[ https://issues.redhat.com/browse/WFCORE-4701?page=com.atlassian.jira.plug... ] Rostislav Svoboda closed WFCORE-4701. ------------------------------------- Fix Version/s: 11.0.0.Beta1 Resolution: Done Merged on Oct 11, 2019 > SecurityCommandsTestCase and SyslogAuditLogTestCase cleanup > ----------------------------------------------------------- > > Key: WFCORE-4701 > URL: https://issues.redhat.com/browse/WFCORE-4701 > Project: WildFly Core > Issue Type: Task > Components: Test Suite > Reporter: Rostislav Svoboda > Assignee: Rostislav Svoboda > Priority: Major > Fix For: 11.0.0.Beta1 > > > SecurityCommandsTestCase and SyslogAuditLogTestCase cleanup > Removal of unused or logically dead code -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2433) Smaller changes in Message/BaseMessage

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2433?page=com.atlassian.jira.plugin... ] Bela Ban commented on JGRP-2433: -------------------------------- Message methods such as get/setArray(), get/setObject() and hasArray() are there for convenience, as a lot of code still set/get a byte array, or use set/getObject() to marshal/unmarshal an object into a byte array. The idea in the future is to change all code that uses these methods to use the relevant subclass (e.g. {{BytesMessage}} / {{ObjectMessage}}), but for now, we'll leave them. [~pruivo] If you have many message implementations, I suggest to keep code that has default behavior in a common superclass (which is a subclass of {{BaseMessage}}) of all your message types. > Smaller changes in Message/BaseMessage > -------------------------------------- > > Key: JGRP-2433 > URL: https://issues.redhat.com/browse/JGRP-2433 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 5.0 > > > Based on Pedro's suggestions (copied from \[1\]): > *Comments/Suggestions* > I've created a new custom {{Message}} class to replace an ISPN command. It can be found here: https://github.com/pruivo/infinispan/blob/t_jgroups_5/core/src/main/java/... > * The set/get...Array/Object must have a default implementation in the interface. I doubt that any custom implementation will ever implement those methods. Similar idea for {{hasArray()}} > * -Probably the {{size()}} shouldn't be implemented in the base class. Initially, I forgot to implement it :). A {{headersSize()}} method would be needed- > > * -It would be nice to have an abstract method write/read payload instead of overriding the writeTo/readFrom- > * -{{copy()}} should be implemented in the base class and be final. Just add an abstract method {{copyPayload()}} that is invoked when the payload needs to be copied. The first parameter for {{copy()}} should have a better name, IMO.- > * -{{MessageFactory}} is kind of difficult to find. Can we have a method in the {{Channel}}? or {{getMessageFactory()}} or {{registerMessage(type, constructor)}}. Also, I found some protocol creating a new {{MessageFactory}}, they should use the same instance, right? And you allow to set a different {{MessageFactory}} that isn't propagated everywhere... is there a use case where an user needs to replace the {{MessageFactory}}? If not, just make it static somewhere- > * -I'm wondering if there is way to avoid conflict to register a new message type. Imagine that wildfly and ispn creates a set new messages type, the conflict will only be detected at runtime. Also, the type is a byte... there is no much room to add custom messages types- > * -Can the {{Flag}} and {{TransientFlag}} use the same short? There are only 2 transient flags so far and they can be the last bits of short. You can use a mask to skip sending them through the network- > * -no perf-ack numbers- > \[1\] https://issues.redhat.com/browse/JGRP-2218 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2433) Smaller changes in Message/BaseMessage

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2433?page=com.atlassian.jira.plugin... ] Bela Ban resolved JGRP-2433. ---------------------------- Resolution: Done > Smaller changes in Message/BaseMessage > -------------------------------------- > > Key: JGRP-2433 > URL: https://issues.redhat.com/browse/JGRP-2433 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 5.0 > > > Based on Pedro's suggestions (copied from \[1\]): > *Comments/Suggestions* > I've created a new custom {{Message}} class to replace an ISPN command. It can be found here: https://github.com/pruivo/infinispan/blob/t_jgroups_5/core/src/main/java/... > * The set/get...Array/Object must have a default implementation in the interface. I doubt that any custom implementation will ever implement those methods. Similar idea for {{hasArray()}} > * -Probably the {{size()}} shouldn't be implemented in the base class. Initially, I forgot to implement it :). A {{headersSize()}} method would be needed- > > * -It would be nice to have an abstract method write/read payload instead of overriding the writeTo/readFrom- > * -{{copy()}} should be implemented in the base class and be final. Just add an abstract method {{copyPayload()}} that is invoked when the payload needs to be copied. The first parameter for {{copy()}} should have a better name, IMO.- > * -{{MessageFactory}} is kind of difficult to find. Can we have a method in the {{Channel}}? or {{getMessageFactory()}} or {{registerMessage(type, constructor)}}. Also, I found some protocol creating a new {{MessageFactory}}, they should use the same instance, right? And you allow to set a different {{MessageFactory}} that isn't propagated everywhere... is there a use case where an user needs to replace the {{MessageFactory}}? If not, just make it static somewhere- > * -I'm wondering if there is way to avoid conflict to register a new message type. Imagine that wildfly and ispn creates a set new messages type, the conflict will only be detected at runtime. Also, the type is a byte... there is no much room to add custom messages types- > * -Can the {{Flag}} and {{TransientFlag}} use the same short? There are only 2 transient flags so far and they can be the last bits of short. You can use a mask to skip sending them through the network- > * -no perf-ack numbers- > \[1\] https://issues.redhat.com/browse/JGRP-2218 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2433) Smaller changes in Message/BaseMessage

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2433?page=com.atlassian.jira.plugin... ] Bela Ban edited comment on JGRP-2433 at 1/15/20 7:01 AM: --------------------------------------------------------- * Implemented {{copy()}} in {{BaseMessage}} and also introduced a method {{copyPayload()}} that's overwritten by subclasses * I guess perf tests should be run once Infinispan has switched to JGroups 5.0 in a temp branch. Preliminary perf numbers for JGroups itself were added to JGRP-2218 some time ago. * I prefer to continue using a short for {{flags}} and a byte for {{transient_flags}}, and not collapse them into one short, as this would leave me with only 3 additional flags. Once I remove flags (e.g. RSVP...), and possibly also remove the {{dest}} field from {{Message}}, I might reconsider this suggestion... * I added {{msg_factory_class}} which requires the fully qualified name of a {{MsgFactory}} impl class; this cannot be set at runtime (as you mentioned, we'd not propagate that to other protocols, which fetch a ref at {{init()}} time). * Changed ID for message type from byte -> short * I don't think we'll be able to avoid detecting collisions between different registrations using the same ID until runtime, but since I widened the byte to a short, we have more space and less likelyhood of collisions. Wildfly and Infinispan could for example shared a common document in which they list all message types and thus avoid collisions. * Added abstract methods {{writePayload()}} and {{readPayload()}} to {{BaseMessage}}. These are the only ones that need to be implemented instead of {{writeTo()}}, {{writeToNoAddresses()}} and {{readFrom()}} * I don't see why {{size()}} shouldn't be implemented in the base class: subclasses can simply call {{super.size()}} and then add their own size... was (Author: belaban): * Implemented {{copy()}} in {{BaseMessage}} and also introduced a method {{copyPayload()}} that's overwritten by subclasses * I guess perf tests should be run once Infinispan has switched to JGroups 5.0 in a temp branch. Preliminary perf numbers for JGroups itself were added to JGRP-2218 some time ago. * I prefer to continue using a short for {{flags}} and a byte for {{transient_flags}}, and not collapse them into one short, as this would leave me with only 3 additional flags. Once I remove flags (e.g. RSVP...), and possibly also remove the {{dest}} field from {{Message}}, I might reconsider this suggestion... * I added {{msg_factory_class}} which requires the fully qualified name of a {{MsgFactory}} impl class; this cannot be set at runtime (as you mentioned, we'd not propagate that to other protocols, which fetch a ref at {{init()}} time). * Changed ID for message type from byte -> short * I don't think we'll be able to avoid detecting collisions between different registrations using the same ID until runtime, but since I widened the byte to a short, we have more space and less likelyhood of collisions. Wildfly and Infinispan could for example shared a common document in which they list all message types and thus avoid collisions. * Added abstract methods {{writePayload()}} and {{readPayload()}} to {{BaseMessage}}. These are the only ones that need to be implemented instead of {{writeTo()}}, {{writeToNoAddresses()}} and {{readFrom()}} > Smaller changes in Message/BaseMessage > -------------------------------------- > > Key: JGRP-2433 > URL: https://issues.redhat.com/browse/JGRP-2433 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 5.0 > > > Based on Pedro's suggestions (copied from \[1\]): > *Comments/Suggestions* > I've created a new custom {{Message}} class to replace an ISPN command. It can be found here: https://github.com/pruivo/infinispan/blob/t_jgroups_5/core/src/main/java/... > * The set/get...Array/Object must have a default implementation in the interface. I doubt that any custom implementation will ever implement those methods. Similar idea for {{hasArray()}} > * Probably the {{size()}} shouldn't be implemented in the base class. Initially, I forgot to implement it :). A {{headersSize()}} method would be needed. > > * -It would be nice to have an abstract method write/read payload instead of overriding the writeTo/readFrom- > * -{{copy()}} should be implemented in the base class and be final. Just add an abstract method {{copyPayload()}} that is invoked when the payload needs to be copied. The first parameter for {{copy()}} should have a better name, IMO.- > * -{{MessageFactory}} is kind of difficult to find. Can we have a method in the {{Channel}}? or {{getMessageFactory()}} or {{registerMessage(type, constructor)}}. Also, I found some protocol creating a new {{MessageFactory}}, they should use the same instance, right? And you allow to set a different {{MessageFactory}} that isn't propagated everywhere... is there a use case where an user needs to replace the {{MessageFactory}}? If not, just make it static somewhere- > * -I'm wondering if there is way to avoid conflict to register a new message type. Imagine that wildfly and ispn creates a set new messages type, the conflict will only be detected at runtime. Also, the type is a byte... there is no much room to add custom messages types- > * -Can the {{Flag}} and {{TransientFlag}} use the same short? There are only 2 transient flags so far and they can be the last bits of short. You can use a mask to skip sending them through the network- > * -no perf-ack numbers- > \[1\] https://issues.redhat.com/browse/JGRP-2218 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2433) Smaller changes in Message/BaseMessage

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2433?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2433: --------------------------- Description: Based on Pedro's suggestions (copied from \[1\]): *Comments/Suggestions* I've created a new custom {{Message}} class to replace an ISPN command. It can be found here: https://github.com/pruivo/infinispan/blob/t_jgroups_5/core/src/main/java/... * The set/get...Array/Object must have a default implementation in the interface. I doubt that any custom implementation will ever implement those methods. Similar idea for {{hasArray()}} * -Probably the {{size()}} shouldn't be implemented in the base class. Initially, I forgot to implement it :). A {{headersSize()}} method would be needed- * -It would be nice to have an abstract method write/read payload instead of overriding the writeTo/readFrom- * -{{copy()}} should be implemented in the base class and be final. Just add an abstract method {{copyPayload()}} that is invoked when the payload needs to be copied. The first parameter for {{copy()}} should have a better name, IMO.- * -{{MessageFactory}} is kind of difficult to find. Can we have a method in the {{Channel}}? or {{getMessageFactory()}} or {{registerMessage(type, constructor)}}. Also, I found some protocol creating a new {{MessageFactory}}, they should use the same instance, right? And you allow to set a different {{MessageFactory}} that isn't propagated everywhere... is there a use case where an user needs to replace the {{MessageFactory}}? If not, just make it static somewhere- * -I'm wondering if there is way to avoid conflict to register a new message type. Imagine that wildfly and ispn creates a set new messages type, the conflict will only be detected at runtime. Also, the type is a byte... there is no much room to add custom messages types- * -Can the {{Flag}} and {{TransientFlag}} use the same short? There are only 2 transient flags so far and they can be the last bits of short. You can use a mask to skip sending them through the network- * -no perf-ack numbers- \[1\] https://issues.redhat.com/browse/JGRP-2218 was: Based on Pedro's suggestions (copied from \[1\]): *Comments/Suggestions* I've created a new custom {{Message}} class to replace an ISPN command. It can be found here: https://github.com/pruivo/infinispan/blob/t_jgroups_5/core/src/main/java/... * The set/get...Array/Object must have a default implementation in the interface. I doubt that any custom implementation will ever implement those methods. Similar idea for {{hasArray()}} * Probably the {{size()}} shouldn't be implemented in the base class. Initially, I forgot to implement it :). A {{headersSize()}} method would be needed. * -It would be nice to have an abstract method write/read payload instead of overriding the writeTo/readFrom- * -{{copy()}} should be implemented in the base class and be final. Just add an abstract method {{copyPayload()}} that is invoked when the payload needs to be copied. The first parameter for {{copy()}} should have a better name, IMO.- * -{{MessageFactory}} is kind of difficult to find. Can we have a method in the {{Channel}}? or {{getMessageFactory()}} or {{registerMessage(type, constructor)}}. Also, I found some protocol creating a new {{MessageFactory}}, they should use the same instance, right? And you allow to set a different {{MessageFactory}} that isn't propagated everywhere... is there a use case where an user needs to replace the {{MessageFactory}}? If not, just make it static somewhere- * -I'm wondering if there is way to avoid conflict to register a new message type. Imagine that wildfly and ispn creates a set new messages type, the conflict will only be detected at runtime. Also, the type is a byte... there is no much room to add custom messages types- * -Can the {{Flag}} and {{TransientFlag}} use the same short? There are only 2 transient flags so far and they can be the last bits of short. You can use a mask to skip sending them through the network- * -no perf-ack numbers- \[1\] https://issues.redhat.com/browse/JGRP-2218 > Smaller changes in Message/BaseMessage > -------------------------------------- > > Key: JGRP-2433 > URL: https://issues.redhat.com/browse/JGRP-2433 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 5.0 > > > Based on Pedro's suggestions (copied from \[1\]): > *Comments/Suggestions* > I've created a new custom {{Message}} class to replace an ISPN command. It can be found here: https://github.com/pruivo/infinispan/blob/t_jgroups_5/core/src/main/java/... > * The set/get...Array/Object must have a default implementation in the interface. I doubt that any custom implementation will ever implement those methods. Similar idea for {{hasArray()}} > * -Probably the {{size()}} shouldn't be implemented in the base class. Initially, I forgot to implement it :). A {{headersSize()}} method would be needed- > > * -It would be nice to have an abstract method write/read payload instead of overriding the writeTo/readFrom- > * -{{copy()}} should be implemented in the base class and be final. Just add an abstract method {{copyPayload()}} that is invoked when the payload needs to be copied. The first parameter for {{copy()}} should have a better name, IMO.- > * -{{MessageFactory}} is kind of difficult to find. Can we have a method in the {{Channel}}? or {{getMessageFactory()}} or {{registerMessage(type, constructor)}}. Also, I found some protocol creating a new {{MessageFactory}}, they should use the same instance, right? And you allow to set a different {{MessageFactory}} that isn't propagated everywhere... is there a use case where an user needs to replace the {{MessageFactory}}? If not, just make it static somewhere- > * -I'm wondering if there is way to avoid conflict to register a new message type. Imagine that wildfly and ispn creates a set new messages type, the conflict will only be detected at runtime. Also, the type is a byte... there is no much room to add custom messages types- > * -Can the {{Flag}} and {{TransientFlag}} use the same short? There are only 2 transient flags so far and they can be the last bits of short. You can use a mask to skip sending them through the network- > * -no perf-ack numbers- > \[1\] https://issues.redhat.com/browse/JGRP-2218 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12969) Include openshift instructions in baremetal Quickstarts docs

by Eduardo Martins (Jira)

[ https://issues.redhat.com/browse/WFLY-12969?page=com.atlassian.jira.plugi... ] Eduardo Martins moved EAP7-1415 to WFLY-12969: ---------------------------------------------- Project: WildFly (was: EAP 7 Planning Pilot) Key: WFLY-12969 (was: EAP7-1415) Issue Type: Feature Request (was: Requirement) Workflow: GIT Pull Request workflow (was: EAP Agile Workflow 2.0) Component/s: Quickstarts (was: Quickstarts) EAP PT Pre-Checked (PC): (was: TODO) Target Release: (was: 7.4.0.GA) EAP PT Community Docs (CD): (was: TODO) EAP PT Product Docs (PD): (was: New) EAP PT Test Dev (TD): (was: TODO) EAP PT Docs Analysis (DA): (was: TODO) EAP PT Test Plan (TP): (was: TODO) EAP PT Analysis Document (AD): (was: TODO) > Include openshift instructions in baremetal Quickstarts docs > ------------------------------------------------------------ > > Key: WFLY-12969 > URL: https://issues.redhat.com/browse/WFLY-12969 > Project: WildFly > Issue Type: Feature Request > Components: Quickstarts > Reporter: Eduardo Martins > Assignee: Eduardo Martins > Priority: Major > > Currently QS readmes include the openshift instructions only for CD releases. QS that run on Openshift (those included in CD releases) should contain openshift instructions for non-CD releases too, as the openshift image is released. > For example helloworld QS, which is also included in CD release: > https://raw.githubusercontent.com/wildfly/quickstart/master/helloworld/RE... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3879) Create Kogito version of Test Scenarios designer

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-3879?page=com.atlassian.jira.plug... ] Gabriele Cardosi updated DROOLS-3879: ------------------------------------- Description: Scope of this PR is to create a *Kogito/client-side only* versions of scesim editor. >From an architectural point of view, the actual implementation has been moved (in the past) inside a common module: `drools-wb-scenario-simulation-editor-client`. Access to it has been "hided" behind a wrapper interface with three actual implementations: * `drools-wb-scenario-simulation-editor-businesscentral-client` for BusinessCentral environment * `drools-wb-scenario-simulation-editor-kogito-testing` to provide a development/debugging setup for the *Kogito/client-side only* environment * `drools-wb-scenario-simulation-editor-kogito-runtime` that should be the one deployed in actual client-side only containers (e.g. VSCode). As agreed upon in the last summer (https://issues.redhat.com/browse/AF-2041), the kogito editors should depend upon a common library, `org.kie.workbench:kie-wb-common-kogito-webapp-base` to put all the code/maven configuration shared by the different editors in one single place. Currently, only the two kogito-related scesim modules fulfill that requirement; all other editors, starting from DMN, should be adapted to this approach. Kogito-testing module is a standalone showcase that provides some minimum interaction to: * load DMN files * create DMN-related scesim assets, selecting one of the imported DMN. Currently - RULE/data object model scesim is disabled. Kogito-runtime module is the version that should run purely client side. It does not provide any graphical widget to load/create/save asset. Some minimal tests may be done in the following way: # full compilation (i.e. included GWT compilation) of the runtime module # open the `drools-wb/drools-wb-screens/drools-wb-scenario-simulation-editor/drools-wb-scenario-simulation-editor-kogito-runtime/target/drools-wb-scenario-simulation-editor-kogito-runtime/index.html` file inside Chrome # inside the Chrome dev console, issue the command `window.gwtEditorBeans.get("ScenarioSimulationEditorKogitoRuntimeScreen").get().setContent("")`; this will show the "New Scesim" popup, where user may choose to create a DMN or RULE scesim; of course, inside Chrome it is not possible to have a reference to other resources, so only "Rule" will work; at the same time, no Data model is available inside Chrome, so the right panel will be empty and the only expected result is an empty grid. # edit the asset # invoke window.gwtEditorBeans.get("ScenarioSimulationEditorKogitoRuntimeScreen").get().getContent() and store the returned xml # invoke window.gwtEditorBeans.get("ScenarioSimulationEditorKogitoRuntimeScreen").get().setContent method with the stored xml Some tricks: to avoid CORS and other policy-related issues: # set chrome://flags/#allow-insecure-localhost for invalid certificates error # start chrome from cli with the command `chrome --allow-file-access-from-files` to allow loading from file. /----/ The "run scenario" functionality won't be implemented by this PR. All the functionalities related to file system/resource access will be simulated in the testing modules (but only for the DMN models), and for the runtime module will depend on the API/environment provided by VSCode was: Scope of this PR is to create a *Kogito/client-side only* versions of scesim editor. >From an architectural point of view, the actual implementation has been moved (in the past) inside a common module: `drools-wb-scenario-simulation-editor-client`. Access to it has been "hided" behind a wrapper interface with three actual implementations: * `drools-wb-scenario-simulation-editor-businesscentral-client` for BusinessCentral environment * `drools-wb-scenario-simulation-editor-kogito-testing` to provide a development/debugging setup for the *Kogito/client-side only* environment * `drools-wb-scenario-simulation-editor-kogito-runtime` that should be the one deployed in actual client-side only containers (e.g. VSCode). As agreed upon in the last summer (https://issues.redhat.com/browse/AF-2041), the kogito editors should depend upon a common library, `org.kie.workbench:kie-wb-common-kogito-webapp-base` to put all the code/maven configuration shared by the different editors in one single place. Currently, only the two kogito-related scesim modules fulfill that requirement; all other editors, starting from DMN, should be adapted to this approach. Kogito-testing module is a standalone showcase that provides some minimum interaction to: * load DMN files * create DMN-related scesim assets, selecting one of the imported DMN. Currently - RULE/data object model scesim is disabled. Kogito-runtime module is the version that should run purely client side. It does not provide any graphical widget to load/create/save asset. Some minimal tests may be done in the following way: # full compilation (i.e. included GWT compilation) of the runtime module # open the `drools-wb/drools-wb-screens/drools-wb-scenario-simulation-editor/drools-wb-scenario-simulation-editor-kogito-runtime/target/drools-wb-scenario-simulation-editor-kogito-runtime/index.html` file inside Chrome # inside the Chrome dev console, issue the command `window.gwtEditorBeans.get("ScenarioSimulationEditorKogitoRuntimeScreen").get().setContent("")`; this will show the "New Scesim" popup, where user may choose to create a DMN or RULE scesim; of course, inside Chrome it is not possible to have a reference to other resources, so only "Rule" will work; at the same time, no Data model is available inside Chrome, so the right panel will be empty and the only expected result is an empty grid. Some tricks: to avoid CORS and other policy-related issues: # set chrome://flags/#allow-insecure-localhost for invalid certificates error # start chrome from cli with the command `chrome --allow-file-access-from-files` to allow loading from file. /----/ The "run scenario" functionality won't be implemented by this PR. All the functionalities related to file system/resource access will be simulated in the testing modules (but only for the DMN models), and for the runtime module will depend on the API/environment provided by VSCode > Create Kogito version of Test Scenarios designer > ------------------------------------------------ > > Key: DROOLS-3879 > URL: https://issues.redhat.com/browse/DROOLS-3879 > Project: Drools > Issue Type: Feature Request > Components: Scenario Simulation and Testing > Reporter: Gabriele Cardosi > Assignee: Yeser Amer > Priority: Major > Labels: drools-tools > > Scope of this PR is to create a *Kogito/client-side only* versions of scesim editor. > From an architectural point of view, the actual implementation has been moved (in the past) inside a common module: `drools-wb-scenario-simulation-editor-client`. > Access to it has been "hided" behind a wrapper interface with three actual implementations: > * `drools-wb-scenario-simulation-editor-businesscentral-client` for BusinessCentral environment > * `drools-wb-scenario-simulation-editor-kogito-testing` to provide a development/debugging setup for the *Kogito/client-side only* environment > * `drools-wb-scenario-simulation-editor-kogito-runtime` that should be the one deployed in actual client-side only containers (e.g. VSCode). > As agreed upon in the last summer (https://issues.redhat.com/browse/AF-2041), the kogito editors should depend upon a common library, `org.kie.workbench:kie-wb-common-kogito-webapp-base` to put all the code/maven configuration shared by the different editors in one single place. > Currently, only the two kogito-related scesim modules fulfill that requirement; all other editors, starting from DMN, should be adapted to this approach. > Kogito-testing module is a standalone showcase that provides some minimum interaction to: > * load DMN files > * create DMN-related scesim assets, selecting one of the imported DMN. > Currently - RULE/data object model scesim is disabled. > Kogito-runtime module is the version that should run purely client side. It does not provide any graphical widget to load/create/save asset. > Some minimal tests may be done in the following way: > # full compilation (i.e. included GWT compilation) of the runtime module > # open the `drools-wb/drools-wb-screens/drools-wb-scenario-simulation-editor/drools-wb-scenario-simulation-editor-kogito-runtime/target/drools-wb-scenario-simulation-editor-kogito-runtime/index.html` file inside Chrome > # inside the Chrome dev console, issue the command `window.gwtEditorBeans.get("ScenarioSimulationEditorKogitoRuntimeScreen").get().setContent("")`; this will show the "New Scesim" popup, where user may choose to create a DMN or RULE scesim; of course, inside Chrome it is not possible to have a reference to other resources, so only "Rule" will work; at the same time, no Data model is available inside Chrome, so the right panel will be empty and the only expected result is an empty grid. > # edit the asset > # invoke window.gwtEditorBeans.get("ScenarioSimulationEditorKogitoRuntimeScreen").get().getContent() and store the returned xml > # invoke window.gwtEditorBeans.get("ScenarioSimulationEditorKogitoRuntimeScreen").get().setContent method with the stored xml > Some tricks: to avoid CORS and other policy-related issues: > # set chrome://flags/#allow-insecure-localhost for invalid certificates error > # start chrome from cli with the command `chrome --allow-file-access-from-files` to allow loading from file. > /----/ > The "run scenario" functionality won't be implemented by this PR. > All the functionalities related to file system/resource access will be simulated in the testing modules (but only for the DMN models), and for the runtime module will depend on the API/environment provided by VSCode -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2435) ClientGmsImpl ignores newer view during join

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2435?page=com.atlassian.jira.plugin... ] Bela Ban updated JGRP-2435: --------------------------- Fix Version/s: 5.0 4.2.0 [~dan.berindei] I assume this is te delta-view email thread? > ClientGmsImpl ignores newer view during join > -------------------------------------------- > > Key: JGRP-2435 > URL: https://issues.redhat.com/browse/JGRP-2435 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.1.9 > Reporter: Dan Berindei > Assignee: Bela Ban > Priority: Major > Fix For: 5.0, 4.2.0 > > > We have random failures in a test that starts 4 nodes in parallel ({{org.infinispan.InitialClusterSizeTest.testInitialClusterSize}}). I get at least one failure if I add {{@Test(invocationCount=100)}}, but I did not get any failure when I did the same with {{org.jgroups.tests.ConcurrentStartupTest.testConcurrentJoinWithLOCAL_PING()}}, maybe because the Infinispan test sends some additional messages and sometimes changes how messages are processed. > The problem seems to be that after receiving a {{JOIN_RSP}} and installing the first view, the GMS implementation is still {{ClientGmsImpl}} when receiving the second view, and the view is ignored. Because this second view already has all 4 members, there is no other {{VIEW}} message and the test just times out. > I added some logs in TP and GMS for debugging, and this is what I see: > {noformat} > 10:37:42,896 TRACE (ucast-receiver-2,Test-NodeC:[]) [UDP] Received oob=false internal=true message GMS: GmsHeader[JOIN_RSP], UNICAST3: DATA, seqno=1, first, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > 10:37:42,898 TRACE (mcast-receiver-3,Test-NodeC:[]) [UDP] Received oob=false internal=false message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=1], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > 10:37:42,906 TRACE (jgroups-4,Test-NodeC:[]) [UDP] Test-NodeC: received [Test-NodeB to Test-NodeC, 61 bytes, flags=INTERNAL], headers are GMS: GmsHeader[JOIN_RSP], UNICAST3: DATA, seqno=1, first, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > 10:37:42,906 TRACE (jgroups-4,Test-NodeC:[]) [GMS] Handling message GMS: GmsHeader[JOIN_RSP], UNICAST3: DATA, seqno=1, first, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > 10:37:42,907 DEBUG (ForkThread-1,InitialClusterSizeTest:[]) [GMS] Test-NodeC: installing view [Test-NodeB|1] (2) [Test-NodeB, Test-NodeC] > 10:37:42,947 TRACE (mcast-receiver-3,Test-NodeC:[]) [UDP] Received oob=false internal=false message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=2], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [UDP] Test-NodeC: received message batch of from Test-NodeB: dest=null, sender=Test-NodeB > 1: > #1: GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=1], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [GMS] Handling message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=1], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [UDP] Test-NodeC: received message batch of from Test-NodeB: dest=null, sender=Test-NodeB > 1: > #1: GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=2], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [GMS] Handling message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=2], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > ### GmsImpl.handleViewChange() {} > 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [GMS] GmsImpl ignoring view update [Test-NodeB|2] (4) [Test-NodeB, Test-NodeC, Test-NodeA, Test-NodeD] > 10:37:42,950 TRACE (jgroups-5,Test-NodeC:[]) [UDP] Test-NodeC: sending msg to Test-NodeB, src=Test-NodeC, headers are GMS: GmsHeader[VIEW_ACK], UNICAST3: DATA, seqno=3, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > ### The ack for the JOIN_RSP is only sent here > 10:37:43,034 TRACE (ForkThread-1,InitialClusterSizeTest:[]) [UDP] Test-NodeC: sending msg to Test-NodeB, src=Test-NodeC, headers are GMS: GmsHeader[VIEW_ACK], UNICAST3: DATA, seqno=4, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] > 10:37:43,034 DEBUG (ForkThread-1,InitialClusterSizeTest:[]) [JGroupsTransport] Waiting for 4 nodes, current view has 2 > {noformat} > To help debugging, {{TP.passBatchUp}} should really log the headers of the messages in the batch, and {{GMS}} and the {{GmsImpl}} subclasses should log at least a DEBUG message every time they ignore a view (even when {{log_view_warnings==false}}). I also suggest removing the default implementations from {{GmsImpl}} and updating the {{ClientGmsImpl}} javadoc, because it talks about handling {{ViewChange}} instead of {{JoinResponse}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12899) Failing JMXPropertyEditorsTestCase in 18.0.0.Final

by Bartosz Baranowski (Jira)

[ https://issues.redhat.com/browse/WFLY-12899?page=com.atlassian.jira.plugi... ] Bartosz Baranowski edited comment on WFLY-12899 at 1/15/20 5:17 AM: -------------------------------------------------------------------- Test is designed to check env variables expansion. So naturally one env var that is present in any OS( one way or another) has been chosen. Since different OS store it a bit differently test has to do some digging and store name of env variable in USER_SYS_PROP. Problem with docker is that it does great job at isolating running process that is - unless you set explicitly some env variable it wont be there, even though it is present in OS/env. (Im assuming that jenkins triggers docker to test WFLY). One solution would be to add -e switch to docker(or any kind of equivalent), second to ignore this part of test if no env value can be detected. [~james-crowley-ibm] - can you please try -e ? was (Author: baranowb): Test is designed to check env variables expansion. So naturally one env var that is present in any OS( one way or another) has been chosen. Since different OS store it a bit differently test has to do some digging and stores name of env variable in USER_SYS_PROP. Problem with docker is that it does great job at isolating running process that is - unless you set explicitly some env variable it wont be there, even though it is present in OS/env. (Im assuming that jenkins triggers docker to test WFLY). One solution would be to add -e switch to docker(or any kind of equivalent), second to ignore this part of test if no env value can be detected. [~james-crowley-ibm] - can you please try -e ? > Failing JMXPropertyEditorsTestCase in 18.0.0.Final > -------------------------------------------------- > > Key: WFLY-12899 > URL: https://issues.redhat.com/browse/WFLY-12899 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 18.0.0.Final > Reporter: James Crowley > Assignee: Bartosz Baranowski > Priority: Major > > When calling "./mvnw install -DallTests", it gets up to the JMXPropertyEditorsTestCase and fails with this error, "Caused by: java.lang.IllegalStateException: Failed to resolve expression: env.USER"}}}}". > Looking at the source code for the test [here|https://github.com/wildfly/wildfly/blob/1bf993be72b570a0c780a58ba05c...], it looks like USER is suppose to be defined by USER_SYS_PROP. > I am not sure what the problem is but I know it is failing somewhere in the above test. > You can see the full log in the in Adopt's test [here|https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/1436/conso...]. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12899) Failing JMXPropertyEditorsTestCase in 18.0.0.Final

by Bartosz Baranowski (Jira)

[ https://issues.redhat.com/browse/WFLY-12899?page=com.atlassian.jira.plugi... ] Bartosz Baranowski commented on WFLY-12899: ------------------------------------------- Test is designed to check env variables expansion. So naturally one env var that is present in any OS( one way or another) has been chosen. Since different OS store it a bit differently test has to do some digging and stores name of env variable in USER_SYS_PROP. Problem with docker is that it does great job at isolating running process that is - unless you set explicitly some env variable it wont be there, even though it is present in OS/env. (Im assuming that jenkins triggers docker to test WFLY). One solution would be to add -e switch to docker(or any kind of equivalent), second to ignore this part of test if no env value can be detected. [~james-crowley-ibm] - can you please try -e ? > Failing JMXPropertyEditorsTestCase in 18.0.0.Final > -------------------------------------------------- > > Key: WFLY-12899 > URL: https://issues.redhat.com/browse/WFLY-12899 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 18.0.0.Final > Reporter: James Crowley > Assignee: Bartosz Baranowski > Priority: Major > > When calling "./mvnw install -DallTests", it gets up to the JMXPropertyEditorsTestCase and fails with this error, "Caused by: java.lang.IllegalStateException: Failed to resolve expression: env.USER"}}}}". > Looking at the source code for the test [here|https://github.com/wildfly/wildfly/blob/1bf993be72b570a0c780a58ba05c...], it looks like USER is suppose to be defined by USER_SYS_PROP. > I am not sure what the problem is but I know it is failing somewhere in the above test. > You can see the full log in the in Adopt's test [here|https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/1436/conso...]. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2435) ClientGmsImpl ignores newer view during join

by Dan Berindei (Jira)

Dan Berindei created JGRP-2435: ---------------------------------- Summary: ClientGmsImpl ignores newer view during join Key: JGRP-2435 URL: https://issues.redhat.com/browse/JGRP-2435 Project: JGroups Issue Type: Bug Affects Versions: 4.1.9 Reporter: Dan Berindei Assignee: Bela Ban We have random failures in a test that starts 4 nodes in parallel ({{org.infinispan.InitialClusterSizeTest.testInitialClusterSize}}). I get at least one failure if I add {{@Test(invocationCount=100)}}, but I did not get any failure when I did the same with {{org.jgroups.tests.ConcurrentStartupTest.testConcurrentJoinWithLOCAL_PING()}}, maybe because the Infinispan test sends some additional messages and sometimes changes how messages are processed. The problem seems to be that after receiving a {{JOIN_RSP}} and installing the first view, the GMS implementation is still {{ClientGmsImpl}} when receiving the second view, and the view is ignored. Because this second view already has all 4 members, there is no other {{VIEW}} message and the test just times out. I added some logs in TP and GMS for debugging, and this is what I see: {noformat} 10:37:42,896 TRACE (ucast-receiver-2,Test-NodeC:[]) [UDP] Received oob=false internal=true message GMS: GmsHeader[JOIN_RSP], UNICAST3: DATA, seqno=1, first, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] 10:37:42,898 TRACE (mcast-receiver-3,Test-NodeC:[]) [UDP] Received oob=false internal=false message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=1], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] 10:37:42,906 TRACE (jgroups-4,Test-NodeC:[]) [UDP] Test-NodeC: received [Test-NodeB to Test-NodeC, 61 bytes, flags=INTERNAL], headers are GMS: GmsHeader[JOIN_RSP], UNICAST3: DATA, seqno=1, first, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] 10:37:42,906 TRACE (jgroups-4,Test-NodeC:[]) [GMS] Handling message GMS: GmsHeader[JOIN_RSP], UNICAST3: DATA, seqno=1, first, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] 10:37:42,907 DEBUG (ForkThread-1,InitialClusterSizeTest:[]) [GMS] Test-NodeC: installing view [Test-NodeB|1] (2) [Test-NodeB, Test-NodeC] 10:37:42,947 TRACE (mcast-receiver-3,Test-NodeC:[]) [UDP] Received oob=false internal=false message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=2], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [UDP] Test-NodeC: received message batch of from Test-NodeB: dest=null, sender=Test-NodeB 1: #1: GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=1], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [GMS] Handling message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=1], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [UDP] Test-NodeC: received message batch of from Test-NodeB: dest=null, sender=Test-NodeB 1: #1: GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=2], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [GMS] Handling message GMS: GmsHeader[VIEW], NAKACK2: [MSG, seqno=2], TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] ### GmsImpl.handleViewChange() {} 10:37:42,948 TRACE (jgroups-5,Test-NodeC:[]) [GMS] GmsImpl ignoring view update [Test-NodeB|2] (4) [Test-NodeB, Test-NodeC, Test-NodeA, Test-NodeD] 10:37:42,950 TRACE (jgroups-5,Test-NodeC:[]) [UDP] Test-NodeC: sending msg to Test-NodeB, src=Test-NodeC, headers are GMS: GmsHeader[VIEW_ACK], UNICAST3: DATA, seqno=3, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] ### The ack for the JOIN_RSP is only sent here 10:37:43,034 TRACE (ForkThread-1,InitialClusterSizeTest:[]) [UDP] Test-NodeC: sending msg to Test-NodeB, src=Test-NodeC, headers are GMS: GmsHeader[VIEW_ACK], UNICAST3: DATA, seqno=4, TP: [cluster=org.infinispan.remoting.transport.InitialClusterSizeTest] 10:37:43,034 DEBUG (ForkThread-1,InitialClusterSizeTest:[]) [JGroupsTransport] Waiting for 4 nodes, current view has 2 {noformat} To help debugging, {{TP.passBatchUp}} should really log the headers of the messages in the batch, and {{GMS}} and the {{GmsImpl}} subclasses should log at least a DEBUG message every time they ignore a view (even when {{log_view_warnings==false}}). I also suggest removing the default implementations from {{GmsImpl}} and updating the {{ClientGmsImpl}} javadoc, because it talks about handling {{ViewChange}} instead of {{JoinResponse}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4145) R&D how to import/export CSV inside VSCode

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4145?page=com.atlassian.jira.plug... ] Gabriele Cardosi reopened DROOLS-4145: -------------------------------------- Assignee: Yeser Amer (was: Gabriele Cardosi) 1) Import/export should not depend on any backend library 2) there must be a command available to be invoked by the container (as for undo/redo operation) > R&D how to import/export CSV inside VSCode > ------------------------------------------ > > Key: DROOLS-4145 > URL: https://issues.redhat.com/browse/DROOLS-4145 > Project: Drools > Issue Type: Enhancement > Reporter: Gabriele Cardosi > Assignee: Yeser Amer > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4169) Can't compile large .drl files with security manager turned on in tomcat

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-4169?page=com.atlassian.jira.plug... ] Mario Fusco resolved DROOLS-4169. --------------------------------- Resolution: Explained > Can't compile large .drl files with security manager turned on in tomcat > ------------------------------------------------------------------------ > > Key: DROOLS-4169 > URL: https://issues.redhat.com/browse/DROOLS-4169 > Project: Drools > Issue Type: Bug > Affects Versions: 7.22.0.Final > Environment: Java 11 > Tomcat 9 > Ubuntu 18.10/Amazon Linux AMI > Reporter: Anthony Bruno > Assignee: Mario Fusco > Priority: Major > > Reproduction repository: https://github.com/AussieGuy0/drools-bug > *Summary* > When large rule (.drl) files are complied **with** the security manager turned > on in a servlet container (e.g. Tomcat), it causes `AccessControlExceptions`, which causes `NoClassDefFoundErrors`. > *Steps* > Prereqs: Program is run in servlet context (e.g .war file in tomcat) > 1. Turn on security manager > 2. Provide policy files through the properties `java.security.policy` and `kie.security.policy` > 3. Compile a `.drl` file that has more than `parallelRulesBuildThreshold` (default: 10) rules > *Expected Result* > Rules are compiled successfully > *Actual Result* > No class def error > *Cause* > In `KnowledgeBuilderImpl`, a `ForkJoinPool` is created and used for parallel building. > A `ForkJoinPool` with no `ForkJoinWorkerThreadFactory` specified, it will use a default factory > that provides it's own permissions. These permissions are not sufficient for compiling > drl files in a servlet context. > *Potential Fix* > A potential fix is to allow the user to provide their own `ForkJoinWorkerThreadFactory` as a > configuration option for drools. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4169) Can't compile large .drl files with security manager turned on in tomcat

by Tibor Zimanyi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4169?page=com.atlassian.jira.plug... ] Tibor Zimanyi edited comment on DROOLS-4169 at 1/15/20 3:57 AM: ---------------------------------------------------------------- Hi [~anthony_bruno], sorry for late reply. I tried with Tomcat and if you specify security permissions in Tomcat's conf/catalina.policy file for your web application, it works. I added this to it (just for testing purposes, you can add more granular permissions): {code:java} grant codeBase "file:${catalina.base}/webapps/test/-" { permission java.security.AllPermission; }; {code} Then I started the server with _./catalina.sh run -security_ and the big DRL worked. Please let me know if this answers your problem and if yes, I will close this JIRA. was (Author: tzimanyi): Hi [~anthony_bruno], sorry for late reply. I tried with Tomcat and if you specify security permissions in Tomcat's conf/catalina.policy file for your web application, it works. I added this to it (just for testing purposes, you can add more granular permissions): grant codeBase "file:${catalina.base}/webapps/test/-" { permission java.security.AllPermission; }; Then I started the server with _./catalina.sh run -security_ and the big DRL worked. Please let me know if this answers your problem and if yes, I will close this JIRA. > Can't compile large .drl files with security manager turned on in tomcat > ------------------------------------------------------------------------ > > Key: DROOLS-4169 > URL: https://issues.redhat.com/browse/DROOLS-4169 > Project: Drools > Issue Type: Bug > Affects Versions: 7.22.0.Final > Environment: Java 11 > Tomcat 9 > Ubuntu 18.10/Amazon Linux AMI > Reporter: Anthony Bruno > Assignee: Mario Fusco > Priority: Major > > Reproduction repository: https://github.com/AussieGuy0/drools-bug > *Summary* > When large rule (.drl) files are complied **with** the security manager turned > on in a servlet container (e.g. Tomcat), it causes `AccessControlExceptions`, which causes `NoClassDefFoundErrors`. > *Steps* > Prereqs: Program is run in servlet context (e.g .war file in tomcat) > 1. Turn on security manager > 2. Provide policy files through the properties `java.security.policy` and `kie.security.policy` > 3. Compile a `.drl` file that has more than `parallelRulesBuildThreshold` (default: 10) rules > *Expected Result* > Rules are compiled successfully > *Actual Result* > No class def error > *Cause* > In `KnowledgeBuilderImpl`, a `ForkJoinPool` is created and used for parallel building. > A `ForkJoinPool` with no `ForkJoinWorkerThreadFactory` specified, it will use a default factory > that provides it's own permissions. These permissions are not sufficient for compiling > drl files in a servlet context. > *Potential Fix* > A potential fix is to allow the user to provide their own `ForkJoinWorkerThreadFactory` as a > configuration option for drools. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4169) Can't compile large .drl files with security manager turned on in tomcat

by Tibor Zimanyi (Jira)

[ https://issues.redhat.com/browse/DROOLS-4169?page=com.atlassian.jira.plug... ] Tibor Zimanyi commented on DROOLS-4169: --------------------------------------- Hi [~anthony_bruno], sorry for late reply. I tried with Tomcat and if you specify security permissions in Tomcat's conf/catalina.policy file for your web application, it works. I added this to it (just for testing purposes, you can add more granular permissions): grant codeBase "file:${catalina.base}/webapps/test/-" { permission java.security.AllPermission; }; Then I started the server with _./catalina.sh run -security_ and the big DRL worked. Please let me know if this answers your problem and if yes, I will close this JIRA. > Can't compile large .drl files with security manager turned on in tomcat > ------------------------------------------------------------------------ > > Key: DROOLS-4169 > URL: https://issues.redhat.com/browse/DROOLS-4169 > Project: Drools > Issue Type: Bug > Affects Versions: 7.22.0.Final > Environment: Java 11 > Tomcat 9 > Ubuntu 18.10/Amazon Linux AMI > Reporter: Anthony Bruno > Assignee: Mario Fusco > Priority: Major > > Reproduction repository: https://github.com/AussieGuy0/drools-bug > *Summary* > When large rule (.drl) files are complied **with** the security manager turned > on in a servlet container (e.g. Tomcat), it causes `AccessControlExceptions`, which causes `NoClassDefFoundErrors`. > *Steps* > Prereqs: Program is run in servlet context (e.g .war file in tomcat) > 1. Turn on security manager > 2. Provide policy files through the properties `java.security.policy` and `kie.security.policy` > 3. Compile a `.drl` file that has more than `parallelRulesBuildThreshold` (default: 10) rules > *Expected Result* > Rules are compiled successfully > *Actual Result* > No class def error > *Cause* > In `KnowledgeBuilderImpl`, a `ForkJoinPool` is created and used for parallel building. > A `ForkJoinPool` with no `ForkJoinWorkerThreadFactory` specified, it will use a default factory > that provides it's own permissions. These permissions are not sufficient for compiling > drl files in a servlet context. > *Potential Fix* > A potential fix is to allow the user to provide their own `ForkJoinWorkerThreadFactory` as a > configuration option for drools. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12899) Failing JMXPropertyEditorsTestCase in 18.0.0.Final

by Bartosz Baranowski (Jira)

[ https://issues.redhat.com/browse/WFLY-12899?page=com.atlassian.jira.plugi... ] Bartosz Baranowski reassigned WFLY-12899: ----------------------------------------- Assignee: Bartosz Baranowski > Failing JMXPropertyEditorsTestCase in 18.0.0.Final > -------------------------------------------------- > > Key: WFLY-12899 > URL: https://issues.redhat.com/browse/WFLY-12899 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 18.0.0.Final > Reporter: James Crowley > Assignee: Bartosz Baranowski > Priority: Major > > When calling "./mvnw install -DallTests", it gets up to the JMXPropertyEditorsTestCase and fails with this error, "Caused by: java.lang.IllegalStateException: Failed to resolve expression: env.USER"}}}}". > Looking at the source code for the test [here|https://github.com/wildfly/wildfly/blob/1bf993be72b570a0c780a58ba05c...], it looks like USER is suppose to be defined by USER_SYS_PROP. > I am not sure what the problem is but I know it is failing somewhere in the above test. > You can see the full log in the in Adopt's test [here|https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/1436/conso...]. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12941) Microprofile count metrics does not increase in wildfly17

by Bartosz Baranowski (Jira)

[ https://issues.redhat.com/browse/WFLY-12941?page=com.atlassian.jira.plugi... ] Bartosz Baranowski resolved WFLY-12941. --------------------------------------- Fix Version/s: 18.0.0.Final Assignee: Bartosz Baranowski (was: Jeff Mesnil) Resolution: Out of Date Resolving based on Reporters last comment - fixed in 18. > Microprofile count metrics does not increase in wildfly17 > ---------------------------------------------------------- > > Key: WFLY-12941 > URL: https://issues.redhat.com/browse/WFLY-12941 > Project: WildFly > Issue Type: Bug > Components: MP Metrics > Reporter: alireza alallah > Assignee: Bartosz Baranowski > Priority: Major > Fix For: 18.0.0.Final > > > for example > @Path("/") > public class RESTEndpoints { > > @GET > @Path("/hello") > @Counted(name"total_count",absolute = true) > public String hello(@DefaultValue("my friend!") @QueryParam("name") String name) { > return "Hello "+name; > > } > > } > Now in http://localhost:9990/metrics *total_count* metric does not increase after invoke endpoint. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12941) Microprofile count metrics does not increase in wildfly17

by Bartosz Baranowski (Jira)

[ https://issues.redhat.com/browse/WFLY-12941?page=com.atlassian.jira.plugi... ] Bartosz Baranowski commented on WFLY-12941: ------------------------------------------- [~alireza.alallah] - WFLY is rolling forward, there are no backport( AFAIR ) - so yes. > Microprofile count metrics does not increase in wildfly17 > ---------------------------------------------------------- > > Key: WFLY-12941 > URL: https://issues.redhat.com/browse/WFLY-12941 > Project: WildFly > Issue Type: Bug > Components: MP Metrics > Reporter: alireza alallah > Assignee: Jeff Mesnil > Priority: Major > > for example > @Path("/") > public class RESTEndpoints { > > @GET > @Path("/hello") > @Counted(name"total_count",absolute = true) > public String hello(@DefaultValue("my friend!") @QueryParam("name") String name) { > return "Hello "+name; > > } > > } > Now in http://localhost:9990/metrics *total_count* metric does not increase after invoke endpoint. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12968) SecurityDomainContextRealm is not caching passwords correctly

by Ricardo Martin Camarero (Jira)

Ricardo Martin Camarero created WFLY-12968: ---------------------------------------------- Summary: SecurityDomainContextRealm is not caching passwords correctly Key: WFLY-12968 URL: https://issues.redhat.com/browse/WFLY-12968 Project: WildFly Issue Type: Bug Components: Security Affects Versions: 18.0.1.Final Reporter: Ricardo Martin Camarero Assignee: Ricardo Martin Camarero The [SecurityDomainContextRealm|https://github.com/wildfly/wildfly/blob/18.0.1...] realm used in elytron mixed scenarios is not taken advantage of the cache if the underlying security-domain is configured with default cache ({{cache-type="default"}}). The problem is similar to what is commented in the [JAASIdentityManagerImpl|https://github.com/wildfly/wildfly/blob/18.0.1.Fi...], the evidence reset the password and then the cache is useless. The solution can also be cloning the password char[] before, this way the cache is OK and the array can be compared correctly. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12088) JAR does not supported for deployment-overlays mechanism

by Bartosz Baranowski (Jira)

[ https://issues.redhat.com/browse/WFLY-12088?page=com.atlassian.jira.plugi... ] Bartosz Baranowski reassigned WFLY-12088: ----------------------------------------- Assignee: Bartosz Baranowski (was: Richard Opalka) > JAR does not supported for deployment-overlays mechanism > -------------------------------------------------------- > > Key: WFLY-12088 > URL: https://issues.redhat.com/browse/WFLY-12088 > Project: WildFly > Issue Type: Bug > Components: Class Loading > Affects Versions: 16.0.0.Final > Reporter: Vlad Filipp > Assignee: Bartosz Baranowski > Priority: Major > > When trying to make a link from an overlay to a JAR, classes from overlay libraries are not loaded for a linked JAR. > The situation is similar when creating a link to a JAR which is located inside EAR. > Should overlay deployment mechanism be supported for JARs? > Example standalone.xml: > {code:java} > <deployment-overlays> > ... > <deployment-overlay name="my-overlay-n1"> > <content ...> > <deployment name="my-jar-inside-ear-use-overlays-libs.jar"/> > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12088) JAR does not supported for deployment-overlays mechanism

by Bartosz Baranowski (Jira)

[ https://issues.redhat.com/browse/WFLY-12088?page=com.atlassian.jira.plugi... ] Bartosz Baranowski edited comment on WFLY-12088 at 1/15/20 1:53 AM: -------------------------------------------------------------------- Hi [~vladimirfrankov] could you please attach reproducer or full description with steps to trigger failure? was (Author: baranowb): Hi [~vladimirfrankov] could you please attach reproducer or steps to trigger failure? > JAR does not supported for deployment-overlays mechanism > -------------------------------------------------------- > > Key: WFLY-12088 > URL: https://issues.redhat.com/browse/WFLY-12088 > Project: WildFly > Issue Type: Bug > Components: Class Loading > Affects Versions: 16.0.0.Final > Reporter: Vlad Filipp > Assignee: Richard Opalka > Priority: Major > > When trying to make a link from an overlay to a JAR, classes from overlay libraries are not loaded for a linked JAR. > The situation is similar when creating a link to a JAR which is located inside EAR. > Should overlay deployment mechanism be supported for JARs? > Example standalone.xml: > {code:java} > <deployment-overlays> > ... > <deployment-overlay name="my-overlay-n1"> > <content ...> > <deployment name="my-jar-inside-ear-use-overlays-libs.jar"/> > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12088) JAR does not supported for deployment-overlays mechanism

by Bartosz Baranowski (Jira)

[ https://issues.redhat.com/browse/WFLY-12088?page=com.atlassian.jira.plugi... ] Bartosz Baranowski commented on WFLY-12088: ------------------------------------------- Hi [~vladimirfrankov] could you please attach reproducer or steps to trigger failure? > JAR does not supported for deployment-overlays mechanism > -------------------------------------------------------- > > Key: WFLY-12088 > URL: https://issues.redhat.com/browse/WFLY-12088 > Project: WildFly > Issue Type: Bug > Components: Class Loading > Affects Versions: 16.0.0.Final > Reporter: Vlad Filipp > Assignee: Richard Opalka > Priority: Major > > When trying to make a link from an overlay to a JAR, classes from overlay libraries are not loaded for a linked JAR. > The situation is similar when creating a link to a JAR which is located inside EAR. > Should overlay deployment mechanism be supported for JARs? > Example standalone.xml: > {code:java} > <deployment-overlays> > ... > <deployment-overlay name="my-overlay-n1"> > <content ...> > <deployment name="my-jar-inside-ear-use-overlays-libs.jar"/> > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12966) Upgrade Hibernate ORM from 5.3.14 to 5.3.15

by Ilia Vassilev (Jira)

[ https://issues.redhat.com/browse/WFLY-12966?page=com.atlassian.jira.plugi... ] Ilia Vassilev updated WFLY-12966: --------------------------------- Labels: downstream_dependency (was: ) > Upgrade Hibernate ORM from 5.3.14 to 5.3.15 > ------------------------------------------- > > Key: WFLY-12966 > URL: https://issues.redhat.com/browse/WFLY-12966 > Project: WildFly > Issue Type: Component Upgrade > Components: JPA / Hibernate > Reporter: Gail Badner > Assignee: Gail Badner > Priority: Major > Labels: downstream_dependency > 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-12909) Fix license names for org.hdrhistogram:HdrHistogram licenses

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-12909?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-12909: ---------------------------------- Affects Version/s: No Release > Fix license names for org.hdrhistogram:HdrHistogram licenses > ------------------------------------------------------------- > > Key: WFLY-12909 > URL: https://issues.redhat.com/browse/WFLY-12909 > Project: WildFly > Issue Type: Task > Components: MP Fault Tolerance > Affects Versions: No Release > Reporter: James Perkins > Assignee: Radoslav Husar > Priority: Blocker > Fix For: 19.0.0.Beta1 > > > This isn't a blocker for beta, but should be for 19.0.0.Final as the generated license names need to match a license name in https://spdx.org/licenses/. > On the [PR|https://github.com/wildfly/wildfly/pull/12800/files/9c843d1a0e00172b00...] to introduce fault tolerance doesn't have quite the right license text for {{org.hdrhistogram:HdrHistogram}}. Looking at the [license file|https://github.com/HdrHistogram/HdrHistogram/blob/master/LICENSE.txt] we just need to determine which license name should be used as both licenses have multiple names. > One other minor note. The order the licenses are listed in the {{full-feature-pack-licenses.xml}} for this dependency may need to be swapped. I _believe_ these need to be in alphabetical order. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4930) [DMN Designer] Remove UUID from Alerts panel validation messages

by Roger Martinez (Jira)

[ https://issues.redhat.com/browse/DROOLS-4930?page=com.atlassian.jira.plug... ] Roger Martinez commented on DROOLS-4930: ---------------------------------------- Hey [~jomarko], yes I think so, although IMO there a a few gaps to consider yet. Think that the idea is having some String that references the element in the output logs, so: * if some name is present for the element, probably no need for UUID * But in case a node has no name, for example just when adding a gateway, which reference you'll use on the logs? There is only UUID available I would say * Also, it can be a point where names are duplicated accross elements, so that may be confusing also just to display the name where there exist several related nodes, right? So I think the solution, whatever it is, may apply to both DMN and BPMN, but it's not yet clear for me how to behave... Thx! > [DMN Designer] Remove UUID from Alerts panel validation messages > ----------------------------------------------------------------- > > Key: DROOLS-4930 > URL: https://issues.redhat.com/browse/DROOLS-4930 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Affects Versions: 7.31.0.Final > Reporter: Michael Anstis > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > > Validation of a DMN diagram can lead to messages being shown in the Alerts Panel. > Stunner is appending the UUID to the message. See [CoreTranslationMessages.getElementValidationMessage()|https://github.com/...] > [~tirelli] has requested their removal. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12957) MP Fault tolerance tests are failing on Ubuntu

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-12957?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-12957: ---------------------------------- Fix Version/s: 19.0.0.Beta1 > MP Fault tolerance tests are failing on Ubuntu > ---------------------------------------------- > > Key: WFLY-12957 > URL: https://issues.redhat.com/browse/WFLY-12957 > Project: WildFly > Issue Type: Bug > Components: MP Fault Tolerance, Test Suite > Affects Versions: No Release > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Major > Fix For: 19.0.0.Beta1 > > > Environment variables with dots in their name are not supported on Ubuntu making the fault tolerance tests fail. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12957) MP Fault tolerance tests are failing on Ubuntu

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-12957?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-12957: ---------------------------------- Affects Version/s: No Release (was: 18.0.0.Beta1) > MP Fault tolerance tests are failing on Ubuntu > ---------------------------------------------- > > Key: WFLY-12957 > URL: https://issues.redhat.com/browse/WFLY-12957 > Project: WildFly > Issue Type: Bug > Components: MP Fault Tolerance, Test Suite > Affects Versions: No Release > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Major > Fix For: 19.0.0.Beta1 > > > Environment variables with dots in their name are not supported on Ubuntu making the fault tolerance tests fail. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11728) Microprofile rest client - redeployment WELD-001414: Bean name is ambiguous.

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-11728?page=com.atlassian.jira.plugi... ] Brian Stansberry commented on WFLY-11728: ----------------------------------------- [~ron_sigal] Yes; I'll resolve it. > Microprofile rest client - redeployment WELD-001414: Bean name is ambiguous. > ---------------------------------------------------------------------------- > > Key: WFLY-11728 > URL: https://issues.redhat.com/browse/WFLY-11728 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 15.0.1.Final > Reporter: Andrej Petras > Assignee: Ronald Sigal > Priority: Critical > Labels: Microprofile, resteasy-client > Fix For: 18.0.1.Final, 19.0.0.Beta1 > > > {noformat} > 09:35:25,936 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."mp-client-1.0.0-SNAPSHOT.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."mp-client-1.0.0-SNAPSHOT.war".WeldStartService: Failed to start service > at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1730) > at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558) > at org.jboss.threads@2.3.2.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) > at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) > at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) > at java.base/java.lang.Thread.run(Thread.java:834) > Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001414: Bean name is ambiguous. Name org.lorislab.mp.client.api.TestRestService resolves to beans: [org.jboss.resteasy.cdi.microprofile.RestClientDelegateBean@2a357dc2, org.jboss.resteasy.cdi.microprofile.RestClientDelegateBean@59b2b6ec] > at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.bootstrap.Validator.validateBeanName(Validator.java:653) > at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.bootstrap.ConcurrentValidator$5.doWork(ConcurrentValidator.java:121) > at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.bootstrap.ConcurrentValidator$5.doWork(ConcurrentValidator.java:119) > at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62) > at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:834) > at org.jboss.threads@2.3.2.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485) > 09:35:25,941 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) WFLYCTL0013: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"mp-client-1.0.0-SNAPSHOT.war\".WeldStartService" => "Failed to start service > Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001414: Bean name is ambiguous. Name org.lorislab.mp.client.api.TestRestService resolves to beans: [org.jboss.resteasy.cdi.microprofile.RestClientDelegateBean@2a357dc2, org.jboss.resteasy.cdi.microprofile.RestClientDelegateBean@59b2b6ec]"}} > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11728) Microprofile rest client - redeployment WELD-001414: Bean name is ambiguous.

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-11728?page=com.atlassian.jira.plugi... ] Brian Stansberry resolved WFLY-11728. ------------------------------------- Fix Version/s: 18.0.1.Final Resolution: Done > Microprofile rest client - redeployment WELD-001414: Bean name is ambiguous. > ---------------------------------------------------------------------------- > > Key: WFLY-11728 > URL: https://issues.redhat.com/browse/WFLY-11728 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 15.0.1.Final > Reporter: Andrej Petras > Assignee: Ronald Sigal > Priority: Critical > Labels: Microprofile, resteasy-client > Fix For: 19.0.0.Beta1, 18.0.1.Final > > > {noformat} > 09:35:25,936 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."mp-client-1.0.0-SNAPSHOT.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."mp-client-1.0.0-SNAPSHOT.war".WeldStartService: Failed to start service > at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1730) > at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558) > at org.jboss.threads@2.3.2.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) > at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) > at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) > at java.base/java.lang.Thread.run(Thread.java:834) > Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001414: Bean name is ambiguous. Name org.lorislab.mp.client.api.TestRestService resolves to beans: [org.jboss.resteasy.cdi.microprofile.RestClientDelegateBean@2a357dc2, org.jboss.resteasy.cdi.microprofile.RestClientDelegateBean@59b2b6ec] > at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.bootstrap.Validator.validateBeanName(Validator.java:653) > at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.bootstrap.ConcurrentValidator$5.doWork(ConcurrentValidator.java:121) > at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.bootstrap.ConcurrentValidator$5.doWork(ConcurrentValidator.java:119) > at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62) > at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:834) > at org.jboss.threads@2.3.2.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485) > 09:35:25,941 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) WFLYCTL0013: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"mp-client-1.0.0-SNAPSHOT.war\".WeldStartService" => "Failed to start service > Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001414: Bean name is ambiguous. Name org.lorislab.mp.client.api.TestRestService resolves to beans: [org.jboss.resteasy.cdi.microprofile.RestClientDelegateBean@2a357dc2, org.jboss.resteasy.cdi.microprofile.RestClientDelegateBean@59b2b6ec]"}} > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

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

by Ronald Sigal (Jira)

[ https://issues.redhat.com/browse/WFLY-12712?page=com.atlassian.jira.plugi... ] Ronald Sigal commented on WFLY-12712: ------------------------------------- Note that WFLY-11728 / RESTEASY-2386 was fixed in RESTEasy release 3.9.1.Final, so it's already in Wildfly. I'm unlinking this from incorporating WFLY-11728 > Upgrade RESTEasy to 3.10.0.Final > -------------------------------- > > Key: WFLY-12712 > URL: https://issues.redhat.com/browse/WFLY-12712 > Project: WildFly > Issue Type: Task > Reporter: Ronald Sigal > Assignee: Ronald Sigal > 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-11728) Microprofile rest client - redeployment WELD-001414: Bean name is ambiguous.

by Ronald Sigal (Jira)

[ https://issues.redhat.com/browse/WFLY-11728?page=com.atlassian.jira.plugi... ] Ronald Sigal commented on WFLY-11728: ------------------------------------- Actually, RESTEASY-2386 was fixed in RESTEasy release 3.9.1.Final, so this should be closed, right? > Microprofile rest client - redeployment WELD-001414: Bean name is ambiguous. > ---------------------------------------------------------------------------- > > Key: WFLY-11728 > URL: https://issues.redhat.com/browse/WFLY-11728 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 15.0.1.Final > Reporter: Andrej Petras > Assignee: Ronald Sigal > Priority: Critical > Labels: Microprofile, resteasy-client > Fix For: 19.0.0.Beta1 > > > {noformat} > 09:35:25,936 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."mp-client-1.0.0-SNAPSHOT.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."mp-client-1.0.0-SNAPSHOT.war".WeldStartService: Failed to start service > at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1730) > at org.jboss.msc@1.4.5.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1558) > at org.jboss.threads@2.3.2.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) > at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) > at org.jboss.threads@2.3.2.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) > at java.base/java.lang.Thread.run(Thread.java:834) > Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001414: Bean name is ambiguous. Name org.lorislab.mp.client.api.TestRestService resolves to beans: [org.jboss.resteasy.cdi.microprofile.RestClientDelegateBean@2a357dc2, org.jboss.resteasy.cdi.microprofile.RestClientDelegateBean@59b2b6ec] > at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.bootstrap.Validator.validateBeanName(Validator.java:653) > at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.bootstrap.ConcurrentValidator$5.doWork(ConcurrentValidator.java:121) > at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.bootstrap.ConcurrentValidator$5.doWork(ConcurrentValidator.java:119) > at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:62) > at org.jboss.weld.core@3.0.5.Final//org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:55) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:834) > at org.jboss.threads@2.3.2.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485) > 09:35:25,941 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) WFLYCTL0013: Operation ("full-replace-deployment") failed - address: ([]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"mp-client-1.0.0-SNAPSHOT.war\".WeldStartService" => "Failed to start service > Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001414: Bean name is ambiguous. Name org.lorislab.mp.client.api.TestRestService resolves to beans: [org.jboss.resteasy.cdi.microprofile.RestClientDelegateBean@2a357dc2, org.jboss.resteasy.cdi.microprofile.RestClientDelegateBean@59b2b6ec]"}} > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12963) Use maven project.groupId for wildfly-microprofile-jwt-smallrye dependencies

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-12963?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFLY-12963: ------------------------------------ Attachment: (was: Не подтвержден 871729.crdownload) > Use maven project.groupId for wildfly-microprofile-jwt-smallrye dependencies > ---------------------------------------------------------------------------- > > Key: WFLY-12963 > URL: https://issues.redhat.com/browse/WFLY-12963 > Project: WildFly > Issue Type: Task > Components: Build System > Reporter: Yeray Borges > Assignee: Yeray Borges > Priority: Minor > Fix For: 19.0.0.Beta1 > > > The use of maven property ${project.groupid} instead of the hardcoded org.wildfly group id facilitates the transition to the product branches. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2434) Support multiple TShark fields parser

by Diego Lovison (Jira)

Diego Lovison created JGRP-2434: ----------------------------------- Summary: Support multiple TShark fields parser Key: JGRP-2434 URL: https://issues.redhat.com/browse/JGRP-2434 Project: JGroups Issue Type: Enhancement Affects Versions: 5.0 Reporter: Diego Lovison Assignee: Bela Ban In other to achieve what I was looking for that is: have the time in front of the line.. it required too many changes in {{Util::parse}} Changes * Need to be divide the {{short version=dis.readShort();}} into the {{dis.read()}} to identify the {{\t}} * {{Util::parse}} is used in GossipRouter Why have a diff parser Prevent changing production code Easy to create/add more fields related only with TShark It reuse the {{Util::parse}} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2434) Support multiple TShark fields parser

by Diego Lovison (Jira)

[ https://issues.redhat.com/browse/JGRP-2434?page=com.atlassian.jira.plugin... ] Diego Lovison reassigned JGRP-2434: ----------------------------------- Assignee: Diego Lovison (was: Bela Ban) > Support multiple TShark fields parser > ------------------------------------- > > Key: JGRP-2434 > URL: https://issues.redhat.com/browse/JGRP-2434 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 5.0 > Reporter: Diego Lovison > Assignee: Diego Lovison > Priority: Major > > In other to achieve what I was looking for that is: have the time in front of the line.. it required too many changes in {{Util::parse}} > Changes > * Need to be divide the {{short version=dis.readShort();}} into the {{dis.read()}} to identify the {{\t}} > * {{Util::parse}} is used in GossipRouter > Why have a diff parser > Prevent changing production code > Easy to create/add more fields related only with TShark > It reuse the {{Util::parse}} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2434) Support multiple TShark fields parser

by Diego Lovison (Jira)

[ https://issues.redhat.com/browse/JGRP-2434?page=com.atlassian.jira.plugin... ] Diego Lovison updated JGRP-2434: -------------------------------- Description: In other to achieve what I was looking for that is: have the time in front of the line.. it required too many changes in {{Util::parse}} Changes * Need to be divide the {{short version=dis.readShort();}} into the {{dis.read()}} to identify the {{\t}} * {{Util::parse}} is used in GossipRouter Why have a diff parser * Prevent changing production code * Easy to create/add more fields related only with TShark * It reuse the {{Util::parse}} was: In other to achieve what I was looking for that is: have the time in front of the line.. it required too many changes in {{Util::parse}} Changes * Need to be divide the {{short version=dis.readShort();}} into the {{dis.read()}} to identify the {{\t}} * {{Util::parse}} is used in GossipRouter Why have a diff parser Prevent changing production code Easy to create/add more fields related only with TShark It reuse the {{Util::parse}} > Support multiple TShark fields parser > ------------------------------------- > > Key: JGRP-2434 > URL: https://issues.redhat.com/browse/JGRP-2434 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 5.0 > Reporter: Diego Lovison > Assignee: Diego Lovison > Priority: Major > > In other to achieve what I was looking for that is: have the time in front of the line.. it required too many changes in {{Util::parse}} > Changes > * Need to be divide the {{short version=dis.readShort();}} into the {{dis.read()}} to identify the {{\t}} > * {{Util::parse}} is used in GossipRouter > Why have a diff parser > * Prevent changing production code > * Easy to create/add more fields related only with TShark > * It reuse the {{Util::parse}} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12963) Use maven project.groupId for wildfly-microprofile-jwt-smallrye dependencies

by Николай Гордуз (Jira)

[ https://issues.redhat.com/browse/WFLY-12963?page=com.atlassian.jira.plugi... ] Николай Гордуз updated WFLY-12963: ---------------------------------- Attachment: Не подтвержден 871729.crdownload > Use maven project.groupId for wildfly-microprofile-jwt-smallrye dependencies > ---------------------------------------------------------------------------- > > Key: WFLY-12963 > URL: https://issues.redhat.com/browse/WFLY-12963 > Project: WildFly > Issue Type: Task > Components: Build System > Reporter: Yeray Borges > Assignee: Yeray Borges > Priority: Minor > Fix For: 19.0.0.Beta1 > > Attachments: Не подтвержден 871729.crdownload > > > The use of maven property ${project.groupid} instead of the hardcoded org.wildfly group id facilitates the transition to the product branches. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12885) Upgrade JSF based on Mojarra 2.3.9.SP05 to 2.3.9.SP06

by Ilia Vassilev (Jira)

[ https://issues.redhat.com/browse/WFLY-12885?page=com.atlassian.jira.plugi... ] Ilia Vassilev updated WFLY-12885: --------------------------------- Summary: Upgrade JSF based on Mojarra 2.3.9.SP05 to 2.3.9.SP06 (was: Upgrade JSF based on Mojarra 2.3.9.SP05 to ...) > Upgrade JSF based on Mojarra 2.3.9.SP05 to 2.3.9.SP06 > ----------------------------------------------------- > > Key: WFLY-12885 > URL: https://issues.redhat.com/browse/WFLY-12885 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System > Reporter: Ilia Vassilev > Assignee: Farah Juma > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-482) Add log4j2 support for WildFly

by James Perkins (Jira)

[ https://issues.redhat.com/browse/WFCORE-482?page=com.atlassian.jira.plugi... ] James Perkins commented on WFCORE-482: -------------------------------------- [~walkerca] I don't think so as the {{Appender}} interface is part of the {{org.apache.logging.log4j:log4j-core}} project which is a full log manager implementation. There is no current plan to fork log4j2 which would be required for that to happen I'd think. It's something that could be researched at some point though. For the integration the main idea is that if you just use the {{log4j-api}} then it will have an implementation that writes to the jboss-logmanager. One idea I would like to implement and do have it working, but it's a bit clumsy, is if you include {{log4j-core}} in a deployment that it would take over the log manager duties for the deployment. Do you have some expectations on how you'd expect it to work? That's the main thing that has held up the integration work, besides time :), is I'm not sure what end users expect. > Add log4j2 support for WildFly > ------------------------------ > > Key: WFCORE-482 > URL: https://issues.redhat.com/browse/WFCORE-482 > Project: WildFly Core > Issue Type: Task > Components: Logging > Environment: Spring 3, Hibernate, Wicket, JBoss AS7 > Reporter: Amarkanth Ranganamayna > Assignee: James Perkins > Priority: Major > > I am trying to use Flume Appender which comes with Log4j2 (log4j 1.x doesn't support flume appender) (AND) inorder to acheive this, I am looking at how to configure JBoss AS7 to use log4j2. > Looks like Jboss AS7 by default use log4j 1.x > Are you guys already working on using log4j2 ? > If NOT, can you please suggest how to configure Jboss AS7 such that it picks up "log4j2.xml" file and doesn't use its own logging. > Thanks, > Amar -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12967) Improve tests in integration/multinode/../transaction/async/TransactionPropagationTestCase

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFLY-12967?page=com.atlassian.jira.plugi... ] Cheng Fang updated WFLY-12967: ------------------------------ Description: This is for tests in {{testsuite/integration/multinode/src/test/java/org/jboss/as/test/multinode/transaction/async/TransactionPropagationTestCase.java}} * replace the {{sleep()}} in test method with {{Future.get()}} after calling async methods * improve jndi lookup ** close context ** cache context at class level ** replace with @EJB injection > Improve tests in integration/multinode/../transaction/async/TransactionPropagationTestCase > ------------------------------------------------------------------------------------------ > > Key: WFLY-12967 > URL: https://issues.redhat.com/browse/WFLY-12967 > Project: WildFly > Issue Type: Enhancement > Components: EJB > Affects Versions: 19.0.0.Beta1 > Reporter: Cheng Fang > Assignee: Cheng Fang > Priority: Major > > This is for tests in {{testsuite/integration/multinode/src/test/java/org/jboss/as/test/multinode/transaction/async/TransactionPropagationTestCase.java}} > * replace the {{sleep()}} in test method with {{Future.get()}} after calling async methods > * improve jndi lookup > ** close context > ** cache context at class level > ** replace with @EJB injection -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12967) Improve tests in integration/multinode/../transaction/async/TransactionPropagationTestCase

by Cheng Fang (Jira)

Cheng Fang created WFLY-12967: --------------------------------- Summary: Improve tests in integration/multinode/../transaction/async/TransactionPropagationTestCase Key: WFLY-12967 URL: https://issues.redhat.com/browse/WFLY-12967 Project: WildFly Issue Type: Enhancement Components: EJB Affects Versions: 19.0.0.Beta1 Reporter: Cheng Fang Assignee: Cheng Fang -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-482) Add log4j2 support for WildFly

by Carl Walker (Jira)

[ https://issues.redhat.com/browse/WFCORE-482?page=com.atlassian.jira.plugi... ] Carl Walker commented on WFCORE-482: ------------------------------------ Will we be able to use the Management Console to set Log4J2 Loggers? How will the integration look if WF packages Log4J2 or if our WARs and EARs package Log4J2? > Add log4j2 support for WildFly > ------------------------------ > > Key: WFCORE-482 > URL: https://issues.redhat.com/browse/WFCORE-482 > Project: WildFly Core > Issue Type: Task > Components: Logging > Environment: Spring 3, Hibernate, Wicket, JBoss AS7 > Reporter: Amarkanth Ranganamayna > Assignee: James Perkins > Priority: Major > > I am trying to use Flume Appender which comes with Log4j2 (log4j 1.x doesn't support flume appender) (AND) inorder to acheive this, I am looking at how to configure JBoss AS7 to use log4j2. > Looks like Jboss AS7 by default use log4j 1.x > Are you guys already working on using log4j2 ? > If NOT, can you please suggest how to configure Jboss AS7 such that it picks up "log4j2.xml" file and doesn't use its own logging. > Thanks, > Amar -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12966) Upgrade Hibernate ORM from 5.3.14 to 5.3.15

by Gail Badner (Jira)

Gail Badner created WFLY-12966: ---------------------------------- Summary: Upgrade Hibernate ORM from 5.3.14 to 5.3.15 Key: WFLY-12966 URL: https://issues.redhat.com/browse/WFLY-12966 Project: WildFly Issue Type: Component Upgrade Components: JPA / Hibernate Reporter: Gail Badner Assignee: Gail Badner 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-12965) (7.3.z) org.jboss.as.test.integration.jpa.cfgfile.CfgFileTestCase fails

by Ilia Vassilev (Jira)

Ilia Vassilev created WFLY-12965: ------------------------------------ Summary: (7.3.z) org.jboss.as.test.integration.jpa.cfgfile.CfgFileTestCase fails Key: WFLY-12965 URL: https://issues.redhat.com/browse/WFLY-12965 Project: WildFly Issue Type: Bug Components: Test Suite Reporter: Ilia Vassilev Assignee: Gail Badner The following fixes in Hibernate ORM 5.3.15.Final cause {{org.jboss.as.test.integration.jpa.cfgfile.CfgFileTestCase}} to fail: https://hibernate.atlassian.net/browse/HHH-13432 https://hibernate.atlassian.net/browse/HHH-12858 There are 2 assertions in the test that fail with those fixes because the Map returned by {{EntityManagerFactory#getProperties}}: 1) does not contain a value for property {{hibernate.connection.driver_class}}. 2) contains a property for {{hibernate.connection.datasource}} that is a {{WildFlyDataSource}} instance, instead of the String {{"java:jboss/datasources/ExampleDS"}}. For 1), Hibernate ORM removes the {{hibernate.connection.driver_class}} property from its copy because it makes no sense when a datasource is provided via {{hibernate.connection.datasource}}. For 2), Hibernate ORM replaces the {{String}} value for {{hibernate.connection.datasource}} with the {{WildFlyDataSource}} instance. I reviewed the JPA 2.2 specification and discussed this issue with [~smarlow], and we agreed that these were acceptable changes to the copy of properties that Hibernate ORM contains. I have confirmed that these fixes do not cause any Jakarta standalone TCK failures. The fix will involve replacing references to those properties with properties that Hibernate ORM does not change. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12964) org.jboss.as.test.integration.jpa.cfgfile.CfgFileTestCase fails

by Gail Badner (Jira)

Gail Badner created WFLY-12964: ---------------------------------- Summary: org.jboss.as.test.integration.jpa.cfgfile.CfgFileTestCase fails Key: WFLY-12964 URL: https://issues.redhat.com/browse/WFLY-12964 Project: WildFly Issue Type: Bug Components: Test Suite Reporter: Gail Badner Assignee: Gail Badner The following fixes in Hibernate ORM 5.3.15.Final cause {{org.jboss.as.test.integration.jpa.cfgfile.CfgFileTestCase}} to fail: https://hibernate.atlassian.net/browse/HHH-13432 https://hibernate.atlassian.net/browse/HHH-12858 There are 2 assertions in the test that fail with those fixes because the Map returned by {{EntityManagerFactory#getProperties}}: 1) does not contain a value for property {{hibernate.connection.driver_class}}. 2) contains a property for {{hibernate.connection.datasource}} that is a {{WildFlyDataSource}} instance, instead of the String {{"java:jboss/datasources/ExampleDS"}}. For 1), Hibernate ORM removes the {{hibernate.connection.driver_class}} property from its copy because it makes no sense when a datasource is provided via {{hibernate.connection.datasource}}. For 2), Hibernate ORM replaces the {{String}} value for {{hibernate.connection.datasource}} with the {{WildFlyDataSource}} instance. I reviewed the JPA 2.2 specification and discussed this issue with [~smarlow], and we agreed that these were acceptable changes to the copy of properties that Hibernate ORM contains. I have confirmed that these fixes do not cause any Jakarta standalone TCK failures. The fix will involve replacing references to those properties with properties that Hibernate ORM does not change. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12963) Use maven project.groupId for wildfly-microprofile-jwt-smallrye dependencies

by Yeray Borges (Jira)

Yeray Borges created WFLY-12963: ----------------------------------- Summary: Use maven project.groupId for wildfly-microprofile-jwt-smallrye dependencies Key: WFLY-12963 URL: https://issues.redhat.com/browse/WFLY-12963 Project: WildFly Issue Type: Task Components: Build System Reporter: Yeray Borges Assignee: Yeray Borges The use of maven property ${project.groupid} instead of the hardcoded org.wildfly group id facilitates the transition to the product branches. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4935) Memory leak in PrometheusKieServerExtension

by Karel Suta (Jira)

Karel Suta created DROOLS-4935: ---------------------------------- Summary: Memory leak in PrometheusKieServerExtension Key: DROOLS-4935 URL: https://issues.redhat.com/browse/DROOLS-4935 Project: Drools Issue Type: Bug Components: kie server Affects Versions: 7.31.0.Final Reporter: Karel Suta Assignee: Maciej Swiderski Prometheus Kie server extensions contains support for custom metrics [1]. These metrics are added when a new container is called [2]. However when container is removed then these metrics stay active. Agenda event listener has container instance as a HashMap key. This container instance is quite big, causing memory leak. [1] https://github.com/kiegroup/droolsjbpm-integration/blob/master/kie-server... [2] https://github.com/kiegroup/droolsjbpm-integration/blob/master/kie-server... -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3502) ScoringStrategiesTest, ScorecardProviderTest, ExternalObjectModelTest, ScoreCardProviderPMMLTest, ScoreCardReasonCodeTest fail on Windows

by Jiri Petrlik (Jira)

[ https://issues.redhat.com/browse/DROOLS-3502?page=com.atlassian.jira.plug... ] Jiri Petrlik commented on DROOLS-3502: -------------------------------------- [~gabriolo] Thank you for info! Please keep me updated! > ScoringStrategiesTest, ScorecardProviderTest, ExternalObjectModelTest, ScoreCardProviderPMMLTest, ScoreCardReasonCodeTest fail on Windows > ----------------------------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-3502 > URL: https://issues.redhat.com/browse/DROOLS-3502 > Project: Drools > Issue Type: Bug > Components: PMML > Affects Versions: 7.16.0.Final > Reporter: Tibor Zimanyi > Assignee: Gabriele Cardosi > Priority: Major > > When running mentioned tests on Windows environment, it fails with following output [1]. > [1] https://gist.github.com/baldimir/f93f32a8e3855205433153712cb3baae -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3502) ScoringStrategiesTest, ScorecardProviderTest, ExternalObjectModelTest, ScoreCardProviderPMMLTest, ScoreCardReasonCodeTest fail on Windows

by Gabriele Cardosi (Jira)

[ https://issues.redhat.com/browse/DROOLS-3502?page=com.atlassian.jira.plug... ] Gabriele Cardosi commented on DROOLS-3502: ------------------------------------------ [~jpetrlik] Hi Jiri. I've just been assigned all those tickets. Right now I'm not sure if this will be valid anymore or will be closed/replaced. > ScoringStrategiesTest, ScorecardProviderTest, ExternalObjectModelTest, ScoreCardProviderPMMLTest, ScoreCardReasonCodeTest fail on Windows > ----------------------------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-3502 > URL: https://issues.redhat.com/browse/DROOLS-3502 > Project: Drools > Issue Type: Bug > Components: PMML > Affects Versions: 7.16.0.Final > Reporter: Tibor Zimanyi > Assignee: Gabriele Cardosi > Priority: Major > > When running mentioned tests on Windows environment, it fails with following output [1]. > [1] https://gist.github.com/baldimir/f93f32a8e3855205433153712cb3baae -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12885) Upgrade JSF based on Mojarra 2.3.9.SP05 to ...

by Ilia Vassilev (Jira)

[ https://issues.redhat.com/browse/WFLY-12885?page=com.atlassian.jira.plugi... ] Ilia Vassilev updated WFLY-12885: --------------------------------- Summary: Upgrade JSF based on Mojarra 2.3.9.SP05 to ... (was: Upgrade JSF based on Mojarra 2.3.9.SP05-redhat-00001 to ...) > Upgrade JSF based on Mojarra 2.3.9.SP05 to ... > ---------------------------------------------- > > Key: WFLY-12885 > URL: https://issues.redhat.com/browse/WFLY-12885 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System > Reporter: Ilia Vassilev > Assignee: Farah Juma > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4934) Multistatement support for MVEL Expressions

by Daniele Zonca (Jira)

[ https://issues.redhat.com/browse/DROOLS-4934?page=com.atlassian.jira.plug... ] Daniele Zonca moved BAPL-1510 to DROOLS-4934: --------------------------------------------- Project: Drools (was: Business Automation Planning) Key: DROOLS-4934 (was: BAPL-1510) Workflow: GIT Pull Request workflow (was: CDW with docs v1) QE Status: NEW > Multistatement support for MVEL Expressions > ------------------------------------------- > > Key: DROOLS-4934 > URL: https://issues.redhat.com/browse/DROOLS-4934 > Project: Drools > Issue Type: Bug > Reporter: Yeser Amer > Assignee: Yeser Amer > Priority: Major > Labels: ScenarioSimulation, drools-tools > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12962) Upgrade WildFly Core 11.0.0.Beta7

by Jeff Mesnil (Jira)

Jeff Mesnil created WFLY-12962: ---------------------------------- Summary: Upgrade WildFly Core 11.0.0.Beta7 Key: WFLY-12962 URL: https://issues.redhat.com/browse/WFLY-12962 Project: WildFly Issue Type: Component Upgrade Components: Management Reporter: Jeff Mesnil Assignee: Jeff Mesnil -- 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.Beta8 (was: 11.0.0.Beta7) > 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.Beta8 > > > 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-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.Beta8 (was: 11.0.0.Beta7) > 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.Beta8 > > > 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-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.Beta8 (was: 11.0.0.Beta7) > 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.Beta8 > > > 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-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.Beta8 (was: 11.0.0.Beta7) > 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.Beta8 > > > 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-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.Beta8 (was: 11.0.0.Beta7) > 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.Beta8 > > > 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

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