+1 We should only make sure, that a related JIRA issue (with a link to this mail threaD) is added to the (next) release logs, so users can understand the rational behind the decision.
Gruss Richard Am Sonntag, den 18.04.2021, 22:50 +0200 schrieb Jean-Louis Monteiro: > Agreed with all > > Le dim. 18 avr. 2021 à 21:37, Mark Struberg < > strub...@yahoo.de.invalid> a > écrit : > > > 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.doConstructorInvok > > e > > (CachedConstructor.java:71) > > > at > > org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSit > > eNoUnwrap.callConstructor > > (ConstructorSite.java:84) > > > at > > org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConst > > ructor > > (CallSiteArray.java:52) > > > at > > org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstruct > > or > > (AbstractCallSite.java:192) > > > at > > org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstruct > > or > > (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
