[wildfly-dev] Re: WFLY-19020: behavior change in persistence unit handling of application client

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... >>