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

Reply via email to