Awesome work Grzegorz Looking forward to a solution to this, even though the use-case in my company died.
Am Dienstag, 30. Januar 2018 13:13:34 UTC+1 schrieb Grzegorz Grzybek: > > Actually... I got it working! (MyFaces, Weld, pax-cdi and pax-web-jetty) - > it was my fault with proxies for annotations. > > But "What I had to change" is still valid - I can try proposing a PR with > these changes and ask for review. > > best regards > Grzegorz Grzybek > > 2018-01-30 11:45 GMT+01:00 Grzegorz Grzybek <[email protected] > <javascript:>>: > >> Hello >> >> I wanted to share my recent experience related to >> https://ops4j1.jira.com/browse/PAXCDI-210 (JSF Beans cannot be resolved). >> >> What I wanted to do is to run simple(st) example with @Named, >> @RequestScoped managed bean accessible from JSF/facelets/EL. >> >> After several major changes (which I hate) I got the example working >> (which required lots of insight into how it works in plain Tomcat + Weld + >> Myfaces), BUT I wasn't able to @Inject a @org.ops4j.pax.cdi.api.Service to >> my bean. I gave up after seeing that weld is trying to compare real >> annotation class (@org.ops4j.pax.cdi.api.Component) with com.sun.Proxy... >> >> What I had to change? >> - in pax-web I had to carefully sort >> org.ops4j.pax.web.service.jetty.internal.HttpServiceContext#servletContainerInitializers >> >> field, to ensure that CDI is "run" before JSF >> - in pax-web, I had to disable tldScanning for additional (declared in >> *.tld) <listener>s and move that part to >> org.ops4j.pax.web.jsp.JasperInitializer >> - org.ops4j.pax.web.service.spi.model.ContextModel#containerInitializers >> has to be *linked* hashMap >> - in pax-web event listeners have to be removed in the context of web >> app's classloader >> - in pax-web, >> org.ops4j.pax.web.extender.war.internal.model.WebApp#addListener() has to >> skip duplicates (I saw several other duplicates for listeners, EL >> resolvers, etc and I didn't have time to fix it) >> - in pax-cdi, >> org.ops4j.pax.cdi.spi.AbstractCdiContainer#contextClassLoader has to be >> carefully chosen - I checked that if we're in the context of pax-web, we >> have to take existing TCCL from pax-web >> (org.ops4j.pax.web.service.spi.util.ResourceDelegatingBundleClassLoader) >> and just add CDI provider bundle to it - otherwise CDI.current() won't work >> (JSF won't find it) >> - in pax-cdi only pax-cdi-undertow-weld had correct JSF integration - I >> had to move it to pax-cdi-weld (Weld → JSF → EL integration, as described >> in http://docs.jboss.org/weld/reference/latest/en-US/html/ri-spi.html, >> A.2.4) >> - pax-cdi-jetty-weld didn't pass correct "org.ops4j.pax.cdi.BeanManager" >> context attribute >> - weld 2.4.6.Final started to require javax.ejb package - weld >> 2.4.5.Final works fine >> - pax-cdi-extensions actually had to export the packages of both >> extensions and my sample WAR bundle had to import them explicitly (I used >> DynamicImport-Package for pax-cdi, weld and myfaces packages) >> >> Summarizing - are there any plans to release pax-cdi 1.0.0.GA at some >> point? For me we're not there yet - it's still not working well. JSF itself >> is IMO a mess full of statics (it's personal opinion, as I've never liked >> JSF, so please excuse me) which are not very OSGI friendly. >> >> I'm also not sure how aries-cdi project goes and at what stage it is and >> how it can be compared to pax-cdi. >> >> What do you think? >> >> best regards >> Grzegorz Grzybek >> > > -- -- ------------------ OPS4J - http://www.ops4j.org - [email protected] --- You received this message because you are subscribed to the Google Groups "OPS4J" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
