Skip to content
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.

Sign up for GitHub

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

auto-detect @Inject method parameter types #172

Merged
merged 1 commit into from
Mar 4, 2024
Merged

auto-detect @Inject method parameter types #172

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion junit5/src/main/java/org/jboss/weld/junit5/auto/ClassScanning.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -101,7 +101,7 @@ static void scanForRequiredBeanClasses(List<Class<?>> testClasses, Weld weld, bo
.forEach(cls -> addClassesToProcess(classesToProcess, cls));

AnnotationSupport.findAnnotatedMethods(currClass, Inject.class, HierarchyTraversalMode.BOTTOM_UP).stream()
.map(Method::getReturnType)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Honestly, I haven't understood the purpose of getReturnType as it was there before. I also can't find initializer method return types mentioned in the specs (https://jakarta.ee/specifications/cdi/4.0/jakarta-cdi-spec-4.0#declaring_initializer). Could it possibly have been a bug, here, to evaluate the return type or shall that be kept and if so what for?
It may not hurt if it works now, regardless of how the test is instantiated.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't understand it either and did some digging too - I think it's a bug/oversight from when the annotation based approach was added.
In CDI, @Inject usage on methods is basically either initializer or annotated constructor neither of which has interesting return type that we should process here.

.flatMap(method -> getExecutableParameterTypes(method, explicitInjection).stream())
.forEach(cls -> addClassesToProcess(classesToProcess, cls));

findFirstAnnotatedConstructor(currClass, Inject.class)
Expand Down
29 changes: 29 additions & 0 deletions junit5/src/test/java/org/jboss/weld/junit5/auto/InjectMethodParamTest.java
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
package org.jboss.weld.junit5.auto;

import static org.junit.jupiter.api.Assertions.assertNotNull;

import jakarta.enterprise.context.Dependent;
import jakarta.inject.Inject;

import org.junit.jupiter.api.Test;

@EnableAutoWeld
class InjectMethodParamTest {

@Dependent
static class Foo {
}

private Foo foo;

@Inject
private void setFoo(Foo foo) {
this.foo = foo;
}

@Test
void testInjectMethodParametersAreAddedToContainerWithNoConfiguration() {
assertNotNull(foo);
}

}
Loading