philippkunz commented on a change in pull request #28:
URL: https://github.com/apache/openwebbeans/pull/28#discussion_r439820083
##########
File path: webbeans-junit5/src/main/java/org/apache/openwebbeans/junit5/Cdi.java
##########
@@ -80,6 +81,15 @@
*/
boolean disableDiscovery() default false;
+ /**
+ * When present on a test method parameter, it will <em>not</em> be
attempted to be resolved with a CDI bean.
+ */
+ @Target(PARAMETER)
Review comment:
As I imagine two extensions at first glance, the existing Cdi and a new
CdiParameterInjections one, these would be heavily coupled in order to respect
and comply with all the cdi definitions. Or how could for example injecting the
same @ApplicationScoped bean instance be achieved without sharing the same
container or any other (too) tight coupling?
To the first point with the global toggle, I'm still having difficulty to
understand why it's necessary in the first place. As long as it does no harm,
fine, and I don't generally object it. But it would open the point about
`extensionContext.getParent()` again we already encountered earlier. At the
moment I would only see the option to scan through all super and enclosing
classes' `@Cdi` annotations which might not even always find a unique result
(and potentially resolving as well
> // todo: enhance the setup to be thread safe? see Meecrowave
ClassLoaderLock class and friends
on top of CdiExtension along the way).
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
