Hello 2018-02-01 21:23 GMT+01:00 Marc Schlegel <[email protected]>:
> Awesome work Grzegorz > > Looking forward to a solution to this, even though the use-case in my > company died. > :) Personally, mixing CDI and OSGi is not very good idea... But if it can be done, I'll try. Currently I'm reviewing all pax-cdi itests and see if they work with my changes - so far, so good (at least with pax-exam-container-native) - even some previously @Ignored tests started working. The problem (now) is that pax-cdi 1.0.x is generally CDI 1.2, but it's being aligned with pax-web 6.x, which at the same time has some JDK9 improvements (ASM6 for example). Weld works well with ASM6 (doesn't need it at all), but It's Openwebbean version 2.x, that's designed for JDK9/ASM6, but it's CDI 2.0... Anyway - I'm pretty sure no one would wait for implementing given use case and no wonder it died ;) My personal favorite was (few years back) spring-MVC + Thymeleaf, but it's a different story. best regards Grzegorz Grzybek > > 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]>: >> >>> 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.Abstract >>> CdiContainer#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. > -- -- ------------------ 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.
