Re: [cdi-dev] thoughts about CDI-377

Hi Antoine, It is surely better to activate CDI on demand for sure but I think we should be able to configure (using a shared spec across EE) jar to include/exclude in scanning (jar names and not packages). Propagate solution seems something hard to maintain/use in real life IMHO. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau 2014-02-13 13:38 GMT+01:00 Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt;: > Hi all, > > > Yesterday someone asked me why he couldn't deploy hawtio [1] in Wildfly without having a crash full of weld exceptions. He couldn't understand why he was having CDI related error on an app that contains no CDI stuff. I orientated him to Wildfly settings[2] to indicate how he could turn off implicite Bean Archive. I also had to tell him that he should do something else if he want the app to turn on Glassfish and something else when it'll be deployed on the future Java EE 7 TomEE version. > > One of the implicit jar in the hawtio.war that triggers CDI and thus make the app crash (thanks to CDI-377) is 'sisu-inject-plexus-2.3.4.jar' coming from sonatype plexus framework I guess. First time I see this dependency... > > Right now the idea to solve CDI-377 is to add exclusion list at the implementation level. But I'm quite sure that 'sisu-inject-plexus-2.3.4.jar' would be forgot on such a list as lot of other libs. So for me this approach is flawed and totally useless. It's a non sense to have to maintain a list of all lib including JSR 330 annotation that are not CDI ! > > I really think we should provide a solution at spec level for CDI-377. > > Right now I have 2 suggestion : > > 1) Revert back default bean discovery type to 'none' > It'll be the easiest way to fix this (one word to change in the spec and probably a few line and tests in the impl / TCK). It'll fix the compatibility issue we have with CDI 1.0 (remember guava team explaining that cannot support CDI 1.0 and 1.1 at the same time). > The only drawback would be that user should explicitly activate CDI in their app as they have to do with CDI 1.0. Perosnaly I think it's better to tell people to add a beans.xml in their own app/lib than explaining them how to hack all jar in their app or use a proprietary config on their server to stop an engine they didn't intend to use. > > > 2) Provide new propagation attribute on bean element in beans.xml > so when I put > <beans version="1.1" bean-discovery-mode="none" propagate="true" > > it would propagate the << none >> to all bean archive without beans.xml > I guess this solution is harder to implement and that it is not working for EAR packaging so that's not my favorite. > > Thanks for your feedback on that. > > Antoine > > > [1] http://hawt.io > [2] https://docs.jboss.org/author/display/WFLY8/CDI+Reference > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev