>I do believe that the same could be said for tapestry-cdi and by extension >FlowLogix >Magnus, can you comment on this? I think that you have to rely on a specific container's implementation to exclude classes from scanning and avoid conficts between CDI and Tapestry IOC. I can be wrong. Also, I didn't see how qualifiers are handled.
>Can you release an alpha version on maven central? will take a look on that even if it not in our priorities list at the moment >There is a case (EAR file, for example) >where some modules use CDI (beans.xml exists) and some don't (no beans.xml), >yet have the same classpath, i.e. have tapestry CDI module on the classpath. >This would cause the Tapestry module to fail, and stop the application startup >in its tracks. >This would be a big problem for us. >Hope that makes it clearer we need to test this use case >What about having Tapestry-IoC as a CDI portable extension which registers >T-IoC services as CDI beans? This way, we can still have the best of two >worlds without Tapestry-IoC implementing CDI and with way less work. Currently, CDI beans can be served as tapestry services but the opposite is not true. Your idea is interesting, need some investigation to see the feasability. >I am very glad to see CDI is supported in Tapestry, but I viewed the >pom.xml, it depended on openejb(not standard CDI api), and tomee(for test). To avoid "java.lang.ClassFormatError" during unit tests, we have to choose a specific api for javaee (standard api is crippled). See http://stackoverflow.com/questions/15518148/maven-javaee-api-vs-jboss-javaee-6-0. Maybe we could add some maven profiles for that. But we implement only standard CDI api (no code tied to openejb) and tomee is only used for tests. >I wish Apache DeltaSpike(which is the successor of MyFaces CODI and >JBoss Seam3 and others) can be considered as dependency, it is also from >Apache.org. yes, it's in our mind, especially since DeltaSpike just moved out of the apache incubator! >Besides @Inject, more features from CDI and Deltaspike can be considered. >1. CDI Event >2. Messages(fire message as event payload and Tapetry components observe >it and display it in page) >3. Conversation(I have asked such a question before, I dream there is a >simple solution to group several Tapestry pages to complete a wizard >like task easily) Totally agree. I hope those features for next releases (though, currently there is no explicit roadmap for that) --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
