[ https://issues.jboss.org/browse/CDI-299?page=com.atlassian.jira.plugin.sy... ] Jozef Hartinger commented on CDI-299: ------------------------------------- As for the performance concerns I think it should be easy to detect all vetoed packages upfront using bytecode scanning. This would probably be more difficult for environments where bytecode scanning is not available. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-299?page=com.atlassian.jira.plugin.sy... ] Mark Struberg edited comment on CDI-299 at 11/19/12 7:29 AM: ------------------------------------------------------------- Jozef, the reason why I brought this up in the EG meeting was because it's imo not that easy to do via bytecode scanning. At least not in a well performing way. How does the scanning work: you open one jar after the other, unzip it in memory and scan it. The problem now arises if you have the @Vetoed information in a jar which only gets scanned later. I actually really like the feature, but currently we would need to do a classForName for each package (bypassing the bytecode level scanning). Basically it can't be done in a single pass! There are 2 ways: either use some information in beans.xml as Martin said. Or we could define the following: "If @Vetoed is used on a package and the same package exists in more than one classpath entries, non portable behaviour results." A user could btw prevent this with an entry in a MANIFEST.MF file: {code} Name: com/mycompany/myproject/packagename Sealed: true {code} http://docs.oracle.com/javase/tutorial/deployment/jar/sealman.html It will become trickier if we add the 'recursive' feature (which is imo also very useful) as there is no Java JAR-sealing for sub-packages. was (Author: struberg): Jozef, the reason why I brought this up in the EG meeting was because it's imo not that easy to do via bytecode scanning. At least not in a well performing way. How does the scanning work: you open one jar after the other, unzip it in memory and scan it. The problem now arises if you have the @Vetoed information in a jar which only gets scanned later. I actually really like the feature, but currently we would need to do a classForName for each package (bypassing the bytecode level scanning). Basically it can't be done in a single pass! There are 2 ways: either use some information in beans.xml as Jozef said. Or we could define the following: "If @Vetoed is used on a package and the same package exists in more than one classpath entries, non portable behaviour results." A user could btw prevent this with an entry in a MANIFEST.MF file: {code} Name: com/mycompany/myproject/packagename Sealed: true {code} http://docs.oracle.com/javase/tutorial/deployment/jar/sealman.html It will become trickier if we add the 'recursive' feature (which is imo also very useful) as there is no Java JAR-sealing for sub-packages. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-299?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-299: ----------------------------------- {quote} You can use bytecode scanning to create an annotation index for the entire deployment upfront {quote} And that would introduce a 2-pass scanning ;) It's really a pathhologic edge case ('freak case') so I think it's fine to declare it non-portable if spread over multiple jars. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-299?page=com.atlassian.jira.plugin.sy... ] Pete Muir edited comment on CDI-299 at 11/20/12 11:45 AM: ---------------------------------------------------------- I think it's reasonable to introduce but make it non-portable if people don't seal their jars. was (Author: pmuir): I think introducing something like, but making it non-portable is a bit confusing. Hmm. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/CDI-299?page=com.atlassian.jira.plugin.sy... ] Pete Muir updated CDI-299: -------------------------- Fix Version/s: 1.1 (Proposed) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira