November 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9516) JPA deployer adding cross sub deployment dependencies when multiple persistence units deployed

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-9516?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-9516: ------------------------------------ The best option, might be adding a persistence unit hint that indicates that component dependencies should only be added for persistence units in the top level deployment and the respective sub deployment. I think that this could be used with the initialise-in-order=true setting. Even better, is for the application to move persistence units to the top level deployment. > JPA deployer adding cross sub deployment dependencies when multiple persistence units deployed > ---------------------------------------------------------------------------------------------- > > Key: WFLY-9516 > URL: https://issues.jboss.org/browse/WFLY-9516 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 11.0.0.Final > Reporter: Brad Maxwell > Assignee: Scott Marlow > > If an ear contains two EJB sub deployments which each contain a Persistence Unit and a Stateless EJB which injects the PU that is in its jar using @PersistenceContext. There is a dependency being added where in the Stateless EJB from one deployment depends on the PU from the other jar. It appears this is happening after this bug fix WFLY-1531 > {code} > app.ear > - ejb-with-pu1.jar > - ejb-with-pu2.jar > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2136) Remove not used mvn dependencies

by Jozef Marko (JIRA)

Jozef Marko created DROOLS-2136: ----------------------------------- Summary: Remove not used mvn dependencies Key: DROOLS-2136 URL: https://issues.jboss.org/browse/DROOLS-2136 Project: Drools Issue Type: Task Affects Versions: 7.4.1.Final Reporter: Jozef Marko Assignee: Jozef Marko In the drools-wb repository, remove all mvn dependencies that {code:mvn} mvn dependency:analyze marks as declared but not used {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2136) Remove not used mvn dependencies

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2136?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-2136: -------------------------------- Sprint: 2017 Week 45-46 > Remove not used mvn dependencies > -------------------------------- > > Key: DROOLS-2136 > URL: https://issues.jboss.org/browse/DROOLS-2136 > Project: Drools > Issue Type: Task > Affects Versions: 7.4.1.Final > Reporter: Jozef Marko > Assignee: Jozef Marko > > In the drools-wb repository, remove all mvn dependencies that > {code:mvn} > mvn dependency:analyze marks as declared but not used > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2136) Remove not used mvn dependencies

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2136?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-2136: -------------------------------- Description: In the drools-wb repository, remove all mvn dependencies that {code:mvn} mvn dependency:analyze {code} marks as declared but not used was: In the drools-wb repository, remove all mvn dependencies that {code:mvn} mvn dependency:analyze marks as declared but not used {code} > Remove not used mvn dependencies > -------------------------------- > > Key: DROOLS-2136 > URL: https://issues.jboss.org/browse/DROOLS-2136 > Project: Drools > Issue Type: Task > Affects Versions: 7.4.1.Final > Reporter: Jozef Marko > Assignee: Jozef Marko > > In the drools-wb repository, remove all mvn dependencies that > {code:mvn} > mvn dependency:analyze > {code} > marks as declared but not used -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9516) JPA deployer adding cross sub deployment dependencies when multiple persistence units deployed

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-9516?page=com.atlassian.jira.plugin.... ] Scott Marlow edited comment on WFLY-9516 at 11/15/17 6:05 PM: -------------------------------------------------------------- {quote}Why does JPA sometimes start in INSTALL and sometimes start in POST_MODULE?{quote} Hibernate can only register its class file transformer during the POST_MODULE phase, so that Hibernate can rewrite entity classes. It is too late for Hibernate to register class file transformers during the INSTALL phase, as the application classes will have already been loaded during the INSTALL phase (I think by Weld). Applications that disable the persistence unit two phase start (via persistence unit hint "wildfly.jpa.twophasebootstrap=false"), will suffer from slower application performance as a result. If wildfly.jpa.twophasebootstrap=true, JPA phase 1 starts during POST_MODULE and JPA phase 2 starts during INSTALL. With wildfly.jpa.twophasebootstrap=false, single phase JPA bootstrap starts during INSTALL. was (Author: smarlow): {quote}Why does JPA sometimes start in INSTALL and sometimes start in POST_MODULE?{quote} Hibernate can only register its class file transformer during the POST_MODULE phase, so that Hibernate can rewrite entity classes. It is too late for Hibernate to register class file transformers during the INSTALL phase, as the application classes will have already been loaded during the INSTALL phase (I think by Weld). Applications that disable the persistence unit two phase start (via persistence unit hint "wildfly.jpa.twophasebootstrap=false"), will suffer from slower application performance as a result. > JPA deployer adding cross sub deployment dependencies when multiple persistence units deployed > ---------------------------------------------------------------------------------------------- > > Key: WFLY-9516 > URL: https://issues.jboss.org/browse/WFLY-9516 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 11.0.0.Final > Reporter: Brad Maxwell > Assignee: Scott Marlow > > If an ear contains two EJB sub deployments which each contain a Persistence Unit and a Stateless EJB which injects the PU that is in its jar using @PersistenceContext. There is a dependency being added where in the Stateless EJB from one deployment depends on the PU from the other jar. It appears this is happening after this bug fix WFLY-1531 > {code} > app.ear > - ejb-with-pu1.jar > - ejb-with-pu2.jar > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9516) JPA deployer adding cross sub deployment dependencies when multiple persistence units deployed

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-9516?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-9516: ------------------------------------ {quote}Why does JPA sometimes start in INSTALL and sometimes start in POST_MODULE?{quote} Hibernate can only register its class file transformer during the POST_MODULE phase, so that Hibernate can rewrite entity classes. It is too late for Hibernate to register class file transformers during the INSTALL phase, as the application classes will have already been loaded during the INSTALL phase (I think by Weld). Applications that disable the persistence unit two phase start (via persistence unit hint "wildfly.jpa.twophasebootstrap=false"), will suffer from slower application performance as a result. > JPA deployer adding cross sub deployment dependencies when multiple persistence units deployed > ---------------------------------------------------------------------------------------------- > > Key: WFLY-9516 > URL: https://issues.jboss.org/browse/WFLY-9516 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 11.0.0.Final > Reporter: Brad Maxwell > Assignee: Scott Marlow > > If an ear contains two EJB sub deployments which each contain a Persistence Unit and a Stateless EJB which injects the PU that is in its jar using @PersistenceContext. There is a dependency being added where in the Stateless EJB from one deployment depends on the PU from the other jar. It appears this is happening after this bug fix WFLY-1531 > {code} > app.ear > - ejb-with-pu1.jar > - ejb-with-pu2.jar > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9516) JPA deployer adding cross sub deployment dependencies when multiple persistence units deployed

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-9516?page=com.atlassian.jira.plugin.... ] Stuart Douglas commented on WFLY-9516: -------------------------------------- The other much harder to solve issue is that CDI requires both PU's to be started, which also causes cyclic dependency issues when initialise-in-order is true. This can be fixed by preventing a two phase start, so JPA effectively ignores initialise in order (which is fine IMHO, as it does not generally run user defined startup code). Why does JPA sometimes start in INSTALL and sometimes start in POST_MODULE? > JPA deployer adding cross sub deployment dependencies when multiple persistence units deployed > ---------------------------------------------------------------------------------------------- > > Key: WFLY-9516 > URL: https://issues.jboss.org/browse/WFLY-9516 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 11.0.0.Final > Reporter: Brad Maxwell > Assignee: Scott Marlow > > If an ear contains two EJB sub deployments which each contain a Persistence Unit and a Stateless EJB which injects the PU that is in its jar using @PersistenceContext. There is a dependency being added where in the Stateless EJB from one deployment depends on the PU from the other jar. It appears this is happening after this bug fix WFLY-1531 > {code} > app.ear > - ejb-with-pu1.jar > - ejb-with-pu2.jar > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9556) Remove unmodified configuration files from the servlet-feature-pack

