yup, the webapp was always kind of a a half baked solution imo. When you just need CDI, then one can use OWB natively in the app on an unmodified Tomcat. If one needs the fully blown EE features, then TomEE is a perfect fit and well tested. I think the complexity added with the web app dropin is not justified by the benefits.
LieGrue, strub > Am 18.04.2021 um 01:06 schrieb David Blevins <david.blev...@gmail.com>: > > 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 >> >
