June 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12191) StackOverflowError is thrown when invoking a REST end-point, with ClientRequestFilter/ClientResponseFilter registered

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12191?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFLY-12191: ----------------------------------------- [~asoldano] [~ron_sigal] I attached as zip that packages up the two classes from [~dwuysan] into a maven project. Zip includes a built war, the maven project and a server.log when I executed http://localhost:8080/playground-webapplication/rest/batch/test. One time I executed it I got a StackOverflowError; in the one attached it was an OOME. The cycle is this: {code} at org.jboss.playground.Authenticator.filter(Authenticator.java:56) at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.filterRequest(ClientInvocation.java:590) at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.invoke(ClientInvocation.java:440) at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation.invoke(ClientInvocation.java:62) at org.jboss.resteasy.client.jaxrs.internal.ClientInvocationBuilder.method(ClientInvocationBuilder.java:297) at org.jboss.playground.Authenticator.filter(Authenticator.java:56) {code} With WildFly 16 this doesn't happen. With 16 the request fails as well, but that's just because the test app is making a REST invocation against a non-existent dummy URL. > StackOverflowError is thrown when invoking a REST end-point, with ClientRequestFilter/ClientResponseFilter registered > --------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-12191 > URL: https://issues.jboss.org/browse/WFLY-12191 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 17.0.0.Final > Environment: Fedora 30, Oracle JDK 1.8.0_181 > Reporter: Deny Wuysan > Assignee: Alessio Soldano > Priority: Major > Attachments: Authenticator.java, BatchManager.java, WFLY-12191.zip > > > Please find attached the two Java files corresponding to the error. When setting debugger on line 50 for Authenticator.java, notice repetitive calls occurred, ONLY on Wildfly 17.0.0.Final. > Have re-tested this case on Wildfly 16.0.0.Final and the REST call made successfully. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12191) StackOverflowError is thrown when invoking a REST end-point, with ClientRequestFilter/ClientResponseFilter registered

by Brian Stansberry (Jira)

