Reverted my commit for now, will check it again in 2.0. Tests are looking now good again with TomEE.
2017-12-01 19:32 GMT+01:00 Thomas Andraschko <[email protected]>: > @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/Delta >> Spike_TomEE/1215/org.apache.deltaspike.modules$deltaspike- >> jsf-module-impl/ >> >> Matej >> >> ----- Original Message ----- >> > From: "John D. Ament" <[email protected]> >> > To: [email protected] >> > 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(Native >> ConstructorAccessorImpl.java:62) >> > at >> > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(De >> legatingConstructorAccessorImpl.java:45) >> > at java.lang.reflect.Constructor.newInstance(Constructor.java:423) >> > at >> > org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassL >> oader.java:446) >> > at >> > org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleCla >> ssLoader.java:274) >> > at >> > org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleC >> lassLoader.java:78) >> > at org.jboss.modules.Module.loadModuleClass(Module.java:606) >> > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoa >> der.java:190) >> > at >> > org.jboss.modules.ConcurrentClassLoader.performLoadClassUnch >> ecked(ConcurrentClassLoader.java:363) >> > at >> > org.jboss.modules.ConcurrentClassLoader.performLoadClass(Con >> currentClassLoader.java:351) >> > at >> > org.jboss.modules.ConcurrentClassLoader.loadClass(Concurrent >> ClassLoader.java:93) >> > at >> > org.jboss.as.weld.WeldModuleResourceLoader.classForName(Weld >> ModuleResourceLoader.java:68) >> > at >> > org.jboss.weld.bootstrap.AnnotatedTypeLoader.loadClass(Annot >> atedTypeLoader.java:65) >> > at >> > org.jboss.weld.bootstrap.AnnotatedTypeLoader.loadAnnotatedTy >> pe(AnnotatedTypeLoader.java:60) >> > at >> > org.jboss.weld.bootstrap.FastAnnotatedTypeLoader.loadAnnotat >> edType(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(It >> erativeWorkerTaskFactory.java:63) >> > at >> > org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(It >> erativeWorkerTaskFactory.java:56) >> > at java.util.concurrent.FutureTask.run(FutureTask.java:266) >> > at >> > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPool >> Executor.java:1149) >> > at >> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo >> lExecutor.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 < >> > [email protected]> 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 <[email protected] >> > > > <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" <[email protected] <javascript:;>> >> > > > > > To: [email protected] <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 < >> [email protected] >> > > > <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 <[email protected] >> > > > <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" <[email protected] >> > > <javascript:;>> >> > > > > > > >> To: [email protected] <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 < >> [email protected] >> > > > <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 >> > > > > > > >> >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> >
