June 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELYWEB-62) Release Elytron Web 1.6.0.CR1

by Farah Juma (Jira)

Farah Juma created ELYWEB-62: -------------------------------- Summary: Release Elytron Web 1.6.0.CR1 Key: ELYWEB-62 URL: https://issues.jboss.org/browse/ELYWEB-62 Project: Elytron Web Issue Type: Release Reporter: Farah Juma Assignee: Farah Juma Fix For: 1.6.0.CR1 -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELYWEB-61) Upgrade WildFly Elytron to 1.10.0.CR1

by Farah Juma (Jira)

Farah Juma created ELYWEB-61: -------------------------------- Summary: Upgrade WildFly Elytron to 1.10.0.CR1 Key: ELYWEB-61 URL: https://issues.jboss.org/browse/ELYWEB-61 Project: Elytron Web Issue Type: Release Reporter: Farah Juma Assignee: Farah Juma -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELYWEB-61) Upgrade WildFly Elytron to 1.10.0.CR1

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELYWEB-61?page=com.atlassian.jira.plugin.... ] Farah Juma updated ELYWEB-61: ----------------------------- Fix Version/s: 1.6.0.CR1 > Upgrade WildFly Elytron to 1.10.0.CR1 > ------------------------------------- > > Key: ELYWEB-61 > URL: https://issues.jboss.org/browse/ELYWEB-61 > Project: Elytron Web > Issue Type: Release > Reporter: Farah Juma > Assignee: Farah Juma > Priority: Major > Fix For: 1.6.0.CR1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1828) Release WildFly Elytron 1.10.0.CR1

by Farah Juma (Jira)

Farah Juma created ELY-1828: ------------------------------- Summary: Release WildFly Elytron 1.10.0.CR1 Key: ELY-1828 URL: https://issues.jboss.org/browse/ELY-1828 Project: WildFly Elytron Issue Type: Release Reporter: Farah Juma Assignee: Farah Juma 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] (WFLY-12201) Upgrade Undertow version to 2.0.20.Final in UndertowTransformersTestCase

by Flavia Rainone (Jira)

Flavia Rainone created WFLY-12201: ------------------------------------- Summary: Upgrade Undertow version to 2.0.20.Final in UndertowTransformersTestCase Key: WFLY-12201 URL: https://issues.jboss.org/browse/WFLY-12201 Project: WildFly Issue Type: Task Components: Web (Undertow) Reporter: Flavia Rainone Assignee: Flavia Rainone The test case needs to be updated so that the test suite runs okay with Undertow 2.0.20.Final -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4042) [DMN Designer] Add support for importing and consuming PMML models 7.5

by Michael Anstis (Jira)

