On Fri, May 17, 2024 at 12:57 AM Wolfgang Knauf via wildfly-dev <wildfly-dev(a)lists.jboss.org&gt; wrote: Hi all, this question is about a change in the way that a JakartaEE application client is launched: https://issues.redhat.com/browse/WFLY-19020 Before the change, an application client might receive a ClassNotFoundException because of a missing hibernate class. My workaround for this was to add jboss-deployment-structure.xml and include the module "org.hibernate". This behavior was changed in 31.0.1 after my bugreport: it seems the application client deploys "persistence.xml" from the EJB jar somehow, and my sample now works. But this change also causes the application client to create/drop the tables each time it is launched if persistence.xml defines "hibernate.hbm2ddl.auto=create-drop". This did not happen with WildFly 31.0.0 and before. It can be avoided if the data source in "appclient.xml" points to a H2 memory database instead of the real database defined in "standalone.xml". I did not verify whether old WildFly versions required the datasource to be defined in "appclient.xml", but I have the feeling that it was necessary. Currently, this is only an unnecessary step. But if the datasource defined in "appclient.xml" would point to the "real" datasource defined in "standalone.xml", the tables would be created each time the client starts. Fortunately, I could not make it work to define a MariaDB connection in "appclient.xml" because it could not resolve the driver, but with some effort this could be possible. What do you think about this change? To me, it sounds unnecessary to create/drop tables from EJB "persistence.xml" when an app client is started. Is it required if the app client itself would use client side JPA? Thanks for starting this discussion!  I appreciate that you are questioning whether the EJB persistence.xml should be visible to the app client deployment.  We should consider the rules in https://jakarta.ee/specifications/platform/10/jakarta-platform-spec-10.0#... and whether any of those are not being followed correctly for your deployment.  The question that we need to answer is whether the (EJB) persistence unit should have been ignored.

Regards, Scott Best regards Wolfgang _______________________________________________ wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org Privacy Statement: https://www.redhat.com/en/about/privacy-policy List Archives: https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message...

Hi Scott, thanks for the detailed analysis. I gave it a try and removed "manifest.mf" from the app client jar, but the tables are still created. Attached is a reworked ear file without the ClassPath entry. Rename it to "KuchenZutatInheritance_Simplied.ear" before deploying or testing the client. Launch it with this call: /appclient.sh /tmp/KuchenZutatInheritance_Simplied.ear#KuchenZutatInheritanceClient.jar" If it would work as you wrote, would the initial "ClassNotFoundException: org.hibernate.collection.spi.PersistentBag" from WFLY-19020 be thrown again?

