December 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12874) JAXB Unmarshaller tries to instantiate abstract class ignoring xsi:type if it is a list element

by Lin Gao (Jira)

[ https://issues.redhat.com/browse/WFLY-12874?page=com.atlassian.jira.plugi... ] Lin Gao closed WFLY-12874. -------------------------- Resolution: Duplicate Issue [~ivassile] Also this one ;) > JAXB Unmarshaller tries to instantiate abstract class ignoring xsi:type if it is a list element > ----------------------------------------------------------------------------------------------- > > Key: WFLY-12874 > URL: https://issues.redhat.com/browse/WFLY-12874 > Project: WildFly > Issue Type: Bug > Reporter: Ilia Vassilev > Assignee: Viral Gohel > Priority: Major > Labels: downstream_dependency > > Upstream Issue: https://github.com/eclipse-ee4j/jaxb-ri/issues/1135 > Upstream PR: https://github.com/eclipse-ee4j/jaxb-ri/pull/1294 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12873) Upgrade JAXB from 2.3.1 to 2.3.3

by Lin Gao (Jira)

[ https://issues.redhat.com/browse/WFLY-12873?page=com.atlassian.jira.plugi... ] Lin Gao closed WFLY-12873. -------------------------- Resolution: Duplicate Issue [~ivassile] Sorry that I oversight this issue and made a PR to another: WFLY-12892, so I close this as duplicated. :) > Upgrade JAXB from 2.3.1 to 2.3.3 > -------------------------------- > > Key: WFLY-12873 > URL: https://issues.redhat.com/browse/WFLY-12873 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System > Reporter: Ilia Vassilev > Assignee: Lin Gao > Priority: Critical > > https://github.com/eclipse-ee4j/jaxb-ri/ -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12892) Upgrade JAXB from 2.3.1 to 2.3.3-b02

by Lin Gao (Jira)

[ https://issues.redhat.com/browse/WFLY-12892?page=com.atlassian.jira.plugi... ] Lin Gao updated WFLY-12892: --------------------------- Summary: Upgrade JAXB from 2.3.1 to 2.3.3-b02 (was: Upgrade JAXB from 2.3.1 to 2.3.3) > Upgrade JAXB from 2.3.1 to 2.3.3-b02 > ------------------------------------ > > Key: WFLY-12892 > URL: https://issues.redhat.com/browse/WFLY-12892 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Lin Gao > Assignee: Lin Gao > Priority: Major > Labels: downstream_dependency > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12896) EE Concurrency Hung Tasks Termination

by Eduardo Martins (Jira)

[ https://issues.redhat.com/browse/WFLY-12896?page=com.atlassian.jira.plugi... ] Eduardo Martins updated WFLY-12896: ----------------------------------- Summary: EE Concurrency Hung Tasks Termination (was: EE Concurrency Hung Task Termination) > EE Concurrency Hung Tasks Termination > ------------------------------------- > > Key: WFLY-12896 > URL: https://issues.redhat.com/browse/WFLY-12896 > Project: WildFly > Issue Type: Feature Request > Components: EE > Reporter: Eduardo Martins > Assignee: Eduardo Martins > Priority: Major > > EE Concurrency Managed Executors configuration includes an optional attribute that defines a runtime threshold to consider tasks to be "hung", i.e. tasks that for whatever reason didn't terminate execution in expected time, and on EAP7-1175 we will expose the number of such tasks as stats, but customers want extra functionality to force the termination of such tasks too (see JBEAP-13779), which will be provided by this RFE. > In high level the new functionality should be: > # add a new attribute to the executor's configuration, which will setup a periodic task to automatically force termination of any hung task running in the executor. > # add a new management op that may be invoked to manually force termination of any hung task running in the executor. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12794) Elytron/JACC: Inconsistent EjbMethodPermissions

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/WFLY-12794?page=com.atlassian.jira.plugi... ] Farah Juma commented on WFLY-12794: ----------------------------------- {{JaccInterceptor}} creates {{EJBMethodPermission}} instances as follows: https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo... Since no method params are provided above, when {{EJBMethodPermission#setMethodSpec}} gets called by the {{EJBMethodPermission}} constructor, it determines the method params and canonicalizes any array parameters. {{EjbJaccConfigurator}} creates {{EJBMethodPermission}} instances as follows: https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo... Notice that method params are provided above via {{methodIdentifier.getParameterTypes()}}. However, this is not correct since these params are not in the canonical form, as required by the {{EJBMethodPermission}} constructor. {{EjbJaccConfigurator}} should create {{EJBMethodPermission}} instances the same way {{JaccInterceptor}} does to ensure that we canonicalize any array parameters. The following PR fixes this: https://github.com/wildfly/wildfly/pull/12855 > Elytron/JACC: Inconsistent EjbMethodPermissions > ----------------------------------------------- > > Key: WFLY-12794 > URL: https://issues.redhat.com/browse/WFLY-12794 > Project: WildFly > Issue Type: Bug > Components: EJB, Security > Affects Versions: 18.0.0.Final > Reporter: Ulf Brosziewski > Assignee: Farah Juma > Priority: Critical > Attachments: quickstart-ejb-sec.diff > > > When JACC is enabled in an elytron application domain, calling a secured ejb method that has an array parameter causes an EjbAccessException. > The reason for the failure is that the EjbMethodPermissions created by the EjbJaccConfigurator and the JaccInterceptor do not agree in the format of the type names for method parameters. According to the JACC specification and API documentation, names for array types should have the "canonical" form: component-type + "[]". The permission objects built by the JaccInterceptor conform to that, but the EjbJaccConfigurator builds them with type names obtained from a "MethodIdentifier", and these names have the internal format as returned by Class.getName(). -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12896) EE Concurrency Hung Task Termination

by Eduardo Martins (Jira)

[ https://issues.redhat.com/browse/WFLY-12896?page=com.atlassian.jira.plugi... ] Eduardo Martins moved EAP7-1407 to WFLY-12896: ---------------------------------------------- Project: WildFly (was: EAP 7 Planning Pilot) Key: WFLY-12896 (was: EAP7-1407) Issue Type: Feature Request (was: Requirement) Workflow: GIT Pull Request workflow (was: EAP Agile Workflow 2.0) Component/s: EE (was: EE) User Story: (was: User wants to have a way to automatically or manually terminate EE Concurrency managed executor hung tasks.) 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) > EE Concurrency Hung Task Termination > ------------------------------------ > > Key: WFLY-12896 > URL: https://issues.redhat.com/browse/WFLY-12896 > Project: WildFly > Issue Type: Feature Request > Components: EE > Reporter: Eduardo Martins > Assignee: Eduardo Martins > Priority: Major > > EE Concurrency Managed Executors configuration includes an optional attribute that defines a runtime threshold to consider tasks to be "hung", i.e. tasks that for whatever reason didn't terminate execution in expected time, and on EAP7-1175 we will expose the number of such tasks as stats, but customers want extra functionality to force the termination of such tasks too (see JBEAP-13779), which will be provided by this RFE. > In high level the new functionality should be: > # add a new attribute to the executor's configuration, which will setup a periodic task to automatically force termination of any hung task running in the executor. > # add a new management op that may be invoked to manually force termination of any hung task running in the executor. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12794) Elytron/JACC: Inconsistent EjbMethodPermissions

by Farah Juma (Jira)

[ https://issues.redhat.com/browse/WFLY-12794?page=com.atlassian.jira.plugi... ] Farah Juma reassigned WFLY-12794: --------------------------------- Assignee: Farah Juma > Elytron/JACC: Inconsistent EjbMethodPermissions > ----------------------------------------------- > > Key: WFLY-12794 > URL: https://issues.redhat.com/browse/WFLY-12794 > Project: WildFly > Issue Type: Bug > Components: EJB, Security > Affects Versions: 18.0.0.Final > Reporter: Ulf Brosziewski > Assignee: Farah Juma > Priority: Critical > Attachments: quickstart-ejb-sec.diff > > > When JACC is enabled in an elytron application domain, calling a secured ejb method that has an array parameter causes an EjbAccessException. > The reason for the failure is that the EjbMethodPermissions created by the EjbJaccConfigurator and the JaccInterceptor do not agree in the format of the type names for method parameters. According to the JACC specification and API documentation, names for array types should have the "canonical" form: component-type + "[]". The permission objects built by the JaccInterceptor conform to that, but the EjbJaccConfigurator builds them with type names obtained from a "MethodIdentifier", and these names have the internal format as returned by Class.getName(). -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

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

by Darran Lofthouse (Jira)

[ https://issues.redhat.com/browse/WFWIP-288?page=com.atlassian.jira.plugin... ] Darran Lofthouse commented on WFWIP-288: ---------------------------------------- Going to test this one next but just to confirm I agree with the Blocker priority for now - the specification does not make many demands on key sizes but 1024 bit keys is one of the few requirements listed. > JWT signed by 1024 bit long key is rejected > ------------------------------------------- > > Key: WFWIP-288 > URL: https://issues.redhat.com/browse/WFWIP-288 > Project: WildFly WIP > Issue Type: Bug > Components: MP JWT > Reporter: Jan Kasik > Assignee: Darran Lofthouse > Priority: Blocker > > 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, 5 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1041) Automate https://github.com/kiali/kiali/issues/1892

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1041?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan reassigned SWSQE-1041: ------------------------------------- Assignee: Hayk Hovsepyan > Automate https://github.com/kiali/kiali/issues/1892 > --------------------------------------------------- > > Key: SWSQE-1041 > URL: https://issues.redhat.com/browse/SWSQE-1041 > Project: Kiali QE > Issue Type: QE Task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > Priority: Major > Labels: automation > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12895) Mojarra-4500 - NPE when determining converter for primitive values

by Ilia Vassilev (Jira)

[ https://issues.redhat.com/browse/WFLY-12895?page=com.atlassian.jira.plugi... ] Ilia Vassilev moved JBEAP-18356 to WFLY-12895: ---------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-12895 (was: JBEAP-18356) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JSF (was: JSF) Affects Version/s: (was: 7.2.5.GA) Fix Version/s: (was: 7.3.1.GA) > Mojarra-4500 - NPE when determining converter for primitive values > ------------------------------------------------------------------ > > Key: WFLY-12895 > URL: https://issues.redhat.com/browse/WFLY-12895 > Project: WildFly > Issue Type: Bug > Components: JSF > Reporter: Ilia Vassilev > Assignee: Ricardo Martin Camarero > Priority: Major > > https://github.com/eclipse-ee4j/mojarra/issues/4500 > On Version 2.3.5 when the backing bean value is a primitive (int, boolean, etc) there is a NPE during the validation phase. > This is a regression from 2.2 > {code} > <h:selectOneMenu value="#{billingAccountView.billingAccount.commissionable}"> > <f:selectItem itemValue="true" itemLabel="Yes" /> > <f:selectItem itemValue="false" itemLabel="No" /> > </h:selectOneMenu> > {code} > Where billingAccountView.billingAccount.commissionable is a primitive boolean > {code} > 15:27:04,781 SEVERE [javax.enterprise.resource.webcontainer.jsf.renderkit] (default task-2) Could not instantiate converter for type boolean: java.lang.NullPointerException > 15:27:04,781 SEVERE [javax.enterprise.resource.webcontainer.jsf.renderkit] (default task-2) : java.lang.NullPointerException > at com.sun.faces.cdi.CdiUtils.createConverter(CdiUtils.java:125) > at com.sun.faces.application.ApplicationImpl.createConverter(ApplicationImpl.java:1458) > at javax.faces.application.ApplicationWrapper.createConverter(ApplicationWrapper.java:425) > at org.omnifaces.cdi.converter.ConverterManager.createConverter(ConverterManager.java:155) > at org.omnifaces.cdi.converter.ConverterManager$Proxy$_$$_WeldClientProxy.createConverter(Unknown Source) > at org.omnifaces.application.OmniApplication.createConverter(OmniApplication.java:98) > at com.sun.faces.renderkit.html_basic.HtmlBasicInputRenderer.getConvertedValue(HtmlBasicInputRenderer.java:127) > at com.sun.faces.renderkit.html_basic.MenuRenderer.convertSelectOneValue(MenuRenderer.java:194) > at com.sun.faces.renderkit.html_basic.MenuRenderer.getConvertedValue(MenuRenderer.java:341) > at javax.faces.component.UIInput.getConvertedValue(UIInput.java:1122) > at javax.faces.component.UIInput.validate(UIInput.java:1030) > at javax.faces.component.UIInput.executeValidate(UIInput.java:1334) > at javax.faces.component.UIInput.processValidators(UIInput.java:757) > at javax.faces.component.UISelectOne.processValidators(UISelectOne.java:207) > at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1298) > at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1298) > at javax.faces.component.UIForm.processValidators(UIForm.java:269) > at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1298) > at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1298) > at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:1298) > at javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:1332) > at com.sun.faces.lifecycle.ProcessValidationsPhase.execute(ProcessValidationsPhase.java:77) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 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 December 2019