August 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13734) JPA subsystem should fail deployment if ValidationMode.CALLBACK is configured but the BV capability is not present

by Scott Marlow (Jira)

[ https://issues.redhat.com/browse/WFLY-13734?page=com.atlassian.jira.plugi... ] Scott Marlow commented on WFLY-13734: ------------------------------------- {quote} I'm not familiar with BV, is CDI a requirement to get it working? If so, CDI already incorporates BV. That could mean we don't require to add it to jpa / jpa-distributed {quote} Currently, JPA, JSF + Weld, gets the ValidatorFactory from deploymentUnit.getAttachment(BeanValidationAttachments.VALIDATOR_FACTORY). We could ask but I think the idea is that a deployment should use the same ValidatorFactory instance for CDI (Weld) and JPA/JSF. We used to have separate ValidatorFactory instances that consumed more memory. If we do add an enhancement for ValidatorFactory instances to be created via application deployment containing ValidatorFactory implementation classes (but not the ValidatorFactory API), that probably would belong in org.jboss.as.ee.beanvalidation.BeanValidationFactoryDeployer or near it. > JPA subsystem should fail deployment if ValidationMode.CALLBACK is configured but the BV capability is not present > ------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-13734 > URL: https://issues.redhat.com/browse/WFLY-13734 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Reporter: Brian Stansberry > Assignee: Scott Marlow > Priority: Major > Fix For: No Release > > > This is a follow-on to https://github.com/wildfly/wildfly/pull/13444 / WFLY-13726. That fix is about applying logic consistently in both places where PersistenceUnitServiceHandler integrates with BV. But I suspect the existing handling isn't correct in the case where ValidationMode.CALLBACK is configured. The javadoc for that enum value says "The persistence provider must perform the lifecycle event validation. It is an error if there is no Bean Validation provider present in the environment." But I think our handling is ignoring that if the BV capability is not present. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13744) Improvements on Galleon layers community documentation

by Yeray Borges Santana (Jira)

Yeray Borges Santana created WFLY-13744: ------------------------------------------- Summary: Improvements on Galleon layers community documentation Key: WFLY-13744 URL: https://issues.redhat.com/browse/WFLY-13744 Project: WildFly Issue Type: Task Components: Documentation Reporter: Yeray Borges Santana Assignee: Yeray Borges Santana We could make some improvements on the WildFly community documentation about the Galleon layers: * Somehow facilitate the identification of what contains each layer. * Describe in this Galleon layers section a short introduction about the different available options to generate a trimmed server * Links about examples -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13734) JPA subsystem should fail deployment if ValidationMode.CALLBACK is configured but the BV capability is not present

by Yeray Borges Santana (Jira)

[ https://issues.redhat.com/browse/WFLY-13734?page=com.atlassian.jira.plugi... ] Yeray Borges Santana edited comment on WFLY-13734 at 8/5/20 8:48 AM: --------------------------------------------------------------------- Hi [~brian.stansberry], I see your point about we already have BV, indeed as an optional dependency, for {{cloud-server}} and {{jaxrs-server}} base layer, so adding it as an optional dep for {{jpa}} / {{jpa-distributed}} is harmless for these two base layers. So, if I understood well, we could need to add BV as optional dep for {{jpa}} / {{jpa-distributed}} to be able to use ValidationMode.NONE with, in addition within {{cloud-server}} and {{jaxrs-server}}, with {{datasources-web-server}} layer and ValidationMode.CALLBACK with all of them excluding the BV optional dependency, right? I'm not familiar with BV, is CDI a requirement to get it working? If so, CDI already incorporates BV. That could mean we don't require to add it to {{jpa}} / {{jpa-distributed}} was (Author: yersan): Hi [~brian.stansberry], I see your point about we already have BV, indeed as an optional dependency, for {{cloud-server}} and {{jaxrs-server}} base layer, so adding it as an optional dep for {{jpa}} / {{jpa-distributed}} is harmless for these two base layers. So, if I understood well, we could need to add BV as optional dep for {{jpa}} / {{jpa-distributed}} to be able to use ValidationMode.NONE with, in addition within {{cloud-server}} and {{jaxrs-server}}, with `datasources-web-server` layer and ValidationMode.CALLBACK with all of them excluding the BV optional dependency, right? I'm not familiar with BV, is CDI a requirement to get it working? If so, CDI already incorporates BV. That could mean we don't require to add it to {{jpa}} / {{jpa-distributed}} > JPA subsystem should fail deployment if ValidationMode.CALLBACK is configured but the BV capability is not present > ------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-13734 > URL: https://issues.redhat.com/browse/WFLY-13734 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Reporter: Brian Stansberry > Assignee: Scott Marlow > Priority: Major > Fix For: No Release > > > This is a follow-on to https://github.com/wildfly/wildfly/pull/13444 / WFLY-13726. That fix is about applying logic consistently in both places where PersistenceUnitServiceHandler integrates with BV. But I suspect the existing handling isn't correct in the case where ValidationMode.CALLBACK is configured. The javadoc for that enum value says "The persistence provider must perform the lifecycle event validation. It is an error if there is no Bean Validation provider present in the environment." But I think our handling is ignoring that if the BV capability is not present. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13734) JPA subsystem should fail deployment if ValidationMode.CALLBACK is configured but the BV capability is not present

by Yeray Borges Santana (Jira)

[ https://issues.redhat.com/browse/WFLY-13734?page=com.atlassian.jira.plugi... ] Yeray Borges Santana commented on WFLY-13734: --------------------------------------------- Well, we would not require excluding BV from {{jpa}} / {{jpa-distributed}} if we want to use ValidationMode.CALLBACK, the user application will supply BV in its classpath. > JPA subsystem should fail deployment if ValidationMode.CALLBACK is configured but the BV capability is not present > ------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-13734 > URL: https://issues.redhat.com/browse/WFLY-13734 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Reporter: Brian Stansberry > Assignee: Scott Marlow > Priority: Major > Fix For: No Release > > > This is a follow-on to https://github.com/wildfly/wildfly/pull/13444 / WFLY-13726. That fix is about applying logic consistently in both places where PersistenceUnitServiceHandler integrates with BV. But I suspect the existing handling isn't correct in the case where ValidationMode.CALLBACK is configured. The javadoc for that enum value says "The persistence provider must perform the lifecycle event validation. It is an error if there is no Bean Validation provider present in the environment." But I think our handling is ignoring that if the BV capability is not present. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13734) JPA subsystem should fail deployment if ValidationMode.CALLBACK is configured but the BV capability is not present

by Yeray Borges Santana (Jira)

[ https://issues.redhat.com/browse/WFLY-13734?page=com.atlassian.jira.plugi... ] Yeray Borges Santana commented on WFLY-13734: --------------------------------------------- Hi [~brian.stansberry], I see your point about we already have BV, indeed as an optional dependency, for {{cloud-server}} and {{jaxrs-server}} base layer, so adding it as an optional dep for {{jpa}} / {{jpa-distributed}} is harmless for these two base layers. So, if I understood well, we could need to add BV as optional dep for {{jpa}} / {{jpa-distributed}} to be able to use ValidationMode.NONE with, in addition within {{cloud-server}} and {{jaxrs-server}}, with `datasources-web-server` layer and ValidationMode.CALLBACK with all of them excluding the BV optional dependency, right? I'm not familiar with BV, is CDI a requirement to get it working? If so, CDI already incorporates BV. That could mean we don't require to add it to {{jpa}} / {{jpa-distributed}} > JPA subsystem should fail deployment if ValidationMode.CALLBACK is configured but the BV capability is not present > ------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-13734 > URL: https://issues.redhat.com/browse/WFLY-13734 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Reporter: Brian Stansberry > Assignee: Scott Marlow > Priority: Major > Fix For: No Release > > > This is a follow-on to https://github.com/wildfly/wildfly/pull/13444 / WFLY-13726. That fix is about applying logic consistently in both places where PersistenceUnitServiceHandler integrates with BV. But I suspect the existing handling isn't correct in the case where ValidationMode.CALLBACK is configured. The javadoc for that enum value says "The persistence provider must perform the lifecycle event validation. It is an error if there is no Bean Validation provider present in the environment." But I think our handling is ignoring that if the BV capability is not present. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5083) ObjectTypeValidator should not accept invalid attribute

by Chao Wang (Jira)

[ https://issues.redhat.com/browse/WFCORE-5083?page=com.atlassian.jira.plug... ] Chao Wang updated WFCORE-5083: ------------------------------ Component/s: Management > ObjectTypeValidator should not accept invalid attribute > ------------------------------------------------------- > > Key: WFCORE-5083 > URL: https://issues.redhat.com/browse/WFCORE-5083 > Project: WildFly Core > Issue Type: Bug > Components: Management > Affects Versions: 13.0.0.Beta3 > Reporter: Chao Wang > Assignee: Chao Wang > Priority: Major > > Adding a global-module with an invalid attribute doesn't give an error. > {code:xml} > [standalone@embedded /] /subsystem=ee:list-add(name=global-modules, value={name=javax.api, test=abc}) > {"outcome" => "success"} > [standalone@embedded /] /subsystem=ee:read-attribute(name=global-modules) > { > "outcome" => "success", > "result" => [{ > "name" => "javax.api", > "test" => "abc" > }] > } > {code} > {code:xml} > [standalone@embedded /] /subsystem=ee:write-attribute(name=global-modules,value=[{name=javax.api, test=123}]) > {"outcome" => "success"} > [standalone@embedded /] /subsystem=ee:read-attribute(name=global-modules) > { > "outcome" => "success", > "result" => [{ > "name" => "javax.api", > "test" => "123" > }] > } > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5083) ObjectTypeValidator should not accept invalid attribute

by Chao Wang (Jira)

[ https://issues.redhat.com/browse/WFCORE-5083?page=com.atlassian.jira.plug... ] Chao Wang updated WFCORE-5083: ------------------------------ Description: Adding a global-module with an invalid attribute doesn't give an error. {code:xml} [standalone@embedded /] /subsystem=ee:list-add(name=global-modules, value={name=javax.api, test=abc}) {"outcome" => "success"} [standalone@embedded /] /subsystem=ee:read-attribute(name=global-modules) { "outcome" => "success", "result" => [{ "name" => "javax.api", "test" => "abc" }] } {code} {code:xml} [standalone@embedded /] /subsystem=ee:write-attribute(name=global-modules,value=[{name=javax.api, test=123}]) {"outcome" => "success"} [standalone@embedded /] /subsystem=ee:read-attribute(name=global-modules) { "outcome" => "success", "result" => [{ "name" => "javax.api", "test" => "123" }] } {code} was: Adding a global-module with slot=... does not work. {code:java} /subsystem=ee:write-attribute(name=global-modules,value=[{name=javax.api,slot="two"}]) {code} or {code:java} /subsystem=ee:list-add(name=global-modules, value={name=javax.api,slot=two}) {code} > ObjectTypeValidator should not accept invalid attribute > ------------------------------------------------------- > > Key: WFCORE-5083 > URL: https://issues.redhat.com/browse/WFCORE-5083 > Project: WildFly Core > Issue Type: Bug > Reporter: Chao Wang > Assignee: Chao Wang > Priority: Major > > Adding a global-module with an invalid attribute doesn't give an error. > {code:xml} > [standalone@embedded /] /subsystem=ee:list-add(name=global-modules, value={name=javax.api, test=abc}) > {"outcome" => "success"} > [standalone@embedded /] /subsystem=ee:read-attribute(name=global-modules) > { > "outcome" => "success", > "result" => [{ > "name" => "javax.api", > "test" => "abc" > }] > } > {code} > {code:xml} > [standalone@embedded /] /subsystem=ee:write-attribute(name=global-modules,value=[{name=javax.api, test=123}]) > {"outcome" => "success"} > [standalone@embedded /] /subsystem=ee:read-attribute(name=global-modules) > { > "outcome" => "success", > "result" => [{ > "name" => "javax.api", > "test" => "123" > }] > } > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5083) ObjectTypeValidator should not accept invalid attribute

by Chao Wang (Jira)

[ https://issues.redhat.com/browse/WFCORE-5083?page=com.atlassian.jira.plug... ] Chao Wang updated WFCORE-5083: ------------------------------ Affects Version/s: 13.0.0.Beta3 > ObjectTypeValidator should not accept invalid attribute > ------------------------------------------------------- > > Key: WFCORE-5083 > URL: https://issues.redhat.com/browse/WFCORE-5083 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 13.0.0.Beta3 > Reporter: Chao Wang > Assignee: Chao Wang > Priority: Major > > Adding a global-module with an invalid attribute doesn't give an error. > {code:xml} > [standalone@embedded /] /subsystem=ee:list-add(name=global-modules, value={name=javax.api, test=abc}) > {"outcome" => "success"} > [standalone@embedded /] /subsystem=ee:read-attribute(name=global-modules) > { > "outcome" => "success", > "result" => [{ > "name" => "javax.api", > "test" => "abc" > }] > } > {code} > {code:xml} > [standalone@embedded /] /subsystem=ee:write-attribute(name=global-modules,value=[{name=javax.api, test=123}]) > {"outcome" => "success"} > [standalone@embedded /] /subsystem=ee:read-attribute(name=global-modules) > { > "outcome" => "success", > "result" => [{ > "name" => "javax.api", > "test" => "123" > }] > } > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5083) ObjectTypeValidator should not accept invalid attribute

by Chao Wang (Jira)

[ https://issues.redhat.com/browse/WFCORE-5083?page=com.atlassian.jira.plug... ] Chao Wang moved JBEAP-20058 to WFCORE-5083: ------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-5083 (was: JBEAP-20058) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) > ObjectTypeValidator should not accept invalid attribute > ------------------------------------------------------- > > Key: WFCORE-5083 > URL: https://issues.redhat.com/browse/WFCORE-5083 > Project: WildFly Core > Issue Type: Bug > Reporter: Chao Wang > Assignee: Chao Wang > Priority: Major > > Adding a global-module with slot=... does not work. > > {code:java} > /subsystem=ee:write-attribute(name=global-modules,value=[{name=javax.api,slot="two"}]) {code} > or > {code:java} > /subsystem=ee:list-add(name=global-modules, value={name=javax.api,slot=two}) {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-5082) Add a new "legacy-remoting" layer.

by Darran Lofthouse (Jira)

Darran Lofthouse created WFCORE-5082: ---------------------------------------- Summary: Add a new "legacy-remoting" layer. Key: WFCORE-5082 URL: https://issues.redhat.com/browse/WFCORE-5082 Project: WildFly Core Issue Type: Task Components: Build System, Remoting Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 13.0.0.Beta4 This layer should make use of legacy security realms for authentication and depend on the layer "management-security-realm" to ensure it is present. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 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 August 2020