September 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-3048) [DMN Designer] CellEditorControl needs to issue a new instance per use

by Michael Anstis (JIRA)

Michael Anstis created DROOLS-3048: -------------------------------------- Summary: [DMN Designer] CellEditorControl needs to issue a new instance per use Key: DROOLS-3048 URL: https://issues.jboss.org/browse/DROOLS-3048 Project: Drools Issue Type: Bug Components: DMN Editor Affects Versions: 7.12.0.Final Reporter: Michael Anstis Assignee: Michael Anstis Priority: Critical A {{Popover}} used to edit a cell or column header (or any other DOM-based editor for that matter) disappears following a change in the widget that causes a {{Layer.draw()}} if the grid is sufficiently wide that there is a column not visible on screen. All cells/columns that use {{CellEditorControls}} (containing, for example, the {{Popover}}) share a single instance from {{CellEditorControl}} and hence although the User makes a change in a visible column the invisible column (scrolled off screen) has its DOM resources destroyed that is the same instance as that for the visible column. See https://github.com/kiegroup/appformer/blob/master/uberfire-extensions/ube.... If a column is not in the _body_ or _floating_ columns collection its DOM resources are destroyed. I probably need to ensure different instances of {{CellEditorControl}} are created for each column/cell where we currently share the same instance. Also check for destruction of DOM elements in {{Document}} when grids/columns etc are destroyed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years

1
0
0 / 0

[JBoss JIRA] (WFLY-11085) Upgrade Jboss Metadata to 12.0.0.Final

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFLY-11085?page=com.atlassian.jira.plugin... ] ehsavoie Hugonnet updated WFLY-11085: ------------------------------------- Component/s: EE > Upgrade Jboss Metadata to 12.0.0.Final > --------------------------------------- > > Key: WFLY-11085 > URL: https://issues.jboss.org/browse/WFLY-11085 > Project: WildFly > Issue Type: Component Upgrade > Components: EE, EJB, Web (Undertow) > Affects Versions: 14.0.0.Final > Reporter: ehsavoie Hugonnet > Assignee: ehsavoie Hugonnet > > Upgrade Jboss Metadata to 12.0.0.Final (with the JavaEE 8 schemas and jboss descriptors using them) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years

1
0
0 / 0

[JBoss JIRA] (WFLY-11087) Upgrade Jboss Metadata to 12.0.0.Final

by ehsavoie Hugonnet (JIRA)

ehsavoie Hugonnet created WFLY-11087: ---------------------------------------- Summary: Upgrade Jboss Metadata to 12.0.0.Final Key: WFLY-11087 URL: https://issues.jboss.org/browse/WFLY-11087 Project: WildFly Issue Type: Component Upgrade Components: EJB, Web (Undertow) Affects Versions: 14.0.0.Final Reporter: ehsavoie Hugonnet Assignee: ehsavoie Hugonnet Upgrade Jboss Metadata to 12.0.0.Final (with the JavaEE 8 schemas and jboss descriptors using them) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years

1
0
0 / 0

[JBoss JIRA] (WFLY-9455) WFLYTX0001: Unable to roll back active transaction thrown for EJB bridge transactions

by Ondra Chaloupka (JIRA)

[ https://issues.jboss.org/browse/WFLY-9455?page=com.atlassian.jira.plugin.... ] Ondra Chaloupka commented on WFLY-9455: --------------------------------------- After some investigation on the WFLY-9588 I consider the XTS module being the right place for adding the ws txn bridge txn suspend filter. See PR: https://github.com/wildfly/wildfly/pull/11702 Could be tested by running the XTS integration testsuite: {{./integration-tests.sh clean install -Dts.noSmoke -Dts.xts -Djboss.dist=$JBOSS_HOME -Dtest=TransactionalTestCase}}. When fix is not applied the log contains the reported error messages. > WFLYTX0001: Unable to roll back active transaction thrown for EJB bridge transactions > ------------------------------------------------------------------------------------- > > Key: WFLY-9455 > URL: https://issues.jboss.org/browse/WFLY-9455 > Project: WildFly > Issue Type: Bug > Components: XTS > Affects Versions: 11.0.0.CR1 > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > It happens to get exception > {code} > ERROR [org.jboss.as.txn] (default task-12) WFLYTX0003: APPLICATION ERROR: transaction still active in request with status 0 > ERROR [org.jboss.as.txn] (default task-12) WFLYTX0001: Unable to roll back active transaction: javax.transaction.SystemException: WFTXN0032: Rollback not allowed on imported transaction > at org.wildfly.transaction.client.LocalTransaction.rollbackAndDissociate(LocalTransaction.java:100) > at org.wildfly.transaction.client.ContextTransactionManager.rollback(ContextTransactionManager.java:83) > at org.jboss.as.txn.deployment.TransactionRollbackSetupAction.checkTransactionStatus(TransactionRollbackSetupAction.java:137) > at org.jboss.as.txn.deployment.TransactionRollbackSetupAction.teardown(TransactionRollbackSetupAction.java:67) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1510) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) > at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > {code} > when using XTS transactions bridged to JTA for EJB handling. This happens on change of integration layer for WFTC in WFLY11. > The integration issues were already discussed as part of the JBTM-2853. > Here I hit a trouble of having log filled with the exception mentioned above. This does not cause a functionality trouble but the log is ugly filled with ERRORs. > The trouble seems to be caused by the fact that transaction is imported on ivocation of WS > https://github.com/wildfly/wildfly/blob/master/webservices/server-integra... > but as it was suspended in the integration code before > https://github.com/jbosstm/narayana/blob/master/txbridge/src/main/java/or... > now the WFTC holds the notion about the transaction even on call of > https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... > and such transaction is tried to be rollback which is forbidden on WFTC for imported ones and thus at least ERROR msg is written to the log. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years

1
0
0 / 0

[JBoss JIRA] (SWSQE-440) Create a Istio Cleanup Job

by Guilherme Baufaker Rêgo (JIRA)

[ https://issues.jboss.org/browse/SWSQE-440?page=com.atlassian.jira.plugin.... ] Guilherme Baufaker Rêgo resolved SWSQE-440. ------------------------------------------- Resolution: Done > Create a Istio Cleanup Job > -------------------------- > > Key: SWSQE-440 > URL: https://issues.jboss.org/browse/SWSQE-440 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Guilherme Baufaker Rêgo > Assignee: Guilherme Baufaker Rêgo > > This Job will handle all the deletion that needs to be done before installing/reinstalling istio -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years

1
0
0 / 0

[JBoss JIRA] (WFLY-11086) Usage of static fields from java.lang classes as EL expressions in JSPs doesn't work when requested more than once

by Adam Krajcik (JIRA)

[ https://issues.jboss.org/browse/WFLY-11086?page=com.atlassian.jira.plugin... ] Adam Krajcik commented on WFLY-11086: ------------------------------------- Commit with updated test for Wildfly TS can be found here: https://github.com/AdamKrajcik/wildfly/commit/2f459d1e54ae000c9f1ee550a4c... > Usage of static fields from java.lang classes as EL expressions in JSPs doesn't work when requested more than once > ------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-11086 > URL: https://issues.jboss.org/browse/WFLY-11086 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 14.0.0.Final > Reporter: Adam Krajcik > Assignee: Stuart Douglas > Attachments: jsp-expression-lang.war > > > Java EE7 (which supports EL 3.0 spec) allows JSPs to use EL expressions like: > {code} > <html> > <body> > foo: --- ${Boolean.TRUE} ---<br> > bar: --- ${Integer.MAX_VALUE} ---<br> > </body> > </html> > {code} > However, the > {code} > ${Boolean.TRUE} > {code} > and > {code} > ${Integer.MAX_VALUE} > {code} > in the above example aren't evaluated correctly if request is send more than once, and instead a blank string is rendered for them. The [^jsp-expression-lang.war] used in Steps to reproduce works correctly in 7.2.0.CD13. > More details in the linked forum thread https://developer.jboss.org/thread/271825. > The existing tests([JspELTestCase|https://github.com/wildfly/wildfly/blob/master/tests... doesn't cover the situation when request is sent more than once. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years

1
0
0 / 0

[JBoss JIRA] (ELYWEB-24) Flip the default behaviour so JASPI is enabled by default.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELYWEB-24?page=com.atlassian.jira.plugin.... ] Darran Lofthouse resolved ELYWEB-24. ------------------------------------ Resolution: Done > Flip the default behaviour so JASPI is enabled by default. > ---------------------------------------------------------- > > Key: ELYWEB-24 > URL: https://issues.jboss.org/browse/ELYWEB-24 > Project: Elytron Web > Issue Type: Task > Components: Undertow Servlet > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.3.0.CR3 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years

1
0
0 / 0

[JBoss JIRA] (ELYWEB-24) Flip the default behaviour so JASPI is enabled by default.

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELYWEB-24: -------------------------------------- Summary: Flip the default behaviour so JASPI is enabled by default. Key: ELYWEB-24 URL: https://issues.jboss.org/browse/ELYWEB-24 Project: Elytron Web Issue Type: Task Components: Undertow Servlet Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.3.0.CR3 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years

1
0
0 / 0

[JBoss JIRA] (DROOLS-3000) Enhance data type restrictions UX (decision tables & DT dialog)

by Liz Clayton (JIRA)

[ https://issues.jboss.org/browse/DROOLS-3000?page=com.atlassian.jira.plugi... ] Liz Clayton commented on DROOLS-3000: ------------------------------------- [~cristiano.nicolai] Yes, I agree it would be good to be consistent with what we already have. Would the code be something that [~karreiro] could pick-up and reuse? > Enhance data type restrictions UX (decision tables & DT dialog) > --------------------------------------------------------------- > > Key: DROOLS-3000 > URL: https://issues.jboss.org/browse/DROOLS-3000 > Project: Drools > Issue Type: Story > Components: DMN Editor > Reporter: Liz Clayton > Assignee: Liz Clayton > Labels: UX, UXTeam, drools-tools > Attachments: DataType selection ('Properties Panel' and 'in-grid').png, Screen Shot 2018-08-10 at 10.23.36 AM.png, Screen Shot 2018-08-24 at 8.38.37 AM.png, Screen Shot 2018-09-26 at 1.24.06 PM.png, Screen Shot 2018-09-26 at 4.48.04 PM.png, Screen Shot 2018-09-26 at 4.52.47 PM.png, pop-overc.png, pop-overcSpecs.png, select.png > > > *Background* > Persona: Business analyst or Rules practitioner > Use Cases: > * From the DMN canvas view - as a user I want to define data type restrictions (one-off instances) from a decision table . > * From the Data Types dialog - as a user I want the ability to define constraints for the following types: https://docs.google.com/spreadsheets/d/1HLYwi5JrCEU6IxWRge7RCKANLiHCL0d2E... > Functional considerations/ pre conditions: > * Consider interaction in light of Property panel and consistency. > * Underscore the notion of one-off constraints. > Verification conditions: > * Scrum team and PO review. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years

1
0
0 / 0

[JBoss JIRA] (WFLY-11086) Usage of static fields from java.lang classes as EL expressions in JSPs doesn't work when requested more than once

by Adam Krajcik (JIRA)

[ https://issues.jboss.org/browse/WFLY-11086?page=com.atlassian.jira.plugin... ] Adam Krajcik moved JBEAP-15541 to WFLY-11086: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-11086 (was: JBEAP-15541) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Web (Undertow) (was: Web (Undertow)) Affects Version/s: 14.0.0.Final (was: 7.2.0.CD14) > Usage of static fields from java.lang classes as EL expressions in JSPs doesn't work when requested more than once > ------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-11086 > URL: https://issues.jboss.org/browse/WFLY-11086 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 14.0.0.Final > Reporter: Adam Krajcik > Assignee: Stuart Douglas > Attachments: jsp-expression-lang.war > > > Java EE7 (which supports EL 3.0 spec) allows JSPs to use EL expressions like: > {code} > <html> > <body> > foo: --- ${Boolean.TRUE} ---<br> > bar: --- ${Integer.MAX_VALUE} ---<br> > </body> > </html> > {code} > However, the > {code} > ${Boolean.TRUE} > {code} > and > {code} > ${Integer.MAX_VALUE} > {code} > in the above example aren't evaluated correctly if request is send more than once, and instead a blank string is rendered for them. The [^jsp-expression-lang.war] used in Steps to reproduce works correctly in 7.2.0.CD13. > More details in the linked forum thread https://developer.jboss.org/thread/271825. > The existing tests([JspELTestCase|https://github.com/wildfly/wildfly/blob/master/tests... doesn't cover the situation when request is sent more than once. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2018