JYI: The class path entry is created by Eclipse if an old style EAR project is used. If you don't add it, the app client project cannot resolve e.g. the ejb remote interface. But this is rather old knowledge - I should test whether it is still necessary. Best regards Wolfgang Am 17.05.24 um 16:59 schrieb Scott Marlow: > > On 5/17/24 10:27 AM, Scott Marlow wrote: >> >> >> On Fri, May 17, 2024 at 12:57 AM Wolfgang Knauf via wildfly-dev >> <wildfly-dev(a)lists.jboss.org&gt; wrote: >> >> Hi all, >> >> this question is about a change in the way that a JakartaEE >> application >> client is launched: https://issues.redhat.com/browse/WFLY-19020 >> >> Before the change, an application client might receive a >> ClassNotFoundException because of a missing hibernate class. My >> workaround for this was to add jboss-deployment-structure.xml and >> include the module "org.hibernate". >> >> This behavior was changed in 31.0.1 after my bugreport: it seems the >> application client deploys "persistence.xml" from the EJB jar >> somehow, >> and my sample now works. >> >> But this change also causes the application client to >> create/drop the >> tables each time it is launched if persistence.xml defines >> "hibernate.hbm2ddl.auto=create-drop". This did not happen with >> WildFly >> 31.0.0 and before. >> It can be avoided if the data source in "appclient.xml" points >> to a H2 >> memory database instead of the real database defined in >> "standalone.xml". >> I did not verify whether old WildFly versions required the >> datasource to >> be defined in "appclient.xml", but I have the feeling that it >> was necessary. >> >> >> Currently, this is only an unnecessary step. But if the datasource >> defined in "appclient.xml" would point to the "real" datasource >> defined >> in "standalone.xml", the tables would be created each time the >> client >> starts. Fortunately, I could not make it work to define a MariaDB >> connection in "appclient.xml" because it could not resolve the >> driver, >> but with some effort this could be possible. >> >> >> What do you think about this change? To me, it sounds unnecessary to >> create/drop tables from EJB "persistence.xml" when an app client is >> started. Is it required if the app client itself would use >> client side JPA? >> >> >> Thanks for starting this discussion!  I appreciate that you are >> questioning whether the EJB persistence.xml should be visible to the >> app client deployment.  We should consider the rules in >> https://jakarta.ee/specifications/platform/10/jakarta-platform-spec-10.0#... >> and whether any of those are not being followed correctly for your >> deployment.  The question that we need to answer is whether the >> (EJB) persistence unit should have been ignored. > > Pasting from the referencing rules for easy reference: > > " > > > 8.3.3. Application Client Container Class Loading Requirements > > Components in the application client container must have access to > the following classes and resources. > > * > > The content of the application client jar file. > > * > > The transitive closure of any libraries referenced by the above > jar file (as specified in Library Support > <https://jakarta.ee/specifications/platform/10/jakarta-platform-spec-10.0#...>). > > * > > The transitive closure of any libraries specified by or > referenced by the containing ear file (as specified in Library > Support > <https://jakarta.ee/specifications/platform/10/jakarta-platform-spec-10.0#...>). > > * > > The Jakarta EE API classes specified in Jakarta EE Technologies > <https://jakarta.ee/specifications/platform/10/jakarta-platform-spec-10.0#... > for the application client container. > > * > > All required Java SE API classes > <https://jakarta.ee/specifications/platform/10/jakarta-platform-spec-10.0#...;. > > Components in the application client container may have access to the > following classes and resources. Portable applications must not > depend on having or not having access to these classes or resources. > > * > > The Jakarta EE API classes specified in Jakarta EE Technologies > <https://jakarta.ee/specifications/platform/10/jakarta-platform-spec-10.0#... > for the containers other than the application client container. > > * > > Any installed libraries available in the application server. > > * > > Other classes or resources contained in the application package, > and specified by an explicit use of an extension not defined by > this specification. > > * > > Other classes and resources that are part of the implementation > of the application server. > > Components in the application client container must not have access > to the following classes and resources, unless such classes or > resources are covered by one of the rules above. > > * > > Other classes or resources in the application package. For > example, the application client should not have access to the > classes in other application client jar files in the same ear > file, nor should it have access to the classes in web > applications or Jakarta Enterprise Beans jar files in the same > ear file. > > " > > The attached > https://issues.redhat.com/secure/attachment/13134094/KuchenZutatInheritan... > archive contains the KuchenZutatInheritanceClient.jar file that has > MANIFEST.MF with: > > class-Path: KuchenZutatInheritanceEJB.jar > > My read is that the appclient container should have access to the EJB > persistence unit since the EJB is on the appclient deployment > classpath.  Still, I think an interesting experiment would be to try > removing the KuchenZutatInheritanceEJB.jar from the appclient > classpath to see if the persistence unit still deploys (if it does, I > think that is a bug worth creating a new WFLY for. > > Scott > >> >> Regards, >> Scott >> >> >> Best regards >> >> Wolfgang >> _______________________________________________ >> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >> List Archives: >> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>

