Re: [DISCUSS] Retiring the "tomee" webapps from TomEE 8

[Zowalla, Richard]

+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/
> > >

Re: [DISCUSS] Retiring the "tomee" webapps from TomEE 8

[Jean-Louis Monteiro]

Agreed with all

Le dim. 18 avr. 2021 à 21:37, Mark Struberg  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 :
> >
> > 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 
> wrote:
> >>
> >> We have a bit of unused legacy with regards to the following we

Re: TOMEE-3722 - Translate to Spanish: examples/rest-xml-json/

[Daniel Dias Dos Santos]

Hello Evaldo,

done, thanks :)

Em sáb., 17 de abr. de 2021 às 23:03, Evaldo Junior <
evaldoapjun...@gmail.com> escreveu:

> I created the issue on the JIRA [1] to translate to spanish of the document
> examples/rest-xml-json.
> Can some of the JIRA admins please assign the ticket to my
> username:evaldoapjunior
>
> [1]https://issues.apache.org/jira/browse/TOMEE-3722
> 
>
>
> Best Regards,
>
>
> Evaldo Junior
>

Re: [DISCUSS] Retiring the "tomee" webapps from TomEE 8

[Mark Struberg]

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