June 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-2993) Can't enable reason code in the guided scorecard

by Ein Verne (Jira)

[ https://issues.redhat.com/browse/DROOLS-2993?page=com.atlassian.jira.plug... ] Ein Verne commented on DROOLS-2993: ----------------------------------- He defined a class Called Applicable, but when import the Object in guided scorecard in KIE workbench, still cannot use the reasons field. {code:java} public class Applicable implements java.io.Serializable { static final long serialVersionUID = 1L; private java.lang.Long id; private java.lang.Double age; private java.util.List<java.lang.String> reasons; private java.lang.Double score; {code} > Can't enable reason code in the guided scorecard > ------------------------------------------------ > > Key: DROOLS-2993 > URL: https://issues.redhat.com/browse/DROOLS-2993 > Project: Drools > Issue Type: Bug > Components: Guided Score Card Editor > Affects Versions: 7.11.0.Final > Environment: All in one jbpm server > Reporter: yi gong > Assignee: Toni Rikkola > Priority: Blocker > Attachments: sandbox1.zip > > > Can't enable the reason code in the guided scorecard editor even the data object has a filed which is string list. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13515) Application does not fail when @Singleton @PostConstruct throws exception

by Ilia Vassilev (Jira)

[ https://issues.redhat.com/browse/WFLY-13515?page=com.atlassian.jira.plugi... ] Ilia Vassilev updated WFLY-13515: --------------------------------- Labels: Regression downstream_dependency (was: Regression) > Application does not fail when @Singleton @PostConstruct throws exception > ------------------------------------------------------------------------- > > Key: WFLY-13515 > URL: https://issues.redhat.com/browse/WFLY-13515 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 19.0.0.Final, 20.0.0.Beta1 > Reporter: Cheng Fang > Assignee: Panagiotis Sotiropoulos > Priority: Major > Labels: Regression, downstream_dependency > Attachments: helloWorld.ear > > > In EAP 6.4 , sub deployments were accessible before all Singleton's PostConstruct were finished, this was fixed via [1]. After this fix if an exception was thrown from PostConstruct, then the whole deployment was in a failed state as well. EAP 7.0 works the same as EAP 6.4 after the fix. > In EAP 7.3/7.2/7.1 when the Singleton throws an exception, the sub deployments are accessible. > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1310908 > EJB 3.1 spec, section 4.8.1: > {quote} > If the Startup annotation appears on the Singleton bean class or if the Singleton has been designated via the deployment descriptor as requiring eager initialization, the container must initialize the Singleton bean instance during the application startup sequence. The container must initialize all such startup-time Singletons before any external client requests (that is, client requests originating outside of the application) are delivered to any enterprise bean components in the application. > {quote} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13571) JSF: selectOneMenu required+disabled true

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/WFLY-13571?page=com.atlassian.jira.plugi... ] Farah Juma commented on WFLY-13571: ----------------------------------- [~soul2zimate] Would you be able to take a look at the NPE that [~clerum] mentioned to see if it's related to the fix for WFLY-13497 as well and if your PR covers this or if more work is needed? > JSF: selectOneMenu required+disabled true > ----------------------------------------- > > Key: WFLY-13571 > URL: https://issues.redhat.com/browse/WFLY-13571 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 20.0.0.Final > Reporter: erick leal > Assignee: Farah Juma > Priority: Major > Attachments: project.zip > > > Submitin selectOneMenu required=true+disabled=true result in validation error message. > Regression in WildFly 20, clicking button fires a message. > WildFly 19 it's ok. > Mojarra issue: https://github.com/eclipse-ee4j/mojarra/issues/4716 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13587) Smallrye OpenAPI throws java.lang.NullPointerException because of null parameter schema

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13587?page=com.atlassian.jira.plugi... ] Paul Ferraro moved JBEAP-19684 to WFLY-13587: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-13587 (was: JBEAP-19684) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: MP OpenAPI (was: MP OpenAPI) Affects Version/s: 20.0.0.Final (was: EAP-XP-1.0.0.GA-CR1) (was: EAP-XP-1.0.0.GA-CR2) > Smallrye OpenAPI throws java.lang.NullPointerException because of null parameter schema > --------------------------------------------------------------------------------------- > > Key: WFLY-13587 > URL: https://issues.redhat.com/browse/WFLY-13587 > Project: WildFly > Issue Type: Bug > Components: MP OpenAPI > Affects Versions: 20.0.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > This was spotted while running RESTEasy test suite against EAP XP 1.0.0 CR1 and CR2. > Initially it seemed that the specific test case [1] was failing due to the same root cause of those tracked by the following issue: > * https://issues.redhat.com/browse/JBEAP-19600 > > Eventually it turned out that the changes to fix the above mentioned issue didn't solve this specific test case failures and a deeper investigation was done, see [2]. > Specifically a strange behavior is represented by the fact that the reproducer built manually by using the same resources used by the test case could be deployed successfully while the WAR archive generated by Arquillian in the RESTEasy TS was failing to deploy regularly. > The investigation detailed at https://github.com/smallrye/smallrye-open-api/issues/353#issuecomment-639... provided evidence that there are some cases in which the parameter schema would be set to null, so the issue [2] was created upstream. > [1] > https://github.com/resteasy/Resteasy/blob/3.11/testsuite/integration-test... > [2] > https://github.com/smallrye/smallrye-open-api/issues/359 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13571) JSF: selectOneMenu required+disabled true

by Cody Lerum (Jira)

