> CDI should not mess with Tapestry-controlled classes at all. They're not > meant to be injected in other objects and Tapestry-IoC already takes care of > dependency injection. > Isn't there any way to prevent packages from being touched by CDI? In Weld?
Yes.. it should not, but it does if you activate it with the empty beans.xml. See this blog entry from Gavin (and my comment). -> http://in.relation.to/13347.lace >> * implementing JSR-330 alone could be dangerous, because in this >> case two IoC containers will try to handle the same annotation as soon >> as the beans.xml file is present. > > Implementing JSR-330, to me, equals to make Tapestry implement JSR 330 > itself, not using any other container to do that. Yes, that was what I meant. But if Tapestry IoC implements JSR 330, there are two DI frameworks that feel responsible. (CDI is using JSR 330 as well). Right now CDI does not try to inject beans into tapestry managed classes .. but after implementing JSR 330 this will change... >> Of course, if you split out the CDI beans into their own jar, >> everything is fine (just provide the beans.xml file there and not in >> the webapp). > > This is far from ideal, as we would need to package the classes before > running or testing the application. Totally agree with you. >> In my understanding we need to go over the tapestry >> MasterObjectProvider to be able to inject the beans then. Where I am >> now is that I contribute an ObjectProvider which queries CDI for the >> objectType and returns it if successfull. This seems to work. > > Have you looked at how the Spring integration is implemented? Yes - that's where I looked to even find a start. But CDI is quite different in that it does not mean to bootstrap itself... that means no custom ServletFilter is needed. > Have you tried a try/catch block around return objectType.cast(bean)? This > should provide a better error message. Nope, thanks for the hint. I will try this tonight. Piero --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