[ https://issues.jboss.org/browse/WFLY-12191?page=com.atlassian.jira.plugin... ] Brian Stansberry updated WFLY-12191: ------------------------------------ Attachment: WFLY-12191.zip > StackOverflowError is thrown when invoking a REST end-point, with ClientRequestFilter/ClientResponseFilter registered > --------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-12191 > URL: https://issues.jboss.org/browse/WFLY-12191 > Project: WildFly > Issue Type: Bug > Components: REST > Affects Versions: 17.0.0.Final > Environment: Fedora 30, Oracle JDK 1.8.0_181 > Reporter: Deny Wuysan > Assignee: Alessio Soldano > Priority: Major > Attachments: Authenticator.java, BatchManager.java, WFLY-12191.zip > > > Please find attached the two Java files corresponding to the error. When setting debugger on line 50 for Authenticator.java, notice repetitive calls occurred, ONLY on Wildfly 17.0.0.Final. > Have re-tested this case on Wildfly 16.0.0.Final and the REST call made successfully. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4190) Port MVEL compiler to Kogito

by Luca Molteni (Jira)

Luca Molteni created DROOLS-4190: ------------------------------------ Summary: Port MVEL compiler to Kogito Key: DROOLS-4190 URL: https://issues.jboss.org/browse/DROOLS-4190 Project: Drools Issue Type: Enhancement Reporter: Luca Molteni Assignee: Mario Fusco -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3819) Rule Units 2.0: evaluate 7.x behavior and consider new design

by Edoardo Vacchi (Jira)

[ https://issues.jboss.org/browse/DROOLS-3819?page=com.atlassian.jira.plugi... ] Edoardo Vacchi commented on DROOLS-3819: ---------------------------------------- consider writing a blog post for community feedback > Rule Units 2.0: evaluate 7.x behavior and consider new design > ------------------------------------------------------------- > > Key: DROOLS-3819 > URL: https://issues.jboss.org/browse/DROOLS-3819 > Project: Drools > Issue Type: Task > Reporter: Edoardo Vacchi > Assignee: Edoardo Vacchi > Priority: Major > Labels: drools-core, submarine > Fix For: 8.0.0.Final > > > I have disabled generation of `unit()` API invocation on DRL compiler in order to make the Unit prototype work quickly. We are now assuming that 1 unit === 1 session, therefore some previous assumptions do not hold anymore. Previous assertions are therefore broken. It is also a good time to re-evaluate some previous considerations on how rule units are supposed to work (e.g. reconsider how guards work etc) > *Deliverable*: PR and (if possible) design document -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4185) KieBuilder incremental compilation does not return Warns, infos

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-4185?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-4185: -------------------------------- Sprint: 2019 Week 23-25 > KieBuilder incremental compilation does not return Warns, infos > --------------------------------------------------------------- > > Key: DROOLS-4185 > URL: https://issues.jboss.org/browse/DROOLS-4185 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Matteo Mortari > Assignee: Mario Fusco > Priority: Major > > Compiling with something like > {code:java} > final KieAssemblersImpl assemblers = (KieAssemblersImpl) ServiceRegistry.getInstance().get(KieAssemblers.class); > assemblers.accept(new DMNAssemblerService()); > KieServices ks = KieServices.Factory.get(); > KieFileSystem kfs = ks.newKieFileSystem(); > kfs.write("src/main/resources/org/acme/test_scorecard.pmml", ks.getResources().newClassPathResource("test_scorecard.pmml", DMNRuntimeKiePMMLTest.class)); > KieBuilder kieBuilder = ks.newKieBuilder(kfs).buildAll(); > assertEquals(0, kieBuilder.getResults().getMessages(org.kie.api.builder.Message.Level.ERROR).size()); > kfs.write("src/main/resources/org/acme/KiePMMLScoreCard_NOPMMLmodelName.dmn", ks.getResources().newClassPathResource("KiePMMLScoreCard_NOPMMLmodelName.dmn", DMNRuntimeKiePMMLTest.class)); > IncrementalResults addResults = ((InternalKieBuilder) kieBuilder).createFileSet("src/main/resources/org/acme/KiePMMLScoreCard_NOPMMLmodelName.dmn").build(); > LOG.debug("getAddedMessages: {}", addResults.getAddedMessages()); > assertTrue(addResults.getAddedMessages().size() > 0); > {code} > would fail on the last assertion, as the WARN message is effectively generated as part of the build, but is not available in returned the list. > A full reproducer can be found with this PR: > https://github.com/kiegroup/drools/pull/2389 > Suggestion: parametrize InternalKieBuilder#build to also return list of Warn or Info, besides of just returning list of errors? > More suggestions here: https://github.com/kiegroup/drools/pull/2389#discussion_r294185056 -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1797) Make the certificate authority used by a certificate-authority-account configurable

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1797?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-1797: ---------------------------- Fix Version/s: 1.10.0.CR1 > Make the certificate authority used by a certificate-authority-account configurable > ----------------------------------------------------------------------------------- > > Key: ELY-1797 > URL: https://issues.jboss.org/browse/ELY-1797 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Certificate Authority > Reporter: Diana Vilkolakova > Assignee: Diana Vilkolakova > Priority: Major > Fix For: 1.10.0.CR1 > > > Currently, Let's Encrypt (https://acme-v02.api.letsencrypt.org/directory) is the only certificate authority that can be used by a certificate-authority-account. In the future, if/when other certificate authorities implement the server side of the ACME protocol, this will need to be configurable. In addition, making this configurable would also allow local Let's Encrypt server instances to be used for testing purposes. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1777) Add version 1.4 of the Elytron client schema

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1777?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-1777: ---------------------------- Fix Version/s: 1.10.0.CR1 > Add version 1.4 of the Elytron client schema > -------------------------------------------- > > Key: ELY-1777 > URL: https://issues.jboss.org/browse/ELY-1777 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Client > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 1.10.0.CR1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1818) Don't use a lambda for the disposal of mechanisms in forEach

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1818?page=com.atlassian.jira.plugin.s... ] Farah Juma resolved ELY-1818. ----------------------------- Resolution: Done > Don't use a lambda for the disposal of mechanisms in forEach > ------------------------------------------------------------ > > Key: ELY-1818 > URL: https://issues.jboss.org/browse/ELY-1818 > Project: WildFly Elytron > Issue Type: Bug > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 1.10.0.CR1 > > > A simple for loop will be sufficient without needing a lambda defining and instantiating. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1820) SecurityProviderServerMechanismFactory should support Provider instances

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1820?page=com.atlassian.jira.plugin.s... ] Farah Juma resolved ELY-1820. ----------------------------- Resolution: Done > SecurityProviderServerMechanismFactory should support Provider instances > ------------------------------------------------------------------------ > > Key: ELY-1820 > URL: https://issues.jboss.org/browse/ELY-1820 > Project: WildFly Elytron > Issue Type: Bug > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 1.10.0.CR1 > > > In many cases we already have the Provider instance or instances, we should not require an intermediate Supplier instance which encourages the use of a lambda just to pass these in. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1823) Update SecurityProviderServerMechanismFactory to cache Provider interaction.

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1823?page=com.atlassian.jira.plugin.s... ] Farah Juma resolved ELY-1823. ----------------------------- Resolution: Done > Update SecurityProviderServerMechanismFactory to cache Provider interaction. > ---------------------------------------------------------------------------- > > Key: ELY-1823 > URL: https://issues.jboss.org/browse/ELY-1823 > Project: WildFly Elytron > Issue Type: Enhancement > Components: HTTP > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Major > Fix For: 1.10.0.CR1 > > > The SecurityProviderServerMechanismFactory regularly interacts with the Provider which can cause contention as calls to getServices() and getService(S,S) are synchronized. > Runtime updates are not actually expected so we should cache the interactions. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 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 June 2019