On Thu, Jun 6, 2024, 9:48 AM Scott Marlow <smarlow(a)redhat.com&gt; wrote: Hi Wolfgang, I thought more about this and the Jakarta EE Platform Specification class loading requirements have no impact on whether persistence units are deployed in the app client container or not. I also just read the https://jakarta.ee/specifications/persistence/3.1/jakarta-persistence-spe... section which only requires that persistence units are deployed in the app client container but doesn't require that contained managed persistence contexts be available. So, there is nothing in the Jakarta EE specification that points out a further bug that I see. More inline below... On 5/18/24 4:12 AM, Wolfgang Knauf wrote: > > Hi Scott, > > thanks for the detailed analysis. I gave it a try and removed > "manifest.mf" from the app client jar, but the tables are still > created. > > Attached is a reworked ear file without the ClassPath entry. > Rename it to "KuchenZutatInheritance_Simplied.ear" before > deploying or testing the client. > > Launch it with this call: > > /appclient.sh > /tmp/KuchenZutatInheritance_Simplied.ear#KuchenZutatInheritanceClient.jar" > > If it would work as you wrote, would the initial > "ClassNotFoundException: > org.hibernate.collection.spi.PersistentBag" from WFLY-19020 be > thrown again? > No, I was wrong about the class loading requirements having an impact.  Since there is no (Jakarta EE) requirement that helps your application, it would probably be best for you to work around the failure by either removing the persistence.xml from KuchenZutatInheritanceEJB.jar or ensure that the persistence.xml is ignored by adding a persistence unit hint "jboss.as.jpa.managed" set to true. Either way, you need a change. Actually, I meant that you could add a Persistence unit hint "jboss.as.jpa.managed" set to false which will prevent it from deploying. Scott Hope this helps. Scott > JYI: The class path entry is created by Eclipse if an old style > EAR project is used. If you don't add it, the app client project > cannot resolve e.g. the ejb remote interface. But this is rather > old knowledge - I should test whether it is still necessary. > > Best regards > > Wolfgang > > Am 17.05.24 um 16:59 schrieb Scott Marlow: >> >> On 5/17/24 10:27 AM, Scott Marlow wrote: >>> >>> >>> On Fri, May 17, 2024 at 12:57 AM Wolfgang Knauf via wildfly-dev >>> <wildfly-dev(a)lists.jboss.org&gt; wrote: >>> >>> Hi all, >>> >>> this question is about a change in the way that a JakartaEE >>> application >>> client is launched: https://issues.redhat.com/browse/WFLY-19020 >>> >>> Before the change, an application client might receive a >>> ClassNotFoundException because of a missing hibernate class. My >>> workaround for this was to add >>> jboss-deployment-structure.xml and >>> include the module "org.hibernate". >>> >>> This behavior was changed in 31.0.1 after my bugreport: it >>> seems the >>> application client deploys "persistence.xml" from the EJB >>> jar somehow, >>> and my sample now works. >>> >>> But this change also causes the application client to >>> create/drop the >>> tables each time it is launched if persistence.xml defines >>> "hibernate.hbm2ddl.auto=create-drop". This did not happen >>> with WildFly >>> 31.0.0 and before. >>> It can be avoided if the data source in "appclient.xml" >>> points to a H2 >>> memory database instead of the real database defined in >>> "standalone.xml". >>> I did not verify whether old WildFly versions required the >>> datasource to >>> be defined in "appclient.xml", but I have the feeling that >>> it was necessary. >>> >>> >>> Currently, this is only an unnecessary step. But if the >>> datasource >>> defined in "appclient.xml" would point to the "real" >>> datasource defined >>> in "standalone.xml", the tables would be created each time >>> the client >>> starts. Fortunately, I could not make it work to define a >>> MariaDB >>> connection in "appclient.xml" because it could not resolve >>> the driver, >>> but with some effort this could be possible. >>> >>> >>> What do you think about this change? To me, it sounds >>> unnecessary to >>> create/drop tables from EJB "persistence.xml" when an app >>> client is >>> started. Is it required if the app client itself would use >>> client side JPA? >>> >>> >>> Thanks for starting this discussion!  I appreciate that you are >>> questioning whether the EJB persistence.xml should be visible >>> to the app client deployment.  We should consider the rules in >>> https://jakarta.ee/specifications/platform/10/jakarta-platform-spec-10.0#... >>> and whether any of those are not being followed correctly for >>> your deployment.  The question that we need to answer is >>> whether the (EJB) persistence unit should have been ignored. >> >> Pasting from the referencing rules for easy reference: >> >> " >> >> >> 8.3.3. Application Client Container Class Loading >> Requirements >> >> Components in the application client container must have access >> to the following classes and resources. >> >> * >> >> The content of the application client jar file. >> >> * >> >> The transitive closure of any libraries referenced by the >> above jar file (as specified in Library Support >> <https://jakarta.ee/specifications/platform/10/jakarta-platform-spec-10.0#...>). >> >> * >> >> The transitive closure of any libraries specified by or >> referenced by the containing ear file (as specified in >> Library Support >> <https://jakarta.ee/specifications/platform/10/jakarta-platform-spec-10.0#...>). >> >> * >> >> The Jakarta EE API classes specified in Jakarta EE >> Technologies >> <https://jakarta.ee/specifications/platform/10/jakarta-platform-spec-10.0#... >> for the application client container. >> >> * >> >> All required Java SE API classes >> <https://jakarta.ee/specifications/platform/10/jakarta-platform-spec-10.0#...;. >> >> Components in the application client container may have access >> to the following classes and resources. Portable applications >> must not depend on having or not having access to these classes >> or resources. >> >> * >> >> The Jakarta EE API classes specified in Jakarta EE >> Technologies >> <https://jakarta.ee/specifications/platform/10/jakarta-platform-spec-10.0#... >> for the containers other than the application client container. >> >> * >> >> Any installed libraries available in the application server. >> >> * >> >> Other classes or resources contained in the application >> package, and specified by an explicit use of an extension >> not defined by this specification. >> >> * >> >> Other classes and resources that are part of the >> implementation of the application server. >> >> Components in the application client container must not have >> access to the following classes and resources, unless such >> classes or resources are covered by one of the rules above. >> >> * >> >> Other classes or resources in the application package. For >> example, the application client should not have access to >> the classes in other application client jar files in the >> same ear file, nor should it have access to the classes in >> web applications or Jakarta Enterprise Beans jar files in >> the same ear file. >> >> " >> >> The attached >> https://issues.redhat.com/secure/attachment/13134094/KuchenZutatInheritan... >> archive contains the KuchenZutatInheritanceClient.jar file that >> has MANIFEST.MF with: >> >> class-Path: KuchenZutatInheritanceEJB.jar >> >> My read is that the appclient container should have access to >> the EJB persistence unit since the EJB is on the appclient >> deployment classpath. Still, I think an interesting experiment >> would be to try removing the KuchenZutatInheritanceEJB.jar from >> the appclient classpath to see if the persistence unit still >> deploys (if it does, I think that is a bug worth creating a new >> WFLY for. >> >> Scott >> >>> >>> Regards, >>> Scott >>> >>> >>> Best regards >>> >>> Wolfgang >>> _______________________________________________ >>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>> To unsubscribe send an email to >>> wildfly-dev-leave(a)lists.jboss.org >>> Privacy Statement: >>> https://www.redhat.com/en/about/privacy-policy >>> List Archives: >>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>>

