Closed x80486 closed 3 years ago
Hm, it seems like your project depends on org.jboss.weld:weld-junit5:2.0.2.Final
which brings in org.jboss.weld.se:weld-se-core:3.1.6.Final
and also org.jboss.weld.se:weld-se-shaded:4.0.0.Final
which is a shaded artifact that contains all Weld classes needed for Java SE: https://github.com/x80486/javase-cdi-weld/blob/master/build.gradle#L38-L40. And so the classpath probably contains multiple versions of the Weld classes (I have no idea how gradle handles this situation). In any case, the problem might be that Weld 3 is using Java EE APIs whereas Weld 4 depends on Jakarta EE APIs, i.e. the @jakarta.inject.Singleton
declared on SpellBookDao
might be just ignored because Weld 3 classes might be loaded first.
Hi,
you're seeing this issue because weld-junit
is currently built on top of javax
packages and therefore Weld 3.x.
It doesn't have a jakarta
-friendly version yet.
Martin is right that you are mixing versions, but even if you used Weld 4 everywhere, this wouldn't fly.
What you could do in the meantime is use Java/Jakarta EE 8 with javax
packages and use Weld 3. Then switch once we ship new major version of weld-junit
.
Anyway, we should fix that ASAP, I was actually thinking about it recently but didn't get to it yet, thanks for this reminder! Probably the only sensible approach is the same as with Weld - have two separate versions, each using a different namespace. WDYT @mkouba?
All right! Thanks for the tips! 🍹 — dangling dependencies are always a hassle.
Wouldn't be better if Weld publishes a BOM and we just need to import it as such, then the rest of the dependencies will get resolved correctly? Something like this:
implementation(enforcedPlatform("org.jboss.weld:weld-core-bom:4.0.0.Final"))
implementation("org.jboss.weld.se:weld-se-shaded")
testImplementation("org.jboss.weld:weld-junit5")
Weld already has a BOM which allows you to align dependencies inside Weld and CDI. However, it doesn't contain any information about weld-junit
.
I am not sure how much sense it makes to put it there - mainly because I cannot tell how common it is to use weld-junit
where you use Weld itself. Plus it basically introduces a circular dependency between these projects which I am pretty much against. But I see where you're coming from.
Martin is right that you are mixing versions, but even if you used Weld 4 everywhere, this wouldn't fly. What you could do in the meantime is use Java/Jakarta EE 8 with
javax
packages and use Weld 3. Then switch once we ship new major version ofweld-junit
.
I tried this approach and still get the same results. I guess I'm going to wait for the new update and will take it from there.
I tried this approach and still get the same results. I guess I'm going to wait for the new update and will take it from there.
That really should work, you probably have some misconfiguration is the test somewhere (like beans not picked up etc).
@x80486 version 3.0.0.Final should land in Central any time soon. Feel free to report back on whether you solved your issue :-)
Probably I have the wrong assumption(s) about how this work, but I'm getting the same results.
Anyway, this is what I'm thinking on how this is should work based on this guide:
org.jboss.weld:weld-junit5:3.0.0.Final
— this is going to use Weld 4.0.0.Final
weld-core-bom
on version 4.0.0.Final
and import org.jboss.weld.se:weld-se-shaded
— that's going to give me everything I need (alternatively, import org.jboss.weld.se:weld-se-core
instead of the shaded version and also jakarta.platform:jakarta.jakartaee-api:8.0.0
)@jakarta.inject.Singleton
or @jakarta.enterprise.context.ApplicationScoped
@EnableAutoWeld
Any field in that test class annotated with @jakarta.inject.Singleton
should be injected properly since @EnableAutoWeld
is going to take care about the bootstrapping and discovering.
I updated the project, just in case you want to take a look
@x80486 I took a look at your repo and here are some hints:
bean defining annotation
as defined here in CDI spec
@Singleton
is not a bean defining annotation and Weld follows that hence the unsatisfied resolution exception you are seeing@ApplicationScoped
will make Weld pick it up. Alternatively, you can annotate the test with @AddBeanClasses(SpellBookDao.class)
and your @Singleton
will be register as well.EntityManager
- this is because Weld scans the SpellBookDao
and discovers the type but it cannot automatically find the bean or rather its producer
@AddBeanClasses
@AddBeanClasses({SpellBookDao.class, EntityManagerFactoryProducer.class, EntityManagerProducer.class})
null
but that's some other problem unrelated to this framework at least from what I can tellLast but not least, in your case the @EnableAutoWeld
approach doesn't do much and you need to be more declarative in which case there is little difference between doing it this way and using just @EnableWeld
+ @WeldSetup
but in the end both approaches are viable and it is entirely up to you.
That's about all I can do to help :)
Wow...it works now! 🍹
I need to add the classes to the @AddBeanClasses
as you suggested — and also include the @ActivateScopes
. I was assuming it wasn't needed and the entire classpath was scanned. Anyway, it has to be selectively configured...not a big deal for the benefits that the library provides!
Thanks again for the tips and the effort! 🥇
Oh yea, I forgot to mention the scope as well.
BTW you can either enable it for the whole duration of the test (which is via @ActivateScopes
) or you can do it for the duration of certain bean method via @ActivateRequestContext
as described here in the specification.
I was assuming it wasn't needed and the entire classpath was scanned.
You could actually achieve this as well, but it is not the default behavior :-)
I have a small (Java SE
11.x
) project where I'm testing CDI with Weld. I have these dependencies (among others but these are the relevant ones for this issue):I have a simple POJO annotated with
@Singleton
and that's what I'm trying to inject in the test class:According to the documentation this should work in such way, but it always fails with:
I was wondering if this is a bug with this library or if there is anything else we should do to make it work? Notice that I'm trying to inject the fields in the class by using
@Inject
avoiding the use ofweld.select(...).get()
.This is the original (obligatory) question, with more details, in StackOverflow. Additionally, I have a project here that can be used to test this, just in case 😇