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 - ops4j@googlegroups.com --- 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 ops4j+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
