[cdi-dev] [JBoss JIRA] (CDI-299) Consider removing @Vetoed on packages

Mark Struberg (JIRA) jira-events at lists.jboss.org
Mon Nov 19 07:31:21 EST 2012


    [ https://issues.jboss.org/browse/CDI-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12735241#comment-12735241 ] 

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.

                  
> Consider removing @Vetoed on packages
> -------------------------------------
>
>                 Key: CDI-299
>                 URL: https://issues.jboss.org/browse/CDI-299
>             Project: CDI Specification Issues
>          Issue Type: Bug
>            Reporter: Pete Muir
>
> What happens when a package is split across jars? What about recursing into 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



More information about the cdi-dev mailing list