@adrian: i would keep it simple -> a global config (per application). @mark: #1 we don't need to introduce a full scanning process #2 if you don't need it and you have a problem with the performance impact during the bootstrapping process (>might< be the case in a >very< large project), you can deactivate the extension #3 @Veto vs * is a different thread (this idea is just related)
regards, gerhard 2011/12/28 Mark Struberg <[email protected]> > CDI treats each and every class which doesn't have an explicite scope as > @Dependent. > I also really dislike this, but we cannot easily change this in the spec > now as it would break backward compatibility. > > > You can basically exclude beans already in CDI-1.0 by using the @Typed() > annotation. > > The problem is that this is pretty un-intuitive and not well known. But it > works well in all containers and doesn't even need any Extension. > > That's the reason why I'm not happy with any other name than @Veto. And > @Veto only for compat reasons with Seam3. All other names are just equally > worse and it would be easier to spread the word about @Typed() > > The 'auto-exclude' is a new thing of course. It allows to exclude whole > packages, but I fear this might be error prone. > > > Btw we should try to minimize our own annotation scanning as it a.) costs > PermGenSpace and b.) costs time. > > LieGrue, > strub > > > > ----- Original Message ----- > > From: Adrian Gonzalez <[email protected]> > > To: "[email protected]" < > [email protected]> > > Cc: > > Sent: Wednesday, December 28, 2011 8:19 AM > > Subject: Re : [DISCUSS] config based exclude > > > > Hello, > > > > 1. just to confirm : this functionnality would be enabled per JAR > (beans.xml ?) > > > > 2. wouldn't it be interesting to add something link exclude-annotation ? > > CDI would the ignore classes marked with those annotations. > > This could benefit some use cases like Spring / CDI integration when user > > annotates Spring beans with= @Service, @Repository, @Controller, > @Component [1]. > > > > > > 3. exclude-package : is it a list of regexp (could be usefull to ignore > entity > > in only one line : .*\.domain for > > com.sample.client.domain, com.sample.salary.domain, etc...) ? > > > > > > > > [1] see http://static.springsource.org/spring/docs/3.1.x/spring-frame= > > work-reference/html/beans.html#beans-stereotype-annotations > > > > > > > > ________________________________ > > De : Gerhard Petracek <[email protected]> > > À : [email protected] > > Envoyé le : Mercredi 28 Décembre 2011 1h56 > > Objet : [DISCUSS] config based exclude > > > > hi @ all, > > > > i've seen a lot of objections concerning the specified behaviour that > every > > (non-abstract) class in a cdi archive is a bean managed by the cdi > > container. > > that's basically a topic for the cdi spec. itself, however, we can also > > think about an additional feature for the bda-impl module of deltaspike. > > > > since we are going to discuss a low-level config [1] which is also > > available during the bootstrapping process of a cdi container, we could > > think about introducing something like: > > "exclude-package" and "auto-exclude" > > > > auto-exclude would #veto all classes without an explicit scope annotation > > (the default scope is Dependent - but if auto-exclude is activated a > > default scope wouldn't be supported. the problem with such a default > scope > > is that you don't know if it is intended that there isn't a specified > > scope.) > > > > regards, > > gerhard > > > > [1] https://issues.apache.org/jira/browse/DELTASPIKE-36 > > >
