|
Description:
|
Injection into plain non-generic object types works, but injection into a wildcard injection point fails with exception.
Works:
{code}
@Inject
private UIInput<FileResource> resource;
{code}
Does not work:
{code}
@Inject
private UIInput<FileResource<?>> resource;
{code}
Exception:
{code}
org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [UIInputMany<Resource<Object>>] with qualifiers [@Service] at injection point [[BackedAnnotatedField] @Inject private org.jboss.forge.addon.shell.mock.wizard.MockCommand.values]
at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:405)
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:327)
at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:178)
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:209)
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:521)
at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:507)
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:482)
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:538)
at org.jboss.weld.bootstrap.api.helpers.ForwardingBootstrap.validateBeans(ForwardingBootstrap.java:75)
at org.jboss.weld.environment.se.Weld.initialize(Weld.java:144)
at org.jboss.forge.furnace.container.cdi.lifecycle.WeldAddonLifecycleProvider.start(WeldAddonLifecycleProvider.java:59)
at org.jboss.forge.furnace.impl.addons.AddonRunnable$1.call(AddonRunnable.java:77)
at org.jboss.forge.furnace.impl.addons.AddonRunnable$1.call(AddonRunnable.java:71)
at org.jboss.forge.furnace.util.ClassLoaders.executeIn(ClassLoaders.java:34)
at org.jboss.forge.furnace.impl.addons.AddonRunnable.run(AddonRunnable.java:70)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:680)
{code}
After talking with pete. This in itself would make sense, the problem (ambiguity) comes when the producer method for these types is such:
{code}
@Produces
@SuppressWarnings({ "unchecked" })
public <T> UIInput<T> produceInput(InjectionPoint injectionPoint)
{code}
This means that the generic type of the type argument itself is not defined, so it's not clear what the behavior should be here. Pete suggested defining multiple producers for things like:
{code}
@Produces
@SuppressWarnings({ "unchecked" })
public <T,S> UIInput<T<S>> produceInput(InjectionPoint injectionPoint)
{code}
{code}
@Produces
@SuppressWarnings({ "unchecked" })
public <T,Q,R> UIInput<T<Q,R>> produceInput(InjectionPoint injectionPoint)
{code}
This would allow use of Lists and Maps, and simple generic types effectively, but does not scale, as the possible combinations of allowed generics are infinite.
And I don't even know if this type of syntax is possible with Java generics. I have not been able to find the right incantation, so I suspect it is not.
|