On 6/9/24 5:45 AM, Wolfgang Knauf wrote: > > Hi Scott, > > using "jboss.as.jpa.managed=false" would change the usage of the > persistence unit also for the EJB jar, wouldn't it? > > What about this chapter in the JPA spec? > https://jakarta.ee/specifications/persistence/3.1/jakarta-persistence-spe... > > > 8.2.2. Persistence Unit Scope > > An EJB-JAR, WAR, application client jar, or EAR can define a > persistence unit. > > When referencing a persistence unit using the /unitName/ > annotation element or /persistence-unit-name/ deployment > descriptor element, the visibility scope of the persistence unit > is determined by its point of definition: > > o > > A persistence unit that is defined at the level of an > EJB-JAR, WAR, or application client jar *is scoped to that* > EJB-JAR, WAR, or *application jar* respectively and is > visible to the components defined in that jar or war. > > > So the app client should not be able to access the persistence unit > defined in the EJB jar, as far as I understand it. I conclude from > this that the persistence unit should also not be deployed in the > client container. In this discussion, I think that we are more of trying to understand if WildFly missed any Persistence unit deployment level requirements.  By deployment, I mean the creation of the container managed entity manager factory for the specified persistence unit definition. I think that the 8.2.2 Persistence Unit Scope rules are more about how a persistence unit name specified in a @PersistenceUnit or @PersistenceContext is mapped to a deployed persistence unit definition. Based on your earlier feedback, I don't think that you are actually expecting to use the persistence unit in your app client container deployment.  So your application could benefit from ensuring that the persistence unit is not deployed in the application client container. Scott > > Best regards > > Wolfgang > > Am 06.06.24 um 23:32 schrieb Scott Marlow: >> >> >> On Thu, Jun 6, 2024, 9:48 AM Scott Marlow <smarlow(a)redhat.com&gt; wrote: >> >> Hi Wolfgang, >> >> I thought more about this and the Jakarta EE Platform >> Specification class loading requirements have no impact on >> whether persistence units are deployed in the app client >> container or not. I also just read the >> https://jakarta.ee/specifications/persistence/3.1/jakarta-persistence-spe... >> section which only requires that persistence units are deployed >> in the app client container but doesn't require that contained >> managed persistence contexts be available. So, there is nothing >> in the Jakarta EE specification that points out a further bug >> that I see. >> >> More inline below... >> >> On 5/18/24 4:12 AM, Wolfgang Knauf wrote: >>> >>> Hi Scott, >>> >>> thanks for the detailed analysis. I gave it a try and removed >>> "manifest.mf" from the app client jar, but the tables are still >>> created. >>> >>> Attached is a reworked ear file without the ClassPath entry. >>> Rename it to "KuchenZutatInheritance_Simplied.ear" before >>> deploying or testing the client. >>> >>> Launch it with this call: >>> >>> /appclient.sh >>> /tmp/KuchenZutatInheritance_Simplied.ear#KuchenZutatInheritanceClient.jar" >>> >>> If it would work as you wrote, would the initial >>> "ClassNotFoundException: >>> org.hibernate.collection.spi.PersistentBag" from WFLY-19020 be >>> thrown again? >>> >> No, I was wrong about the class loading requirements having an >> impact.  Since there is no (Jakarta EE) requirement that helps >> your application, it would probably be best for you to work >> around the failure by either removing the persistence.xml from >> KuchenZutatInheritanceEJB.jar or ensure that the persistence.xml >> is ignored by adding a persistence unit hint >> "jboss.as.jpa.managed" set to true. Either way, you need a change. >> >> Actually, I meant that you could add a Persistence unit hint >> "jboss.as.jpa.managed" set to false which will prevent it from >> deploying. >> >> Scott >> >> Hope this helps. >> >> Scott >> >>> JYI: The class path entry is created by Eclipse if an old style >>> EAR project is used. If you don't add it, the app client >>> project cannot resolve e.g. the ejb remote interface. But this >>> is rather old knowledge - I should test whether it is still >>> necessary. >>> >>> Best regards >>> >>> Wolfgang >>> >>> Am 17.05.24 um 16:59 schrieb Scott Marlow: >>>> >>>> On 5/17/24 10:27 AM, Scott Marlow wrote: >>>>> >>>>> >>>>> On Fri, May 17, 2024 at 12:57 AM Wolfgang Knauf via >>>>> wildfly-dev <wildfly-dev(a)lists.jboss.org&gt; wrote: >>>>> >>>>> Hi all, >>>>> >>>>> this question is about a change in the way that a >>>>> JakartaEE application >>>>> client is launched: >>>>> https://issues.redhat.com/browse/WFLY-19020 >>>>> >>>>> Before the change, an application client might receive a >>>>> ClassNotFoundException because of a missing hibernate >>>>> class. My >>>>> workaround for this was to add >>>>> jboss-deployment-structure.xml and >>>>> include the module "org.hibernate". >>>>> >>>>> This behavior was changed in 31.0.1 after my bugreport: >>>>> it seems the >>>>> application client deploys "persistence.xml" from the EJB >>>>> jar somehow, >>>>> and my sample now works. >>>>> >>>>> But this change also causes the application client to >>>>> create/drop the >>>>> tables each time it is launched if persistence.xml defines >>>>> "hibernate.hbm2ddl.auto=create-drop". This did not happen >>>>> with WildFly >>>>> 31.0.0 and before. >>>>> It can be avoided if the data source in "appclient.xml" >>>>> points to a H2 >>>>> memory database instead of the real database defined in >>>>> "standalone.xml". >>>>> I did not verify whether old WildFly versions required >>>>> the datasource to >>>>> be defined in "appclient.xml", but I have the feeling >>>>> that it was necessary. >>>>> >>>>> >>>>> Currently, this is only an unnecessary step. But if the >>>>> datasource >>>>> defined in "appclient.xml" would point to the "real" >>>>> datasource defined >>>>> in "standalone.xml", the tables would be created each >>>>> time the client >>>>> starts. Fortunately, I could not make it work to define a >>>>> MariaDB >>>>> connection in "appclient.xml" because it could not >>>>> resolve the driver, >>>>> but with some effort this could be possible. >>>>> >>>>> >>>>> What do you think about this change? To me, it sounds >>>>> unnecessary to >>>>> create/drop tables from EJB "persistence.xml" when an app >>>>> client is >>>>> started. Is it required if the app client itself would >>>>> use client side JPA? >>>>> >>>>> >>>>> Thanks for starting this discussion! I appreciate that you >>>>> are questioning whether the EJB persistence.xml should be >>>>> visible to the app client deployment.  We should consider the >>>>> rules in >>>>> https://jakarta.ee/specifications/platform/10/jakarta-platform-spec-10.0#... >>>>> and whether any of those are not being followed correctly for >>>>> your deployment. The question that we need to answer is >>>>> whether the (EJB) persistence unit should have been ignored. >>>> >>>> Pasting from the referencing rules for easy reference: >>>> >>>> " >>>> >>>> >>>> 8.3.3. Application Client Container Class Loading >>>> Requirements >>>> >>>> Components in the application client container must have >>>> access to the following classes and resources. >>>> >>>> * >>>> >>>> The content of the application client jar file. >>>> >>>> * >>>> >>>> The transitive closure of any libraries referenced by the >>>> above jar file (as specified in Library Support >>>> <https://jakarta.ee/specifications/platform/10/jakarta-platform-spec-10.0#...>). >>>> >>>> * >>>> >>>> The transitive closure of any libraries specified by or >>>> referenced by the containing ear file (as specified in >>>> Library Support >>>> <https://jakarta.ee/specifications/platform/10/jakarta-platform-spec-10.0#...>). >>>> >>>> * >>>> >>>> The Jakarta EE API classes specified in Jakarta EE >>>> Technologies >>>> <https://jakarta.ee/specifications/platform/10/jakarta-platform-spec-10.0#... >>>> for the application client container. >>>> >>>> * >>>> >>>> All required Java SE API classes >>>> <https://jakarta.ee/specifications/platform/10/jakarta-platform-spec-10.0#...;. >>>> >>>> Components in the application client container may have access >>>> to the following classes and resources. Portable applications >>>> must not depend on having or not having access to these >>>> classes or resources. >>>> >>>> * >>>> >>>> The Jakarta EE API classes specified in Jakarta EE >>>> Technologies >>>> <https://jakarta.ee/specifications/platform/10/jakarta-platform-spec-10.0#... >>>> for the containers other than the application client >>>> container. >>>> >>>> * >>>> >>>> Any installed libraries available in the application server. >>>> >>>> * >>>> >>>> Other classes or resources contained in the application >>>> package, and specified by an explicit use of an extension >>>> not defined by this specification. >>>> >>>> * >>>> >>>> Other classes and resources that are part of the >>>> implementation of the application server. >>>> >>>> Components in the application client container must not have >>>> access to the following classes and resources, unless such >>>> classes or resources are covered by one of the rules above. >>>> >>>> * >>>> >>>> Other classes or resources in the application package. For >>>> example, the application client should not have access to >>>> the classes in other application client jar files in the >>>> same ear file, nor should it have access to the classes in >>>> web applications or Jakarta Enterprise Beans jar files in >>>> the same ear file. >>>> >>>> " >>>> >>>> The attached >>>> https://issues.redhat.com/secure/attachment/13134094/KuchenZutatInheritan... >>>> archive contains the KuchenZutatInheritanceClient.jar file >>>> that has MANIFEST.MF with: >>>> >>>> class-Path: KuchenZutatInheritanceEJB.jar >>>> >>>> My read is that the appclient container should have access to >>>> the EJB persistence unit since the EJB is on the appclient >>>> deployment classpath.  Still, I think an interesting >>>> experiment would be to try removing the >>>> KuchenZutatInheritanceEJB.jar from the appclient classpath to >>>> see if the persistence unit still deploys (if it does, I think >>>> that is a bug worth creating a new WFLY for. >>>> >>>> Scott >>>> >>>>> >>>>> Regards, >>>>> Scott >>>>> >>>>> >>>>> Best regards >>>>> >>>>> Wolfgang >>>>> _______________________________________________ >>>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>>>> To unsubscribe send an email to >>>>> wildfly-dev-leave(a)lists.jboss.org >>>>> Privacy Statement: >>>>> https://www.redhat.com/en/about/privacy-policy >>>>> List Archives: >>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>>>>

