Studying Seam 3, I discovered that Seam Solder allows the @Named
annotation to be applied to packages - in that case, all beans in this package will be automatically named, as if they were qualified with @Named
themselves. I didn't see too much advantages on doing something like this (and you can point me some situations where it can be useful!) but it made me wonder: wouldn't it be reasonable to CDI (or Seam Solder) to allow arbitrary qualifiers to be applied to packages as well, maintaining the same semantics of this @Named
qualifier? Is it a possible functionality in future versions of the CDI specification? Is there a reason for not allowing it?

- 26,083
- 8
- 103
- 158
1 Answers
I didn't see too much advantages on doing something like this (and you can point me some situations where it can be useful!)
@Named
(as you certainly know) makes a managed bean accessible from within JSF pages. Applied on package level it will simply assign an EL name to all beans in that package. While I agree with you that this is certainly not a killer feature, I can imagine that quite often everything within a certain package needs to be accessed via EL. Of course it's another question if annotating all beans individually wouldn't be better in terms of readability.
wouldn't it be reasonable to CDI (or Seam Solder) to allow arbitrary qualifiers to be applied to packages as well, maintaining the same semantics of this @Named qualifier?
@SomeQualifier
would apply the same qualifier to all beans in the package. Contrary to @Named
I can hardly imagine that this would make much sense - looking back on a couple of CDI projects in the last year, I think I never had a package where all beans in it required the same qualifier. Kind of makes extra sense if you remember that qualifiers are meant for loose coupling of components... (Say you have an interface with three implementations - almost certainly those would belong into different packages or even jars)

- 14,039
- 5
- 40
- 55
-
I would hardly use `@Named` in a package given the point you cited: readability. OTOH, I can realize a package with various close implementations (let's say, `LDAPAuthenticator`, `LDAPQuery`, `LDAPConnector`) for various related interfaces (`Authenticator`, `Query`, `Connector`). In this case, I would happily qualify the package - even because the own package would document the "LDAP nature" of the classes. Doesn't it sound reasonable? BTW, I do not know the `@SomeQualifier` - do you have any link about it? – brandizzi Sep 12 '11 at 00:52
-
Hm. I see. I personally would discourage such a methodology (IMHO it's dangerously close to "I'm grouping my classes in a certain way for the only reason that it saves me a qualifer"), plus the ldap-nature of the bean types could already be expressed by the type name itself and/or corresponding package name. Anyhow, such a thing should be relatively easy achievable through a CDI extension (scan bean types at startup and see if any package-qualifiers are to be applied)... Oh, `@SomeQualifer` is documented next to `@IJustNeededAQualiferNameForTheExample` :-) – Jan Groth Sep 12 '11 at 04:27
-
Ah, now everything makes sense about this revolutionary annotation :) BTW, the way I purposed to organize my beans is the way I feel the more natural, personally. I would never use it just to avoid some annotations. Anyway, I think you gave me a good answer about why people do not think a lot about qualifying packages. More opinions would be welcomed but your answer is accepted :) – brandizzi Sep 12 '11 at 13:32