-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Draft Lite version of BeanManager. #471
Conversation
The set of methods you chose looks good to me. I've briefly pondered |
Looks reasonable to me, and reflects what I am able to implement right now for build time annotation processing |
FTR I have verified (with |
I was wondering if we could come up with a name that would naturally be a "subset" of the I was thinking maybe |
Hmm, I like the notion of That being said, I agree that |
I think |
Similar to @manovotn , I prefer the name shows the relationship with the other Bean Manager. How about |
|
* CDI Lite users should primarily use this version of bean manager but can choose to use standard {@link BeanManager} | ||
* as well. However, some of it's methods will not work. | ||
*/ | ||
public interface BeanManagerLite { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Further to the discussion, I think both Graeme and I prefer CoreBeanManager
.
Hmm; a |
|
Right; I'm aware of what is intended but I think all these alternatives—the one proposed, What about something like Regardless, I urge treading very carefully here: when names aren't crystal clear, sometimes that means the underlying concepts can end up not being crystal clear either. |
I used similar reasoning when proposing I very much agree that Another option -- the new extension API is currently dubbed |
With the above said, would Just FTR, the logic used in comments above is good. However, our currently existing That being said, I am not against either proposal so long as it contains reasonable degree of familiarity. |
One quick opinion: don't use "lite" in the API, specification or documentation. It would create a world in which there would be heavy stuff and light stuff, and misspells "light" in a way that evokes mid-20th-century American advertising of cheap goods designed to fail quickly, and bakes it into the API signature itself. Almost any other option would be better. |
The other options I have: |
Just noticed there's |
Yeah, good point. I'll add it to this PR (with the current naming, we'd need to change that on multiple places and we don't seem to have an agreement on the name yet). |
* @throws IllegalStateException if called during application initialization, before the {@link AfterBeanDiscovery} | ||
* event is fired. | ||
*/ | ||
List<Interceptor<?>> resolveInterceptors(InterceptionType type, Annotation... interceptorBindings); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was also wondering -- do we actually want these 2 methods (resolveObserverMethods
and resolveInterceptors
)? I know we implement them in Quarkus, but they sound a bit too runtime-oriented.
Thanks! I added one comment about 2 methods about which I'm not sure. One other thing is -- on a few places, we mention JNDI, which we probably want to remove from Also, on a few places in |
Not sure either. I added it because without portable extensions, this might be the only way to get your hands on interceptor/OMs.
I see what you mean, but I am not sure it's worth the hassle. We'd probably need to copy the method into original BM as well with the original wording. Then again, something like
Will do. However, note that the very same method can then be used from standard BM which will make the wording awkward again. So I'd probably replace it by |
@Ladicek, I've added some class javadoc and changed the occurrences of EDIT: also rebased on master to fix conflict in BM API I didn't touch the JNDI yet because I am not sure we need to tackle it if it was there even now for all CDI envs. Alternatively, we could change the sentence into something like:
That being said, the wording above (and the one currently in PR) would imply that you can obtain |
My vote is still for |
@manovotn Given that As for JNDI, we could possibly restrict it to Jakarta EE. (In the spec split, I have currently put it into CDI Full, but we could easily move it to Jakarta EE part as well.) Something like
But what you have, with CDI Full, seems fine as well. |
Updated accordingly to the suggestion. |
…ion from CDI class.
As more people lean towards |
This should be ready for merge - soon as it gets a green stamp. |
This is a first version of the Lite variant of BM - related to #469
It contains a subset of methods from original BM that would be guaranteed to run under CDI Lite restrictions all the while giving user an API that doesn't return
UnsupportedException
on any of its methods.Note that the idea is that Lite users would be encouraged to use this Lite BM variant but they won't be blocked from using full blown
BeanManager
if they choose to (but some methods will throw exceptions). This is due to the fact that implementations can choose to implement more functionalities than Lite requires.Any future changes that would want to add more methods from classic BM to its Lite counterpart are an easy change so I propose this first draft with smaller set of features that should make sense and be aligned with the functionalities that we discussed should be part of Lite.
Suggestions regarding what should/shouldn't be in Lite BM are welcome as well as alternative names for it (although it should IMO contain
BeanManager
in it).