On 6/11/24 3:34 PM, Wolfgang Knauf wrote: > > Hi Scott, > > yes, in my sample the EJB jar contains the only piece of code that > works directly with the database/persistence unit. The application > client does not use it.  As a app client probably runs on a different > machine than the application server, it should probably not even have > network access to the real database. > > The JPA standard seems to allow "persistence.xml" etc. in app > clients, but as far as I understand chapter 8.2.2, the client could > only use the one that is defined inside the client jar (or maybe its > utility jars), but not the ones from other modules. So a use case > could be that the EJB jar uses a persistence unit pointing to a > "real" database server, while the app client uses its own > EntityManager to e.g. store local data in a database. > If that was the case, there would of been more the Persistence specification that makes that a requirement for the (Persistence) container.  The Persistence container is the part of WildFly (or any Jakarta EE implementation) that deploys the persistence unit definitions in the persistence.xml. The Jakarta EE TCK tests do validate that Persistence works from the app client  containers (like what WildFly provides) but apparently, we do not have a test that validated the same conditions as your application happens to use.  Otherwise, we would of fixed the WFLY-19020 problem over ten years ago or so when we (really me) made the mistake of adding the WFLY-19020 bug that is now fixed. > I am not an expert on JakartaEE at all, I just have the feeling that > the curren behavior (introduced by WFLY-19020) is wrong. So, if you > consider the current implementation correct, I am probably the one > that is wrong ;-). > > My issue WFLY-19020 was just about the problem that the server > returned an entity bean to the app client and there was a > ClassNotFoundException. So, on the client side some jar seemed to be > missing. You added the code that deploys the persistence unit, which > fixes my error, but gives me a bad feeling... > In my research of the WFLY-19020 issue, I checked "table 2 Jakarta EE technologies" (https://jakarta.ee/specifications/platform/10/jakarta-platform-spec-10.0#...) which mentions that Persistence(JPA) is required to be supported in the App Client Container and I found some (WildFly internal) code that prevented Persistence from working for your test WFLY-19020 case due to an internal condition check being wrong. The WFLY-19020 code change https://github.com/scottmarlow/wildfly/commit/c5aaac09200fdbb695496c410c4... removed an incorrect (app client) check during Persistence deployment.  I very much appreciated the issue reporting the problem as several years went by before you reported the issue. I suspect that others may of experienced the same problem but didn't create an issue or ask for help. I think that you can solve this problem with a packaging solution to have a different ear for the client machines that doesn't have a persistence.xml file in the ejb jar or does have a persistence.xml that is ignored via the following hint being in the persistence.xml: property name="jboss.as.jpa.managed" value="false" /> "jboss.as.jpa.managed" defaults to true but if it is false, the (WildFly) Persistence container will not deploy the persistence unit that has jboss.as.jpa.managed set to false. Regards, Scott > Best regards > > Wolfgang > > Am 11.06.24 um 15:16 schrieb Scott Marlow: >> >> >> On 6/9/24 5:45 AM, Wolfgang Knauf wrote: >>> >>> Hi Scott, >>> >>> using "jboss.as.jpa.managed=false" would change the usage of the >>> persistence unit also for the EJB jar, wouldn't it? >>> >>> What about this chapter in the JPA spec? >>> https://jakarta.ee/specifications/persistence/3.1/jakarta-persistence-spe... >>> >>> >>> 8.2.2. Persistence Unit Scope >>> >>> An EJB-JAR, WAR, application client jar, or EAR can define a >>> persistence unit. >>> >>> When referencing a persistence unit using the /unitName/ >>> annotation element or /persistence-unit-name/ deployment >>> descriptor element, the visibility scope of the persistence >>> unit is determined by its point of definition: >>> >>> o >>> >>> A persistence unit that is defined at the level of an >>> EJB-JAR, WAR, or application client jar *is scoped to that* >>> EJB-JAR, WAR, or *application jar* respectively and is >>> visible to the components defined in that jar or war. >>> >>> >>> So the app client should not be able to access the persistence unit >>> defined in the EJB jar, as far as I understand it. I conclude from >>> this that the persistence unit should also not be deployed in the >>> client container. >> >> In this discussion, I think that we are more of trying to understand >> if WildFly missed any Persistence unit deployment level >> requirements.  By deployment, I mean the creation of the container >> managed entity manager factory for the specified persistence unit >> definition. >> >> I think that the 8.2.2 Persistence Unit Scope rules are more about >> how a persistence unit name specified in a @PersistenceUnit or >> @PersistenceContext is mapped to a deployed persistence unit definition. >> >> Based on your earlier feedback, I don't think that you are actually >> expecting to use the persistence unit in your app client container >> deployment.  So your application could benefit from ensuring that >> the persistence unit is not deployed in the application client >> container. >> >> Scott >> >>> >>> Best regards >>> >>> Wolfgang >>> >>> Am 06.06.24 um 23:32 schrieb Scott Marlow: >>>> >>>> >>>> On Thu, Jun 6, 2024, 9:48 AM Scott Marlow <smarlow(a)redhat.com&gt; wrote: >>>> >>>> Hi Wolfgang, >>>> >>>> I thought more about this and the Jakarta EE Platform >>>> Specification class loading requirements have no impact on >>>> whether persistence units are deployed in the app client >>>> container or not. I also just read the >>>> https://jakarta.ee/specifications/persistence/3.1/jakarta-persistence-spe... >>>> section which only requires that persistence units are >>>> deployed in the app client container but doesn't require that >>>> contained managed persistence contexts be available. So, there >>>> is nothing in the Jakarta EE specification that points out a >>>> further bug that I see. >>>> >>>> More inline below... >>>> >>>> On 5/18/24 4:12 AM, Wolfgang Knauf wrote: >>>>> >>>>> Hi Scott, >>>>> >>>>> thanks for the detailed analysis. I gave it a try and removed >>>>> "manifest.mf" from the app client jar, but the tables are >>>>> still created. >>>>> >>>>> Attached is a reworked ear file without the ClassPath entry. >>>>> Rename it to "KuchenZutatInheritance_Simplied.ear" before >>>>> deploying or testing the client. >>>>> >>>>> Launch it with this call: >>>>> >>>>> /appclient.sh >>>>> /tmp/KuchenZutatInheritance_Simplied.ear#KuchenZutatInheritanceClient.jar" >>>>> >>>>> If it would work as you wrote, would the initial >>>>> "ClassNotFoundException: >>>>> org.hibernate.collection.spi.PersistentBag" from WFLY-19020 >>>>> be thrown again? >>>>> >>>> No, I was wrong about the class loading requirements having an >>>> impact.  Since there is no (Jakarta EE) requirement that helps >>>> your application, it would probably be best for you to work >>>> around the failure by either removing the persistence.xml from >>>> KuchenZutatInheritanceEJB.jar or ensure that the >>>> persistence.xml is ignored by adding a persistence unit hint >>>> "jboss.as.jpa.managed" set to true. Either way, you need a change. >>>> >>>> Actually, I meant that you could add a Persistence unit hint >>>> "jboss.as.jpa.managed" set to false which will prevent it from >>>> deploying. >>>> >>>> Scott >>>> >>>> Hope this helps. >>>> >>>> Scott >>>> >>>>> JYI: The class path entry is created by Eclipse if an old >>>>> style EAR project is used. If you don't add it, the app >>>>> client project cannot resolve e.g. the ejb remote interface. >>>>> But this is rather old knowledge - I should test whether it >>>>> is still necessary. >>>>> >>>>> Best regards >>>>> >>>>> Wolfgang >>>>> >>>>> Am 17.05.24 um 16:59 schrieb Scott Marlow: >>>>>> >>>>>> On 5/17/24 10:27 AM, Scott Marlow wrote: >>>>>>> >>>>>>> >>>>>>> On Fri, May 17, 2024 at 12:57 AM Wolfgang Knauf via >>>>>>> wildfly-dev <wildfly-dev(a)lists.jboss.org&gt; wrote: >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> this question is about a change in the way that a >>>>>>> JakartaEE application >>>>>>> client is launched: >>>>>>> https://issues.redhat.com/browse/WFLY-19020 >>>>>>> >>>>>>> Before the change, an application client might receive a >>>>>>> ClassNotFoundException because of a missing hibernate >>>>>>> class. My >>>>>>> workaround for this was to add >>>>>>> jboss-deployment-structure.xml and >>>>>>> include the module "org.hibernate". >>>>>>> >>>>>>> This behavior was changed in 31.0.1 after my bugreport: >>>>>>> it seems the >>>>>>> application client deploys "persistence.xml" from the >>>>>>> EJB jar somehow, >>>>>>> and my sample now works. >>>>>>> >>>>>>> But this change also causes the application client to >>>>>>> create/drop the >>>>>>> tables each time it is launched if persistence.xml defines >>>>>>> "hibernate.hbm2ddl.auto=create-drop". This did not >>>>>>> happen with WildFly >>>>>>> 31.0.0 and before. >>>>>>> It can be avoided if the data source in "appclient.xml" >>>>>>> points to a H2 >>>>>>> memory database instead of the real database defined in >>>>>>> "standalone.xml". >>>>>>> I did not verify whether old WildFly versions required >>>>>>> the datasource to >>>>>>> be defined in "appclient.xml", but I have the feeling >>>>>>> that it was necessary. >>>>>>> >>>>>>> >>>>>>> Currently, this is only an unnecessary step. But if the >>>>>>> datasource >>>>>>> defined in "appclient.xml" would point to the "real" >>>>>>> datasource defined >>>>>>> in "standalone.xml", the tables would be created each >>>>>>> time the client >>>>>>> starts. Fortunately, I could not make it work to define >>>>>>> a MariaDB >>>>>>> connection in "appclient.xml" because it could not >>>>>>> resolve the driver, >>>>>>> but with some effort this could be possible. >>>>>>> >>>>>>> >>>>>>> What do you think about this change? To me, it sounds >>>>>>> unnecessary to >>>>>>> create/drop tables from EJB "persistence.xml" when an >>>>>>> app client is >>>>>>> started. Is it required if the app client itself would >>>>>>> use client side JPA? >>>>>>> >>>>>>> >>>>>>> Thanks for starting this discussion!  I appreciate that you >>>>>>> are questioning whether the EJB persistence.xml should be >>>>>>> visible to the app client deployment.  We should consider >>>>>>> the rules in >>>>>>> https://jakarta.ee/specifications/platform/10/jakarta-platform-spec-10.0#... >>>>>>> and whether any of those are not being followed correctly >>>>>>> for your deployment.  The question that we need to answer >>>>>>> is whether the (EJB) persistence unit should have been >>>>>>> ignored. >>>>>> >>>>>> Pasting from the referencing rules for easy reference: >>>>>> >>>>>> " >>>>>> >>>>>> >>>>>> 8.3.3. Application Client Container Class Loading >>>>>> Requirements >>>>>> >>>>>> Components in the application client container must have >>>>>> access to the following classes and resources. >>>>>> >>>>>> * >>>>>> >>>>>> The content of the application client jar file. >>>>>> >>>>>> * >>>>>> >>>>>> The transitive closure of any libraries referenced by >>>>>> the above jar file (as specified in Library Support >>>>>> <https://jakarta.ee/specifications/platform/10/jakarta-platform-spec-10.0#...>). >>>>>> >>>>>> * >>>>>> >>>>>> The transitive closure of any libraries specified by or >>>>>> referenced by the containing ear file (as specified in >>>>>> Library Support >>>>>> <https://jakarta.ee/specifications/platform/10/jakarta-platform-spec-10.0#...>). >>>>>> >>>>>> * >>>>>> >>>>>> The Jakarta EE API classes specified in Jakarta EE >>>>>> Technologies >>>>>> <https://jakarta.ee/specifications/platform/10/jakarta-platform-spec-10.0#... >>>>>> for the application client container. >>>>>> >>>>>> * >>>>>> >>>>>> All required Java SE API classes >>>>>> <https://jakarta.ee/specifications/platform/10/jakarta-platform-spec-10.0#...;. >>>>>> >>>>>> Components in the application client container may have >>>>>> access to the following classes and resources. Portable >>>>>> applications must not depend on having or not having access >>>>>> to these classes or resources. >>>>>> >>>>>> * >>>>>> >>>>>> The Jakarta EE API classes specified in Jakarta EE >>>>>> Technologies >>>>>> <https://jakarta.ee/specifications/platform/10/jakarta-platform-spec-10.0#... >>>>>> for the containers other than the application client >>>>>> container. >>>>>> >>>>>> * >>>>>> >>>>>> Any installed libraries available in the application server. >>>>>> >>>>>> * >>>>>> >>>>>> Other classes or resources contained in the application >>>>>> package, and specified by an explicit use of an >>>>>> extension not defined by this specification. >>>>>> >>>>>> * >>>>>> >>>>>> Other classes and resources that are part of the >>>>>> implementation of the application server. >>>>>> >>>>>> Components in the application client container must not have >>>>>> access to the following classes and resources, unless such >>>>>> classes or resources are covered by one of the rules above. >>>>>> >>>>>> * >>>>>> >>>>>> Other classes or resources in the application package. >>>>>> For example, the application client should not have >>>>>> access to the classes in other application client jar >>>>>> files in the same ear file, nor should it have access to >>>>>> the classes in web applications or Jakarta Enterprise >>>>>> Beans jar files in the same ear file. >>>>>> >>>>>> " >>>>>> >>>>>> The attached >>>>>> https://issues.redhat.com/secure/attachment/13134094/KuchenZutatInheritan... >>>>>> archive contains the KuchenZutatInheritanceClient.jar file >>>>>> that has MANIFEST.MF with: >>>>>> >>>>>> class-Path: KuchenZutatInheritanceEJB.jar >>>>>> >>>>>> My read is that the appclient container should have access >>>>>> to the EJB persistence unit since the EJB is on the >>>>>> appclient deployment classpath.  Still, I think an >>>>>> interesting experiment would be to try removing the >>>>>> KuchenZutatInheritanceEJB.jar from the appclient classpath >>>>>> to see if the persistence unit still deploys (if it does, I >>>>>> think that is a bug worth creating a new WFLY for. >>>>>> >>>>>> Scott >>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Scott >>>>>>> >>>>>>> >>>>>>> Best regards >>>>>>> >>>>>>> Wolfgang >>>>>>> _______________________________________________ >>>>>>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>>>>>> To unsubscribe send an email to >>>>>>> wildfly-dev-leave(a)lists.jboss.org >>>>>>> Privacy Statement: >>>>>>> https://www.redhat.com/en/about/privacy-policy >>>>>>> List Archives: >>>>>>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>>>>>>