[ https://issues.redhat.com/browse/WFLY-13571?page=com.atlassian.jira.plugi... ] Cody Lerum commented on WFLY-13571: ----------------------------------- [~fjuma] do you want a different issue for the NPE on submit of disabled checkbox? Repo project is here [https://github.com/codylerum/jsf-disabled-input] > JSF: selectOneMenu required+disabled true > ----------------------------------------- > > Key: WFLY-13571 > URL: https://issues.redhat.com/browse/WFLY-13571 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 20.0.0.Final > Reporter: erick leal > Assignee: Farah Juma > Priority: Major > Attachments: project.zip > > > Submitin selectOneMenu required=true+disabled=true result in validation error message. > Regression in WildFly 20, clicking button fires a message. > WildFly 19 it's ok. > Mojarra issue: https://github.com/eclipse-ee4j/mojarra/issues/4716 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13571) JSF: selectOneMenu required+disabled true

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/WFLY-13571?page=com.atlassian.jira.plugi... ] Farah Juma commented on WFLY-13571: ----------------------------------- Just FYI, [~soul2zimate] has submitted a fix upstream, we are trying to get some feedback from the upstream reviewers: [https://github.com/eclipse-ee4j/mojarra/pull/4717] > JSF: selectOneMenu required+disabled true > ----------------------------------------- > > Key: WFLY-13571 > URL: https://issues.redhat.com/browse/WFLY-13571 > Project: WildFly > Issue Type: Bug > Components: JSF > Affects Versions: 20.0.0.Final > Reporter: erick leal > Assignee: Farah Juma > Priority: Major > Attachments: project.zip > > > Submitin selectOneMenu required=true+disabled=true result in validation error message. > Regression in WildFly 20, clicking button fires a message. > WildFly 19 it's ok. > Mojarra issue: https://github.com/eclipse-ee4j/mojarra/issues/4716 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13566) Ensure that Jandex indexes are released from JPA deployment memory after deployment completes

by Ilia Vassilev (Jira)

[ https://issues.redhat.com/browse/WFLY-13566?page=com.atlassian.jira.plugi... ] Ilia Vassilev updated WFLY-13566: --------------------------------- Labels: downstream_dependency (was: ) > Ensure that Jandex indexes are released from JPA deployment memory after deployment completes > --------------------------------------------------------------------------------------------- > > Key: WFLY-13566 > URL: https://issues.redhat.com/browse/WFLY-13566 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: JBoss AS7 7.2.0.Final > Reporter: Scott Marlow > Assignee: Scott Marlow > Priority: Major > Labels: downstream_dependency > Fix For: 21.0.0.Beta1 > > > org.jboss.as.jpa.service.PersistenceUnitServiceImpl#start() needs to always call pu.setAnnotationIndex(null) to clear the deployment reference to the Jandex Indexes. > Currently without the fix, the Jandex Index will be released at application undeployment time. With the fix, the Jandex Index memory will be released after application deployment is complete. Note that the Jandex Index contains metadata for the application deployment classes and are not needed after deployment is complete. > Note that this problem shouldn't occur when persistence.xml contains: > {code} > <property name="wildfly.jpa.twophasebootstrap" value="false"/> > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13586) Add a Galleon layer for JSONB

by Yeray Borges Santana (Jira)

Yeray Borges Santana created WFLY-13586: ------------------------------------------- Summary: Add a Galleon layer for JSONB Key: WFLY-13586 URL: https://issues.redhat.com/browse/WFLY-13586 Project: WildFly Issue Type: Feature Request Components: Build System Reporter: Yeray Borges Santana Assignee: Yeray Borges Santana Create a Galleon layer to provision JsonB API and Impl modules. These modules are optionally provisioned by jaxrs, jaxrs-server and cloud-server. We can use this layer to add them on top of any other layer, or provision them even if optional dependencies are excluded. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13585) Add a Galleon layer for JSONP

by Yeray Borges Santana (Jira)

Yeray Borges Santana created WFLY-13585: ------------------------------------------- Summary: Add a Galleon layer for JSONP Key: WFLY-13585 URL: https://issues.redhat.com/browse/WFLY-13585 Project: WildFly Issue Type: Feature Request Components: Build System Reporter: Yeray Borges Santana Assignee: Yeray Borges Santana Create a Galleon layer to provision JsonP API and Impl modules. These modules already belong to the base server, so the idea with this layer is just to ensure they are provisioned independently if they are excluded in the future from the base-server layer. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3313) Websocket Auth - Container is not aware of the Principal

by Caleb Adams (Jira)

[ https://issues.redhat.com/browse/WFLY-3313?page=com.atlassian.jira.plugin... ] Caleb Adams commented on WFLY-3313: ----------------------------------- This is also occurring on WildFly 17.0.1.Final... EJBContext returns the anonymous principal and @RolesAllowed checks within the EJB container are broken. > Websocket Auth - Container is not aware of the Principal > -------------------------------------------------------- > > Key: WFLY-3313 > URL: https://issues.redhat.com/browse/WFLY-3313 > Project: WildFly > Issue Type: Bug > Components: EJB, Security, Web (Undertow), Web Sockets > Affects Versions: 8.1.0.CR1, 10.0.0.Final, 15.0.0.Final > Reporter: Markus D > Priority: Major > Attachments: websocket-different-principals-ejb-vs-socket.png, websocket-endpoint-security.war > > > The Websocket is protected by the web.xml. The session object of the callback object correctly returns the principal. > When an EJB is called the callerPrincipal is always anonymous. > @Resource > private SessionContext ctx; > Principal callerPrincipal = ctx.getCallerPrincipal(); > Running thread here: > https://community.jboss.org/thread/240617 > Shouldn't the principal be propagated to the EJB container when a websocket callback method triggered? -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

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 June 2020