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]>: > 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.jett > y.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.JasperIn > itializer > - 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.
