-
1. Re: bean discovery question
Hello,
it is indeed all about discovery mode. Do give a read to this part of specification.
With annotated mode set to "all", Weld will attempt to convert everything it can into a bean. As for what it can convert, that is also defined by specification (here).
On the other hand with mode "annotated" it will only look for classes with so called bean defining annotations.
You can also specify some exclude filters in beans.xml to prevent certain classes/packages from being turned into beans.
Although I would suggest to use "annotated" discovery mode instead as it is just much easier to control what becomes a bean.
As for DeltaSpike - I don't know what parts of DS are you using but many of them have been reimplemented as parts of MicroProfile specification and you might be better off using that, so take a look around.
DeltaSpike tries to stay compatible with older CDI versions (up to 1.0 I think?) which often presents annoying obstructions because many additional and often used features were only introduced later on in CDI lifetime. My guess (but it's just a guess!) is that the problem you are seeing lies in the fact that CDI 1.0 didn't yet have "annotated" mode therefore DS heavily relies on all classes being automatically picked up as beans.
-
2. Re: bean discovery question
manovotn thanks for the elaborate answer.
I am actually using delta spike for scheduling purposes only. I like being able to schedule jobs staying clear of specific implementations. I use tomcat with a web app so I do not thing the EJB timer annotations can be used there.
do you know of any CDI replacement? I am trying to asses moving from spring to a cdi container for DI purposes.
whats also strange is that in most places I read that 'all' is the better way to go and that its also a default which is super strange to me. this will make almost all classes CDI beans.
also strange is that the sepc went with black listing style (exclude) and neglected white list style. as in my case, its a lot easier to say what package I want to include as CDI beans rether than say what I want to exclude.
your thoughts?.
-
3. Re: bean discovery question
If it's scheduling, you could take a look at things like Quartz. I am not sure about their CDI integration though as I haven't used that much.
About 'all' being considered better - it is popular, I suppose because it requires no effort to make it run that way. That's it's default is because CDI 1.0 had only this mode and for backward portability reasons, that cannot be changed.
Also, Weld is lazy so while there are potentially lots of beans, Weld will create none until they are requested for the first time.
It sure effects boot time time though, a lot of scanning and metadata processing has to be done.
About blacklisting - again, "all" was first and was default, so with everything being included, it was natural to introduce exclusions. Although all of this happened before I was involved so I am just guessing
Furthermore CDI extensions allow you to register a lot of additional beans so that kind of overlaps with what whitelisting would do.
-
4. Re: bean discovery question
on a side note,
its puzling that there are so little extension libraries out there. being new to CDI I thought I would find tons of them. I wonder why there arent so many.
also, web container deployment seem to be the odd one out. SE got its own section in 2.0, EE has many more options (such as scheduling) and web app only kinda stuck in the middle without anything special
-
5. Re: bean discovery question
You are spot on, CDI specification defines EE and SE compatibility, when it comes to servlet, that's actually unsupported and it's basically a Weld feature.
As for libraries, they saw little success because you usually don't want to pull in huge library just do achieve one little thing.
Oftentimes it is also easy to just write that one capability yourself via some extension.
Rather then standalone libraries, many other specs or technologies offer some CDI integration or capabilities.