by James Perkins (JIRA)

James Perkins created WFLY-9556: ----------------------------------- Summary: Remove unmodified configuration files from the servlet-feature-pack Key: WFLY-9556 URL: https://issues.jboss.org/browse/WFLY-9556 Project: WildFly Issue Type: Task Components: Build System Reporter: James Perkins Assignee: James Perkins The {{servlet-feature-pack}} contains some standalone configuration files that can be inherited from the {{core-feature-pack}}. These files should be removed from the {{servlet-feature-pack}} so changes are only required in core. The following files should be removable: * application-roles.properties * application-users.properties * mgmt-groups.properties * mgmt-users.properties -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9516) JPA deployer adding cross sub deployment dependencies when multiple persistence units deployed

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-9516?page=com.atlassian.jira.plugin.... ] Scott Marlow edited comment on WFLY-9516 at 11/15/17 3:41 PM: -------------------------------------------------------------- [~bmaxwell] to ensure that the persistence unit is available to the started EJBs, during application deployment, we add an internal service dependency from the EJB component(s) to the persistence unit(s), so the EJB will not start until the persistence unit has started. With persistence units defined in multiple ejb (sub) modules and initialize-in-order=true, we are going to get into trouble as we are only starting one ejb jar module at a time but adding dependencies from the ejb jar module on all of the persistence units defined in other modules. {quote} "jboss.deployment.subunit.\"reproducer-ear-0.1.ear\".\"reproducer-ejb.jar\".component.StatelessBean1.START is missing [jboss.persistenceunit.\"reproducer-ear-0.1.ear/reproducer-ejb2.jar#pu2\"]" {quote} Regarding what is at the top level of the EAR, ejb modules are sub-deployments. A jar with persistence.xml in ear/lib is at the top level of EAR deployment. An application workaround, could be to move the persistence unit definitions to (non-ejb) jars in ear/lib. A (possible) fix could be: * Introduce a persistence unit hint to change our deployment code (JPA/Weld) to not add component dependencies on persistence units contained by other subdeployments. * Or change our deployment code (JPA/WELD) to not add component dependencies on persistence units contained by other subdeployments if the initialize-in-order=true. was (Author: smarlow): [~bmaxwell] to ensure that the persistence unit is available to the started EJBs, during application deployment, we add an internal service dependency from the EJB component(s) to the persistence unit(s), so the EJB will not start until the persistence unit has started. With persistence units defined in multiple ejb (sub) modules and initialize-in-order=true, we are going to get into trouble as we are only starting one ejb jar module at a time but adding dependencies from the ejb jar module on all of the persistence units defined in other modules. {quote} "jboss.deployment.subunit.\"reproducer-ear-0.1.ear\".\"reproducer-ejb.jar\".component.StatelessBean1.START is missing [jboss.persistenceunit.\"reproducer-ear-0.1.ear/reproducer-ejb2.jar#pu2\"]" {quote} Regarding what is at the top level of the EAR, ejb modules are sub-deployments. A jar with persistence.xml in ear/lib is at the top level. An application workaround, could be to move the persistence unit definitions to (non-ejb) jars in ear/lib. A (possible) fix could be: * Introduce a persistence unit hint to change our deployment code (JPA/Weld) to not add component dependencies on persistence units contained by other subdeployments. * Or change our deployment code (JPA/WELD) to not add component dependencies on persistence units contained by other subdeployments if the initialize-in-order=true. > JPA deployer adding cross sub deployment dependencies when multiple persistence units deployed > ---------------------------------------------------------------------------------------------- > > Key: WFLY-9516 > URL: https://issues.jboss.org/browse/WFLY-9516 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 11.0.0.Final > Reporter: Brad Maxwell > Assignee: Scott Marlow > > If an ear contains two EJB sub deployments which each contain a Persistence Unit and a Stateless EJB which injects the PU that is in its jar using @PersistenceContext. There is a dependency being added where in the Stateless EJB from one deployment depends on the PU from the other jar. It appears this is happening after this bug fix WFLY-1531 > {code} > app.ear > - ejb-with-pu1.jar > - ejb-with-pu2.jar > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9516) JPA deployer adding cross sub deployment dependencies when multiple persistence units deployed

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-9516?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-9516: ------------------------------------ [~bmaxwell] to ensure that the persistence unit is available to the started EJBs, during application deployment, we add an internal service dependency from the EJB component(s) to the persistence unit(s), so the EJB will not start until the persistence unit has started. With persistence units defined in multiple ejb (sub) modules and initialize-in-order=true, we are going to get into trouble as we are only starting one ejb jar module at a time but adding dependencies from the ejb jar module on all of the persistence units defined in other modules. {quote} "jboss.deployment.subunit.\"reproducer-ear-0.1.ear\".\"reproducer-ejb.jar\".component.StatelessBean1.START is missing [jboss.persistenceunit.\"reproducer-ear-0.1.ear/reproducer-ejb2.jar#pu2\"]" {quote} Regarding what is at the top level of the EAR, ejb modules are sub-deployments. A jar with persistence.xml in ear/lib is at the top level. An application workaround, could be to move the persistence unit definitions to (non-ejb) jars in ear/lib. A (possible) fix could be: * Introduce a persistence unit hint to change our deployment code (JPA/Weld) to not add component dependencies on persistence units contained by other subdeployments. * Or change our deployment code (JPA/WELD) to not add component dependencies on persistence units contained by other subdeployments if the initialize-in-order=true. > JPA deployer adding cross sub deployment dependencies when multiple persistence units deployed > ---------------------------------------------------------------------------------------------- > > Key: WFLY-9516 > URL: https://issues.jboss.org/browse/WFLY-9516 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 11.0.0.Final > Reporter: Brad Maxwell > Assignee: Scott Marlow > > If an ear contains two EJB sub deployments which each contain a Persistence Unit and a Stateless EJB which injects the PU that is in its jar using @PersistenceContext. There is a dependency being added where in the Stateless EJB from one deployment depends on the PU from the other jar. It appears this is happening after this bug fix WFLY-1531 > {code} > app.ear > - ejb-with-pu1.jar > - ejb-with-pu2.jar > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 8 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 November 2017