@john iIRC ASM should be shaded, not sure why it happends Am Freitag, 1. Dezember 2017 schrieb Matej Novotny :
> Doesn't look like the error I saw, for me deployment was OK but the test > failed (there was no redirection done on button click in the selenium test > so it then crashed with NoSuchElementException). > Haven't really dug deeper as I am rather unfamiliar with that module, just > found out what commits caused that. > > What I saw was similar to what TomEE fails with - > https://builds.apache.org/view/A-D/view/DeltaSpike/job/ > DeltaSpike_TomEE/1215/org.apache.deltaspike.modules$ > deltaspike-jsf-module-impl/ > > Matej > > ----- Original Message ----- > > From: "John D. Ament" <johndam...@apache.org <javascript:;>> > > To: dev@deltaspike.apache.org <javascript:;> > > Sent: Friday, December 1, 2017 4:40:24 PM > > Subject: Re: CI for DeltaSpike? > > > > I'm not sure if its the cause or not, but I see this when running the > > failing tests on wildfly 10.1 > > > > 10:31:46,124 WARN [org.jboss.modules] (Weld Thread Pool -- 6) Failed to > > define class > > org.apache.deltaspike.proxy.impl.AsmDeltaSpikeProxyClassGenerator$1 in > > Module "deployment.nav-event-uc001.war:main" from Service Module Loader: > > java.lang.NoClassDefFoundError: Failed to link > > org/apache/deltaspike/proxy/impl/AsmDeltaSpikeProxyClassGenerator$1 > (Module > > "deployment.nav-event-uc001.war:main" from Service Module Loader): > > org/objectweb/asm/ClassVisitor > > 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.jboss.modules.ModuleClassLoader.defineClass( > ModuleClassLoader.java:446) > > at > > org.jboss.modules.ModuleClassLoader.loadClassLocal( > ModuleClassLoader.java:274) > > at > > org.jboss.modules.ModuleClassLoader$1.loadClassLocal( > ModuleClassLoader.java:78) > > at org.jboss.modules.Module.loadModuleClass(Module.java:606) > > at org.jboss.modules.ModuleClassLoader.findClass( > ModuleClassLoader.java:190) > > at > > org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked( > ConcurrentClassLoader.java:363) > > at > > org.jboss.modules.ConcurrentClassLoader.performLoadClass( > ConcurrentClassLoader.java:351) > > at > > org.jboss.modules.ConcurrentClassLoader.loadClass( > ConcurrentClassLoader.java:93) > > at > > org.jboss.as.weld.WeldModuleResourceLoader.classForName( > WeldModuleResourceLoader.java:68) > > at > > org.jboss.weld.bootstrap.AnnotatedTypeLoader.loadClass( > AnnotatedTypeLoader.java:65) > > at > > org.jboss.weld.bootstrap.AnnotatedTypeLoader.loadAnnotatedType( > AnnotatedTypeLoader.java:60) > > at > > org.jboss.weld.bootstrap.FastAnnotatedTypeLoader.loadAnnotatedType( > FastAnnotatedTypeLoader.java:96) > > at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:98) > > at > > org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1. > doWork(ConcurrentBeanDeployer.java:65) > > at > > org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1. > doWork(ConcurrentBeanDeployer.java:62) > > at > > org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call( > IterativeWorkerTaskFactory.java:63) > > at > > org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call( > IterativeWorkerTaskFactory.java:56) > > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > > at > > java.util.concurrent.ThreadPoolExecutor.runWorker( > ThreadPoolExecutor.java:1149) > > at > > java.util.concurrent.ThreadPoolExecutor$Worker.run( > ThreadPoolExecutor.java:624) > > at java.lang.Thread.run(Thread.java:748) > > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > > > > 10:31:46,125 INFO [org.jboss.weld.Bootstrap] (Weld Thread Pool -- 1) > > WELD-000119: Not generating any bean definitions from > > org.apache.deltaspike.proxy.impl.AsmDeltaSpikeProxyClassGenerator > because > > of underlying class loading error: Type org.objectweb.asm.ClassVisitor > from > > [Module "deployment.nav-event-uc001.war:main" from Service Module > Loader] > > not found. If this is unexpected, enable DEBUG logging to see the full > > error. > > 10:31:46,126 INFO [org.jboss.weld.Bootstrap] (Weld Thread Pool -- 6) > > WELD-000119: Not generating any bean definitions from > > org.apache.deltaspike.proxy.impl.AsmDeltaSpikeProxyClassGenerator$1 > because > > of underlying class loading error: Type Failed to link > > org.apache.deltaspike.proxy.impl.AsmDeltaSpikeProxyClassGenerator$1 > (Module > > "deployment.nav-event-uc001.war:main" from Service Module Loader): > > org.objectweb.asm.ClassVisitor not found. If this is unexpected, enable > > DEBUG logging to see the full error. > > > > If that's the case, then it should be as simple as adding the missing > > libraries. > > > > On Fri, Dec 1, 2017 at 6:52 AM Thomas Andraschko < > > andraschko.tho...@gmail.com <javascript:;>> wrote: > > > > > @matej > > > You also reopened a issue that i created. > > > I'm currently in brasil, so i dont have time to look at it. > > > I removed this call as its actually not required and the wrapping in > > > PrimeFaces works fine. Not sure why it breaks navigation but we can > simple > > > revert it for this release. > > > > > > Am Freitag, 1. Dezember 2017 schrieb Gerhard Petracek : > > > > > > > hi matej, > > > > > > > > imo the main point here is that in the past we received too many > wrong > > > > failures and almost no commit really broke the backward > compatibility. > > > > > > > > regards, > > > > gerhard > > > > > > > > > > > > > > > > 2017-12-01 11:49 GMT+01:00 Matej Novotny <manov...@redhat.com > <javascript:;> > > > > <javascript:;>>: > > > > > > > > > Hi Gerhard, > > > > > > > > > > > i'm not sure if others are still following it. at the time i did > the > > > > > > releases, it was a mandatory step. > > > > > > > > > > Yes, I hope nobody releases without actually testing it at all. > > > > > But this check IMO comes too late - there are multiple "fixes" > present, > > > > > where the author apparently didn't even execute the tests. > > > > > Checking this before release means you bump into problems with > issues > > > > > which were "fixed" six months ago. > > > > > Hence I am suggesting whether we shouldn't look into some more > flexible > > > > > approach. > > > > > I know Travis still isn't quite the thing beucase of the > structure, I > > > am > > > > > just trying to start a discussion here and see how people view > thing - > > > > > maybe I am just weird with my requirements :) > > > > > > > > > > > back then i also added ci-jobs for new owb/weld releases > immediately. > > > > > > (it looks like nobody took over that part.) > > > > > > > > > > Would be great if this was still done, every new weld release is > > > > announced > > > > > directly on DS mailing list, so it's just about updating it. > > > > > > > > > > > > > > > Matej > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Gerhard Petracek" <gpetra...@apache.org <javascript:;> > <javascript:;>> > > > > > > To: dev@deltaspike.apache.org <javascript:;> <javascript:;> > > > > > > Sent: Thursday, November 30, 2017 3:32:04 PM > > > > > > Subject: Re: CI for DeltaSpike? > > > > > > > > > > > > hi matej, > > > > > > > > > > > > one of the (manual) steps for a release is to check those results > > > > > (before a > > > > > > release gets started at all). > > > > > > i'm not sure if others are still following it. at the time i did > the > > > > > > releases, it was a mandatory step. > > > > > > back then i also added ci-jobs for new owb/weld releases > immediately. > > > > > > (it looks like nobody took over that part.) > > > > > > > > > > > > regards, > > > > > > gerhard > > > > > > > > > > > > > > > > > > > > > > > > 2017-11-30 14:59 GMT+01:00 Romain Manni-Bucau < > rmannibu...@gmail.com <javascript:;> > > > > <javascript:;>>: > > > > > > > > > > > > > Sorry Matej, I don't get how Travis would help since you can > do the > > > > > > > same with jenkins which is already configured. > > > > > > > > > > > > > > Having the default build running on both weld and OWB would be > more > > > > > > > beneficial IMHO, but it is just the opinion from my side of the > > > fence > > > > > > > and experience. > > > > > > > > > > > > > > Romain Manni-Bucau > > > > > > > @rmannibucau | Blog | Old Blog | Github | LinkedIn > > > > > > > > > > > > > > > > > > > > > 2017-11-30 14:57 GMT+01:00 Matej Novotny <manov...@redhat.com > <javascript:;> > > > > <javascript:;>>: > > > > > > > > Thanks, but it was more of a rhetorical question (you saved > me > > > some > > > > > > > digging though). > > > > > > > > Still my claim holds true, nobody cares about them much. They > > > must > > > > > have > > > > > > > been failing for quite some time now > > > > > > > > Not to mention they aren't even updated to latest Weld > version > > > (or > > > > > > > WildFly version for that matter). > > > > > > > > > > > > > > > > > > > > > > > > Matej > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > >> From: "Romain Manni-Bucau" <rmannibu...@gmail.com > <javascript:;> > > > <javascript:;>> > > > > > > > >> To: dev@deltaspike.apache.org <javascript:;> <javascript:;> > > > > > > > >> Sent: Wednesday, November 29, 2017 5:03:02 PM > > > > > > > >> Subject: Re: CI for DeltaSpike? > > > > > > > >> > > > > > > > >> Hi Matej, > > > > > > > >> > > > > > > > >> they are all on the ASF jenkins: > > > > > > > >> https://builds.apache.org/view/A-D/view/DeltaSpike/ > > > > > > > >> > > > > > > > >> Romain Manni-Bucau > > > > > > > >> @rmannibucau | Blog | Old Blog | Github | LinkedIn > > > > > > > >> > > > > > > > >> > > > > > > > >> 2017-11-29 16:47 GMT+01:00 Matej Novotny < > manov...@redhat.com <javascript:;> > > > > <javascript:;>>: > > > > > > > >> > Hello > > > > > > > >> > > > > > > > > >> > I wanted to bring up a topic of CI (Continuous Irritation > - > > > eh, > > > > I > > > > > > > meant > > > > > > > >> > Integration OFC) and DeltaSpike. > > > > > > > >> > Apparently, there is no such thing now and even while > some CI > > > > jobs > > > > > > > exist > > > > > > > >> > (where are they, anyway?), nobody really pays attention to > > > them. > > > > > > > >> > I mean those for Weld ones must have been failing for few > > > months > > > > > and > > > > > > > yet > > > > > > > >> > the JIRAs causing that were happily marked as Resolved. > > > > > > > >> > Meaning whoever fixed that probably only ran smoke tests > with > > > > OWB. > > > > > > > >> > > > > > > > > >> > Today I noticed there is going to be a release soon and > so I > > > > > quikly > > > > > > > went to > > > > > > > >> > check how the build/tests fare with Weld profiles. > > > > > > > >> > Turned out to be a disaster. So I then have to spend > > > > considerable > > > > > time > > > > > > > >> > backtracking the changes and figuring out the actual > problem. > > > > > > > >> > And it's not the first time this happened either. > > > > > > > >> > > > > > > > > >> > Therefore I wanted to bring up the topic of CI to avoid > this > > > in > > > > > the > > > > > > > future. > > > > > > > >> > The ideal scenario is sending PRs and having them checked > > > > *before* > > > > > > > merging > > > > > > > >> > - obviously not an option here. > > > > > > > >> > The GH repo is but a mirror (something we have to stick > to I > > > > > presume) > > > > > > > which > > > > > > > >> > makes it more complex, but still, it should be possible > to set > > > > up > > > > > a > > > > > > > Travis > > > > > > > >> > build on GH master which will execute after every sync. > > > > > > > >> > That way the failures would be readily visible (via the > travis > > > > > status > > > > > > > >> > "button"). > > > > > > > >> > In order to discover most problems there is no need for a > > > > complete > > > > > > > test > > > > > > > >> > matrix, it would do to just have two version of OWB and > Weld > > > > > without > > > > > > > EE > > > > > > > >> > container (with just the Arq. one). > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > A penny for your thoughts? > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > Regards > > > > > > > >> > Matej > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > >