> On Apr 19, 2021, at 11:15 AM, Jenkins, Rodney J (Rod) > <jenki...@nationwide.com> wrote: > > You stated, "In practice, I don't believe anyone actually used it and we do > not heavily test this technique." > > Until recently, we heavily relied on the drop in war. It was our main source > of obtaining TomEE. In the recent months we have moved to the full version > of TomEE. It was quite nice to be able to have a base TomCat installation, > then when someone needed it, we just dropped in the war. This reduced our > overhead. However, the classes did not get loaded the same. That lead us to > moving to the full version of TomEE with embedded Tomcat.
That's great news, Rod. I recall you mentioning you were heavily reliant on the wars, so I was concerned you'd be affected. Are you full transitioned off the wars or would it be helpful for us to maintain them for a couple releases? On classes not getting loaded the same, that's definitely the primary pitfall of them. The war essentially loads and shoves a bunch of libraries into the Tomcat parent classloader such that other webapps can then see them. It's non-deterministic, however, as webapps might have been loaded before that happens. The webapp would try to address that by restarting those webapps, which would of course introduce other complexities. -David > > On 4/17/21, 6:06 PM, "David Blevins" <david.blev...@gmail.com> wrote: > > Digging up this old discussion thread on removing the tomee-foo-webapp > modules. > > At the moment our TCK progress is essentially halted due to issues created > by the complexity of these webapps and how we build the server. > > The crux of the issue is that we're getting duplicate jars in our war > files which causes the TCK runs to encounter startup errors and fail before > any tests are run. Here's an example: > > $ curl -O > https://repository.apache.org/content/groups/snapshots/org/apache/tomee/apache-tomee/8.0.7-SNAPSHOT/apache-tomee-8.0.7-20210417.052409-158-plume.zip > > > $ unzip -l apache-tomee-8.0.7-20210417.052409-158-plume.zip | grep > cxf-core > 1431799 04-17-2021 05:23 > apache-tomee-plume-8.0.7-SNAPSHOT/lib/cxf-core-3.5.0-SNAPSHOT.jar > 1431799 04-17-2021 05:23 > apache-tomee-plume-8.0.7-SNAPSHOT/lib/cxf-core-3.5.0-20210417.035622-203.jar > > There are duplicates of basically any SNAPSHOT dependency. Sometimes > there'll be duplicates even of openejb-core. I've checked the sha256 hashes > on the duplicate jars like the above and in most cases they are different, > meaning we're getting two different builds of the SNAPSHOT showing up. > > When we go to run the TCK we encounter issues as there are parts of the > TCK that are standalone (no server) and we need to construct a classpath of > specific jars. That will fail like so: > > Caused by: java.lang.Exception: Found more than one file to be > included into path; dir=target/apache-tomee-plume-8.0.7-SNAPSHOT/lib, > includes=cxf-rt-rs-client-*.jar, excludes=null; found: > /Users/dblevins/work/apache/tomee-tck/target/apache-tomee-plume-8.0.7-SNAPSHOT/lib/cxf-rt-rs-client-3.5.0-20210417.035728-202.jar:/Users/dblevins/work/apache/tomee-tck/target/apache-tomee-plume-8.0.7-SNAPSHOT/lib/cxf-rt-rs-client-3.5.0-SNAPSHOT.jar > at sun.reflect.NativeConstructorAccessorImpl.newInstance0 (Native > Method) > at sun.reflect.NativeConstructorAccessorImpl.newInstance > (NativeConstructorAccessorImpl.java:62) > at sun.reflect.DelegatingConstructorAccessorImpl.newInstance > (DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance (Constructor.java:423) > at org.codehaus.groovy.reflection.CachedConstructor.invoke > (CachedConstructor.java:77) > at > org.codehaus.groovy.reflection.CachedConstructor.doConstructorInvoke > (CachedConstructor.java:71) > at > org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrap.callConstructor > (ConstructorSite.java:84) > at > org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor > (CallSiteArray.java:52) > at > org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor > (AbstractCallSite.java:192) > at > org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor > (AbstractCallSite.java:200) > at openejb.tck.util.PathBuilder.append (PathBuilder.groovy:89) > > What's worse is that this issue seems somewhat random. Sometimes you get > away with no duplicate jars. > > Additionally, if you need to rebuild the server binary (say plume) to test > a one line change it takes quite a while because we need to build several > binaries first. The tomee/tomee-webapp/ module builds a war that feeds into > the tomee/tomee-plume-webapp/ module which feeds into tomee/apache-tomee/ > which produces all the actual zips, tars. Here's how big the target > directories are for those three modules after a build: > > $ du -sh tomee/tomee-webapp/target/ tomee/tomee-plume-webapp/target/ > tomee/apache-tomee/target/ > 37M tomee/tomee-webapp/target/ > 206M tomee/tomee-plume-webapp/target/ > 1.1G tomee/apache-tomee/target/ > > Overall we produce 3.3GB in our build. To get your one-line change up to > the internet for a TCK run, you need to up load an insane amount of binaries. > On an EC2 box with extremely good internet connection it takes about 2 hours > to do a snapshot deploy. > > A snapshot that is broken and unusable. > > I think I can fix our duplicate jar issue and get things working, but FYI > that doesn't really fix our build. We'll need to do more serious work to get > that in shape. > > > -David > > >> On May 23, 2019, at 1:28 AM, David Blevins <david.blev...@gmail.com> wrote: >> >> We have a bit of unused legacy with regards to the following webapps: >> >> 34M tomee-microprofile-webapp-8.0.0-M3.war >> 58M tomee-plume-webapp-8.0.0-M3.war >> 51M tomee-plus-webapp-8.0.0-M3.war >> 6.6M tomee-webaccess-8.0.0-M3.war >> 32M tomee-webapp-8.0.0-M3.war >> >> From the early days of TomEE we created a "drop-in webapp" version for plain >> Tomcat users. This was largely for convenience to people who may have had >> to use a stock Tomcat in cloud or other environments. The idea being they >> could upgrade their Tomcat to a TomEE by dropping in the war. >> >> In practice, I don't believe anyone actually used it and we do not heavily >> test this technique. There is a known limitation that if your webapp starts >> before the "tomee" webapp, the integration will have to do a separate >> undeploy/redeploy of your webapp which is clunky. As well the magic >> required to load the tomee webapp's contents into the Tomcat server >> classloader is obtuse and complicates the integration. >> >> We should discuss removing them from TomEE 8.0. >> >> There'd be a bit of work involved, but it would trim a good 181MB from the >> release process. We have to upload that 181MB twice; once to Nexus and once >> to the Apache Mirror System staging repo. So in the end it reduces the >> upload overhead by 362MB, which is a big deal if you're on a network not >> blazingly fast. >> >> Thoughts? >> >> -- >> David Blevins >> http://twitter.com/dblevins >> http://www.tomitribe.com >> > > >
smime.p7s
Description: S/MIME cryptographic signature
