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>:
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