[JBoss JIRA] (WFLY-13734) JPA subsystem should fail deployment if ValidationMode.CALLBACK is configured but the BV capability is not present
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13734?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFLY-13734:
-----------------------------------------
[~yersan]. FYI re this discussion. This makes me wonder whether the jpa / jpa-distributed layers need to have the bean-validation layer as an optional dependency.
The primary 'server' layers that incorporate JPA ('cloud-server' and 'jaxrs-server') already include the bean-validation layer, so for anyone using those adding b-v as a dep to jpa would have no practical impact. But for someone adding jpa to some other base, a change may mean they now get b-v when they didn't want it. They can exclude it though.
I'm fine with what [~smarlow] thinks is best here. But if we are going to change anything it must happen with WF 21; after that this layer should be locked down.
> 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
>
> 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
[JBoss JIRA] (WFLY-13734) JPA subsystem should fail deployment if ValidationMode.CALLBACK is configured but the BV capability is not present
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13734?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFLY-13734:
-----------------------------------------
{quote}
As I see it, we are introducing a non-EE-compatible server mode which I think is okay.
{quote}
Yes, Galleon layers allow you to provision a server that has what you want, and that isn't necessarily spec compliant.
{quote}
I don't think we need to handle CALLBACK mode at all, as Hibernate will fail the deployment for us.
{quote}
Sounds fine. I'll resolve this issue then.
> 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
>
> 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
[JBoss JIRA] (WFLY-13741) The standalone-load-balancer configurations should depend on legacy-management
by Darran Lofthouse (Jira)
Darran Lofthouse created WFLY-13741:
---------------------------------------
Summary: The standalone-load-balancer configurations should depend on legacy-management
Key: WFLY-13741
URL: https://issues.redhat.com/browse/WFLY-13741
Project: WildFly
Issue Type: Task
Components: Build System
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 21.0.0.Beta1
The standalone-load-balancer.xml/config.xml which can be found in ee-feature-pack and servlet-feature-pack should depend on the legacy-management layer instead of depending on management and adding security to it.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (WFCORE-5080) KeyStoresTestCase fails on IBM Java 8
by Ricardo Martin Camarero (Jira)
Ricardo Martin Camarero created WFCORE-5080:
-----------------------------------------------
Summary: KeyStoresTestCase fails on IBM Java 8
Key: WFCORE-5080
URL: https://issues.redhat.com/browse/WFCORE-5080
Project: WildFly Core
Issue Type: Bug
Components: Test Suite
Affects Versions: 13.0.0.Beta3
Reporter: Ricardo Martin Camarero
Assignee: Sonia Zaldana
Same issue than WFCORE-5004 but in test case KeyStoresTestCase (inside elytron folder too). It's the same problem with the certificate comparison if using the EMAILADDRESS field. Previously it was hidden by the mock-server issue (WFCORE-5023).
[~szaldana] I'm assigning it to you, it's just repeating what you did for the previous JIRA but for the new class. If you don't have time or prefer that I do the JIRA just assign it back to me. Thanks a lot!
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[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 edited comment on WFLY-13734 at 8/4/20 11:00 AM:
--------------------------------------------------------------
[~brian.stansberry]
{quote}
Ah, so if there is no ValidatorFactory but ValidationMode.CALLBACK is used, then Hibernate ORM or other JPA impl will reject that at their level?
{quote}
Yes, that is correct, although to pass the Jakarta EE TCK tests, we do need the ValidatorFactory as that is required for Jakarta EE compatible server implementations. As I see it, we are introducing a non-EE-compatible server mode which I think is okay.
[From JPA 2.2 SPEC|https://jakarta.ee/specifications/persistence/3.0/persistence_3.0-RC2.html#a2394]:
{code}
In Jakarta EE environments, a ValidatorFactory instance is made available by the Jakarta EE container. The container is responsible for passing this validator factory to the persistence provider via the map that is passed as an argument to the createContainerEntityManagerFactory call. The map key used by the container must be the standard property name jakarta.persistence.validation.factory.
In Java SE environments, the application can pass the ValidatorFactory instance via the map that is passed as an argument to the Persistence.createEntityManagerFactory call. The map key used must be the standard property name jakarta.persistence.validation.factory. If no ValidatorFactory instance is provided by the application, and if a Bean Validation provider is present in the classpath, the persistence provider must instantiate the ValidatorFactory using the default bootstrapping approach defined by the Bean Validation specification [5], namely Validation.buildDefaultValidatorFactory().
{code}
{quote}
If so, then maybe instead of exception it would just be an INFO msg in the server log? So if they indeed didn't package their own BV impl, then when it fails the log gives them a hint.
{quote}
I don't think we need to handle CALLBACK mode at all, as Hibernate will fail the deployment for us. Sorry that I wasn't clear before but I had to be reminded of the above linked spec requirement. I knew that there was a requirement but I couldn't find the written contract until now.
was (Author: smarlow):
[~brian.stansberry]
{quote}
Ah, so if there is no ValidatorFactory but ValidationMode.CALLBACK is used, then Hibernate ORM or other JPA impl will reject that at their level?
{quote}
Yes, that is correct, although to pass the Jakarta EE TCK tests, we do need the ValidatorFactory as that is required for Jakarta EE compatible server implementations. As I see it, we are introducing a non-EE-compatible server mode which I think is okay.
[From JPA 2.2 SPEC|https://jakarta.ee/specifications/persistence/3.0/persistence_3.0-RC2.html#a2394]:
{code}
In Jakarta EE environments, a ValidatorFactory instance is made available by the Jakarta EE container. The container is responsible for passing this validator factory to the persistence provider via the map that is passed as an argument to the createContainerEntityManagerFactory call. The map key used by the container must be the standard property name jakarta.persistence.validation.factory.
In Java SE environments, the application can pass the ValidatorFactory instance via the map that is passed as an argument to the Persistence.createEntityManagerFactory call. The map key used must be the standard property name jakarta.persistence.validation.factory. If no ValidatorFactory instance is provided by the application, and if a Bean Validation provider is present in the classpath, the persistence provider must instantiate the ValidatorFactory using the default bootstrapping approach defined by the Bean Validation specification [5], namely Validation.buildDefaultValidatorFactory().
{code}
{quote}
If so, then maybe instead of exception it would just be an INFO msg in the server log? So if they indeed didn't package their own BV impl, then when it fails the log gives them a hint.
{quote}
I don't think we need to handle CALLBACK mode at all, as Hibernate will fail the deployment for us. Sorry that I wasn't clear before but I had to be reminded of the above linked spec requirement. I knew that there was a requirement but I couldn't find the written contract until now.
> 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
>
> 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
[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:
-------------------------------------
[~brian.stansberry]
{quote}
Ah, so if there is no ValidatorFactory but ValidationMode.CALLBACK is used, then Hibernate ORM or other JPA impl will reject that at their level?
{quote}
Yes, that is correct, although to pass the Jakarta EE TCK tests, we do need the ValidatorFactory as that is required for Jakarta EE compatible server implementations. As I see it, we are introducing a non-EE-compatible server mode which I think is okay.
[From JPA 2.2 SPEC|https://jakarta.ee/specifications/persistence/3.0/persistence_3.0-RC2.html#a2394]:
{code}
In Jakarta EE environments, a ValidatorFactory instance is made available by the Jakarta EE container. The container is responsible for passing this validator factory to the persistence provider via the map that is passed as an argument to the createContainerEntityManagerFactory call. The map key used by the container must be the standard property name jakarta.persistence.validation.factory.
In Java SE environments, the application can pass the ValidatorFactory instance via the map that is passed as an argument to the Persistence.createEntityManagerFactory call. The map key used must be the standard property name jakarta.persistence.validation.factory. If no ValidatorFactory instance is provided by the application, and if a Bean Validation provider is present in the classpath, the persistence provider must instantiate the ValidatorFactory using the default bootstrapping approach defined by the Bean Validation specification [5], namely Validation.buildDefaultValidatorFactory().
{code}
{quote}
If so, then maybe instead of exception it would just be an INFO msg in the server log? So if they indeed didn't package their own BV impl, then when it fails the log gives them a hint.
{quote}
I don't think we need to handle CALLBACK mode at all, as Hibernate will fail the deployment for us. Sorry that I wasn't clear before but I had to be reminded of the above linked spec requirement. I knew that there was a requirement but I couldn't find the written contract until now.
> 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
>
> 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
[JBoss JIRA] (WFLY-13734) JPA subsystem should fail deployment if ValidationMode.CALLBACK is configured but the BV capability is not present
by Brian Stansberry (Jira)
[ https://issues.redhat.com/browse/WFLY-13734?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFLY-13734:
-----------------------------------------
Ah, so if there is no ValidatorFactory but ValidationMode.CALLBACK is used, then Hibernate ORM or other JPA impl will reject that at their level?
If so, then maybe instead of exception it would just be an INFO msg in the server log? So if they indeed didn't package their own BV impl, then when it fails the log gives them a hint.
> 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
>
> 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
[JBoss JIRA] (DROOLS-5559) Kie-workbench and kie-server going OOM with subsequent build and deployment
by Sachin Kamath (Jira)
Sachin Kamath created DROOLS-5559:
-------------------------------------
Summary: Kie-workbench and kie-server going OOM with subsequent build and deployment
Key: DROOLS-5559
URL: https://issues.redhat.com/browse/DROOLS-5559
Project: Drools
Issue Type: Bug
Components: Examples (Workbench), kie server
Affects Versions: 7.31.0.Final
Reporter: Sachin Kamath
Assignee: David Gutierrez
Hi Team,
We are using kie-workbench and kie-server for managing the rules using decision table spreadsheet. What we see is that, with continuous build and deployments being done, the servers are going out of memory. This is resulting in instability of the environment and frequent restarts are required to fix the issue.
Here are the parameters:
*kie-workbench* :
Xms: 20G
Xmx: 20G
Metaspace Xmx:8G Xms:8G
Using G1GC algorithm.
*kie-server:*
Xms: 4G
Xmx: 4G
Metaspace: Xmx:2G Xms:2G
Using G1GC algorithm.
*Steps for replication :*
# Excel sheet has 50k rows.
# Build the artifacts and deploy with version V1. The first deployment would be successful.
# Change the version to V2 and deploy once again. Now we will have version V1 and V2 both in the kie-servers but V2 would be serving he requests.
# Before deploying version V3, remove version V1. Build and deploy V3.
# Now when deploying version V4, after removing the version V2, the kie-servers are going out of memory.
Even though we are making sure that only last 2 valid versions are present, the servers are going out of memory. After restarting the servers, the last two valid versions V3 and V4 are successfully deployed again. The error in kie-servers clearly says Java heap space issue. But the point here is, it is fine after restart. I could sense there is some other problem. With visual VM, i could see that the memory consumption gradually increases with deployment of different versions but its not released as we remove the old version.
Any pointers would be helpful here.
Im really unsure if its a bug or im missing some parameters around it.
Thanks
Sachin
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (JGRP-2493) RELAY does not use protocol stack supplied programmatically
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2493?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2493:
--------------------------------
The setter is {{setBridgeCreator(Function<String,JChannel> c)}}. It accepts the bridge_props and needs to return an *unconnected* JChannel.
> RELAY does not use protocol stack supplied programmatically
> -----------------------------------------------------------
>
> Key: JGRP-2493
> URL: https://issues.redhat.com/browse/JGRP-2493
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.2.4
> Reporter: S Pokutniy
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.2.5
>
>
> RELAY does not use protocol stack supplied programmatically (i.e. stack which was set by using relay.setProtocolStack(protocolStack). Even though the stack is used in init(), the function below only relies on bridge_props file. Even though using an XML file is mostly possible, it becomes problematic when a custom SSLContext needs to be used in SSL_KEY_EXCHANGE, which can now only be set programmatically.
>
> protected void createBridge() {
> try {
> if(log.isTraceEnabled())
> log.trace("I'm the coordinator, creating a channel (props=" + bridge_props + ", cluster_name=" + bridge_name + ")");
> {color:#FF0000}bridge=new JChannel(bridge_props);{color}
> bridge.setDiscardOwnMessages(true); // don't receive my own messages
> bridge.setReceiver(new Receiver());
> bridge.connect(bridge_name);
> }
> catch(Exception e) {
> log.error(Util.getMessage("FailedCreatingBridgeChannelProps") + bridge_props + ")", e);
> }
> }
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months
[JBoss JIRA] (JGRP-2493) RELAY does not use protocol stack supplied programmatically
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2493?page=com.atlassian.jira.plugin... ]
Bela Ban resolved JGRP-2493.
----------------------------
Resolution: Done
> RELAY does not use protocol stack supplied programmatically
> -----------------------------------------------------------
>
> Key: JGRP-2493
> URL: https://issues.redhat.com/browse/JGRP-2493
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.2.4
> Reporter: S Pokutniy
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.2.5
>
>
> RELAY does not use protocol stack supplied programmatically (i.e. stack which was set by using relay.setProtocolStack(protocolStack). Even though the stack is used in init(), the function below only relies on bridge_props file. Even though using an XML file is mostly possible, it becomes problematic when a custom SSLContext needs to be used in SSL_KEY_EXCHANGE, which can now only be set programmatically.
>
> protected void createBridge() {
> try {
> if(log.isTraceEnabled())
> log.trace("I'm the coordinator, creating a channel (props=" + bridge_props + ", cluster_name=" + bridge_name + ")");
> {color:#FF0000}bridge=new JChannel(bridge_props);{color}
> bridge.setDiscardOwnMessages(true); // don't receive my own messages
> bridge.setReceiver(new Receiver());
> bridge.connect(bridge_name);
> }
> catch(Exception e) {
> log.error(Util.getMessage("FailedCreatingBridgeChannelProps") + bridge_props + ")", e);
> }
> }
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 2 months