[ https://issues.jboss.org/browse/DROOLS-4042?page=com.atlassian.jira.plugi... ] Michael Anstis edited comment on DROOLS-4042 at 6/17/19 3:57 PM: ----------------------------------------------------------------- [~tirelli] [~jomarko] {quote} if the PMML file contains no "named" model (only an anonymous one), the UI should indicate that this model is being used (how to indicate that I leave to UX, but we can call it "default model" or whatever). {quote} We don't do this at present and it should probably be a new JIRA (in the name of agility). [~tirelli] {quote} is it possible to automatically update the document attribute on function definitions when a PMML model is renamed? {quote} I'd just like to clarify as your question is a little ambiguous, there is a mechanism to update files in the WB when another is saved/renamed/deleted etc in the workbench already. So, when the PMML file (*document*) is renamed we can look for DMN models referencing the PMML *document* and update the field. What is more difficult (more expensive operation) is to scan DMN models and update the PMML *model* when the _content_ of the PMML _document_ changes and PMML *models* renamed. Which did you want? A new JIRA would be raised for this too. was (Author: manstis): [~tirelli] [~jomarko] {quote} if the PMML file contains no "named" model (only an anonymous one), the UI should indicate that this model is being used (how to indicate that I leave to UX, but we can call it "default model" or whatever). {quote} We don't do this at present and it should probably be a new JIRA (in the name of agility). [~tirelli] {quote} is it possible to automatically update the document attribute on function definitions when a PMML model is renamed? {quote} I'd just like to clarify as your question is a little ambiguous, there is a mechanism to update files in the WB when another is saved/renamed/deleted etc in the workbench already. So, when the PMML file (*document*) is renamed we can look for DMN models referencing the PMML *document* and update the field. What is more difficult (more expensive operation) is to scan DMN models and update the PMML *model* when the _content_ of the PMML _document_ changes and PMML *models* renamed. Which did you want? A new JIRA would be raised for this too. > [DMN Designer] Add support for importing and consuming PMML models 7.5 > ---------------------------------------------------------------------- > > Key: DROOLS-4042 > URL: https://issues.jboss.org/browse/DROOLS-4042 > Project: Drools > Issue Type: Epic > Components: DMN Editor > Affects Versions: 7.24.0.Final > Reporter: Michael Anstis > Assignee: Michael Anstis > Priority: Critical > Labels: drools-tools > > We need the ability to import PMML _documents_. This should be via the "Imported models" tab. Once a _document_ has been imported (and an alias assigned) selection of the _document_ and a _model_ held therein should be possible via the PMML Function boxed expression editor. > h2. Requirement > - As user, via included models tab, remove included pmml model, even if used somewhere > - As user, via included models tab, rename included pmml model, even if used somewhere > - As user, via included models tab, include multiple pmml models > - As user, via included models tab, include multiple pmml models at the same time eternal dmn > - As user, via included models tab, include multiple pmml models at the same time external dmn, kinds are visually distinguished > - As user, via dmn designer, if Document or Model of included pmml was changed, the lisboxes in dmn offers new values > - As user, via included models tab, no restriction for included pmml model name > - As user, via new test scenarios, test dmn model that uses pmml inside > - As user, via kie-server, query kie container that has dmn model with pmml > h2. UX design > - Selectbox in place of Document and Model selection > h2. Documentation > - Mention what pmml model can be imported into dmn > - Mention where it can be used > - Mention if something more needed to dpeloy such project on kie server > h2. Acceptance test > - Include two pmml models > - In dmn, select one in function grid > - Change the selected one to second > - Finish the dmn model > - build deploy on kie-server > - Interact with kie container via rest > - Create new test scenario for created dmn model -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4042) [DMN Designer] Add support for importing and consuming PMML models 7.5

by Michael Anstis (Jira)

[ https://issues.jboss.org/browse/DROOLS-4042?page=com.atlassian.jira.plugi... ] Michael Anstis commented on DROOLS-4042: ---------------------------------------- [~tirelli] [~jomarko] {quote} if the PMML file contains no "named" model (only an anonymous one), the UI should indicate that this model is being used (how to indicate that I leave to UX, but we can call it "default model" or whatever). {quote} We don't do this at present and it should probably be a new JIRA (in the name of agility). [~tirelli] {quote} is it possible to automatically update the document attribute on function definitions when a PMML model is renamed? {quote} I'd just like to clarify as your question is a little ambiguous, there is a mechanism to update files in the WB when another is saved/renamed/deleted etc in the workbench already. So, when the PMML file (*document*) is renamed we can look for DMN models referencing the PMML *document* and update the field. What is more difficult (more expensive operation) is to scan DMN models and update the PMML *model* when the _content_ of the PMML _document_ changes and PMML *models* renamed. Which did you want? A new JIRA would be raised for this too. > [DMN Designer] Add support for importing and consuming PMML models 7.5 > ---------------------------------------------------------------------- > > Key: DROOLS-4042 > URL: https://issues.jboss.org/browse/DROOLS-4042 > Project: Drools > Issue Type: Epic > Components: DMN Editor > Affects Versions: 7.24.0.Final > Reporter: Michael Anstis > Assignee: Michael Anstis > Priority: Critical > Labels: drools-tools > > We need the ability to import PMML _documents_. This should be via the "Imported models" tab. Once a _document_ has been imported (and an alias assigned) selection of the _document_ and a _model_ held therein should be possible via the PMML Function boxed expression editor. > h2. Requirement > - As user, via included models tab, remove included pmml model, even if used somewhere > - As user, via included models tab, rename included pmml model, even if used somewhere > - As user, via included models tab, include multiple pmml models > - As user, via included models tab, include multiple pmml models at the same time eternal dmn > - As user, via included models tab, include multiple pmml models at the same time external dmn, kinds are visually distinguished > - As user, via dmn designer, if Document or Model of included pmml was changed, the lisboxes in dmn offers new values > - As user, via included models tab, no restriction for included pmml model name > - As user, via new test scenarios, test dmn model that uses pmml inside > - As user, via kie-server, query kie container that has dmn model with pmml > h2. UX design > - Selectbox in place of Document and Model selection > h2. Documentation > - Mention what pmml model can be imported into dmn > - Mention where it can be used > - Mention if something more needed to dpeloy such project on kie server > h2. Acceptance test > - Include two pmml models > - In dmn, select one in function grid > - Change the selected one to second > - Finish the dmn model > - build deploy on kie-server > - Interact with kie container via rest > - Create new test scenario for created dmn model -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4191) Finalize merging of Quarkus extension for Kogito

by Mario Fusco (Jira)

Mario Fusco created DROOLS-4191: ----------------------------------- Summary: Finalize merging of Quarkus extension for Kogito Key: DROOLS-4191 URL: https://issues.jboss.org/browse/DROOLS-4191 Project: Drools Issue Type: Task Components: core engine Reporter: Mario Fusco Assignee: Mario Fusco -- 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 Alessio Soldano (Jira)

[ https://issues.jboss.org/browse/WFLY-12191?page=com.atlassian.jira.plugin... ] Alessio Soldano commented on WFLY-12191: ---------------------------------------- Hi [~dwuysan] and [~brian.stansberry], I haven't tried this, but I suspect it could be related to https://issues.jboss.org/browse/RESTEASY-2084. Basically, we were not automatically registering @Provider annotated filters before; here the client request filter is automatically registered when building up any client and it creates and uses a new client in its filter() method, which seems to result in the loop. We'll investigate this properly, but perhaps you can work around this in your Authenticator code (in a custom way checking if you've been called already for the current request or having the client filter registered programmatically in the client where needed instead of annotating if with @Provider). > 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 edited comment on WFLY-12191 at 6/17/19 10:54 AM: ------------------------------------------------------------------- [~asoldano] [~ron_sigal] I attached a 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 due to exceeded gc limit. Both are manifestations of the same basic issue. 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. was (Author: brian.stansberry): [~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

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